By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
445,813 Members | 1,252 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 445,813 IT Pros & Developers. It's quick & easy.

Python does not play well with others

P: n/a
The major complaint I have about Python is that the packages
which connect it to other software components all seem to have
serious problems. As long as you don't need to talk to anything
outside the Python world, you're fine. But once you do, things
go downhill. MySQLdb has version and platform compatibility
problems. So does M2Crypto. The built-in SSL support is weak.
Even basic sockets don't quite work right; the socket module
encapsulates the timeout mechanism but doesn't get it right.

In the Perl, Java, PHP, and C/C++ worlds, the equivalent
functions just work. That's because, in those worlds, either the
development team for the language or the development team
for the subsystem takes responsibility for making them work.
Only Python doesn't do that.

Python has been around long enough that this should have
been fixed by now.

John Nagle
Jan 24 '07 #1
Share this Question
Share on Google+
113 Replies


P: n/a

JohnMySQLdb has version and platform compatibility problems.

Got specific examples? I've successfully used MySQLdb on Linux, Mac and
Solaris with no compatibility problems at all.

JohnEven basic sockets don't quite work right; the socket module
Johnencapsulates the timeout mechanism but doesn't get it right.

As has been reported here a number of times, this simply awaits someone with
the time and inclination to do the work. If it itches you then scratch the
itch.

JohnIn the Perl, Java, PHP, and C/C++ worlds, the equivalent functions
Johnjust work. That's because, in those worlds, either the
Johndevelopment team for the language or the development team for the
Johnsubsystem takes responsibility for making them work. Only Python
Johndoesn't do that.

You seem to be expecting something for free from the volunteer development
team. If these things are important enough you can always pay someone to do
the work and contribute it back to the community. The work didn't happen
for free in any of the communities you mentioned. Someone (Sun, AT&T,
whoever) paid for it in either time or money.

Skip
Jan 24 '07 #2

P: n/a
At Tuesday 23/1/2007 22:50, John Nagle wrote:
The major complaint I have about Python is that the packages
which connect it to other software components all seem to have
serious problems. As long as you don't need to talk to anything
outside the Python world, you're fine. But once you do, things
go downhill.
That appears to be your situation.
>MySQLdb has version and platform compatibility
problems.
Which, specifically?
>So does M2Crypto.
Both of them are third-party libraries maintained by volunteer people
(and I could ask why do you menction M2Crypto specifically?)
>The built-in SSL support is weak.
Even basic sockets don't quite work right; the socket module
encapsulates the timeout mechanism but doesn't get it right.
I use several packages connecting to the "outside Python" world
without problems. If you have these specific problems, perhaps you
could try to fix them? Get funding to make them fixed? Do the funding yourself?
In the Perl, Java, PHP, and C/C++ worlds, the equivalent
functions just work. That's because, in those worlds, either the
development team for the language or the development team
for the subsystem takes responsibility for making them work.
Only Python doesn't do that.
I think that it was done because *someone* was sponsoring the
development (like IBM, Sun, and others).
--
Gabriel Genellina
Softlab SRL


__________________________________________________
Preguntá. Respondé. Descubrí.
Todo lo que querías saber, y lo que ni imaginabas,
está en Yahoo! Respuestas (Beta).
¡Probalo ya!
http://www.yahoo.com.ar/respuestas

Jan 24 '07 #3

P: n/a
John Nagle <na***@animats.comwrites:
The major complaint I have about Python is that the packages
which connect it to other software components all seem to have
serious problems. As long as you don't need to talk to anything
outside the Python world, you're fine. But once you do, things
go downhill. MySQLdb has version and platform compatibility
problems. So does M2Crypto. The built-in SSL support is weak.
Even basic sockets don't quite work right; the socket module
encapsulates the timeout mechanism but doesn't get it right.

In the Perl, Java, PHP, and C/C++ worlds, the equivalent
functions just work. That's because, in those worlds, either the
development team for the language or the development team
for the subsystem takes responsibility for making them work.
Only Python doesn't do that.

Python has been around long enough that this should have
been fixed by now.

John Nagle
You experience isn't shared by everyone. Some of us find Python the
most functional and portable of the candidates you mention.

Perl - excellent modules and bindings for just about everything you
can think of, but the whole thing is painful to watch. Once you've
done a few code reviews on 10,000 line perl packages where even the
authors have no idea what the code is doing, you tend to look
elesewhere.

Java - a world of its own. They reinvent the wheel instead of linking
to existing libraries. In the process you get libraries upon
libraries upon libraries. Even if there isn't a performance hit, you
(as a human) can get lost. And the language is just too verbose to
live with.

PHP - are we talking web scripts or serious programs? Are you doing
numerical analysis, NLP, computational chemistry, or bit twiddling in
PHP?

C - the portable assembler. Solid, trusted, tunable performance,
bindings for everything. Of course memory bugs can stop your project
in its tracks for indeterminant periods.

C++ - objects tacked onto C; but that didn't work so invent a whole
world of templates and rewrite everything again, but now trickier than
C to bind to other languages. Good work can be done in C++, but that
is a testimony to the programmers and not to the language.

Python - it just works. Same scripts run on every platform. Bindings
available to every C/C++/FORTRAN library I've needed so far. Often
the bindings are not complete, but oddly enough the binding developers
have chosen to do just the functions I need, so who cares. A clean
architecture for adding more function bindings if I'm so inclined.

--
Harry George
PLM Engineering Architecture
Jan 24 '07 #4

P: n/a
Harry George wrote:
John Nagle <na***@animats.comwrites:
You experience isn't shared by everyone. Some of us find Python the
most functional and portable of the candidates you mention.
The language is fine. It's the bindings to other packages that
are the problem. There are three different packages for talking
to OpenSSL, and they're all broken in some important way.

What's actually needed on the SSL side, I think, is to
add bindings to the built-in SSL to export the functionality
the M2Crypto C binding module has. Preferably with better
attention to reference count problems, and without using SWIG.
Then move over the Python portions of M2Crypto.

Some problems, all of which are known and logged bugs:

- The built in SSL package doesn't actually validate anything,
and will happily accept bogus SSL certificates.
- The built in SSL package doesn't allow access to most of the
fields of an SSL certificate, and the ones you can get
are returned in a debug format that's not parseable.
- M2Crypto has OpenSSL and SWIG version dependencies beyond
what is documented. The latest version of SWIG has
a problem which breaks builds with older versions of
OpenSSL.
- M2Crypto may still have a memory leak associated with contexts.
(Check out "close" in "Context".)
- M2Crypto doesn't understand SSL certificates which support
a list of sites.
- M2Crypto and the socket library don't play nice about timeouts.

Most of these problems have been known for years. The last person to
try to fix this was treated so badly he stopped contributing. Read
the bug history for "[1114345] Add SSL certificate validation".
It's sad.

