eg:

from price_parser import Price

# ok
price = Price.fromstring("¥36,000")
print(price)
# Price(amount=Decimal('36000'), currency='¥')

# not ok
price = Price.fromstring("36元人民币")
print(price)
# Price(amount=Decimal('36'), currency=None)

Hi,

I came across this example:

In [14]: Price.fromstring("2 pairs from $349", decimal_separator=".")
Out[14]: Price(amount=Decimal('2'), currency='$')

given we consider extracting currency as $ would it make sense to handle this case inside price parser?

First of all: Nice library, thanks for creating it.

For converting between major currencies it would be nice to have the ISO 4217 code of the parsed price (EUR, USD, AUD, ...) as this is easier for handling exchange rates.

Is there any plan to support that?

from price_parser import Price
print(Price.fromstring('3.350').amount_float)
print(Price.fromstring('3.3500').amount_float)
print(Price.fromstring('3.35').amount_float)
print(Price.fromstring('3.355').amount_float)

Results:

3350.0
3.35
3.35
3355.0

• python 3.8.6
• price-parser 0.3.4

'$ .75' is incorrectly parsed as 75

I have an example:

price = Price.fromstring("122$")

Is possible to get the USD as currency instead of $?

Some store show price with non-break space and parser return None.

These examples:

Price.fromstring('180', currency_hint='$${product.price.currency}')
Price.fromstring('180', currency_hint='qwerty $')
Price.fromstring('180', currency_hint='qwerty $ asdfg')

All of them return Price(amount=Decimal('180'), currency='$').

From what I understand in the code, this happens in _search_safe_currency:

_search_unsafe_currency('asd $ qwe')
# <re.Match object; match='$'>

Would it be in the scope of the library to match the currency more strictly?
This would cover the use-case when we are pretty sure that the currency hint is exact, not fuzzy.

When I type:
Price.fromstring("Today I buy 3 coats with 300.000 VND")
Your library returned:
Price(amount=Decimal('3'), currency='VND')
but the result I want is: Price(amount=Decimal('300.000'), currency='VND')

Currently the price-parser library call only extract prices and store them with it's currency tag. I would like to propose the ability of converting one price to another. If this proposal is approved I would start working on the idea.

E.g.

price_parser.parse_price('0.99¢')  # currency is not returned
price_parser.parse_price('0.99c')  # currency is not returned

The program sees the following string:

New (8) from $93.99

As 8$

The lists of supported Python versions are not up to date and are also different: I see the tests run on 3.6-3.10, the setup.py metadata declares 3.6-3.8 support, and the currently supported versions should be 3.8-3.11.

I tried to test the library on this:

from price_parser import parse_price
parse_price("The price of 2000 plates is $13,004")

Output:

Price(amount=Decimal('2000'), currency='$')

It's unable to understand the context. I have gone through the code in parser.py, it's using regex to extract prices as well as the currency symbol.
Could you please share the vision of creating this library?

1. Was it to process a column of a database that contains the prices like this:
   

This way it can definitely resolve the minor human errors and help data scientists while preprocessing.

Or
The plan was to create a library that can extract prices from normal text like this:
"The price of 2000 plates is $13,004"?

Does it makes sense to return a Price instance with currency set and without a price value?

Actually if we have a substring inside a string that matches with an existing currency, it will be returned even if we are not mentioning the currency:

In [1]: Price.fromstring("STRING WITH NO PRICE BUT HAS A WORD THAT CONTAINS PART OF A CURRENCY NAME: EUROPE")
Out[1]: Price(amount=None, currency='EUR')

