What's so funny? WAS Re: rotor replacement

[Paul Rubin]

Skip Montanaro <skip at pobox.com> writes:
>     >> * Quixote
> 
>     Paul> Don't know what this is.
> 
> Web app framework.

I think Python should add a web app framework to its core, again since
it otherwise can't seriously begin to compete with PHP.  However,
there are lots of approaches so this is an example of where your
suggested process of letting a bunch of different implementations
circulate before choosing something is a good idea.

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

Hmm, sounds like it has the same issues as Pyrex.  I'm also not sure
why you'd want both PyInline and Pyrex.

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

Can't wxPython use GTK?

> It's still an example of a broadly useful package available outside
> the core distribution.

I'd say if access to GTK is widely important functionality, then the
core should provide it in some way (e.g. through wxPython) and that's
enough.  If your company wants some different (i.e. nonstandard, if
wxPython becomes the standard) form of access, then it can deal with
the consequences of not following standards.

>     Paul> 2. Isn't xmlrpclib written in Python?  
> Yes.  The implementation language is just a detail.

I think it's more than a detail.  If an external module is written in
Python, I can download it from wherever and include it with my own app
that I send to an end user.  I do the work so the end user doesn't
have to.  If it's written in C, then the end user has to deal with it.

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

What kind of refinements are you envisioning?  This isn't a web
application framework we're talking about.  It's more like the sha
module.

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

So aren't you happier when the other person provides you with a
solution that installs with one command, instead of a solution that
requires you to download N different modules from who knows where, and
install them separately, all while hoping that they haven't been
tampered with?  If I'm trying to provide someone else with a solution,
I'd rather use sigalarm than make the end-user download an extra
module, because I think they'll be happier that way.

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

Only those people who think that a cross-platform application is one
that works on both XP Home and XP Pro.  That does simplify some
things.  Life in a cult is often indeed simpler than life in the real
world <wink>.

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

Yes, CSV is complicated and benefits from that process just like
web app frameworks do.  Let's pick another example, the hmac module
that appeared in Python 2.2.  It implements the RFC 2104 HMAC algorithm.

Where are the two mature implementations that circulated before the
hmac module was added?  Where were the authors pooling their
collective wisdom?  Where was the year of user feedback?  The answer
is, nothing like that was needed.  HMAC is simple enough for a module
author to read RFC 2104 and implement what it says, run some tests,
and declare the module good to go.

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

Martin is saying the opposite: that he doesn't understand the point of
writing a new module that synthesizes from experiences with old
modules, instead of just using one of the old modules.

I don't think there's a one-size-fits-all answer to any of these
questions.  You have to have your hands in the details of a specific
problem, to arrive at the best way to deal with that problem.