What's so funny? WAS Re: rotor replacement

[Paul Rubin]

Skip Montanaro <skip at pobox.com> writes:
> What's your point?  That I have to download and perhaps install them to use
> them?  In that case, how are these two scenarios different:
> 
>     * I have to download and build the MySQLdb package to talk to MySQL
>       servers from Python code
> 
>     * I have to ensure that the readline library and include files are
>       installed on my system before the readline module (which is included
>       in the core distribution) can be built

The difference is that once Python is installed on your machine and
you can get a ">>>" prompt, you have readline available right away but
you have to download something to use MySQLdb.  Whoever took care of
your Python installation, and it may not have been you, also took care
of readline.  The past several OS distributions I've installed have
included Python and readline out of the box, so I never had to think
about readline.  The last time I used a Python instance that didn't
come with the OS (on Windows XP at work), the IT department had
installed Python on my desktop before I started using it, so I still
didn't have to worry about readline.  But any module that doesn't
come in the distro, I have to download myself.

> I and many other people happily use external packages other people have
> written as well as make stuff available.  My guess is that you do as well.

No, I don't.  I do use them sometimes but I'm unhappy about them.  If
I can write something using a core module instead of an external
module, I prefer to use the core module.  So I'll generally use dbm
instead of MySQL unless I really need MySQL, which I haven't yet in
Python (I've used MySQL with Perl dbi, but Perl, you know, shudder).

Also, external module installation scripts often don't work properly,
so I end up having to wrestle the code to get it installed.  And if a
geek like me has such trouble installing external modules, what hope
does a normal end-user have?  Maybe if you're using Windows, that
stuff has been debugged better, but I've had poor results under
GNU/Linux.

I've had this discussion here before, maybe not with you.  What I
really want is zero installations of anything.  I just want to go to
the store and buy a new computer and have a complete OS install with
full sources and a full set of applications including Python already
installed when I first power it up.  My practical approximation is to
buy a new computer, immediately reformat the HD to remove the icky
Redmond virus, and then install a GNU/Linux distro that includes
Python (and readline).  If Python really aims for world domination,
that means it has to shoot for being preinstalled on almost every new
computer the way Windows is now.  And all the interesting modules
should be there, maybe in a "contrib" directory that gets little or no
maintenance priority from the core team.

> If everyone adopted your position that it wasn't Python unless it
> had been added to the core, we'd all be reinventing lots of wheels
> or tackling much less challenging tasks, if we programmed in Python
> at all.  Here's an incomplete list of stuff not in the core I have
> used happily over the past several years to do my jobs using Python:

That makes no sense at all.  That list is a list of programs written
in the Python language.  They are Python programs, where Python is an
adjective.  Python, the noun referring to a piece of software,
generally means the stuff in the Python distro.  That doesn't stop
programs outside the distro from being useful.  Mediawiki is a PHP
program.  That doesn't mean Mediawiki is part of PHP.

>     * MySQLdb, Sqlite, pycopg, sybase-python - all database modules

These should all be in the core if Python wants to be a serious
competitor to PHP, which comes with interfaces for those db's and
several additional ones besides.  That these modules are missing are a
significant library deficiency.

>     * CSV, Object Craft's csv, DSV - csv modules predating csv in the core

That's fixed now, csv is in the core.

>     * SpamBayes

I have the impression this is an application and not a module, or
anyway is written mainly to support one application.  Should be
separate.  Also, it's written in Python(?) rather than C, which means
the installation headaches from not being in the core aren't so bad.

>     * Quixote

Don't know what this is.

>     * Docutils

Should be in the core if it's what I think it is.

>     * MoinMoin

Application, should be separate.  Also, GPL'd, I think.  Can't be
distributed under PSF license.  

>     * Pyrex

Sort of problematic, would be interesting to have something like this
in the core but maybe Pyrex as it currently stands isn't the answer.

I have the impression that PyPy is going to depend on Pyrex in a
fundamental way, so it will have to be in the core when we dump CPython.

>     * Psyco

I think this isn't ready for prime time yet.  Should go into the core
once it is.

>     * PyInline

Not sure what this is.

>     * PyGTK

wxPython might be a better choice.  wxpython.org quotes Guido as
saying "wxPython is the best and most mature cross-platform GUI
toolkit, given a number of constraints. The only reason wxPython isn't
the standard Python GUI toolkit is that Tkinter was there first".  I
don't have direct experience with either wxPython or PyGTK, though.
If I can get by with Tkinter, I'd rather do that, since Tkinter is in
the core.  

>     * xmlrpclib before it was in the core

1. Did you really need this, instead of some more reasonable rpc format?
   xdrlib has been in the core forever.
2. Isn't xmlrpclib written in Python?  

>     * MAL's mx.DateTime before the core datetime module was available

See, as Python improved, those things went into the core.

>     * timeout_socket before sockets supported timeouts

Could you use sigalarm instead?

> Many of those things I could never have written myself, either for
> lack of time, lack of skill or both.  I'm grateful they were
> available when I needed them and feel no qualms about using them
> even though they are not distributed with Python proper.

Sure, it's fine if you have all those modules and you write a Python
program that uses, say, five of them.  External modules aren't so bad
when the developer and the end user are the same person.  What happens
if you send your Python program to a nonprogrammer friend who has just
a vanilla Python installation?  Now he has to download and install
those five modules too.  You send him the url's where you got the
modules a year ago.  What are the chances that the 5 url's even all
still work, much less the chance of him being able to install and run
all 5 of the modules without needing help?  What if the versions he
downloads (from separate developers) have gotten out of sync with each
other and can't interoperate any more?  

If Python's maintainers are going to recommend those modules to people
as a substitute for providing those functions in the core, it would be
a big help if the modules were mirrored on python.org instead of
merely linked, since a lot of links turn into 404's over time.

> Notice another interesting feature of several of those items: csv,
> xmlrpclib, mx.DateTime, timeout_socket.  They were all modules I used that
> eventually wound up in the core in some fashion.  They didn't go in the core
> first, then demonstrate their usefulness.  It was the other way around.

I'm not sure about timeout_socket and it sounds like it should have
just been a patch to the socket module, not a new module.  csv is
quite a complex module and took a lot of tweaking and PEP editing
before standardization.  But the need for it was obvious; the only
good reason it wasn't in the core ages ago was that no one had done
the work of writing it and shaking it out.  xmlrpclib, not sure.  How
long was it in separate distribution?  Also, xmlrpc is a pretty new
protocol so it took a while before people wanted it.  DES has been
around since the 1970's and AES has about the same users as DES, so
there's a known level of demand.  That should be enough to say yes or
no to whether there should be a core module or not.

Also, your notion of trying to create a "category king" of AES modules
doesn't reflect how these things work.  There are at least 10
different AES modules that provide the same AES function.  If somebody
is using one, they have no reason to switch to another.  If it takes
20 visible users for including a module to be worthwhile, and those 10
modules have 5 users each, those populations are going to stay stable
until one of them goes in the core and becomes the standard.  (And
actually: mxCrypto is the most capable of these packages and might be
the one with the most users, but it's completely unsuitable for the
core because of its size).

> Not everything that is useful belongs in the core distribution.  I
> think you are confusing "batteries included" with "everything,
> including the kitchen sink".

Well, if you compare the Python stdlib with the toolkits that come
with competing languages, say PHP or Java, you can see that Python's
lib could be enhanced with considerably more stuff without being
excessive.