On Sat, Sep 05, 2020 at 12:44:47AM -0400, Cade Brown wrote:
First of all, you're comparing immutable value types to dynamic objects which are predicated and processed based on the memory address (e.g. for equality testing, by default). Of course they're going to have different semantics, especially when converting to a unique string representation.
What's your point here? There is no guarantee that `eval(repr(x))` must always return something equal to x, and one reason that isn't a guarantee is the difference between value types (whether mutable or not) and identity types. That's not the only acceptable reason though.
A better question to ask is why does it work for *almost* all values of 'float' , but not infinite ones... This is a glaring hole in my opinion.
That is a better question, but it's not a great question. Nor is it a glaring hole: Python is 30 years old, if this was an obvious lack that people need regularly, it would have been fixed years ago.
Unless you have thought of something new that none of the tens or hundreds of thousands of Python users over the decades have thought of, I think we can be fairly confident that this is at best a minor feature.
Python is a mature and popular language. Any "glaring hole" in the language is likely to be:
- a matter of personal preference or taste;
- something that has been ruled out due to backwards compatibility or because it doesn't fit the execution model;
- or something of such minor importance that nobody noticed or cared.
In the last case, it's not exactly *glaring* then.
Why do you think having 'inf' is better than something that means something to the python interpreter?
Not everything has to be a builtin constant.
If it's a keyword, there is the *very large* cost that it will break any code that uses Infinity as a name.
There's the opportunity cost: once we create an Infinity or Inf constant, then we're stuck with it forever, even if a better use for that name comes along.
There is the development cost: somebody has to do the work, write the tests, write the documentation.
There's the on-going bloating cost: every new feature increases the size of the language, the interpreter, the documentation, the time it takes to compile the interpreter, etc. A few milliseconds here, a few bytes there, it all adds up.
There's the cost to users: one more builtin that you have to learn, one more thing to know, one more choice to make, more questions for beginners to ask:
"What's the difference between float('inf') and Infinity?"
"Why is it Infinity not Inf?"
"Why is there no builtin NAN constant?"
You can argue that these are all *small* costs, and I agree. (Other than the backwards-compatibility breaking use of a new keyword, which alone would almost certainly rule this out.)
But, based on the discussion so far, the benefit is even smaller. If the costs are greater than the benefit, then adding an Infinity constant will make the language worse, not better.
Come up with an important, interesting use-case, and that balance could change. But consistency with other floats alone is not a very interesting or important reason.
There's no NAN constant either. Do you want that?
I've had countless times where I've had to Google how to create an infinite float, and second guessed myself because it is very unintuitive to have to call a string conversion to get what amounts to a constant.
x = Decimal('0.1') p = Path('/home/user/file') regex = re.compile(r'spam.*')
Does this mean that we need to have constants for Decimals, Paths, regexes, etc too?
I guess we need an infinite number of builtin named constants.
No? Then what makes infinity important enough to be an exception?
I'm sorry that you can't remember the basic idiom `float('inf')` or that you can import it from the math lib, even after googling it "countless" times. Perhaps you should write it on a postit note and stick it on your monitor?
I'm not being sarcastic. I've literally done that for other things I had trouble remembering.
The 'use case' is being able to specify a number which is constant, by a constant, and not requiring me to execute a function call.
That's not a use-case. That's a personal preference that literally boils down to "But I don't want to use a function call!".
But okay, you can get this by monkey-patching the builtins. Stick this in your PYTHONSTARTUP file, or the entry point to your Python applications:
import builtins builtins.inf = float('inf')
and now you can use `inf` as a builtin name everywhere.
It's not a keyword, but making Infinity a keyword would be even more costly, breaking backwards compatibility for very little benefit.
Further, keeping it the way it is harbors readability. Every time I parse code that contains `float('inf')` I ask myself why it is having to do this, because it seems like code shouldn't have to.
I think you mean "hinders", and I think that's a very idiosyncratic complaint. I think more people would be confused why Python makes Infinity a special built-in constant. C and Java don't.
Your argument seems to stem from the least possible Python can do (i.e. it doesn't HAVE to do anything more than it does currently).
This mailing list is python-ideas, which is for ideas currently not in Python. I am aware that nothing *has* to be done, I am merely suggesting why it would make sense to add, and why it would make Python a more complete, predictable and frankly 'prettier' language (albeit subjective). I don't see how any of your points address those concerns
Nobody is saying you are in the wrong for raising the issue. Only that you haven't given sufficient justification for this to go through the stages:
* an idea
* a good idea
* a good idea with consensus that we should do it
* somebody actually does the work to make it happen.
The truth is, for my own petty and personal reasons, I wish Python had INF and NAN builtins too. My own PYTHONSTARTUP file contains code to add them to the main namespace (I don't bother with putting them in builtins, because I only use them interactively). But I'm pretty sure I would be in a minority for that.
And that's the point of this list really. It's not about "What's best for *me*?" it's "What's best for the majority?"
It might help if you read this blog post by one of the senior devs:
I don't think that anyone disagrees that there are advantages to having a builtin Infinity. Only whether the advantages outweigh the costs and disadvantages.