John Nagle
Jan 24 '07 #5

P: n/a
On 1/23/07, John Nagle <na***@animats.comwrote:
The major complaint I have about Python is that the packages
which connect it to other software components all seem to have
serious problems. As long as you don't need to talk to anything
outside the Python world, you're fine. But once you do, things
go downhill. MySQLdb has version and platform compatibility
problems. So does M2Crypto. The built-in SSL support is weak.
Even basic sockets don't quite work right; the socket module
encapsulates the timeout mechanism but doesn't get it right.

In the Perl, Java, PHP, and C/C++ worlds, the equivalent
functions just work. That's because, in those worlds, either the
development team for the language or the development team
for the subsystem takes responsibility for making them work.
Only Python doesn't do that.

Python has been around long enough that this should have
been fixed by now.

John Nagle
This just isn't correct. You think that socket libraries don't have
incompatibilities in C and that C++ libraries don't have versioning
problems? You think that SSL works right from Java in all cases, or
that changing your mysql client libraries underneath PHP won't affect
it?
Jan 24 '07 #6

P: n/a
On 1/24/07, John Nagle <na***@animats.comwrote:
Harry George wrote:
John Nagle <na***@animats.comwrites:
You experience isn't shared by everyone. Some of us find Python the
most functional and portable of the candidates you mention.

The language is fine. It's the bindings to other packages that
are the problem. There are three different packages for talking
to OpenSSL, and they're all broken in some important way.

What's actually needed on the SSL side, I think, is to
add bindings to the built-in SSL to export the functionality
the M2Crypto C binding module has. Preferably with better
attention to reference count problems, and without using SWIG.
Then move over the Python portions of M2Crypto.

Some problems, all of which are known and logged bugs:

- The built in SSL package doesn't actually validate anything,
and will happily accept bogus SSL certificates.
- The built in SSL package doesn't allow access to most of the
fields of an SSL certificate, and the ones you can get
are returned in a debug format that's not parseable.
- M2Crypto has OpenSSL and SWIG version dependencies beyond
what is documented. The latest version of SWIG has
a problem which breaks builds with older versions of
OpenSSL.
- M2Crypto may still have a memory leak associated with contexts.
(Check out "close" in "Context".)
- M2Crypto doesn't understand SSL certificates which support
a list of sites.
- M2Crypto and the socket library don't play nice about timeouts.

Most of these problems have been known for years. The last person to
try to fix this was treated so badly he stopped contributing. Read
the bug history for "[1114345] Add SSL certificate validation".
It's sad.
Just to be clear: The problem here is "my personal itch is not being
scratched by other people for me", not "Python doesn't play well with
others". You are not any more important than anyone else and assuming
that anyone cares about your problems is a major fallacy. You have a
specific library that doesn't meet your needs, and that you are not
interested in maintaining yourself, so you are attempting to leverage
some sort of community guilt trip to get other people to do it for
you. That's dishonest and off-putting.

Not everyone has the ability or desire to contribute. That is fine.
They might even ask if anyone is interested in doing it for them,
which is also fine - there are many people who enjoy working on
something that is of use to others, even if it's not important to them
personally. But stop acting like you're entitled to special
consideration, or that the "Python community" is failing some sort of
duty by not catering to you specifically.
Jan 24 '07 #7

P: n/a
On 24 Jan, 02:50, John Nagle <n...@animats.comwrote:
The major complaint I have about Python is that the packages
which connect it to other software components all seem to have
serious problems. As long as you don't need to talk to anything
outside the Python world, you're fine.
I think you're overstating your case here, since there is a lot of
Python code out there (much of it under the radar of many readers of
this newsgroup/list) whose purpose is precisely that of integration
with other software components. Having read what you've written
elsewhere with regard to SSL integration with Python, though, the
causes of the symptoms you're seeing are mostly correctly identified in
your own analysis.
In the Perl, Java, PHP, and C/C++ worlds, the equivalent functions just work.
We may have differing experiences here. Java stuff, in my experience,
usually needs lots of precisely versioned .jar files and then
frequently doesn't "just work". C and C++ aren't complete environments,
but there are admittedly some libraries/frameworks/environments based
on those languages which might provide solutions which often work
satisfactorily. I don't really want to think of the cocktail of
solutions available for Perl to solve any given problem, but people
often report that the quality varies somewhat between them.
That's because, in those worlds, either the
development team for the language or the development team
for the subsystem takes responsibility for making them work.
Only Python doesn't do that.
And this is where I'd almost reach agreement with you. It's not enough
for the language to keep growing new features if the libraries are
broken or appear archaic, and this task seems to be outside the "core
developers" area of interest. Of course, people like you and I could
help update the libraries, although finding the time for making more
than just suggestions can be quite difficult, but the core developers
merely signalling that the libraries are a priority area for
development would probably lead to fewer people pushing their own
favourite syntax brush-ups or esoteric constructs, hopefully leading
some people (with enough time) to update, document and improve what's
already there.

Paul

Jan 24 '07 #8

P: n/a
On Wed, Jan 24, 2007 at 06:24:37AM +0000, Harry George wrote:
>
Perl - excellent modules and bindings for just about everything ...
Java - a world of its own. They reinvent the wheel instead of ...
PHP - are we talking web scripts or serious programs? Are you ...
C - the portable assembler. Solid, trusted, tunable ...
C++ - objects tacked onto C; but that didn't work so invent ...
Python - it just works. Same scripts run on every platform ...
What about C# ?
e
--
Egbert Bouwman - Keizersgracht 197 II - 1016 DS Amsterdam - 020 6257991
================================================== ======================
Jan 24 '07 #9

P: n/a
Chris Mellon wrote:
On 1/24/07, John Nagle <na***@animats.comwrote:
>Harry George wrote:
John Nagle <na***@animats.comwrites:
Just to be clear: The problem here is "my personal itch is not being
scratched by other people for me", not "Python doesn't play well with
others". You are not any more important than anyone else and assuming
that anyone cares about your problems is a major fallacy. You have a
specific library that doesn't meet your needs, and that you are not
interested in maintaining yourself, so you are attempting to leverage
some sort of community guilt trip to get other people to do it for
you. That's dishonest and off-putting.
No, the problem is that these things are broken.

Python is the only major open source project I've encountered where
there's so much hostility to bug reports.

For a while, I tried submitting long, detailed bug reports showing
where in the C code a problem lies, and pointing out ways to fix it.
But I don't want to take over maintenance on the SSL package;
it's too delicate.

John Nagle
Jan 24 '07 #10

