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

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 
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:-).