Chris Angelico writes:
> Not to mention everyone's keyboards. Python != APL. Err, I mean,
> Python ≠ APL.
I am really tired of this argument.
set() is not going to go away. And it's easy enough to install
input methods (aka "keyboards") on any modern system that allow you to
enter these if you want to. Most programmer's editors allow you to
define abbreviations that will do the same. It's just not that hard
if you want to do it, and there's no way forcing you to do it will
make it past the backward-compatibility requirement.
I'm perfectly happy with the TOOWTDI/YAGNI argument: you don't buy
much clarity with ∅ over set(), with math.π over math.pi, or λx: x
over lambda x: x, so let's just don't.[1]
But let's not introduce the purely English native problem of
undeveloped muscle memory when we're discussing whether Python should
allow these aliases (and aliases they have to be for backward
compatibility). On the flip side of the TOOWTDI argument, I'm pretty
sure most programmers will have no trouble understanding any of the
aliases mentioned above. Sickly sweet syntactic sugar, yes, but not a
barrier to understanding.
Since many of the usual identifiers actually work already:
>>> import math
>>> π = math.pi; π
3.141592653589793
>>> τ = math.tau; τ
6.283185307179586
>>> γ = math.gamma; γ(1)
1.0
we are going to start seeing them. I'm -1 on putting these in the
stdlib; programmers who want to do this can do it already. I don't
think that fact that
>>> γ
<built-in function gamma>
uses the English spelling rather than the Greek letter is a big deal,
and isn't justification for adding them to the stdlib.
To me, the question here is if we should enable this compact,
traditional mathematical style for those who want it in their own code
by
(a) special-casing some characters that are "mis-classified" by
Unicode, such as ∞ and ∅, or perhaps
(b) add a function that allows users to override the Unicode standard
classification and add these characters to the set allowed in
identifiers.
lambda is a different issue. We'd have to special-case the Greek
letter version and probably add it to the grammar, so that's pretty
clearly out on TOOWTDI/YAGNI grounds IMO.
Note that (b) might induce a security issue since depending on
implementation it could allow overriding compatible and confusable
normalization. I don't think we do such normalization, but if we do,
that would be something to think about.
Steve
Footnotes:
[1] It's amusing that lambda is a binding *operator* in Python (thus
the lack of a space in "λx" above), but "λ" is not an operator in
Unicode -- the opposite of the issue with "∅", except that you can't
add operator symbols in Python so aliasing by the user can't work anyhow.
_______________________________________________
Python-ideas mailing list -- [email protected]
To unsubscribe send an email to [email protected]
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at
https://mail.python.org/archives/list/[email protected]/message/VSSB4HTCH3O6IRGKBDRI7FGIHN4O6OUT/
Code of Conduct: http://python.org/psf/codeofconduct/
