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.
Um, yes?
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.
On the other hand, Javascript and Julia do. So maybe you can find the
rationale they used for adding them, and if it applies here, Python may
do the same.
> 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).
Correct!
> 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:
https://www.curiousefficiency.org/posts/2011/02/status-quo-wins-stalemate.html
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.
--
Steve
_______________________________________________
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at
https://mail.python.org/archives/list/python-ideas@python.org/message/ZFMGHAARALKH2JQNRUEH7PE35GV2FA7D/
Code of Conduct: http://python.org/psf/codeofconduct/
