Some Python 2.1 ideas
thomas at xs4all.net
Sat Dec 23 15:21:59 EST 2000
On Sat, Dec 23, 2000 at 09:00:25AM -0800, Bob Alexander wrote:
> New operator: embedded assignment
Not very likely. It would mean changing assignment from a statement to an
operator (you can do that without actually introducing a new operator, by
the way, if it wasn't for the =/== confusion issue.) I looked at something
slightly similar while doing the augmented-assignment work (a
'content-filling' statement, ':='. The main difference with '=' being that
it would allow container objects to provide their implementation of '=', and
it wouldn't actually re-bind the name.) I didn't really like it myself,
though, and it was out of that particular scope, so I didn't do anything
However, I doubt an *operator* doing assignment would be accepted by Guido.
It goes against several of Python's implicit and explicit guidelines (one of
them being 'Guido should like it' :) Of course, stranger things have
happened. As the purpose of PEPs is to close discussion on issues such as
these once and for all, one way or another, it's not a bad idea at all to
> Variations on "for"
> Here are some possible additional forms of "for" that seem appealing:
> Allow slice-like syntax as shorthand for xrange():
> for i in 10: # equivalent to "for i in xrange(10)"
> for i in 5:10: # equivalent to "for i in xrange(5, 10)"
> for i in 20:10:-1: # equivalent to "for i in xrange(20, 10, -1)"
The 'range-literal' proposal (also one of mine ;) was rejected after being
on the "check this in when you're ready" list for a while. In fact, if Guido
had had those second thoughts a couple of days later, they might have made
it anyway :-) In any case, one of the reasons it was rejected was because
the slice-like syntax is just a bit *too* confusing. It looks a lot like
slicing, but it isn't, really, due to small details, and that makes it a bad
idea. (Strange as it may seem, that is actually my opinion too, and I don't
regret one bit that the range-literal proposal was rejected.)
Funnily enough, I also implemented the 'indexing-for' almost-PEP (which was
written by Just van Rossum, but not accepted as a PEP) which was rejected
because of uhm, one reason or another. Mainly the Guido-line above. I have
since considered proposing
for i in <x> .. <y>:
(or perhaps three dots instead of two) as an alternative to the
'indexing-for' syntax, but I wanted to catch Guido in a sufficiently good
mood to try it. And perhaps I should first have a public fight with Just,
just so show that I'm not conspiring with him :-)
Guido may disagree, but I still believe the idea behind PEPs is to stop
discussion of closed issues (or waiting-for-implementation ones) and you
can't do that if you only PEP subjects that have a chance or two in hell to
> String method to remove trailing newline
> <string>.chomp() # sorry, borrowed the method name from Perl
This suggestion I kind of like. Not the method name, though, since it
implies the string itself is modified (which it can't, as you should all
know ;) I don't know howmuch of a chance this method has, but it *is* an
often requested function. This is just the first time I've seen the request
phrased as a string method rather than a string module function :) I
personally don't have Python code that needs something that strips newlines
but not trailing whitespace, but there is probably code that does.
Thomas Wouters <thomas at xs4all.net>
Hi! I'm a .signature virus! copy me into your .signature file to help me spread!
More information about the Python-list