P: n/a
On 1/24/07, John Nagle <na***@animats.comwrote:
Chris Mellon wrote:
On 1/24/07, John Nagle <na***@animats.comwrote:
Harry George wrote:
John Nagle <na***@animats.comwrites:
Just to be clear: The problem here is "my personal itch is not being
scratched by other people for me", not "Python doesn't play well with
others". You are not any more important than anyone else and assuming
that anyone cares about your problems is a major fallacy. You have a
specific library that doesn't meet your needs, and that you are not
interested in maintaining yourself, so you are attempting to leverage
some sort of community guilt trip to get other people to do it for
you. That's dishonest and off-putting.

No, the problem is that these things are broken.
That's *your* problem. I don't write any code that uses SSL and so
it's not *my* problem. In a community effort, you either need to fix
your own problems or convince other people that they should fix them.
Saying "hey guys, this is broken" is a start. "You guys are shirking
your responsibilities and not supporting me the way I want to be
supported" is not, because it assumes an entitlement that you do not
have.
Python is the only major open source project I've encountered where
there's so much hostility to bug reports.
You've never submitted a duplicate bug to Gnome, have you? Regardless,
I see very little hostility toward bug reports. You confuse people
failing to satisfy your needs with hostility.
For a while, I tried submitting long, detailed bug reports showing
where in the C code a problem lies, and pointing out ways to fix it.
But I don't want to take over maintenance on the SSL package;
it's too delicate.
And yet, you are perfectly willing to claim that everyone else who
makes the same decision is failing, somehow. Could one not point out
that you are failing your responsibility to the Python community,
following the same logic?
Jan 24 '07 #11

P: n/a

JohnPython is the only major open source project I've encountered
Johnwhere there's so much hostility to bug reports.

You're misinterpreting lack of time (or itches that need scratching by the
people willing to do the work) for hostility. Lest you think that there is
no activity on bugs, scan the python-checkins mailing list archive:

http://mail.python.org/pipermail/python-checkins/

Grepping through the January mbox archive I see 96 different bug ids
mentioned in the checkins. For December I see 116 different ids. I could
go back farther, but I'll let you do that.

Skip
Jan 24 '07 #12

P: n/a
On 25 Jan., 04:46, "Paul Boddie" <p...@boddie.org.ukwrote:
That's because, in those worlds, either the
development team for the language or the development team
for the subsystem takes responsibility for making them work.
Only Python doesn't do that.And this is where I'd almost reach agreement with you. It's not enough
for the language to keep growing new features if the libraries are
broken or appear archaic, and this task seems to be outside the "core
developers" area of interest.
But it shouldn't be - although this is not a request for the core
developers to maintain any 3rd party package in the world, of course. A
while ago someone on python-dev suggested to use builtbot to monitor
were 3rd party packages get broken by new Python releases and offered
this as a service to library developers. I do think this and similar
ideas are relevant to improve overall quality, not only that of the
CPython interpreter. I would also suggest stricter policies for PyPI
were unmaintained packages might be removed after a period ( or at
least tagged in a certain way ).

But maybe admitting quality problems of free software that is affecting
the whole community ( and not just isolated projects ) is just too much
negative PR on a "competitive language market"? We all know Ruby makes
us happy and Haskell is driven by real academics, who are doing
software engineering right, by default. Maybe Python could survive only
leaving the impression that it binds to everything and has an ever
growing code base of high quality?

Jan 24 '07 #13

P: n/a
hg
egbert wrote:
On Wed, Jan 24, 2007 at 06:24:37AM +0000, Harry George wrote:
>>
Perl - excellent modules and bindings for just about everything ...
Java - a world of its own. They reinvent the wheel instead of ...
PHP - are we talking web scripts or serious programs? Are you ...
C - the portable assembler. Solid, trusted, tunable ...
C++ - objects tacked onto C; but that didn't work so invent ...
Python - it just works. Same scripts run on every platform ...

What about C# ?
e
--
Egbert Bouwman - Keizersgracht 197 II - 1016 DS Amsterdam - 020 6257991
================================================== ======================

arf arf

Jan 24 '07 #14

P: n/a
Harry George wrote:
Perl - excellent modules and bindings for just about everything you
....
Java - a world of its own. They reinvent the wheel instead of linking
....
PHP - are we talking web scripts or serious programs? Are you doing
....
C - the portable assembler. Solid, trusted, tunable performance,
....
C++ - objects tacked onto C; but that didn't work so invent a whole
....
Python - it just works. Same scripts run on every platform.
The world has become very small these days...

Although I do not agree to the OP, because Python works for me very good on
different platforms (i.e. different Versions of Windows, Linux and Mac OS
X), there are some other old fellows around, which are very good for cross
platform programming. C and C++ are definitely *not* one of them, I would
say. True, you can write cross platform with them, but... I'm missing
especially some of the older cross platform languages in your list (I would
set Tcl at the top of the list, but Lisp and others will appear in such a
list also), which have grown and became mature over the years. Most cross
platform problems and others issues have been fixed and really worked out
in them. New kids on the block may be more dynamic (Python really is), but
they can learn much from the old guys. Sometimes one should have a look and
learn from still good working ancestors...

Regards
Stephan

Jan 25 '07 #15

P: n/a
Dennis Lee Bieber wrote:
Uhm... Unless something has happened that I don't know about, isn't
C# a M$ specific product?
Mono?

Regards
Stephan
Jan 25 '07 #16

P: n/a
At Thursday 25/1/2007 03:39, Dennis Lee Bieber wrote:
>On Wed, 24 Jan 2007 19:04:39 +0100, egbert <eg************@hccnet.nl>
declaimed the following in comp.lang.python:
On Wed, Jan 24, 2007 at 06:24:37AM +0000, Harry George wrote:
>
Perl - excellent modules and bindings for just about everything ...
Java - a world of its own. They reinvent the wheel instead of ...
PHP - are we talking web scripts or serious programs? Are you ...
C - the portable assembler. Solid, trusted, tunable ...
C++ - objects tacked onto C; but that didn't work so invent ...
Python - it just works. Same scripts run on every platform ...
What about C# ?

Uhm... Unless something has happened that I don't know about, isn't
C# a M$ specific product?
Not exactly. It's defined by an ISO standard; there are several
implementations apart from MS, like Borland C# Builder and the Mono project.
--
Gabriel Genellina
Softlab SRL


__________________________________________________
Preguntá. Respondé. Descubrí.
Todo lo que querías saber, y lo que ni imaginabas,
está en Yahoo! Respuestas (Beta).
¡Probalo ya!
http://www.yahoo.com.ar/respuestas

Jan 25 '07 #17

P: n/a
On 1/24/07, Harry George <ha************@boeing.comwrote:
Python - it just works. Same scripts run on every platform. Bindings
available to every C/C++/FORTRAN library I've needed so far. Often
the bindings are not complete, but oddly enough the binding developers
have chosen to do just the functions I need, so who cares. A clean
architecture for adding more function bindings if I'm so inclined.
Although that is true on Linux, it is often not the case on Windows.
Sometimes the binding lacks a binary for the minor version of Python
you use or it depends on something which depends on something which
sometimes is only available in source form. Still, I would rather take
Python's approach than Java's.

