Discussion: Introducing new operators for matrix computation

[Huaiyu Zhu]

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
>