Hacker News Reader

Comment by vosper | Hacker News Reader

Maybe this should be obvious, but I don't have a computer to hand to try and figure it out: In the example for f-string interpolation, why does value have to be declared like this:

  value = decimal.Decimal("12.34567")

Why wouldn't this work?

  value = 12.34567

View on HN

The nice thing about Python is that aliasing is pretty easy to shorten tedious statements (while not being magical). If I had to write tons of those in code, I might say:

  D = decimal.Decimal
  x = D("1.2345")

Also (at least this was once true) by doing so you save Python from a dictionary lookup after the dot "." each time.

Or from decimal import Decimal as D

You could, but it's very unobvious. Unless you had it as a clear convention across the code base I'd imagine it would just lead to a lot of confusion.

Wait. This is extremely common to do in Python. If it really led to lots of confusion, I don't think it'd be that common.

What's common isn't necessarily a good practice to follow - https://google.github.io/styleguide/pyguide.html#Imports

By importing a function and assigning a 1 char alias to it, the readability of the code is impacted.

I'm a bit confused by your comment. From your link: > Use from x import y as z ... if y is an inconveniently long name.

"import ... as" is both common and per Google's style guide a good practice to follow in this scenario.

No, the Style Guide says "use imports for packages and modules only", which (alias or not) rules out importing single functions.

You're right. I wouldn't import a function as a single letter module if I was only using it once or twice, but I do think there's value in some cases. decimal.Decimal("1.2345") or even d.Decimal("1.2345") can be cluttering.

Going by the guide, you would do 'import pprint; pprint.pprint("foo")'...which, at least in my experience, I've never seen. It's always "from pprint import pprint" or "from pprint import pprint as pp" It could be that I work with slobs.

I don't think having a different view on the relative value of conciseness vs. visible name spacing than is at play in the Google Python style guide makes you a slob.

You find "decimal" to be an inconveniently long name? In my experience "import...as" is reserved for things like PowerIterationClustering and the like. The overriding principle is to always choose readability over succinctness.

Depends how often it's used. If you're just calling it once I wouldn't bother, but I was going off of makecheck's comment of, "if I had to write tons of those in code." I misread the style guide linked, I do find decimal.Decimal("12.34567") inconveniently long--but I generally don't mind inconveniently long names for increased intelligibility and the IDE does most of the heavy lifting. I don't often use "as" it's usually to increase the readability.

Similarly, I often see "from pprint import pprint as pp"

While I haven't used it with something as rarely used as Decimal, I almost always alias numpy and tensorflow to np and tf respectively. I find it cleans up the code drastically.

Those are common conventions for those particular libraries though.

Maybe so, but more obvious than what the grandparent wrote.

Because the latter is a floating point number syntax.

There could be an argument for switching to decimals as standard, but even ignoring the practical consequences, I think for historical reasons (I assume this is the standard of programming languages; in Ruby for example is the same) it's not something that will be ever agreed/changed.

Because that gives you a Float, not a Decimal.

Doesn't seem very Pythonic to me...

Every type-inference language I am aware of assumes that anything that looks like a float is a float. It would be un-pythonic to assume that everything that looks like a float is a decimal. Imagine having to cast every damn float to a float.

In Haskell: `2.3 :: Fractional t => t`

In other words, it can be inferred to be any type that implements the Fractional typeclass, which includes Decimal types. Not that it is relevant here, because you basically need to have types for something like this to work, if you have proper type inference, then you don't need to assume any type, and can just interpret a literal as whatever is needed.

Since when does an exact decimal literal "look like a float" more than it looks like a decimal?

Tradition. It was easier for computers and the rest is history.

Yeah, I was going to say, "Since computers."