--
mvh Björn
Jan 25 '07 #18

P: n/a
Kay Schluehr wrote:
On 25 Jan., 04:46, "Paul Boddie" <p...@boddie.org.ukwrote:
>> That's because, in those worlds, either the
development team for the language or the development team
for the subsystem takes responsibility for making them work.
Only Python doesn't do that.And this is where I'd almost reach agreement with you. It's not enough
for the language to keep growing new features if the libraries are
broken or appear archaic, and this task seems to be outside the "core
developers" area of interest.

But it shouldn't be - although this is not a request for the core
developers to maintain any 3rd party package in the world, of course. A
while ago someone on python-dev suggested to use builtbot to monitor
were 3rd party packages get broken by new Python releases and offered
this as a service to library developers. I do think this and similar
ideas are relevant to improve overall quality, not only that of the
CPython interpreter. I would also suggest stricter policies for PyPI
were unmaintained packages might be removed after a period ( or at
least tagged in a certain way ).

But maybe admitting quality problems of free software that is affecting
the whole community ( and not just isolated projects ) is just too much
negative PR on a "competitive language market"? We all know Ruby makes
us happy and Haskell is driven by real academics, who are doing
software engineering right, by default. Maybe Python could survive only
leaving the impression that it binds to everything and has an ever
growing code base of high quality?
Looking at the history of the bug, it ends with a request from Martin
von Loewis that James Eagan (the author of the patch, for which we
should be grateful) provide unit tests and documentation to go with the
code already contributed, finally followed by a comment from James that
it will be a while before he has time to make the necessary changes.

I don't think there's any attempt here to avoid admitting that there's a
quality problem with the existing code. Adding new functionality without
tests and documentation certainly wouldn't improve things.

regards
Steve
--
Steve Holden +44 150 684 7255 +1 800 494 3119
Holden Web LLC/Ltd http://www.holdenweb.com
Skype: holdenweb http://del.icio.us/steve.holden
Blog of Note: http://holdenweb.blogspot.com

Jan 25 '07 #19

P: n/a
On Jan 24, 1:50 am, John Nagle <n...@animats.comwrote:
In the Perl, Java, PHP, and C/C++ worlds, the equivalent
functions just work. That's because, in those worlds, either the
development team for the language or the development team
for the subsystem takes responsibility for making them work.
Only Python doesn't do that.
I have much sympathy for your position. I think the problem is that
Python is quite capable in many areas, such that the people in the
community with the expertise to extend the language and libraries, are
usually the ones who've been happily using the polished features for
years and have found they need nothing more. And the ones who need
those features probably got bored of waiting for progress long ago. You
get the responses you do from years of natural selection in the
community. I think that is why many of the SIGs are stagnant, why the
standard library has so much fluff yet still lacks in key areas such as
multimedia and web development, etc.

People can say, "if you want it done, why aren't you doing it?", and is
a fair question, but it doesn't alter the fact of Python's deficiencies
in certain areas when compared with other languages.

--
Ben Sizer

Jan 25 '07 #20

P: n/a
On 25 Jan, 12:01, "Ben Sizer" <kylo...@gmail.comwrote:
>
Python is quite capable in many areas, such that the people in the
community with the expertise to extend the language and libraries, are
usually the ones who've been happily using the polished features for
years and have found they need nothing more. And the ones who need
those features probably got bored of waiting for progress long ago. You
get the responses you do from years of natural selection in the
community. I think that is why many of the SIGs are stagnant, why the
standard library has so much fluff yet still lacks in key areas such as
multimedia and web development, etc.
I think this is also a good insight into why things are as they are
within the core development section of the community, although one can
wonder what some people actively developing the language are actually
doing with it if they are satisfied with the state of some of the
standard library solutions. However, there are lots of factors which
motivate people and the proliferation (or otherwise) of solutions to
common problems: whether one develops one's own solutions as separate
projects and/or tries to push for a consensus, whether one cares about
other people using such solutions, whether one aspires to contributing
to the standard library.

