Python does not play well with others

[John Nagle]

Re: Python does not play well with others

Paul Rubin wrote:

John Nagle <nagle@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

[Skip Montanaro]

Re: Python does not play well with others

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

[Bruno Desthuilliers]

Re: Python does not play well with others

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.

[John Nagle]

Re: Python does not play well with others

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

[Ben Finney]

Re: Python does not play well with others

John Nagle <nagle@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

[Paul Rubin]

Re: Python does not play well with others

Ben Finney <bignose+hate s-spam@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.

[msoulier]

Re: Python does not play well with others

On Jan 23, 8:50 pm, John Nagle <n...@animats.c omwrote:

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

[msoulier]

Re: Python does not play well with others

On Jan 24, 2:59 pm, John Nagle <n...@animats.c omwrote:

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

[skip@pobox.com]

Re: Python does not play well with others


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

[Ben Finney]

Re: Python does not play well with others

John Nagle <nagle@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

[John Nagle]

Re: Python does not play well with others

Paul Rubin wrote:

Ben Finney <bignose+hate s-spam@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

[Paul Boddie]

Re: Python does not play well with others

On 2 Feb, 03:46, Paul Rubin <http://phr...@NOSPAM.i nvalidwrote:

>
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 "fashionabl y" 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

[Paul Boddie]

Re: Python does not play well with others

On 2 Feb, 04:56, Ben Finney <bignose+hate s-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
"permanentl y", 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

[Paul Rubin]

Re: Python does not play well with others

"Paul Boddie" <paul@boddie.or g.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.

[Chris Mellon]

Re: Python does not play well with others

On 02 Feb 2007 11:10:04 -0800, Paul Rubin
<"http://phr.cx"@nospam. invalidwrote:

"Paul Boddie" <paul@boddie.or g.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?