[Web-SIG] Re: Just lost another one to Rails

[Ian Bicking]

Martijn Faassen wrote:
> There are a ton of non-core XML frameworks around for Python, enjoying 
> considerate popularity. The python 'xml' package is not the "one true 
> way" to do XML with Python, and certainly doesn't enjoy anything near 
> the popularity and buzz of Ruby on Rails, say. I don't see why the 
> situation for any higher-level web framework should be different in this 
> respect.

I think the standard library is difficult, because it mixes all sorts of 
things together.  I involves methodology -- very conservative, backward 
compatible, slow to improve -- which suggests that a package should be 
at a certain point in its life.  It also suggests applicability, that 
the package should be reasonably generic and not unduly complex.  And it 
encourages people to use it, either directly or indirectly, instead of 
alternatives.  All of these are important, but they are fairly separate. 
  mxDateTime would have been a very capable implementation of date-time 
objects, and was a de facto standard, but because of methodology 
conflicts that didn't happen (I assume because mxDateTime had to be 
released on a schedule determined by commercial concerns).  Wx is 
similar but even worse; there's no practical way I can imagine it going 
into the standard library, and it's not just inertia, but rather Tk 
actually *remains* ideal simply because it is largely dead.

Generally the standard library is become much less practical way to move 
Python forward.  Backporting has to be extensive for the library to be 
viable to use.  Up-front design becomes burdensome -- I'm sure there was 
a lot of useful things that came out of the decimal discussion, but the 
whole process seemed odd and drawn-out from the outside.  Copied designs 
can shortcut this (e.g., logging), but lead to other design problems. 
And even as this happens, distributions are often pulling the standard 
library apart into pieces.  Batteries Included has certainly helped me 
as a developer, but it's not what I have my eyes on for the future.

It would be nice if process and politics could be separated.  There's a 
lot of modules in the standard library that no one should use, even if 
they aren't marked "deprecated" -- there might be no reason for those 
modules to go away ever, but they just shouldn't get new users. 
Similarly there's modules not in the standard library that should be de 
facto standards, but for good reason can't be part of the standard 
library development process.  But there's no way to suggest that to 
people except for information question-and-answer sessions in IRC or 
mailing lists, or the the vague and unpredictable rankings of Google.

"Politics" might be a bad name for this; it doesn't have to be 
contentious -- for instance, sgmllib has no hero who will be offended 
that people are steered away from it.  But I can't think of a better 
name.  Anyway, I think it might be possible to resolve that issue more 
easily than the technical issues involved in extending the standard library.

-- 
Ian Bicking  /  ianb at colorstudy.com  /  http://blog.ianbicking.org