Over the years, people have tended towards building their own
communities around their projects rather than attempting to engage the
wider Python community, and I think a motivation behind that has been
the intractability of improving parts of the standard library. For
example, how would one update the cgi module? Since lots of code
including various Web frameworks makes use of the cgi module, it can't
just go away or have its APIs changed radically, but this doesn't
exactly make for a pretty "out of the box" solution for Web
programming. Someone else was complaining recently about URL handling
and the required combination of urllib, cgi and urlparse (or perhaps
some other combination, depending on what one's needs are). Presented
with the problem of rationalising all this, the chosen solution (as
adopted by the Web-SIG) is, as it is frequently, to ignore the problem
and to work on other things instead.
People can say, "if you want it done, why aren't you doing it?", and is
a fair question, but it doesn't alter the fact of Python's deficiencies
in certain areas when compared with other languages.
True. It also doesn't address the issue of development priorities and
their role in defining the platform's own standards. We all know that
the Python language has issues (or "warts" as they are popularly
called), although some of the most notable ones don't seem to have been
addressed as yet in the plans for Python 3000 (eg. default argument
evaluation), but some of the most awkward aspects of using Python
involve libraries, not some deficiency of the language. However,
reforming the standard library is a topic which has arisen in all
seriousness only recently in the Python 3000 process (PEP 3108), and
the scope of the related activity is highly restricted - it's almost an
afterthought. Where the "why aren't you doing it?" part comes in
involves the observation that even if someone is motivated enough to
take something like this and to move forward in their own direction
[1], unless such initiatives are embraced by the core developers they
will remain peripheral, non-standard extensions that will at best only
become mainstream much later on.

I do wonder whether the interests of language/runtime project
developers eventually become completely aligned with the needs of such
projects, making things like "multimedia and web development" seem
irrelevant, uninteresting or tangential. This has worrying implications
for the perceived relevance of Python with regard to certain kinds of
solutions, despite the wealth of independently produced libraries
available for the language.

Paul

[1]
http://wiki.python.org/moin/CodingPr...tandardLibrary

Jan 25 '07 #21

P: n/a
Paul.... We all know that the Python language has issues (or "warts"
Paulas they are popularly called), although some of the most notable
Paulones don't seem to have been addressed as yet in the plans for
PaulPython 3000 (eg. default argument evaluation), but some of the
Paulmost awkward aspects of using Python involve libraries, not some
Pauldeficiency of the language....

I think EasyInstall might have some role to play in improving the library
status quo. Consider the cgi module. It was originally written in probably
1995 or earlier and for a long time was the only game in town.
Consequently, lots of applications used it. Times have changed though and
there's a whole new alphabet soup of web application frameworks available.
I installed Pylons the other day with "easy_install pylons". No fuss, no
muss. Over time (maybe in Python 3) modules like cgi, which arguably no
longer belong in the core can be maintained externally and installed only
when needed.

Skip
Jan 25 '07 #22

P: n/a
Paul Boddie wrote:
On 25 Jan, 12:01, "Ben Sizer" <kylo...@gmail.comwrote:
>I think that is why many of the SIGs are stagnant, why the standard library
has so much fluff yet still lacks in key areas such as multimedia and web
development, etc.
... I think this is also a good insight into why things are as they are
within the core development section of the community, although one can wonder
what some people actively developing the language are actually doing with it
if they are satisfied with the state of some of the standard library
solutions. However, there are lots of factors which motivate people and the
proliferation (or otherwise) of solutions to common problems: whether one
develops one's own solutions as separate projects and/or tries to push for a
consensus, whether one cares about other people using such solutions, whether
one aspires to contributing to the standard library.

Over the years, people have tended towards building their own communities
around their projects rather than attempting to engage the wider Python
community, and I think a motivation behind that has been the intractability
of improving parts of the standard library.
Yes. Working on "frameworks" is perceived as cooler than working
on libraries. Things like Ruby on Rails, Struts, Zope, and Twisted
get attention. There are papers and conferences on these things.
It's hard to get people excited about overhauling
the CGI library, or making mod_python work securely in shared-hosting
environments.

The key distinction between a framework and a library is that users
are expected to make their code fit the framework. In particular,
frameworks aren't expected to play well with each other. If you need
something from Zope and something from Twisted, you're probably not
going to be able to make it work. Libraries, on the other hand,
are expected to play well together. Which means that they have to
handle the hard cases correctly, not just the easy ones.
True. It also doesn't address the issue of development priorities and their
role in defining the platform's own standards
....
I do wonder whether the interests of language/runtime project developers
eventually become completely aligned with the needs of such projects, making
things like "multimedia and web development" seem irrelevant, uninteresting
or tangential. This has worrying implications for the perceived relevance of
Python with regard to certain kinds of solutions, despite the wealth of
independently produced libraries available for the language.
Something like that happened to the C++ standards committee.
The committee was captured by the template fanatics, and most new
standards work involves doing computation at compile time via template
expansion. That's seldom done in production code, yet most of the
standards effort is devoted to making cool template hacks work better.
Meanwhile, real problems, like doing something about memory leaks and buffer
overflows, are ignored by the C++ committee. As a result, C++ is
being displaced by Java and C#, which don't have elaborate templates but do have
memory safety.

I'm not sure how the Python development community will deal with this
problem. But what's happened in the C++ standards world has clearly
been very bad for users of the language. Learn from the mistakes there.

My main concern is with glue code to major packages. The connections
to OpenSSL, MySQL, and Apache (i.e. mod_python) all exist, but have major
weaknesses. If you're doing web applications, those are standard pieces
which need to work right. There's a tendency to treat those as abandonware
and re-implement them as event-driven systems in Twisted. Yet the
main packages aren't seriously broken. It's just that the learning curve
to make a small fix to any of them is substantial, so nobody new takes
on the problem.

John Nagle
Animats
Jan 25 '07 #23

P: n/a
John Nagle <na***@animats.comwrites:
My main concern is with glue code to major packages. The connections
to OpenSSL, MySQL, and Apache (i.e. mod_python) all exist, but have major
weaknesses. If you're doing web applications, those are standard pieces
which need to work right. There's a tendency to treat those as abandonware
and re-implement them as event-driven systems in Twisted. Yet the
main packages aren't seriously broken. It's just that the learning curve
to make a small fix to any of them is substantial, so nobody new takes
on the problem.
There is an attitude widespread in the Python community, maybe
inherited from Extreme Programming, that when writing some subsystem
it's enough to implement just enough functionality to satisfy the
application's immediate needs. Then if the application needs more
functionality from the subsystem later, go back and add it. That's
fairly reasonable when the application and subsystem are being done by
the same people and there's not such a learning curve. But it's
unwise for libraries. For all Java's ugliness, when the Java library
developers want to implement some protocol like SSL, they take the
specification for the protocol and they implement it completely.
Python's library modules are very often missing stuff, as you've
pointed out.

In the specific examples of OpenSSL, MySQL, and Apache, the modules
involved aren't even part of the Python stdlib, the way JSSE and JDBC
are part of the Java stdlib (I guess that doesn't apply to Tomcat
though).
Jan 25 '07 #24

P: n/a

JohnMy main concern is with glue code to major packages. The
Johnconnections to OpenSSL, MySQL, and Apache (i.e. mod_python) all
Johnexist, but have major weaknesses.

I have no SSL experience or direct mod_python experience (I do use Myghty
effectively), but I have used MySQLdb extensively in multi-threaded
environments. There is a Python database API (PEP 249). As far as I know,
MySQLdb implements this API well. I have personally never had problems.
Andy Dustman, the author of the package is quite responsive to requests
raised in the mysql-python forums on SourceForge
(http://sourceforge.net/forum/?group_id=22307). If you have problems with
MySQLdb, bring them up there. I'm sure Andy will respond.

Skip
Jan 25 '07 #25

P: n/a
On Jan 25, 12:17 pm, John Nagle <n...@animats.comwrote:
My main concern is with glue code to major packages. The connections
to OpenSSL, MySQL, and Apache (i.e. mod_python) all exist, but have major
weaknesses. If you're doing web applications, those are standard pieces
which need to work right. There's a tendency to treat those as abandonware
and re-implement them as event-driven systems in Twisted.
In the real world I've worked on Python web apps at my last 3 jobs, and
they've all used mod_python and either MySQL or Postgres. I haven't
had a need to do anything with OpenSSL from Python; all that takes
place in the Apache server (possibly with some mod_rewrite rules to
ensure that certain pages are only hit from https and so forth).

I think the impression that everyone's using some sexy new framework
like Django or TurboGears or Pylons on Twisted or lighttpd/wsgi is
pretty misleading, especially when it comes to companies with a
decent-size existing codebase (we're into the "fairly large" range with
about 325,000 lines of Python now--most is independent of the
architecture, but it'd still be an administratively sizeable
change)--the place I'm at currently is considering moving to
apache+wsgi, but that's a smaller change (and one that's been under
consideration for months now).

Jan 25 '07 #26

P: n/a
"sj*******@yahoo.com" <sj*******@yahoo.comwrites:
I haven't had a need to do anything with OpenSSL from Python; all
that takes place in the Apache server
That's a reasonable approach for a typical server-side web
application, but there are other types of Python apps that can also
want to use SSL. It's a pain to have to deal with OpenSSL at all, and
I hope that TLSLite (a very incomplete SSL implementation written in
pure Python) one day becomes complete and does all the stuff that JSSE
does.
(possibly with some mod_rewrite rules to ensure that certain pages
are only hit from https and so forth).
Normally you'd do that SSLRequireSSL or SSLRequire, if that matters.
Jan 25 '07 #27

P: n/a
Paul Rubin wrote:
"sj*******@yahoo.com" <sj*******@yahoo.comwrites:
>>I haven't had a need to do anything with OpenSSL from Python; all
that takes place in the Apache server


That's a reasonable approach for a typical server-side web
application, but there are other types of Python apps that can also
want to use SSL. It's a pain to have to deal with OpenSSL at all, and
I hope that TLSLite (a very incomplete SSL implementation written in
pure Python) one day becomes complete and does all the stuff that JSSE
does.
That's the problem. We now have four SSL implementations for
Python, none of which let you do all the things OpenSSL can do.

The fact that people keep writing new ones, instead of fixing the
existing ones, indicates a problem with the development process.

Can you build the built-in SSL package without building all of
Python? That in itself would be useful. Then the thing could
be worked on without too much pain. The built-in SSL package
basically works, although it doesn't check anything. It just
doesn't get at enough OpenSSL functionality.

I think the right way out of this mess is to 1) break
out the SSL module so it can be built separately by the
usual "python setup.py build" process, 2) add more
access functions to the built-in SSL C glue module, 3) bring over
such Python parts of M2Crypto as are useful and make them
work with the built-in SSL module, and 4) get rid of SWIG.

