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

[Guido van Rossum]

> > Rip out the fancy behaviors of xrange that nobody uses: repeat, slice,
> > contains, tolist(), and the start/stop/step attributes.  This includes
> > removing the 4th ('repeat') argument to PyRange_New().
> 
> Eek... What do we have the fucking warning framework and deprecation
> warnings for, anyway ?!

For more important things?!

I posted the PEP about this, and I got mostly favorable or lukewarm
responses.  *One* person admitted they were using advanced xrange()
features now, but he said he wouldn't miss them.  The warning
framework and deprecation warnings are important for things that will
change the semantics of things *without* causing an error message
(like nested scopes).  They are also important for things that will
require lots of folks to change their code.

>From the responses to the PEP posting it doesn't seem like there are
many people using xrange() in non-idiomatic ways, so the latter risk
seems very small to me.

With the exception of the change to PyRange_New(), the changes here
will give people clear error message when they try to use the existing
features.  If you insist, I can change the signature for PyRange_New()
back and add a warning if the 4th argument is not 1, but I'm reluctant
there too.

> It may sound overly conservative, but I *really*
> don't like ripping things out just because you don't like them, without even
> as much as a release with a warning (and no, 2.1.1 can't have the warning;
> PEP 6 won't allow it.)

Of course not.

> You're basically telling people "You didn't use it the way I thought people
> would use it but never documented anywhere, so if you used them the way they
> are documented, you're screwed." Defense offers exhibit A: the
> standard library reference:
> 
> http://www.python.org/doc/current/lib/typesseq-xrange.htm:
> "XRange objects behave like tuples, and offer a single method"

Well, they never did behave like tuples (s+t never worked, and you
couldn't slice a repeated xrange object).  But more importantly,
(almost) nobody has used them as such.

> (Not to mention http://www.python.org/doc/current/lib/typesseq.html which
> *strongly* suggests all the operations in the table apply to range-objects
> as well as to strings, unicode strings, lists, tuples and buffers.)

I'll update this to explain that concat, repeat and slice don't work
for xrange() object.

> The API change also means binary and source level breakages... Is it
> really that much trouble to, just for *one* release, keep the
> functionality and just generate a warning when the 4th argument is
> something other than '1' ?

No binary breakage -- the 4th argument is normally 1 anyway.

The source breakage is easy to fix.

Again, the real point of the deprecation policy is not to *never* get
an error in old code.  It is to make sure that you don't get burned by
*silent* changes in semantics, and to make sure that *common* usage
that will stop working is caught.  Advanced xrange() is not common.
Calling PyRange_New() from C is not common.

> I can live (though not agree with, sorry ;P) the removal of xrange
> advanced features... just not from supported to *gone* in a single
> step.

Sorry, then you better commit suicide. :-)

--Guido van Rossum (home page: http://www.python.org/~guido/)