SyntaxWarning in _mechanize_dist when using Python 2.6

[Felix Schwarz]

Whenever I install twill on Python 2.6, I get a SytaxWarning which is
a bit annoying:
/home/fs/trac/eggs/twill-0.9-py2.6.egg/twill/other_packages/
_mechanize_dist/_msiecookiejar.py:255: SyntaxWarning: assertion is
always true, perhaps remove parentheses?
assert (sig in ("HASH", "LEAK",

This should be fixed in mechanize as well - a first step could be to
unbundle mechanize so that it can be fixed once.

Reproducing the problem is easy:

$ easy_install twill
Searching for twill
Reading http://pypi.python.org/simple/twill/
Reading http://www.idyll.org/~t/www-tools/twill.html
Reading http://twill.idyll.org/
Best match: twill 0.9
Downloading http://darcs.idyll.org/~t/projects/twill-0.9.tar.gz
Processing twill-0.9.tar.gz
Running twill-0.9/setup.py -q bdist_egg --dist-dir /tmp/easy_install-
dxcKDm/twill-0.9/egg-dist-tmp-_Sy2Eh
build/bdist.linux-i686/egg/twill/other_packages/_mechanize_dist/
_msiecookiejar.py:255: SyntaxWarning: assertion is always true,
perhaps remove parentheses?
assert (sig in ("HASH", "LEAK",
zip_safe flag not set; analyzing archive contents...
twill.__init__: module references __file__
twill.commands: module references __file__
/home/fs/trac/eggs/twill-0.9-py2.6.egg/twill/other_packages/
_mechanize_dist/_msiecookiejar.py:255: SyntaxWarning: assertion is
always true, perhaps remove parentheses?
assert (sig in ("HASH", "LEAK",

[Jesse London]

I agree, if this is a current issue in mechanize, it needs to be fixed in mechanize; and in order easily to take advantage of such fixes, twill will need to unbundle mechanize.

The initial unbundling need not be traumatic -- twill's setup can require whichever version of mechanize it's currently bundling, (or whichever is closest to what it's bundling).  A subsequent step to addressing this issue would be to make whatever changes will be required of twill to support mechanize's current (and/or fixed) version.

[C. Titus Brown]

On Thu, Mar 26, 2009 at 10:58:59AM -0500, Jesse London wrote:
-> I agree, if this is a current issue in mechanize, it needs to be fixed in
-> mechanize; and in order easily to take advantage of such fixes, twill will
-> need to unbundle mechanize.
-> The initial unbundling need not be traumatic -- twill's setup can require
-> whichever version of mechanize it's currently bundling, (or whichever is
-> closest to what it's bundling). A subsequent step to addressing this issue
-> would be to make whatever changes will be required of twill to support
-> mechanize's current (and/or fixed) version.

Just a note:

unbundling is far from a given. We can discuss more in person at the
twill sprint, but people better come with pretty persuasive arguments
for it ;) -- I'm very strongly against it at the moment.

Note that a similar argument (much more general, of ourse) has been
raging on Python-dev. Nothing near a consensus has been reached, and I
think it would be a good idea to read the entire thread (look up
"integrate BeautifulSoup" and "setuptools has divided the Python
community" from march and maybe february) to collect arguments for and
against a reliance on package managers.

I'll try to summarize my own views before Monday.

cheers,
--titus
--
C. Titus Brown, c...@msu.edu

[Felix Schwarz]

Jesse London schrieb:

> I agree, if this is a current issue in mechanize, it needs to be fixed in
> mechanize; and in order easily to take advantage of such fixes, twill will
> need to unbundle mechanize.

Looks like my second message did not make it to this mailing list. This
is what I added yesterday 9:52 GMT+1:
Actually I just noticed that this is fixed in mechanize's svn already so
it's just twill's mechanize version.

fs

[Felix Schwarz]

C. Titus Brown schrieb:

> Just a note:
>
> unbundling is far from a given. We can discuss more in person at the
> twill sprint, but people better come with pretty persuasive arguments
> for it ;) -- I'm very strongly against it at the moment.

I have to admit that I'm a bit biased (as a Package Maintainer for
Fedora+EPEL/RHEL).

I know that unbundling etc. is a controversial topic. IMHO the only sane
way for distribution (be it Python packages, Perl modules or other
libraries) is to use the system's packaging mechanism even if this is
much more work for a cross-platform toolkit like Python.

However for what it's worth, two reasons why you should consider unbundling:
- mechanize 0.1.10 dropped Python 2.3 support but some people still need
2.3 (e.g. trac on RHEL4). If you use the system version of mechanize,
people with Python 2.6 use a newer version which gets rid of all these
DeprecationWarning issues and others with 2.3 just use an old version
of mechanize.
- twill is not in Fedora exactly because of the work to unbundle all
modules (there is no way that Fedora will accept privatly bundled
packages): https://bugzilla.redhat.com/show_bug.cgi?id=253355

So even if you want to keep this 'everything included' feeling, please
decouple the modules. I suggest not to move mechanize (and all the other
libraries) to their own namespace but use a lib folder where your code
can just do 'import mechanize'.

That way it will be very easy for distributions to remove the bundled
code. Even better, with some setuptools trickety you might even import
the system's mechanize version automatically if it is already installed.

fs

[C. Titus Brown]

On Fri, Mar 27, 2009 at 10:18:12AM +0100, Felix Schwarz wrote:

[ ... ]

-> So even if you want to keep this 'everything included' feeling, please
-> decouple the modules. I suggest not to move mechanize (and all the other
-> libraries) to their own namespace but use a lib folder where your code
-> can just do 'import mechanize'.

*poof*, your wish is granted!

Seriously, I'd be interested in figuring out to make it trivial to
switch between "batteries included" and "batteries already installed".
It's already pretty easy... but it does require ~3-4 lines of code to be
changed.

-> That way it will be very easy for distributions to remove the bundled
-> code. Even better, with some setuptools trickety you might even import
-> the system's mechanize version automatically if it is already installed.

Does anyone see the problem with that? Anyone? Anyone? ;)

User: "twill doesn't work!"
us: "what version are you using?"
User: "Dunno, I downloaded the one off your Web page."
us: "OK, that would be x.y.z. Now, do what version of mechanize are you
using -- the one that comes with twill, or one you already had
installed?"
User: "huh?"

I'm not saying this kind of problem can't be solved or at least
ameliorated in a few ways, but I can guarantee you that the number of
support e-mails is going to go up dramatically if we do unbundling
dynamically...

[C. Titus Brown]

On Fri, Mar 27, 2009 at 09:59:45AM +0100, Felix Schwarz wrote:
-> Jesse London schrieb:

-> > I agree, if this is a current issue in mechanize, it needs to be fixed in
-> > mechanize; and in order easily to take advantage of such fixes, twill will
-> > need to unbundle mechanize.
->

-> Looks like my second message did not make it to this mailing list. This
-> is what I added yesterday 9:52 GMT+1:
-> Actually I just noticed that this is fixed in mechanize's svn already so
-> it's just twill's mechanize version.

See https://twill.googlecode.com/svn/branches/0.9.2-dev/twill