If somebody will do 1), I'll take a look at 2).

John Nagle
Jan 25 '07 #28

P: n/a
John Nagle <na***@animats.comwrites:
That's the problem. We now have four SSL implementations for
Python, none of which let you do all the things OpenSSL can do.
I'm aware of some OpenSSL wrappers plus TLSlite. Am I missing a
couple more? I guess maybe the OpenSSL wrappers also work on GnuTLS.
Can you build the built-in SSL package without building all of
Python?
I thought there was no built-in SSL package-- it just calls OpenSSL.
Jan 25 '07 #29

P: n/a
Harry George napisa³(a):
You experience isn't shared by everyone. Some of us find Python the
most functional and portable of the candidates you mention.
The point on MySQLdb is rather common, many people who used it with
SQLObject will confirm. Fortunately for MySQLdb, the MySQL on its own is
much worse. Fortunately for us, the MySQLdb library is not a part of
Python distribution, so Python can not be blamed for its deficiencies. ;)

--
Jarek Zgoda
http://jpa.berlios.de/
Jan 25 '07 #30

P: n/a
Paul Rubin wrote:
John Nagle <na***@animats.comwrites:
> That's the problem. We now have four SSL implementations for
Python, none of which let you do all the things OpenSSL can do.


I'm aware of some OpenSSL wrappers plus TLSlite. Am I missing a
couple more? I guess maybe the OpenSSL wrappers also work on GnuTLS.

> Can you build the built-in SSL package without building all of
Python?


I thought there was no built-in SSL package-- it just calls OpenSSL.
"import SSL" brings in a .dll or .so object called "_ssl.pyd".
This contains C glue code which connects Python to the
C-based OpenSSL library. That's the component which needs work.
Its source code is at

http://svn.python.org/view/python/trunk/Modules/_ssl.c

Part of the problem is that the build of _ssl.pyd
is too integrated into the main Python build to work on easily.
You can't just build and test a new SSL module and give it to others
to test. You have to rebuild the whole Python system, and
people who want to test the modified module need to run a
custom Python build.

SSL is somewhat integrated into the socket module internally,
although from the code I don't see that this is absolutely
necessary. The build machinery for SSL is in

http://svn.python.org/view/python/trunk/setup.py

After looking at that for a while, and the directory
structure, it looks like the Python directory layout and
build system makes the assumption that anything in the
standard distribution is built as part of the basic
Python build. The module itself could be separated from
the trunk build; Python will run without it. It's the
build process and directory structure which ties it up.

As far as I can tell, there's no concept in the
Python build system of a module that's built separately
but ships with the standard Python distribution. Is
that correct?

So now I understand why the standard SSL module doesn't
get fixed, and why there are three or four alternative
re-implementations of it. It's easier to replace than
to repair.

John Nagle
Jan 26 '07 #31