Sure, lots but not all (Scheme doesn't, for instance) programming languages treat things that look like decimals as floats as a popular performance-over-correctness optimization, but I don't think that makes an exact decimal representation look like anything but a decimal.

The Python Decimal class was introduced 10 years ago in version 2.4. That's after Python was 12 years old (from v. 1.0). It is a standard library module, not a first level type. This is not the least unusual.

Even Swift, as modern as it gets, operates the same way. You are arguing against a convention that is as deep rooted as CPUs capable of floating point calculations.

To this day, there ARE no "decimal" CPU operations. There are integer and float operations.

Actually, I am arguing against describing exact decimal representation as something that "looks like a float" (particularly a binary float.)

I'm not arguing against Python's behavior. I do think that, at a minimum, there are major and very common software domains where the common optimization is more harmful than beneficial, and that it's good that some languages buck the trend. But while I don't think it should be an unquestioned tradition in language design, I don't think it's categorically wrobg, either.

> To this day, there ARE no "decimal" CPU operations

First, this isn't true, there are CPUs that have decimal (still floating point, so only exact within a subset of their full range) operations.

Second, it's irrelevant; many languages have types (including types for common literals) that don't map to a specialized class of operations in the CPU, where the language compiles operations down to aggregates of operations on some lower level type or types.

Since about 1972 when C adopted that as a convention.

Sure, I get the difference between float and Decimal, but why can't floats be formatted with precision in the example? Are they using Decimal because it's best practice, even though it adds more code to the string formatting example ?

Floats can absolutely be formatted, but the result may be unexpected, because it is basically a (hardware based) C binary float:

https://en.wikipedia.org/wiki/IEEE_floating_point

So, because users will typically be surprised that 2.2 + 3.1 results in 5.300000000000001, or that round(2.675, 2) gives 2.67 (instead of 2.68), best practice is to use Decimal, which will give users the results they expect:

https://docs.python.org/3/library/decimal.html

Makes sense. I guess what I was getting at is that introducing Decimal to the example about f-string interpolation makes the example more complicated than it absolutely needs to be, but I can see why they did it.

I think some of that extra complexity could be papered over with either making decimal() available like int() and float(), which would eliminate the import, and/or implementing a decimal literal format, such as 0d2.675, analogous to the format of Hexadecimal and Octal literals (0xCC00CC and 0o267, respectively).

I like that second idea, perhaps a mention on the python-ideas mailing list?

Perhaps. I need to mull it over a bit before I take that plunge (but thank you for the encouragement!).

One possible objection is that while Decimal is in the standard library, it isn't a built-in type, so either Decimals need to be elevated to built-ins, or some magic needs to happen when importing the decimal module to add the literal.

They used Decimal just to show the nested attribute access

Here's a practical example that comes to mind. I work in film and we deal with frame rates. Often tools use 24 or 30 frames per second. 30fps is a simplification of 60 frames interlaced, which is technically 29.97fps. The main use-case we have is storing, comparing, and occasionally flipping between fractions and decimals. You would think integers would work. We've tried to update our tools to use 29.97 when it is necessary (although, this spans Python, databases, and third-party applications). The first attempt used floats, but we'd have scenarios where we'd get 24.00001 or errors comparing two values. The second attempt just used strings for frame rate so comparisons and storage work and you have a lookup table when you need to convert. Decimal sounds like a better solution.

A similar scenario in film (that hasn't caused as much trouble for me) is aspect ratio, which is the height/width of an image. Fractions and decimals are used interchangeably in conversation.

Besides using decimals instead of floats for your frame-rate use case (definitely a better fit), using a Python fraction may be a more useful representation for aspect ratios:

https://docs.python.org/3/library/fractions.html

Also possibly useful in that context (and bringing us back full circle to the OP's subject), Python 3.6 has added the as_integer_ratio() method to Decimal instances:

https://docs.python.org/3.6/library/decimal.html#decimal.Dec...

Floats != decimals, and it's good practice to use Decimal I think.

It's not good practice. You must use Decimal when precision is important. Example: when dealing with currency, so arithmetic operations don't create or miss cents.

Reply on news.ycombinator.com