Some Python 2.1 ideas

[Thomas Wouters]

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
with it.

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
PEP this.

> ----
> 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
get accepted.

> ----
> 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!