P: n/a
Andy Dustman, the author of the package is quite responsive to requests
raised in the mysql-python forums on SourceForge
(http://sourceforge.net/forum/?group_id=22307). If you have problems with
MySQLdb, bring them up there. I'm sure Andy will respond.
I apologize in advance for beating this dead horse... This morning a
possible bug was reported in MySQLdb. Andy determined it was indeed a bug,
had a fix checked into the source repository in a couple hours and reported
that it would be in the next 1.2 beta release.

Skip
Jan 29 '07 #32

P: n/a
John Nagle a écrit :

(snip)
My main concern is with glue code to major packages. The connections
to OpenSSL, MySQL, and Apache (i.e. mod_python) all exist, but have major
weaknesses.
Neither MySQLdb nor mod_python are part of the Python's standard lib AFAIK.
If you're doing web applications,
I do.
those are standard pieces
which need to work right.
I avoid using MySQL - SQLite does a better job as a lighweight
SQL-compliant no-server solution, and PostgreSQL is years ahead of MySQL
when it comes to serious, rock-solid transactional RDBMS. But I had no
problem with the MySQLdb package so far. I also tend to favor
Apache-independant deployment solutions, so while I had some fun with
mod_python, I failed to clearly understand how broken it is. And I did
not have to worry about the ssl support in Python so far. FWIW, I had do
some LDAP stuff with both PHP and Python, and I would certainly not
advocate PHP's LDAP support.
There's a tendency to treat those as abandonware
and re-implement them as event-driven systems in Twisted.
While Twisted seems an interesting project, it's usually not the first
mentioned when talking about web development with Python.
Yet the
main packages aren't seriously broken. It's just that the learning curve
to make a small fix to any of them is substantial, so nobody new takes
on the problem.
If you feel you need it, then it's up to you.
Jan 29 '07 #33

P: n/a
Just a followup. I'm still trying to get Python, MySQL, MySQLdb,
M2Crypto, and maybe mod_python to work on a shared hosting server.
This is amazingly difficult, because of all the version incompatibility issues.
Python, MySQL, MySQLdb, SWIG, OpenSSL, and gcc all have to have the
right versions, and those aren't necessarily the versions shipping
in some major Linux distros.

From EZpublishing tech support:
"To make matters worse, we can't run the newer version of openSSL on any of our
current servers. It's a standard redhat rpm and redhat hasn't upgraded it. We
can install it on dedicated servers, but it is too risky for other users to be
installed on a shared environment."

From Aplus.net tech support:
"No, db connectivity with Python is not supported. Modules for Python
can't be installed by request on shared hosting."

And these are companies that say they support Python.

Python still isn't ready for prime time in the web hosting world.

John Nagle
Feb 2 '07 #34

P: n/a
John Nagle <na***@animats.comwrites:
Just a followup. I'm still trying to get Python, MySQL, MySQLdb,
M2Crypto, and maybe mod_python to work on a shared hosting server.
>From your description in the rest of the message, it seems that it's
the *hosting providers* who are unable to do this, not you.
And these are companies that say they support Python.

Python still isn't ready for prime time in the web hosting world.
That doesn't follow. It's just as valid to say that the web hosting
providers (that you've interacted with so far) aren't ready to support
the Python functionality you want.

--
\ "To be is to do" -- Plato |
`\ "To do is to be" -- Aristotle |
_o__) "Do be do be do" -- Sinatra |
Ben Finney

Feb 2 '07 #35

P: n/a
Ben Finney <bi****************@benfinney.id.auwrites:
Python still isn't ready for prime time in the web hosting world.
That doesn't follow. It's just as valid to say that the web hosting
providers (that you've interacted with so far) aren't ready to support
the Python functionality you want.
I'd say the functionality that John wants is the same that pretty much
everyone wants, and it's much easier to get for other languages than
for Python.
Feb 2 '07 #36

P: n/a
On Jan 23, 8:50 pm, John Nagle <n...@animats.comwrote:
The major complaint I have about Python is that the packages
which connect it to other software components all seem to have
serious problems. As long as you don't need to talk to anything
outside the Python world, you're fine.
As one who has attempted to develop a wxPython application with an
sqlite backend, developing on both Linux and Windows, I would conclude
that the problem is version skew between third-party components and
the core.

Python 1.5.2 touted a simple core language that made Python easy to
learn. I would argue that the core is no longer simple, and it is very
easy to write modules that are not backwards-compatible. This results
in third-party components that you may need but are either not updated
against the new version of Python that you're using, or are not
compatible with the older version of Python that you shipped with.

I found it quite a frustrating experience. Love the language but I'd
rather it not keep reinventing itself quite so quickly, permitting
maintainers to keep up, especially when said maintenance is a
volunteer effort.

Mike

Feb 2 '07 #37

P: n/a
On Jan 24, 2:59 pm, John Nagle <n...@animats.comwrote:
Python is the only major open source project I've encountered where
there's so much hostility to bug reports.
Try telling the Perl community that their debugger is broken. That
didn't go well. ;-)

Mike

Feb 2 '07 #38

P: n/a

John From Aplus.net tech support:
John"No, db connectivity with Python is not supported. Modules for
JohnPython can't be installed by request on shared hosting."

JohnAnd these are companies that say they support Python.

JohnPython still isn't ready for prime time in the web hosting world.

Why do you lay the blame at the feet of the Python developers? Find another
hosting service.

Skip
Feb 2 '07 #39

P: n/a
John Nagle <na***@animats.comwrites:
Python is the only major open source project I've encountered where
there's so much hostility to bug reports.
Bear in mind that if you send a message only to this mailing list,
that's not a bug report. That's a discussion, which may be worth
having, but not one you can reasonably expect to result in a fix for a
bug.

A bug report should be sent to the bug tracker for the software
against which you're reporting a bug. Only at that point does it
become something on which you can comment about attitude toward bug
reports, because before that point the bug report doesn't exist in a
useful form.
For a while, I tried submitting long, detailed bug reports showing
where in the C code a problem lies, and pointing out ways to fix it.
That's great. I hope your attention to detail was well received.
But I don't want to take over maintenance on the SSL package; it's
too delicate.
That's fair enough. But if no-one maintains it to your satisfaction,
you do get what you pay for. If it's important to you, it should be
worth an investment of *some* kind from you, to ensure it is
maintained.

--
\ "The Bermuda Triangle got tired of warm weather. It moved to |
`\ Alaska. Now Santa Claus is missing." -- Steven Wright |
_o__) |
Ben Finney

Feb 2 '07 #40

P: n/a
Paul Rubin wrote:
Ben Finney <bi****************@benfinney.id.auwrites:
>>>Python still isn't ready for prime time in the web hosting world.

That doesn't follow. It's just as valid to say that the web hosting
providers (that you've interacted with so far) aren't ready to support
the Python functionality you want.


I'd say the functionality that John wants is the same that pretty much
everyone wants, and it's much easier to get for other languages than
for Python.
That's about it.

What's so striking is that this was a surprise. One would think
from what one reads about Python that it just works.

I've been able to pound through these problems. I finally
got M2Crypto, Python, and MySQLdb all working on a shared
hosting server. But it was quite a bit of work. I gave up on
getting the hosting provider to install current versions.

So I just spent four hours struggling with the build procedure
for M2Crypto, to get it to build with a combination of versions of OpenSSL,
M2Crypto, and SWIG that aren't the latest, but are supposed to work.
(Hint: you need to define "__i386__" or other machine if appropriate
as a command line argument to SWIG, so that OpenSSL's older conditional
includes work right.)

This is really a build system management and coordination issue.
Python has only two kinds of modules - nailed into the distribution,
or external and unsupported. Whether or not something is supported
should be independent of whether it's built by the main build file.
Components which have external dependencies, like SSL, M2Crypto,
and MySQLdb don't fit well into that model. They need to undergo
regression testing with each new Python distribution, but they don't
really need to be part of the main build. Right now, SSL is too
far inside, while the other two are too far outside. A middle
ground would help.

Otherwise, you get version hell.

John Nagle
Feb 2 '07 #41

P: n/a
On 2 Feb, 03:46, Paul Rubin <http://phr...@NOSPAM.invalidwrote:
>
I'd say the functionality that John wants is the same that pretty much
everyone wants, and it's much easier to get for other languages than
for Python.
If the hosting provider doesn't want to install MySQLdb then it may
not be a technical issue - perhaps they just can't be bothered to
install it, possibly because there's no demand or benefit to the
bottom line in doing so. That said, I think that a large part of the
community does no-one any favours by "fashionably" requiring the most
cutting edge software, insisting on Python 2.5 in some cases, in order
for their stuff to work. Then again, getting stuff to work across
several versions (and combinations of several versions of several
packages) is an issue of release engineering, and it's no coincidence
that companies have made good business out of this kind of thing.

Perhaps Python needs a "backports" project where newer software is
backported to older Python releases. Alternatively, given the
increasing prominence of virtual server hosting, people might be
advised to consider one of those hosting plans: the benefits of being
able to install almost anything, often with modern operating system
distributions whose packages are updated, surely outweigh the
administrative demands and price differences in at least some
situations.

Paul

Feb 2 '07 #42

P: n/a
On 2 Feb, 04:56, Ben Finney <bignose+hates-s...@benfinney.id.au>
wrote:
>
A bug report should be sent to the bug tracker for the software
against which you're reporting a bug. Only at that point does it
become something on which you can comment about attitude toward bug
reports, because before that point the bug report doesn't exist in a
useful form.
I think it's also worth considering various social factors when filing
bug reports. Whilst a report sent directly to the developers of a
particular module might ultimately be the way to get bugs fixed
"permanently", it is also worth investigating whether there are any
other parties affected by those bugs, whether bugs have been filed in
other places (eg. in a Linux distribution's bug tracker), and whether
there are communities who have an interest in fixing the bugs in a
more timely fashion.

I see this kind of thing every now and again with projects like KDE.
Often, in a distribution, the version of KDE won't be the absolute
latest from kde.org, and the level of interest amongst the original
developers to fix bugs in older releases is somewhat restrained.
Consequently, I would look to distributions to fix problems with their
KDE packages, especially since many of them appear to perform surgery
on KDE, often making the resulting software almost unmaintainable by
the original developers. Of course, if the bugs are genuine things
which are present "upstream" (ie. in the original software) then I'd
expect that any fixes ultimately make their way back to the original
developers, although various projects (including KDE) seem
uninterested even in merging ready-made fixes to older releases unless
it involves a major security flaw.

Paul

Feb 2 '07 #43

P: n/a
"Paul Boddie" <pa**@boddie.org.ukwrites:
If the hosting provider doesn't want to install MySQLdb then it may
not be a technical issue - perhaps they just can't be bothered to
install it, possibly because there's no demand or benefit to the
bottom line in doing so.
Why should the hosting provider need to devote attention to something
like that? MySQLdb or something like it should be included with
Python, not added separately by the hosting provider. Python is
really making more demands on hosting providers than comparable
languages do. PHP hosting providers don't have to install a separate
PHP to MySQL interface gizmo as far as I know.
Feb 2 '07 #44

P: n/a
On 02 Feb 2007 11:10:04 -0800, Paul Rubin
<"http://phr.cx"@nospam.invalidwrote:
"Paul Boddie" <pa**@boddie.org.ukwrites:
If the hosting provider doesn't want to install MySQLdb then it may
not be a technical issue - perhaps they just can't be bothered to
install it, possibly because there's no demand or benefit to the
bottom line in doing so.

Why should the hosting provider need to devote attention to something
like that? MySQLdb or something like it should be included with
Python, not added separately by the hosting provider. Python is
really making more demands on hosting providers than comparable
languages do. PHP hosting providers don't have to install a separate
PHP to MySQL interface gizmo as far as I know.
--
How about because thats what you pay them for? Seriously. Do you even
think about what you're saying? Python needs to move MySQL (and only
MySQL, of course) into the core because installing packages is too
much of a burden for hosting companies?

Christ.

There are a number of languages which are primarily used for "web
development". PHP is the *only* one that ships with MySQL client
access.

Ruby doesn't (only primarily web development because of rails)
ASP, either .NET or classic, doesn't.
Java (in any form I'm aware of) doesn't.
Cold Fusion doesn't.
Perl doesn't.

Who wants to host at a company that can't install packages anyway?

And who wants to be "comparable" to PHP?
Feb 2 '07 #45

P: n/a
"Chris Mellon" <ar*****@gmail.comwrites:
How about because thats what you pay them for? Seriously. Do you even
think about what you're saying? Python needs to move MySQL (and only
MySQL, of course) into the core because installing packages is too
much of a burden for hosting companies?
What does "batteries included" mean to you? To me, it means you don't
have to install add-ons.

If you don't like that, complain to the people who put that into the
Python sales pitch, not to me.

Feb 2 '07 #46

P: n/a
On 02 Feb 2007 11:41:03 -0800, Paul Rubin
<"http://phr.cx"@nospam.invalidwrote:
"Chris Mellon" <ar*****@gmail.comwrites:
How about because thats what you pay them for? Seriously. Do you even
think about what you're saying? Python needs to move MySQL (and only
MySQL, of course) into the core because installing packages is too
much of a burden for hosting companies?

What does "batteries included" mean to you? To me, it means you don't
have to install add-ons.
Well, thats just stupid. I'm not sure where else to go with that.
Feb 2 '07 #47

P: n/a
On Feb 2, 2:41 pm, Paul Rubin <http://phr...@NOSPAM.invalidwrote:
"Chris Mellon" <arka...@gmail.comwrites:
How about because thats what you pay them for? Seriously. Do you even
think about what you're saying? Python needs to move MySQL (and only
MySQL, of course) into the core because installing packages is too
much of a burden for hosting companies?

