PEP0238 lament

[David Bolen]

barry at zope.com (Barry A. Warsaw) writes:

> >>>>> "DB" == David Bolen <db3l at fitlinxx.com> writes:
> 
>     DB> Thus, the very fact that the behavior is moving towards
>     DB> breakage may hold up people from moving for fear of the
>     DB> resource involved to ensure they don't have a problem, which
>     DB> in turn may prolong the period of time when such breakage is a
>     DB> risk.
> 
> If this is a real fear then you can never upgrade your Python, even if
> a new version introduces no language changes.

Well, that's an extreme - I think most reasonable people gauge their
concern about the upgrade based on what changes, and which of those
changes are new features or changed features, and what breaks existing
behavior.  I'm just suggesting (note the "may") that those that break
backwards compatibility may cause more hesistancy than new features,
and the paragraph was in response to the comparison to the change from
1.4 to 1.5 which I don't think had as much breakage (but am not
positive).

And sure, it's my responsibility to test as much of my system as I can
with all the intermediate releases (I keep them all on my development
machine) as they come out even if they won't get used in the field.

But I don't disagree with your general point - there's always some
risk involved in upgrading and you need to take that into account in
any system that you are working in that will evolve.

> But if this is really a fear then upgrading Python might not even be
> your biggest worry.  What if you upgrade some underlying library, or
> apply an OS patch, or add more memory, or a faster disk, or change to
> a new C compiler?  Any or all of those things may break your code or
> it may not.  I've certainly been victim to such "innocent" upgrade
> breakages.  So you still have to think hard about it, test
> aggressively, plan defensively, and cross your fingers.  Why would you
> upgrade Python any differently?

Agreed.  I don't think we discussing the overall process of upgrading
in this thread though, as much as how the specific change under
discussion might affect the variables (and planning, testing, etc...)
involved.

> But there's also no reason why Python should stagnate, or not fix its
> warts, or not evolve, so that /new/ applications or newer versions of
> existing applications cannot be written more elegantly, more
> succintly, or more maintainably.  No, new versions should not
> gratuitously break old code without some systematic migration plan,
> but that's what __future__ and the PEPs are all about.

I hope no-one is reading my commentary as suggesting that Python
should stagnate or in any other way not evolve, as I don't intend it
that way.  I do think it's worth highlighting that incompatible
changes need significantly more evaluation and weighing against the
compatibility cost involved with implementing them, than just new
features or forward-compatible bug fixes.

After writing my last post, it did also solidify in my mind that I
believe this division change is the first that struck me as one for
which the __future__ system is not as well suited, if only because
unlike other incompatible changes, once the future cycle time has
elapsed, the change is silent and permits old code to run incorrectly
without warning.  __future__ works well for something that is
incrementally introduced, with warnings for future failures, and then
real failures.  So you have to fix code during the future cycle time
or it'll break and not be usable.  But that's not quite true here.

--
-- David
-- 
/-----------------------------------------------------------------------\
 \               David Bolen            \   E-mail: db3l at fitlinxx.com  /
  |             FitLinxx, Inc.            \  Phone: (203) 708-5192    |
 /  860 Canal Street, Stamford, CT  06902   \  Fax: (203) 316-5150     \
\-----------------------------------------------------------------------/