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.