What does "batteries included" mean to you? To me, it means you don't
have to install add-ons.
So let's make a 500MB executable and add Numpy, Zope, Django, PIL,
pretty much everything actually. Even better, make CheeseShop just a
frontend to a build system that adds and updates automatically
submitted packages to the core. Problem solved ! <wink>.

George

Feb 2 '07 #48

P: n/a

PaulWhy should the hosting provider need to devote attention to
Paulsomething like that? MySQLdb or something like it should be
Paulincluded with Python, ...

What about Firebird? Oracle? Sybase? Who maintains them in the core?
MySQLdb is quite stable outside the core. What would adding it to the core
do other than adding a lot of maintenance overhead to the developers' group?
How many versions of MySQL should the Python developers test with? How many
versions of Python? How many different platforms? Who decides? If *all*
you're talking about are relational database adaptors I see the obvious
candidates:

database: Sybase, Oracle, MySQL, SQLite, ODBC, Firebird
database versions: who knows? assume two per database
python versions: 2.4, 2.5, 2.6, 3.0?
platforms: windows, pick two linux flavors, solaris

Those numbers give me 6 * 2 * 4 * 4 == 192 combinations to test. Ignore
Python 2.4. That brings it down to 144. Only test on one linux variant and
skip solaris. Now you're at 72. Leave Firebird and Sybase out of the mix.
Now you're down to 48. That's still a fair sized burden. Now extend the
problem to non-database packages.

It seems to me that the PyBots project would be a better way to address the
combinatorial explosion caused by supporting multiple versions of multiple
packages on multiple platforms with multiple versions of Python:

http://www.pybots.org/

Do you have a favorite third-party package? A favorite platform? A
preferred version of your package? Set up one or more buildbots for it.
Whenever checkins occur on active Python branches occur (currently 2.5 and
SVN head, but easily extended to newer versions) your bots get built. You
can note the problem and either encourage a change to Python or to your
favorite package. This sort of solution has a couple advantages:

* Presence of a buildbot implies some level of interest by the community
at large. When the guy maintaining the HPUX-10 buildbot for the
OpenView widget set takes it down and nobody steps in to pick up the
slack, it suggests nobody cares enough about that combination anymore.

* It scales, both in people and compute resources.

Skip
Feb 2 '07 #49

P: n/a

PaulWhat does "batteries included" mean to you? To me, it means you
Pauldon't have to install add-ons.

Who decides which batteries are important to include?

Skip
Feb 2 '07 #50

113 Replies

This discussion thread is closed

Replies have been disabled for this discussion.