[Fwd: Re: [Python-Dev] Introducing new operators for matrix
Fri, 14 Jul 2000 15:04:52 -0700 (PDT)
I like this idea as well. I only need to clarify two things:
1. Is this available right now? Where to get it?
2. Will this be guaranteed to be compatible with future development of
My doubt is: If this is the case why the augmented assinment needs to be a
The development of MatPy has been quite rapid since it started over a month
ago. Right now we are ready to go into feature addition phase that will be
even faster. The only uncertainty is what operators we will have. We got
our own patch yesterday. We'd like to settle on this very quickly.
Once these are settled, we'll just included it in the MatPy distribution.
After we get enough usage the whole NumPy-MatPy packages might be included
in core python just as string or re.
Given that there is a conference next week, perhaps we can't fix it in a
week. But we'll decide soon after that.
I will not argue any more here about how many new users python may attract
with matrix. With proper tools I would be able to prove by fact.
Although we seek the core developer opinions here, we do not really need
approval to go ahead. But the danger is that a bad choice may stuck with
python for ever when this thing gets incorporated into main distribution.
Switching the meaning of the operators would be almost completely
impossible, unlike the regex and re case. So even if you don't make use of
matrix now, you might still want to give a thought on how it should be done.
On Fri, 14 Jul 2000, Paul Prescod wrote:
> I like this idea!
> -------- Original Message --------
> Subject: Re: [Python-Dev] Introducing new operators for matrix
> Date: Fri, 14 Jul 2000 14:02:36 -0400
> From: Andrew Kuchling <email@example.com>
> Reply-To: firstname.lastname@example.org
> To: email@example.com
> References: <Pine.LNX.firstname.lastname@example.org>
> On Fri, Jul 14, 2000 at 01:36:20PM -0400, Eric S. Raymond wrote:
> >Huaiyu Zhu <email@example.com>:
> >> This is not a call for a special language for matrix only. But we do need
> >> enough binary operators to override with. The additional operators might be
> >> useful at other places as well.
> >I agree that supporting user-defined syntax threatens to fragment the language.
> >To avoid that, perhaps it would be best to leave what are in effect
> >user-definable hooks in Python's lexical space.
> Huaiyu Zhu thinks that better matrix operators will attract a
> significant new of new users; I'm doubtful of this claim. We're both
> just guessing, since neither of us has actual evidence to support our
> respective points of view. Given that uncertainty, there seems little
> impetus for adding new operators; Python will have to live with them
> for a long time, even if the matrix work withers after a short time,
> or never really catches on.
> It should be possible to try out new operators *right now*, with no
> core changes. I believe Jeremy's compiler code, written in pure
> Python, can parse a module and generate the corresponding bytecodes.
> Therefore, you could take that code and hack it to support 'a .| b',
> by generating equivalent code to a.__dotbar__(b), or whatever. The
> only visible difference is that some error messages would be obscure;
> 2 .| 1 would get a '2 has no attribute __dotbar__' exception; this
> isn't significant.
> So, rather than add a whole bunch of new operators to the core, I'd
> first want to see the alternative syntax implemented through a hacked
> parser and *in use by a significant community*, and then we can
> consider what bits from it to add to the core.
> Python-Dev mailing list