What's so funny? WAS Re: rotor replacement

[Skip Montanaro]

    Paul> I've had this discussion here before, maybe not with you.  What I
    Paul> really want is zero installations of anything.  

Fine.  Go build a sumo distribution and track the normal CPython.  The
problem isn't all that new.  (Take a look at scipy.org for one take on that
theme.  Of course Linux distros have been doing their take on this forever.)

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

    Paul> That makes no sense at all.  That list is a list of programs
    Paul> written in the Python language.  They are Python programs, where
    Paul> Python is an adjective.

No, many of them are just modules or programming frameworks.

    >> * SpamBayes

    Paul> I have the impression this is an application and not a module, 

Yes, you're correct.

    >> * Quixote

    Paul> Don't know what this is.

Web app framework.

    >> * Docutils

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

Probably will be someday.

    >> * MoinMoin

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

Sure.

    >> * Psyco

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

It's getting close for those of us with Intel chips in our boxes.

    >> * PyInline

    Paul> Not sure what this is.

A module for inlining C code within a Python module.  Also see Weave from
the scipy.org folks.  It was inspired by the Perl Inline::C module.

    >> * PyGTK

    Paul> wxPython might be a better choice.  

Doesn't matter.  At work they decreed GTK as the GUI platform long before I
came along (they also use gtkmm for C++ apps).  It's still an example of a
broadly useful package available outside the core distribution.

    >> * xmlrpclib before it was in the core

    Paul> 1. Did you really need this, instead of some more reasonable rpc
    Paul>    format?

Yes, for several years I used a homegrown RPC solution behind the Musi-Cal
website that was Python only.  Eventually Mojam (a Perl shop) bought
Musi-Cal (a Python shop).  I switched to XML-RPC with little effort.  At one
point we also had Java talking XML-RPC.

    Paul> xdrlib has been in the core forever.

Sure.  But it's somewhat lower level than XML-RPC and isn't really an RPC
protocol.  It's just a marshalling protocol and is probably not as flexible
as XML-RPC at that.

    Paul> 2. Isn't xmlrpclib written in Python?  

Yes.  The implementation language is just a detail.  I also use Fredrik
Lundh's sgmlop library to accelerate XML-RPC and play some other games when
I know I'm talking Python-to-Python (marshal my args, then XML-RPC the
result passing a single argument between the client and server).

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

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

Sure, than that's what Martin has been trying to tell you about your AES
proposal.  Put it out there, refine it, and get it into the core when it's
mature.

    >> * timeout_socket before sockets supported timeouts

    Paul> Could you use sigalarm instead?

I suppose.  That's not the point though.  I'm not married to the concept as
you seem to be that something has to be in the core distribution to be of
use to me.  I'm perfectly happy incorporating solutions other people
provide.  I believe you will find I am in the majority in this regard.

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

    Paul> Sure, it's fine if you have all those modules and you write a
    Paul> Python program that uses, say, five of them.  External modules
    Paul> aren't so bad when the developer and the end user are the same
    Paul> person.  What happens if you send your Python program to a
    Paul> nonprogrammer friend who has just a vanilla Python installation?

I figure out some other packaging solution.  In my world most of the
software I write is for my employer, so this is not a problem I face very
often.  People use freeze, py2exe, py2app or other packaging solutions to
solve most/all of these problems.

    Paul> Now he has to download and install those five modules too.  You
    Paul> send him the url's where you got the modules a year ago.  What are
    Paul> the chances that the 5 url's even all still work, much less the
    Paul> chance of him being able to install and run all 5 of the modules
    Paul> without needing help?  What if the versions he downloads (from
    Paul> separate developers) have gotten out of sync with each other and
    Paul> can't interoperate any more?

This is the well-known "CPAN in Python" problem.  People are working on it.
Perhaps you would like to spend some energy helping solve it.  If so, join
the catalog-sig.

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

    Paul> I'm not sure about timeout_socket and it sounds like it should
    Paul> have just been a patch to the socket module, not a new module.

Sure, but a shim between the socket module and Python modules that used it
was a good first approximation to the problem.  (I am also a firm believer
in successive approximation to problem solving, especially when I don't know
enough about the problem to know precisely what form the final solution will
take.)

    Paul> csv is quite a complex module and took a lot of tweaking and PEP
    Paul> editing before standardization.  But the need for it was obvious;
    Paul> the only good reason it wasn't in the core ages ago was that no
    Paul> one had done the work of writing it and shaking it out.

Actually, there were at least two fairly mature implementations of CSV
modules out there before the PEP was a twinkle in anyone's eye.  The authors
of those modules got together and wrote the current PEP and module from
scratch based upon their collective experience.  I think the effort of
having a couple versions out in the field followed by joint effort to
produce something worthy of inclusion in the core is an excellent
demonstration of what Martin has been saying all along.

    Paul> xmlrpclib, not sure.  How long was it in separate distribution?

Not all that long.  XML-RPC itself hadn't been around very long before
Fredrik wrote xmlrpclib.  Both the protocol and xmlrpclib (as well as
similar modules for other languages) caught on pretty quickly.  

Skip