[Python-Dev] Re: [Python-checkins] CVS: python/dist/src/Include rangeobject.h,2.16,2.17

Thomas Wouters thomas@xs4all.net
Sat, 7 Jul 2001 21:31:58 +0200

On Sat, Jul 07, 2001 at 02:14:31PM -0400, Guido van Rossum wrote:
> Yes, the lawyers have a way of scaring us all, don't they. :-)

I don't care about the lawyers, we have lawyers to do that (and they're
*good*, just look at the court cases we've won against all odds :) but I do
care about angry customers badmouthing the company I work for, which I like
to think isn't an ordinary one :)

> I hear clearly that you want the advanced xrange() behavior to
> generate a warning before I take it out.  I still think that's
> unnecessary, given that nobody in their right mind uses it.  But since
> people who are out of their mind have access to lawyers too, you can
> go ahead and restore the old code and stuff it with warnings.  Make
> sure to add a warning for every feature that I've taken out!

Great, thanx, I will, right after I cancel my lawyer's appointment. ;)

> (Do you think you'll need to add a warning to the __contains__
> implementation?  Taking that away doesn't change the functionality,
> but changes the *performance* from O(1) to O(n).)

I hadn't even noticed you took that one out... I can't say I see much point
in removing it, but I don't see a reason to add a warning for it.

> Regarding the yield statement: I'd love to require a future statement,
> but the current support for future statements doesn't support
> modifying the parser based on the presence of future statements, and I
> don't know how to resolve that, short of totally rewriting the parser
> or scanning ahead looking for a future statement with some regular
> expression.

Aha. Hrm... 

> Sobering thought: It's possible, given all the other changes that I'm
> thinking about, that it just won't be possible to make Python 2.2
> fully backwards compatible.  Should we rename it to 3.0?  Forget about
> the changes?  Label it as experimental and encourage ISPs to install
> it as an "alternative" version, only available by using "python2.2"?

Well... hrm... Iterators, generators and the type/class unification strike
me as more than enough reason to call it Python 3.0. Or we could ship 2.2
with iterators, but not the other features, warn against identifiers called
'yield' in that one, and ship 3.0 not long after. I have to admit I object
less to adding 'yield' without warning than removing advanced xrange
features, for two reasons: a new keyword breaks at compilation time, 
whereas missing xrange features appear at runtime, and secondly, I *like*
generators :)

A new parser that handles keywords more gracefully would also be an
excellent reason for a 3.0 version number :-)

> PS: I am beginning to believe that the ThreadingTCPServer /
> SocketServer problems reported on SF are serious enough to warrant
> fixing in 2.1.1.  I'll try to get to the bottom of it ASAP, but if
> someone else could look into this I'd be grateful too.

Unsure which problems those are, but I'll keep an eye open for it (I'm going
through the CVS logs, now that I figured out how to get them working, and
the SF bug/patch database in the coming week.)

Thomas Wouters <thomas@xs4all.net>

Hi! I'm a .signature virus! copy me into your .signature file to help me spread!