[Python-Dev] Release Schedules (was Stability & change) (original) (raw)

Alex Martelli aleax@aleax.it
Tue, 9 Apr 2002 16:58:38 +0200

On Tuesday 09 April 2002 04:36 pm, Guido van Rossum wrote: ...

> This is http://python.org/sf/444708.

Which I'll reopen, because this is the first good use case for that suggestion I've seen. Alex is sounding much like me now (i.e., we've lured him over to our side :-):

Nolo contendere -- I was originally dubious on int/long unification (not negative, but dubious), but having tasted a little I do want more.

str() of some expressions will change, but it's "OK in a

str(23**45) is '18956258430116202791319715713277227626159289499745290235663543' in Python 2.2; how will it change? I must be confused -- I thought repr() could yet change, while str() already had for the int/long case?

minor release" since we can provide a nice way to deal with the effect. Never mind that code that deals with this in the traditional way will break silently (displaying numbers that are a factor 10 too small!), which IMO is worse than the worst effect of str(1==1) changing (at least that'll fail with an error when it fails). Not

Yes, I'll have to deal with the breakage in my old code (if/when I ever dust off my old bridge-research stuff, which I haven't had time to revisit in ages) -- I do have a few cases in which repr rather than str comes into play, assuming that's what's going to change (the str changes I had already dealt with, I think). (As str(somelist) uses repr on the items, I have this problem...).

I guess the difference is that I see very different magnitude and opposite signs in the conceptual effects of the two changes -- introducing booleans vs hiding int/long distinctions. The latter means leaving the problems of "how many bits does this number have" to rare, specific low-level uses, just as it should be. The former "fills a badly needed gap" IMHO. And for the costs, changing repr() seems slightly lesser -- had str(1==1) remained as '1' while only repr changed, I'd have accounted that as a fractionally lower (practical) cost for PEP 285.

So in the end it still comes down to total cost vs total benefit, where presumably reasonable people can differ on each of the two sides of the equation (and the decision is up to you), rather than absolute, objective rules.

that I disagree, but I expect that if this happens to break Paul Rubin's code (to use a random example :-), all hell will break loose.

Not everybody need be reasonable, of course -- being unreasonable used to be women's privilege, but we have equality of the sexes now:-).

Alex