Discussion: Introducing new operators for matrix computation
Huaiyu Zhu
huaiyu_zhu at yahoo.com
Wed Jul 19 15:21:37 EDT 2000
This is good news! I'll make a summary of pending issues so we can have a
more focused discussion.
Huaiyu
On Wed, 19 Jul 2000, Tim Peters wrote:
> 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
>
More information about the Python-list
mailing list