Discussion: new math operators
R.M.Everson
R.M.Everson at ex.ac.uk
Mon Jul 24 08:59:23 EDT 2000
Neil Hodgson <neilh at scintilla.org> wrote:
>> As one of the more reactionary Pythoneers with regard to syntax
>> changes and as someone who is unlikely to ever need to use the
>> new operators, I say the braced operators are the best.
Huaiyu Zhu <hzhu at knowledgetrack.com> writes:
> I just posted a summary that dismissed this idea before seeing
> recent two posts favoring brace based operators. It's becoming
> increasingly obvious that most discussants here favor this. Yes,
> I agree with all the advantages of this.
> Now the questions are:
> 1. How do we test reactions from people who do not read this
> thread? Anyone volunteer to give a try?
> 2. How important does the possible future extension play in this?
> What considerations should be put in this?
> 3. If there could be future calculus of operators, would we now
> favor (*)=
> or (*=) for augmented assignment?
I've been following this thread for a while. As a Matlab user, I am
quite comfortable with the .op notation and could certainly live with
the @op variant, although I prefer ~op as being less dense and
P***-ish. These have the (distinct) advantage of being quite
straight-forward to implement in the very short term.
However, I certainly agree with the arguments for (op) except in one
respect. As Huaiyu demonstrated in an earlier post, I find that style
very difficult to parse visually, particularly anything involving
parentheses to group expressions. Easy visual parsing is a
prerequisite for this sort of application where there is a good deal
of interactive, exploratory development: it's one of the things that
makes Python (and Matlab) a pleasure.
Most of the confusion arises because () are already over-used (for
grouping, forcing precedence, enclosing tuples, enclosing function
arguments, and probably more). How about a different pair of
delimiter characters to enclose the operator? I would rule out {} and
[] as they also have quite specific meanings already.
That leaves <op>
Two possible objections:
1. Ambiguity with greater/less than. I haven't thought of any
situations that couldn't be resolved by a decent parser.
2. It looks a bit like bra and ket, but isn't.
I would greatly prefer this syntax to (op).
Richard.
--
Richard Everson.
Department of Computer Science, Exeter University Voice: +44 1392 264065
R.M.Everson at ex.ac.uk Sec: +44 1392 264061
http://www.dcs.ex.ac.uk/academics/reverson Fax: +44 1392 264067
More information about the Python-list
mailing list