[Python-3000] Namespaces are one honking great idea -- let's do more of those!

[Stephen J. Turnbull]

Mike Meyer writes:
 > On Thu, 07 Feb 2008 11:48:08 +0900 "Stephen J. Turnbull" <stephen at xemacs.org> wrote:

 > > I think this should be a separate tool, but either way I'd not object
 > > to making it easy to do, as long as it was not default.
 > 
 > And this is the real issue with your approach. If you're doing things
 > on systems you control, or where you're bundling in the python install
 > you're going to use, then we can do it however you want, and things
 > will be fine.

Please, give me some credit.  I'm talking about a default for systems
I don't control, but do want (a) to stop giving bad advice to and (b)
to stop abetting their bad practices.

So don't tell me that I'm mistaking my personal practices for a global
optimum.  I'm not.  I've thought pretty carefully about how this
applies in the context of presently widespread practices.

But now that you've put that fallacy on the table, let me point out
that it seems to apply to *you*.  It's just that lots of other people
have adopted the same global suboptimum, which makes it workable.  As
Opus the penguin says, "If a million people do the same stupid thing,
it is still a stupid thing."  Now, the "python" link is not *stupid*
in the context of the economics of networks, but we can do better, and
it won't cost much.

 > People building an app for distribution are going to want it to run in
 > an many places as possible. If the only name that python makes
 > available by default is "python", that's what they're going to use.

First, you're wrong, as you immediately pointed out yourself.  It's
not *Python-provided* defaults that matter.  It's the defaults
provided by common distro vendors, which for the market in question
dwarf installs from source as distributed by Python.

Second, my point is to change that default *and the bug-prone behavior
enabled by it*, so I'm not at all bothered by the fact that I'm
changing the default and thus am incompatible with bug-prone behavior.

 > Leaving things as they are leaves things as they are. If we're going
 > to break backwards comparability in the language, I think we should
 > try and improve this situation.

AFAICS my proposal *is* a technical improvement, in the sense that it
will work substantially better and at lower total cost in breakage,
debugging, and special-casing within communities that adopt it.  You
have made no argument against it except that it is a change and you
don't like change, and then you vastly exaggerate the likely annoyance
the removal of the "python" link creation step will cause, as well as
the potential for actual breakage.  True, it may get no uptake, and
then the small annoyances that will occasionally happen are for
nothing.  But the upside is quite large compared to the small
annoyances.

 > Adding an install target or tool to create version-specific links (of
 > any flavor) suggests a solution, but I suspect it'll be ignored by a
 > large percentage of platforms.

I doubt they'll ignore it.  They may decide not to implement it for
the reasons you gave (stipulated and omitted).  More likely, platforms
like Debian with its /etc/alternatives mechanism will find a way to
fit it into their existing alternatives mechanism.  Either way, if
Python adopts it for from-source installs, my proposal is compatible
with such systems.  If it works well, and as you suggest below app
vendors who use it press the platform maintainers (directly or through
customers as you suggest), platforms will adopt it -- we're talking a
couple dozen people who do watch each other and diffuse innovations
rapidly in the open source sector, and the proprietary vendors are
rapidly becoming more nimble (and watching the open source sector)
themselves.

 > Making the default install provide those links gives those developers
 > an expectation that they can use them. If some packagers breaks that -
 > well, the problem is that python on their system is broken. Yeah, some
 > developers will ignore the links and keep using "python". But some -
 > me, for instance - will provide a patch to users and tell them to
 > complain to the maintainers of that package for their system.

That's the way it's supposed to work.  I don't claim that my proposal
will be entirely painless, but it won't be very painful.  Application
developers who *do* use it can get benefits *without* any cooperation
from installed systems as long as users can install appropriate links
(or wrappers on Windows) on their executable search PATH.  The only
problem you'll face is if the systems are doing something really
insane like "ln -s perl5.8 python2.2".<wink>  And of course Python or
third parties can provide a link analysis tool for determining what
versions of Python are available and where the binaries live (eg,
borrow Zope's).