Re: [Mailman-Developers] print >> sys.stderr does not compile
Hi Fil,
You recently changed all calls like write('(locked)', file=sys.stderr) to print >> sys.stderr, _('(locked)')
but the latter will not compile on my machine. Am I missing something?
I'd guess that your version of Python isn't recent enough to have the new `>>' for I/O redirection.
Sorry, but I don't know what version you'd require.
Ralph.
But I have : Python 1.5.2 (#0, Dec 27 2000, 14:53:01) [GCC 2.95.2 20000220 (Debian GNU/Linux)] on linux2 Copyright 1991-1995 Stichting Mathematisch Centrum, Amsterdam
@ Ralph Corderoy (ralph@inputplus.demon.co.uk) :
Hi Fil,
You recently changed all calls like write('(locked)', file=sys.stderr) to print >> sys.stderr, _('(locked)')
but the latter will not compile on my machine. Am I missing something?
I'd guess that your version of Python isn't recent enough to have the new `>>' for I/O redirection.
Sorry, but I don't know what version you'd require.
Ralph.
-- Fil
You recently changed all calls like write('(locked)', file=sys.stderr) to print >> sys.stderr, _('(locked)')
but the latter will not compile on my machine. Am I missing something?
I'd guess that your version of Python isn't recent enough to have the new `>>' for I/O redirection.
Sorry, but I don't know what version you'd require.
Indeed it seems that python 1.52 does not accept the new calls. The error is not here with python2.
miel:~/mailman# python2 Python 2.0 (#0, Jan 11 2001, 10:52:15) [GCC 2.95.2 20000220 (Debian GNU/Linux)] on linux2 Type "copyright", "credits" or "license" for more information.
print >> sys.stderr, "toto" Traceback (most recent call last): File "<stdin>", line 1, in ? NameError: There is no variable named 'sys'
miel:~/mailman# python Python 1.5.2 (#0, Dec 27 2000, 14:53:01) [GCC 2.95.2 20000220 (Debian GNU/Linux)] on linux2 Copyright 1991-1995 Stichting Mathematisch Centrum, Amsterdam
print >> sys.stderr, "toto" File "<stdin>", line 1 print >> sys.stderr, "toto" ^ SyntaxError: invalid syntax
-- Fil
On Tue, Feb 20, 2001 at 11:47:50AM +0100, Fil wrote:
You recently changed all calls like write('(locked)', file=sys.stderr) to print >> sys.stderr, _('(locked)')
but the latter will not compile on my machine. Am I missing something?
I'd guess that your version of Python isn't recent enough to have the new `>>' for I/O redirection.
Sorry, but I don't know what version you'd require.
Indeed it seems that python 1.52 does not accept the new calls.
You mean Python 1.5.2, not 1.52. There is a difference, even though 1.52 will probably never exist :)
The error is not here with python2.
The README clearly states what version of Python you need to run Mailman. It currently says:
Mailman requires Python 2.0 or greater, which can be downloaded
from [...]Future versions will probably require Python 2.1 ;)
-- Thomas Wouters <thomas@xs4all.net>
Hi! I'm a .signature virus! copy me into your .signature file to help me spread!
@ Thomas Wouters (thomas@xs4all.net) :
The README clearly states what version of Python you need to run Mailman. It currently says:
Mailman requires Python 2.0 or greater, which can be downloaded from [...]Future versions will probably require Python 2.1 ;)
All right. But. I've installed python2 with Debian, and mailman does not know how to use it (Debian installs python2 as /usr/bin/python2, and /usr/bin/env python points to the python1x version.)
But this must be a debian issue ;)
-- Fil
On Tue, Feb 20, 2001 at 12:50:13PM +0100, Fil wrote:
@ Thomas Wouters (thomas@xs4all.net) :
The README clearly states what version of Python you need to run Mailman. It currently says:
Mailman requires Python 2.0 or greater, which can be downloaded from [...]Future versions will probably require Python 2.1 ;)
All right. But. I've installed python2 with Debian, and mailman does not know how to use it (Debian installs python2 as /usr/bin/python2, and /usr/bin/env python points to the python1x version.)
So either point 'python' to 'python2', or change all scripts to point to the right python executable.
But this must be a debian issue ;)
Partly, yes.
-- Thomas Wouters <thomas@xs4all.net>
Hi! I'm a .signature virus! copy me into your .signature file to help me spread!
So either point 'python' to 'python2', or change all scripts to point to the right python executable.
Well I hoped ./configure --with-mail-gid=65534 --with-python=/usr/bin/python2 would do it.
But this must be a debian issue ;) Partly, yes.
The explanation is here; python2.0 does not have the right license for Debian. Consequence: mailman is currently not compatible with debian.
http://lists.debian.org/debian-python-0102/msg00028.html
-- Fil
On Tue, Feb 20, 2001 at 01:06:42PM +0100, Fil wrote:
So either point 'python' to 'python2', or change all scripts to point to the right python executable.
Well I hoped ./configure --with-mail-gid=65534 --with-python=/usr/bin/python2 would do it.
It should, probably, but it doesn't work for the scripts in bin/... Not sure why that is. Barry ?
But this must be a debian issue ;) Partly, yes.
The explanation is here; python2.0 does not have the right license for Debian. Consequence: mailman is currently not compatible with debian.
That's not the reason for the python<->python2 difference, or at least shouldn't be. If the licence isn't right, python2 shouldn't be distributed at all ;) The name change is to avoid breakage in running scripts, because of a few subtle changes in python 2.0.
-- Thomas Wouters <thomas@xs4all.net>
Hi! I'm a .signature virus! copy me into your .signature file to help me spread!
"TW" == Thomas Wouters <thomas@xs4all.net> writes:
TW> It should, probably, but it doesn't work for the scripts in
TW> bin/... Not sure why that is. Barry ?Because the scripts in bin/ use the "/usr/bin/env python" trick. You need a symlink from "python -> python2" somewhere earlier in your $PATH.
I'm not enthusiastic about changing this in the Mailman source, since I'm disappointed at Debian's decision.
-Barry
@ Barry A. Warsaw (barry@digicool.com) :
"TW" == Thomas Wouters <thomas@xs4all.net> writes:
TW> It should, probably, but it doesn't work for the scripts in TW> bin/... Not sure why that is. Barry ?Because the scripts in bin/ use the "/usr/bin/env python" trick. You need a symlink from "python -> python2" somewhere earlier in your $PATH.
Well: I've symlinked /usr/bin/python to /usr/bin/python2, and another error pops up : does mailman need some python libraries which are not in python2-base ?
miel:~# /home/mailman/bin/newlist Traceback (most recent call last): File "/home/mailman/bin/newlist", line 56, in ? from Mailman import MailList File "/home/mailman/Mailman/MailList.py", line 34, in ? from mimelib.address import getaddresses ImportError: No module named mimelib.address
"F" == Fil <fil@rezo.net> writes:
F> Well: I've symlinked /usr/bin/python to /usr/bin/python2, and
F> another error pops up : does mailman need some python libraries
F> which are not in python2-base ?Yes, I thought my announcement of the Big Changes included a pointer to mimelib. It is not yet integrated, but will be for a future release.
http://barry.wooz.org/software/pyware.html-Barry
At 06:29 PM 2/20/01 +0100, Fil wrote:
Well: I've symlinked /usr/bin/python to /usr/bin/python2, and another error pops up : does mailman need some python libraries which are not in python2-base ?
miel:~# /home/mailman/bin/newlist Traceback (most recent call last): File "/home/mailman/bin/newlist", line 56, in ? from Mailman import MailList File "/home/mailman/Mailman/MailList.py", line 34, in ? from mimelib.address import getaddresses ImportError: No module named mimelib.address
If you're gonna run alpha code, you really need to read the developers list; Barry pointed out quite clearly early on that you needed Python 2.0, *and* you needed his mimelib module which wasn't in the mailman tree yet, and gave the website to get it from. There's a bunch of problems with 2.1 right now, and if you've been noticing over the last few days there's been a flurry of bug reports and patches (mostly from me, as I slam into them :-)), so it's a little more of a "hands on" release (not surprising, since it's an alpha.) In fact, until the next round of checkins happens, it mostly wont work at all without the patches I recently posted.
On Tue, Feb 20, 2001 at 12:22:11PM -0500, Barry A. Warsaw wrote:
"TW" == Thomas Wouters <thomas@xs4all.net> writes:
TW> It should, probably, but it doesn't work for the scripts in TW> bin/... Not sure why that is. Barry ?
Because the scripts in bin/ use the "/usr/bin/env python" trick. You need a symlink from "python -> python2" somewhere earlier in your $PATH.
But why provide the --with-python configure option if you end up having to have python in your path after all ? It would make more sense if it allowed pointing to a working python anywhere. I can think of several situations where that might be desirable, for security or debugging purposes, and only one of them is "because I run debian" :-)
-- Thomas Wouters <thomas@xs4all.net>
Hi! I'm a .signature virus! copy me into your .signature file to help me spread!
"TW" == Thomas Wouters <thomas@xs4all.net> writes:
TW> But why provide the --with-python configure option if you end
TW> up having to have python in your path after all ? It would
TW> make more sense if it allowed pointing to a working python
TW> anywhere. I can think of several situations where that might
TW> be desirable, for security or debugging purposes, and only one
TW> of them is "because I run debian" :-)Mostly because I didn't want to have .in files for every script in bin/. It didn't occur to me that a distro would rename the Python executable to something other than `python'. It might be time to autoconf templatize those bin/ scripts.
-Barry
"TW" == Thomas Wouters <thomas@xs4all.net> writes:
TW> The README clearly states what version of Python you need to
TW> run Mailman. It currently says:
>> Mailman requires Python 2.0 or greater, which can be downloaded
>> from [...]Yup, I've announced that requirement long ago. Python 2.0 has too many great features (and bug fixes!) to ignore.
TW> Future versions will probably require Python 2.1 ;)I'm going to try to avoid that, if possible, especially since Python 2.1 isn't even in beta testing yet!
"F" == Fil <fil@rezo.net> writes:
F> All right. But. I've installed python2 with Debian, and mailman
F> does not know how to use it (Debian installs python2 as
F> /usr/bin/python2, and /usr/bin/env python points to the
F> python1x version.)Two things. You can use the --with-python configure option to choose which Python executable gets compiled into the source. Second, add a symlink somewhere on your $PATH so that your shell finds /usr/bin/python2 before wherever python1.x is installed.
"F" == Fil <fil@rezo.net> writes:
F> The explanation is here; python2.0 does not have the right
F> license for Debian. Consequence: mailman is currently not
F> compatible with debian.
F> http://lists.debian.org/debian-python-0102/msg00028.htmlTwo comments, which I'm not directing at the Debian folks because they need to make their own decisions, and because I don't know who at Debian to direct these to.
First, I don't buy the backwards compatibility argument. Yes, some code broke, but it was broken anyway (people using undocumented APIs). The broken code is easily fixed.
Second, while the Python 1.6 license (which is included by value in Python 2.0) is /technically/ incompatible with the GPL, it is in spirit compatible. The incompatibility really is a technicality of the license language and not of philosophy, and I'm very confident that an agreement between the FSF and CNRI will allow a release of Python 1.6.1 (and hence Python 2.0.1) with this technicality erased. Don't ask me about an ETA on that; if I had any influence over the process at all, it would have happened a long time ago. The FSF and CNRI are like the proverbial rock and hard place, and we're the ones stuck in the middle.
All that having been said, I specifically asked RMS if he had any problems with me basing future Mailman releases on Python 2.0. He said he did not.
-Barry
On Tue, Feb 20, 2001 at 12:20:27PM -0500, Barry A. Warsaw wrote:
First, I don't buy the backwards compatibility argument. Yes, some code broke, but it was broken anyway (people using undocumented APIs). The broken code is easily fixed.
That is not something you can sell very easily, Barry. From the perspective of providing a service to a lot of third parties, with at best a varying cluelevel, upgrading is a very scary thing. I may seem very conservative on python-dev, wrt. backwards compatibility, but I assure you I'm quite the radical compared to some people, and compared to myself when considering upgrades on production platforms :)
For instance, because we run webservers that serve over 10k domains, I am very cautious in upgrading Apache, PHP or GD-lib on those machines. Yet every time I do it, after careful consideration, I 'break' some websites that were conciously or unconciously depending on a bug in some piece of that software, or linked to a fixed version of a library, or using an obsolete API. They might have been wrong in doing so, but from their perspective it's very simple: it worked, *we* changed something, and now it no longer works.
Nevertheless I do think Debian is going a bit over the wall in this case, since they have a very clear distinction between stable, testing and unstable trees. They could certainly switch python to python2 in the unstable tree, since it'll be some time before that tree is going into testing, and more yet before it's stable. It may have something to do with the missing readline support in python2, though -- the disabling of modules people might depend on falls under backwards compatibility again :)
-- Thomas Wouters <thomas@xs4all.net>
Hi! I'm a .signature virus! copy me into your .signature file to help me spread!
"TW" == Thomas Wouters <thomas@xs4all.net> writes:
TW> That is not something you can sell very easily, Barry. From
TW> the perspective of providing a service to a lot of third
TW> parties, with at best a varying cluelevel, upgrading is a very
TW> scary thing. I may seem very conservative on python-dev,
TW> wrt. backwards compatibility, but I assure you I'm quite the
TW> radical compared to some people, and compared to myself when
TW> considering upgrades on production platforms :)Upgrading sucks. It always breaks something, and the only way to avoid that is to never upgrade! But I can appreciate the sentiment. I think it was Jakob Neilsen who said, when he was talking about the rate that users upgrade their browsers, that it takes about 2 years to get the majority of users to upgrade to a new version. If Python adoption follows the same curve, I suspect that we'll still see significant Python 1.5.2 usage for another 18 months or so. :}
TW> Nevertheless I do think Debian is going a bit over the wall in
TW> this case, since they have a very clear distinction between
TW> stable, testing and unstable trees. They could certainly
TW> switch python to python2 in the unstable tree, since it'll be
TW> some time before that tree is going into testing, and more yet
TW> before it's stable.I don't keep up on Debian release procedures, but that sounds like the right approach to me.
TW> It may have something to do with the missing readline support
TW> in python2, though -- the disabling of modules people might
TW> depend on falls under backwards compatibility again :)And now we're back to the licensing issues. Which suck worse than anything else. I'd rather be debating the merits of indentation for blocking with a devote obfuscated C code hacker than sit in another room with lawyers debating licenses.
-Barry
On Tue, Feb 20, 2001 at 12:20:27PM -0500, Barry A. Warsaw wrote:
F> The explanation is here; python2.0 does not have the right F> license for Debian. Consequence: mailman is currently not F> compatible with debian. F> http://lists.debian.org/debian-python-0102/msg00028.htmlTwo comments, which I'm not directing at the Debian folks because they need to make their own decisions, and because I don't know who at Debian to direct these to.
First, I don't buy the backwards compatibility argument. Yes, some code broke, but it was broken anyway (people using undocumented APIs). The broken code is easily fixed.
You're right and that's not it. For instance bash2 wasn't fully compatible with bash1, but while Red Hat never had the balls to push bash2 as default bash, debian did, even though it broke a few things that were really errors in the user scripts.
The problem is that if the license was categorized as non free according to Debian's free software guidelines, they fork the package so that you can decide to run python from debian main, or python2 from non-free. Had they called python2, python, there would have been no way for a user to keep the 'free' python if he/she had non-free in his/her list of package sources.
This is merely a packaging issue.
Marc
PS: don't flame me about what's free or non free, I know nothing about this specific issue, I'm just explaining what the technical reasons for the package split would be.
Microsoft is to operating systems & security .... .... what McDonalds is to gourmet cooking
Home page: http://marc.merlins.org/ | Finger marc_f@merlins.org for PGP key
"MM" == Marc MERLIN <marc_news@valinux.com> writes:
MM> PS: don't flame me about what's free or non free, I know
MM> nothing about this specific issue, I'm just explaining what
MM> the technical reasons for the package split would be.Thanks, very helpful!
-Barry
participants (6)
-
barry＠digicool.com -
Fil -
Marc MERLIN -
Ralph Corderoy -
Ron Jarrell -
Thomas Wouters