[Python-Dev] Python-3 transition in Arch Linux

Thomas Wouters thomas at python.org
Fri Nov 5 09:47:18 CET 2010


On Fri, Nov 5, 2010 at 01:43, Stephen J. Turnbull <stephen at xemacs.org>wrote:

> Thomas Wouters writes:
>
>  > To clarify (but I dont speak for the rest of #python, just myself), I
> think
>  > the move was premature, but I don't use Arch and I don't know what
> typical
>  > Arch users expect.
>
> All of the Arch users I know expect Arch to occasionally do radical
> things because they're the right things to do in the long run.  But
> every avant garde distribution picks up its share of wannabes who
> don't understand how the process works.
>
>  > The reason I think it's premature is that 'python2' just doesn't
>  > work everywhere, and I would have gone for a transitionary period
>  > where '/usr/bin/python' is something that screams loudly that it
>  > shouldn't be used before it executes 'python2'.
>
> This is unrealistic.  It would seriously annoy Arch's intended
> audience.  (Eg, recently I've become a lot more favorable to using
> Word instead of OOo because Word doesn't pop up a useless warning
> every time I save a .doc file.)  Practically speaking, it would have
> to be off by default, like Python pending deprecation warnings.
>

Wait, what? Warning about impending brokenness is *more annoying* than just
plain breaking? How on earth would the warning be "useless"?
Keep in mind that the warning would only show up *if stuff would otherwise
not work*.

Anyway, I bet that anybody capable of upgrading their *Arch* packages
> and complaining to *#python* about resulting breakage would be capable
> of complaining to #python about the weird warning about python2.  And
> you can't have a NO /USR/BIN/PYTHON topic, can you?<wink>
>

Any change is disruptive. My comment wasn't about the crowd of people
visiting #python and complaining, it was about the decision to change
/usr/bin/python, and how it was done. However, a warning with a clear
description -- for example, a link to a webpage explaining the situation --
would most assuredly have prevented many people from coming to #python in
desperation. They might still have *complained*, in #python or elsewhere,
but it would have been a lot clearer.


>
>  > As for #python, well, we got this storm of people utterly confused
>  > about how their stuff doesn't work anymore, and putting the blame
>  > in the wrong place.
>
> How so?  Ultimately, Guido is responsible for this.  Sure, the

immediate symptom was caused by Arch's action, but Python 3 *is*
> rather incompatible with Python 2.  You're going to get a storm every
> time a distro changes, and in a year or two, it's no longer going to
> be something you can dispose of by setting a hotkey to "Google for
> 'BOGUS Linux python'" -- it's going to be stuff that requires a real
> understanding of how Python 3 differs from Python 2, and often will be
> pretty subtle.


>  > I don't think a distribution should ever cause that (even though
>  > many do in lesser ways)
>
> Sure, and Guido should have exercised the Time Machine a little harder
> so that Python 3 never needed to happen.  IOW, this is the price of
> success and wide distribution.
>

No, that's not my point at all. The problem isn't that Python 3 is
incompatible with Python 2. The problem is that stuff broke without
(apparently) fair warning. This isn't a Python thing, this is a distribution
thing: for users of a distribution, having a clear, usable migration path
for incompatible changes is *important*. For users, not packagers, this
means you have to slap them in the face with upcoming incompatible changes,
or they won't notice. It may not be important for Arch, or for the users
Arch expects to have, but it sure as hell is important to me and every
sysadmin I know :)

-- 
Thomas Wouters <thomas at python.org>

Hi! I'm a .signature virus! copy me into your .signature file to help me
spread!
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20101105/65451594/attachment.html>


More information about the Python-Dev mailing list