This happens because we use regexes to match the currencies inside a string. But this approach would create a problem when single-letter currencies is handled better (#3) .

I can see two options to handle this scenario:

1. Consider as currency only if the substring is surrounded by whitespaces:

In [2]: Price.fromstring("SOMETHING EUROPE SOMETHING")
Out[2]: Price(amount=None, currency=None)

In [3]: Price.fromstring("SOMETHING EUR SOMETHING")
Out[3]: Price(amount=None, currency='EUR')

2. Consider as currency only if the entire string matches exactly with the currency name:

In [4]: Price.fromstring("EUR")
Out[4]: Price(amount=None, currency='EUR')

In [5]: Price.fromstring("SOMETHING EUR SOMETHING")
Out[5]: Price(amount=None, currency=None)

The API does not handle negative values:

from price_parser import Price
def test_price_parser():
    value = Price.fromstring("R$ 1,00")
    assert value.amount_float == 1.0

    value = Price.fromstring("R$ -2,00")
    assert value.amount_float == -2.0 # Fails

parse_price("12,999.00 ر.س.")
Price(amount=Decimal('12999.00'), currency=None)

price = Price.fromstring("1,234,567.890")

it should be

Decimal('1234569.890')

is

Decimal(1234569890)

Sometimes values like 140.000 can mean 140, not 140K; this happens when e.g. website authors put price in semantic markup with 3 digit precision. It looks like the only way to fix it is to allow customizing price extraction; e.g. it can be fixed by having "decimal_separator_hint" argument for price parsing functions, which one can pass for these "bad" websites.

Some expectations:

>>> parse_price('$ 4 millones')
Price(amount=Decimal('4000000'), currency='$')
>>> parse_price('$ 400 mil')
Price(amount=Decimal('400000'), currency='$')
>>> parse_price('1.45 milliards INR')
Price(amount=Decimal('1450000000'), currency='INR')
>>> parse_price('115 millions de dollars (estimation)')
Price(amount=Decimal('115000000'), currency='dollars')
>>> parse_price('Drei 000 000 $')
Price(amount=Decimal('3000000'), currency='$')

When type checking with MyPy, an error is thrown when using from price_parser import parse_price, namely:

Module "price_parser" does not explicitly export attribute "parse_price"; implicit reexport disabled

I suspect this is due to the entities not being defined in __all__

First of all, thank you for creating it. it scales very well. overall nice library.

I came across this issue when currency value has E notation.
Ex:

from price_parser import Price
Price.fromstring("3.891506499E8")
> Price(amount=Decimal('3.891506499'), currency=None)

Dates like July, 2004 or 15.08.2017 should not be parsed as prices, we should detect them and return amount=None currency=None.

Currently amount of items may be picked as a price, instead of the price number:

In [5]: Price.fromstring('3 Ausgaben für nur 14,85 EUR')
Out[5]: Price(amount=Decimal('3'), currency='EUR')

In [6]: Price.fromstring('Buy Now - 2 Litre Was $120.00 Now $60.00')
Out[6]: Price(amount=Decimal('2'), currency='$')

I think making price-parser to prefer numbers close to currency symbol (instead of taking the first one) may help to fix such cases - maybe not all of them, but at least some.

Currently CI looks broken, it is not running on pull requests.

As stated in the title, if you have a number for example ",89" or ",89 €" it will be parsed as "89" instread of "0.89" which would be the correct value

Some of the single-letter currencies are not picked up:

In [7]: Price.fromstring('R273.00')
Out[7]: Price(amount=Decimal('273.00'), currency=None)

In [9]: Price.fromstring('61.858 L')  # Romanian New Leu
Out[9]: Price(amount=Decimal('61858'), currency=None)

We should support them. The main issue is that they're ambiguous; we should be careful not to pick e.g. L or R letter from the extra text appearing in price string passed.

I wanted to contribute to this repo. Tried to install it manually using the python setup.py develop and python setup.py commands but it gave me errors.

I noticed that for the Swiss Franc (CHF) for values above 1,000, the notation CHF 1'000 is used.

parse_price("CHF 1'200.20")
Out[27]: Price(amount=Decimal('1'), currency='CHF')

Korean, and Japanese uses each specific money character like '₩', '￥'.
But that country also using their text based money character to represent currency.
Korean uses '원', Japanese uses '円'.
but this parser can't parse that character.

Thank you.