Sleeping in the same room with Guido for a night did not make it easier to
channel him, but it did make it easier to cloud his mind: Guido is not
opposed to adding new operator symbols to core Python. As of breakfast
Tuesday, anyway, and there are witnesses, so he'll have trouble changing his
mind (well, it will be clumsy for him to *admit* it if he changes his mind
<wink> ...).
But but but (you knew it wouldn't be *that* easy!):
+ Everybody concerned that new operators are "not Pythonic" please swallow
it -- it is Pythonic, cuz Guido said it is <0.9 wink -- but see following
points too>. Contribute by helping to come up with a complete and
Pythonically beautiful implementation instead.
+ Please keep this off of Python-Dev. Doesn't belong there (at least not
yet). Interested parties can form a mailing list, or try to discuss it on
comp.lang.python (my personal hope is that you try the latter, and stick to
one Subject line).
+ There *must* be a PEP for this. Guido won't read any more of the
debate -- it's too voluminous, repetitive and contentious. He'll eventually
read a PEP, though, *after* some sort of consensus is reached. A PEP
requires a champion. I hope Huaiyu Zhu volunteers for this, as he's argued
his case eloquently and rationally. The champion doesn't need to know how
to implement it, but does need to summarize sometimes-opposing positions
dispassionately.
+ There are things Guido will & won't tolerate. Guessing which is an
interesting & educational challenge <wink>. For example, adding a new
operator like
.+
is fine, as the maximal-munch rule for lexing can resolve formal ambiguities
easily. OTOH, *any* new operator symbol containing a backslash is dead
before arrival -- backslash has purely "meta" meanings in Python today. If
the goal is to make Python look exactly like some other language, forget it.
It's still Python, with some light syntactic sugar to make life in special
domains sweeter.
+ This one is from me, but it's a safe bet you can view at as precognitive
channeling if you oppose it: anyone suggesting to, e.g., make ".+" mean
something new and exciting for ints or floats or strings or ... will be
shot. There are probably no operations on the builtin types used frequently
enough to merit new syntactic shorthands (excepting, perhaps, that if P3K
changes the meaning of integer division, a new "//" operator for flooring
division was looked upon kindly in the past). The new operators are for
convenience in special domains (where the case for them is indeed very
strong), not an excuse to turn current Python into a cryptic mess.
+ Also from me: forget about user-defined precedence and associativity.
The PEP must define these once & for all, and that's that.
+ The set of new operator symbols cannot be open-ended (as it is in, e.g.,
Haskell). There are at least 4 variants of Python tranlators already in
existence, and Guido wants the set of operator symbols fixed so that a
variety of parsing techniques can be used in their natural forms without
trickery. IOW, the full set of operator symbols must-- as it is today --be
a fixed finite set known in advance.
+ If the numerical folk can't reach consensus on the set of operators and
what they should mean, my bet is that Guido will let this die rather than
get sucked into Pronouncing on each of the points in dispute. After all, he
has little personal use for this stuff: if the people who *do* want it
can't agree, it's not worth having.
how's-that-for-a-mysterious-announcement<wink>?-ly y'rs - tim
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4