On Thu, Jul 05, 2001 at 11:07:32AM -0400, Guido van Rossum wrote:
> > > 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.
I'm sorry, but I have to disagree with this, and vehemently disagree.
Violently, even. Had I not taken the time to write this, it would have been
riddled with cusswords ;) I'll tell you why we disagree, though: we look at
Python from two entirely different angles. Let me try to explain mine, and
why it is *bad* to change something, even something that should be rarely
used, without warning.
You seem to argue from the belief that everyone installs their own Python
version, or upgrades by choice, being fully aware of all the changes it
carries with them. This is (unfortunately) probably true for most of the
Python users. I say unfortunately, because it means Python still hasn't hit
the main stream :)
XS4ALL is an ISP. We provide a bunch of services, like webhosting, machine
hosting, shell access, etc. We have something like 100k shell users, and 8k
webservers with CGI access, and all of them can use Python. Upgrading
anything in that setup is a bitch. Upgrading something that *might* break
'broken' customer code is even worse. We had a client threaten to sue us for
upgrading a Perl version where
close <FILEHANDLE>;
was changed from a warning into a (compile time) error. Nevermind that it
never did anything in the first place, suddenly their scripts generated an
HTTP error 500, without them changing anything. And believe me, when you
have 8k clueless companies hire wannabe-scriptkiddies to grab some Matt's
Scripting Archive perl scripts from the 'net and get them working the way
the company wants, you accumulate a *lot* of broken-but-barely-working code.
Upgrading something that might break *perfectly valid code* is a lot, lot
worse. The advanced xrange behaviour being gone in 2.2, as well as a 'yield'
keyword added (which you hinted at in a c.l.py posting) without future
statement, would make it practically impossible for me to upgrade Python
from 2.0/2.1 to stock 2.2.
I can't imagine it's any different for Gregor or any of the other
package/distribution maintainers. How are they supposed to provide a smooth
upgrade path if code breaks in silent and unobvious ways ? How can they
decide for their millions of 'customers' whether or not they should have
used xrange's advanced features ?? About the only thing I can think of that
people like Gregor and/or people like me can do, is revert the xrange change
and add warnings ourselves.
I'm sorry, but "it shouldn't have been used this way" is simply not enough
justification to rip something out without as much as a warning in advance.
Range-objects aren't broken now. They aren't blocking the advancement of
Python in any significant way like 'import *' and 'exec' were for nested
scopes. Adding warnings should not be that hard, or the warnings framework
is very broken. And I don't see why we bother with future statements and
warnings at all if we still won't give the guarantee that code won't go from
'documentation-correct' to 'silently-broken' in a *single release*. It
doesn't quite give the message that Python cares about backward
compatibility or code-stability at all, so why bother trusting it at all ?
Unfortunately, I can't decide *not* to upgrade Python either. One of our
customers once threatened to sue us for not upgrading GCC. (And, of course,
when we did, one of our other customers threatened to sue us for upgrading
GCC, because of the damned C++ ABI/API changes.) We've had (and still have!)
similar upgrade nightmares with F-secure SSH and OpenSSH, where you don't
really have the option not to upgrade if you care about system security. I
really don't need another package to worry about.
> 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.
Not for you, probably not for most people. But I don't trust my customers,
so I can't know what they do or what they rely on. But I do know that the
removal of the advanced xrange() behaviour is very silent indeed, and it
definately warrants a warning in a release before it is ripped out.
Especially because there seems to be no reason to remove it, other than "I
don't like it". Guido, I trust your language instincts; I know you are
probably right about the advanced features of xrange, and I would never try
to persuade you to do what you think is wrong, just supply my own opinion.
But in maintenance issues, both in a technical and in a PR sense, I trust my
own instincts a lot more than yours, and my instrincts are running around in
bright red bodypaint, smacking themselves over the head with cluebricks,
going "don't do it, don't do it".
> > 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. :-)
And leave you to finish 2.1.1 as well as 2.0.1 ? Hmmm. But I'll tell you one
thing: if you make me be 2.2 Patch Czar with xrange still lobotomized, I'll
have to consider that a bug and fix it the same week 2.2 comes out.
--
Thomas Wouters <thomas@xs4all.net>
Hi! I'm a .signature virus! copy me into your .signature file to help me spread!
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4