Re: Please wait before bloating Debian with python2- packages
On Jan 22, J?r?me Marant wrote: I've recently seen some python2- modules being uploaded into Incoming. It seems that people did not read our previous thread and prefer to duplicate package for all Python interpreters. This is all non-sense. Please realize that this will bloat Debian an unconsistant way. Rob recently came up with an interesting proposal, inspired from emacsen way of installing modules. I don't know if he had a deeper look in it and if he started implementing something since then. Matthias, Gregor, what do you think of this? Thanks. Right now, I'm ready to help on implementing something but I don't want that we duplicate our efforts. Rob, did you start something ? Unfortunately, this argument doesn't apply to binary modules, which are specific to the particular version of the interpreter (IIRC). That's why python2-pqueue is there. I suppose you could put both 1.5 and 2.0 modules in one package and depend on python-base (= 1.5.2) | python2-base, but I really didn't think of that at the time... In any event, there are good technical reasons to keep both 1.5 and 2.0 for now that have nothing to do with the GPL issue. Chris -- Chris Lawrence [EMAIL PROTECTED] - http://www.lordsutch.com/chris/ Computer Systems Manager (Physics Astronomy, 125 Lewis, 662-915-5765) Instructor, POL 101 (Political Science, 208 Deupree, 662-915-5949)
[EMAIL PROTECTED]: Bug#101165: reportbug fails to install]
Anyone have a clue what might cause this? I'm stumped.
Chris
--
Chris Lawrence [EMAIL PROTECTED] - http://www.lordsutch.com/chris/
---BeginMessage---
Package: reportbug
Version: 1.17
Whenever I try to install reportbug I get the following:
Setting up reportbug (1.17) ...
/var/lib/dpkg/info/reportbug.postinst: line 34: 2810 Segmentation fault
python -O /usr/lib/python1.5/compileall.py -q $i
dpkg: error processing reportbug (--configure):
subprocess post-installation script returned error exit status 139
Linux d-ni 2.4.4 #1 Sat May 5 17:48:03 EST 2001 i686 unknown
a few package versions below:
ii dpkg 1.9.9 Package maintenance system for Debian
ii python-base1.5.2-16 An interactive object-oriented
scripting lan
ii python-newt0.50.17-7 A newt module for Python.
--
/\ Joanne Rosemary Hunter
\ / ([EMAIL PROTECTED]) {http://menagerie.tf/~jrhunter}
X --(ASCII Ribbon Campaign - No HTML Mail or postings!)
/ \ Of course I don't know how interesting any of this really is,
but now you've got it in your brain cells so you're stuck with it.
-Gary Larson
---End Message---
Re: Status report on python2 transition
as debs. This may or may not be a problem (some people may want to track CVS). I think this covers all of the important issues though. It may be needlessly complex, but it does support users having whatever Pythons they want installed and should allow most things to work. Chris -- Chris Lawrence [EMAIL PROTECTED] - http://www.lordsutch.com/chris/
Re: Status report on python2 transition
On Jul 12, Bruce Sass wrote: On 12 Jul 2001, Jérôme Marant wrote: Bruce Sass [EMAIL PROTECTED] writes: Surely adopting a convention of... #!/usr/bin/env python[major.minor] ...is preferable. It does the same thing without additional runtime overhead and without creating a class of Debian-specific Python programs. I object to this. It make scripts not portable to other systems as it currently does with current python 2.0 scripts in Debian. We shall end up with this trick as soon as possible. How not portable? Any build of Python I have done installs both: bin/pythonmajor.minor and bin/python as hardlinks... ...calling python-wrapper to execute the program is definately not portable to other systems. True... but it would only be done by Python scripts in Debian packages that depend on external modules. The problem with a hardcoded version in the #! path is that it locks the script into running with that version. Let me give you a for instance: - I create a package that uses and depends on python-newt. Python-newt is only supplied for Python 1.5 at the moment, so I hardcode a call to /usr/bin/python1.5 - python-newt's maintainer releases a new python-newt that works with python 2.1, and drops python 1.5 support. - I install the new python-newt (and probably a lot of the python-2.1-*) - My package is now broken and I have to reupload it, even though all I need to change is the #!. With python-wrapper: - python-newt's maintainer does the right black magic with the python-wrapper business. - I create a package that uses and depends on python-newt. I call /usr/bin/python-wrapper. - python-newt's maintainer releases a new python-newt that works with python 2.1, and drops python 1.5 support. - I install the new python-newt (and probably a lot of the python-2.1-*) - My package still works fine, since python-wrapper knows that this version of python-newt needs python 2.1 to run. Now, two questions arise from all this: - Are we willing to have One and Only One Python in each stable release? If so, screw this python-wrapper business. It really doesn't solve any problems with locally-installed Pythons, except by making sure Debian packaged python programs don't use local pythons. But we will need to figure out some way to cleanly deal with not having python 1.5 in woody (a long Conflicts line looks likely). - If we aren't willing to do this, then we either live with a lot of messy dependencies that have to be updated every time a new x.y python comes out, or go with something like python-wrapper that leaves dealing with new Pythons mostly painless. The only other solution is to call python-wrapper /usr/bin/python, and make it fallback to calling a Python interpreter (defined by alternatives or whatever) if no suitable wrapper is found. That is completely portable, except in the case where /usr/bin/python is expected to be an ELF binary (does freeze need this?), but it adds overhead to every invocation. I have nothing invested one way or the other, mind you. Chris -- Chris Lawrence [EMAIL PROTECTED] - http://www.lordsutch.com/chris/ Instructor and Doctoral Student, Political Science, Univ. of Mississippi 208 Deupree Hall - 662-915-5949
Re: Python upgrade path (draft/proposal)
On Oct 17, Matthias Klose wrote:
With the last python-1.5.2-18.2 NMU we have non-conflicting python1.5,
2.0 and 2.1 packages in unstable, not more not less.
Here two proposals, how to go further on. The first proposal is a
safer proposal (but needs more uploads and needs loong). The second
proposal accepts some breakage during the upgrade, but is a bit
shorter.
[...]
Each package maintainer should decide, if he only supports the
default python version, or more than one version (the policy
should make this clear).
a) support the default version only: Name your package
python-XXX (for a library). Make your package depend on
python-base (= 2.1), python-base ( 2.2).
b) support more than one python version: Make packages
python1.5-XXX and python2.1-XXX and a package python-XXX.
The python1.5-XXX and python2.1-XXX packages should depend
on python1.5-base and python2.1-base, the python-XXX
package should depend on of of the python1.5-XXX or
python2.1-XXX packages.
If maintainer A (maintaining python-FOO (depending on
python-base (= 2.1), python-base ( 2.2)) decides for (a),
then a maintainer B should be allowed to repackage
python1.5-FOO, if his package cannot be converted to
use the default python version.
May I suggest a simpler alternative for (b) (or maybe an alternative c):
Make package python-XXX containing support for both python 1.5 and
python 2.1. For each python {1.5,2.1} that is installed, bytecompile
the package's .py files on install. Since we use
/usr/lib/pythonx.y/site-packages, it won't hurt anything if the
other version is not installed. If the files are identical, they
should only appear in the package once (use hard links or symlinks,
but don't symlink directories because of .py[co]). Depend on
python-base (= 1.5.2-1) and nothing should break. Build-depend on
both python1.5-base and python2.1-base.
Since the buildds need both versions installed to make
python{2.1,1.5}-X anyway, this approach doesn't cause them any extra
problems.
The only downside is that people with one installed python will get
extra cruft installed, but the use of links should minimize it. I'd
follow this alternative unless the package consists entirely of .so
files and the .so files are *big*.
I can build a new python-pqueue as an example if anyone wants to see
how this might work in practice...
Chris
--
Chris Lawrence [EMAIL PROTECTED] - http://www.lordsutch.com/chris/
Instructor and Doctoral Student, Political Science, Univ. of Mississippi
208 Deupree Hall - 662-915-5765
Re: Python upgrade path (draft/proposal)
On Oct 18, Matthias Klose wrote:
May I suggest a simpler alternative for (b) (or maybe an alternative c):
Make package python-XXX containing support for both python 1.5 and
python 2.1. For each python {1.5,2.1} that is installed, bytecompile
the package's .py files on install. Since we use
/usr/lib/pythonx.y/site-packages, it won't hurt anything if the
other version is not installed. If the files are identical, they
should only appear in the package once (use hard links or symlinks,
but don't symlink directories because of .py[co]). Depend on
python-base (= 1.5.2-1) and nothing should break. Build-depend on
both python1.5-base and python2.1-base.
Depend on python-base (= 1.5.2-1), python-base ( 2.2), or do you
_know_ the future ;-? You have to make a new upload, but it's an
acknowledgement by the package that he actually tested the package
with the new version.
I typo'ed here. I meant python1.5-base | python2.1-base.
Since the buildds need both versions installed to make
python{2.1,1.5}-X anyway, this approach doesn't cause them any extra
problems.
The only downside is that people with one installed python will get
extra cruft installed, but the use of links should minimize it. I'd
follow this alternative unless the package consists entirely of .so
files and the .so files are *big*.
Is it really simpler?
- from the user's point of view, you have to install packages you
don't want.
Well, you have to install *files* you don't want, but you don't need
all of the pythonX.Y-base packages, just the particular version you
want to use. The point is that the user doesn't have to care which
Python he has installed to figure out which extension to use; it just
works.
- from the package maintainer's point of view,
* you have to make new uploads every time a new python is installed/
adjust your packaging rules.
Well, you have to do that anyway, regardless.
* you have to make sure your symlink system works for every single
package. I would prefer a system, availabe in python-base, but
then each package would have to pre-depend on python-base.
I haven't tested it with a package that installs .py files. I may try
to do it with reportbug this weekend and share my results.
* it's limited to arch independent packages. python1.5 and python2.1
have different ABIs. I didn't look at 2.1 and 2.2 compatibility.
No, arch dependent packages can have separate so files for each major
version of Python; see python-pqueue 0.2-3 for an example. It's
actually easier with arch dependent packages because you're not
duplicating files.
i.e. there is:
/usr/lib/python1.5/site-packages/pqueuemodule.so
/usr/lib/python2.1/site-packages/pqueuemodule.so
two modules, compiled against the appropriate pythonX.Y-dev packages.
The beauty of it is that if you don't have one version installed, it
doesn't matter, except for the disk space you're using. (Hence why I
said not to use it for big .so files, where big is probably = 100k or
so.)
Anthony Towns describe a register/unregister system in
http://lists.debian.org/debian-python/2001/debian-python-200110/msg00066.html
Do you want to give it a try?
That much overhead may not be necessary; really, all you need to do in
your postinst is (in Python... adjust to sh as you see fit):
for version in glob.glob('/usr/bin/python?.?'):
sys.system(version+' compileall.py
/usr/lib/'+version+'/site-packages/my-package')
sys.system(version+' -O compileall.py
/usr/lib/'+version+'/site-packages/my-package')
Seems short, simple, and to the point. The only downside is you won't
automatically get new .pyc and .pyo files every time you install a new
major version (in which case it might be nicer to go with something
like a register/unregister system... YMMV).
Chris
--
Chris Lawrence [EMAIL PROTECTED] - http://www.lordsutch.com/chris/w
Re: Final draft of Python Policy (hopefully ;-)
On Oct 27, Gregor Hoffleit wrote: I've put a version 0.3.6 of the Python Policy Draft on http://people.debian.org/~flight/python/. The version is still a little bit rough and sometimes incomplete, but it already gives a good outline of the Python packaging system we are installing just now. Please have a look at the document, and post all fundamental problems you have with the content. If nobody find fundamental show-stoppers that render this unusable, we're going to submit it to Debian Policy very soon. My main concern is that the policy seems to force the installation of the default version to use anything in the distribution that uses python... a few comments, focusing on section 2: - If a package works with any version of Python in the archive, is there a setup that allows users to choose which version of Python they want to have installed? Or are they stuck with the default version? - If not, how is /usr/bin/python going to be handled? We threw out using an alternative for it, but that was when we were still calling the default version python-base. If the default version isn't installed, presumably /usr/bin/python doesn't exist under the current setup. What do you use for a #! then? - Why is the following statement in the policy (2.1.1)? You should not make a default, unversioned module package python-foo depend on the versioned Python package pythonX.Y! 'Depends: pythonX.Y' appears to be synonymous to 'Depends: python (= X.Y), python ( X.Y+1)'. Is this some sort of newbie-friendliness we're going for? If so, why? The only good reason I can think of is to have a parallel between the python-foo/python and pythonM.N-foo/pythonM.N names. But since that's rather user-invisible (it's a dependency), I don't quite see the point. - Should 2.1.1 require python-foo to provide pythonX.Y-foo? - Again in 2.1.1: Should any new python-foo conflict with python-base (= 1.5.2-18.4) so python-base has to be upgraded for python-foo to be upgraded too? (Could this get rid of the whole conficts problem in python core?) - Would it be cleaner to make all pythonX.Y-foo provide python-foo, so any version-independent package that needs foo can depend on python-foo? If we did this (and got rid of the Depends funkiness) we could throw out 2.1.1 completely, as it would be a special case of 2.1.2. - 2.1.2.2, or some other part of the policy, should explicitly prohibit the use of /usr/lib/site-python, as it is deprecated upstream. - I'm not sure in 2.1.2.2 that /usr/lib/python/site-packages is a good name... maybe /usr/share/python/site-packages instead. (After all, the things should be arch independent.) I'd be happy to code up the symlink thingamajig for 2.1.2.2 if nobody's working on it. - Perhaps instead of a dependency on python (= X.Y+1), 2.1.2.2 should say packages should confict with python ( X.Y+1), unless we want to force everyone to have the default version installed. - Maybe the rationale should be at the beginning of section 2... it would make the rest of the section more understandable. - (editorial nit) There seems to be a superfluous in the rationale. Anyway, feel free to rip away... Chris -- Chris Lawrence [EMAIL PROTECTED] - http://www.lordsutch.com/chris/
Re: what to do about python-kjbuckets
On Nov 04, Matthias Klose wrote: Donovan Baarda writes: On Sun, Nov 04, 2001 at 05:23:30PM +0100, Joel Rosdahl wrote: [...] But there is a problem: The current (from 1997) upstream version[1] doesn't work with Python = 2.0. Now, Berthold Hoellmann, Oleg Broytmann and others have ported[2] kjbuckets to work with newer Pythons, but it's not as official as one could hope. For instance, the version number is still the same as the old upstream version (2.2). I'm not sure what to do. Here's a couple of solutions: [...] 2) Only make a python1.5-kjbuckets package. (Nah.) [...] 5) Use date in version, i.e. 2.2.port.20011104 or similar. (Best solution I can come up with.) [...] I would hope that you also make a python1.5-kjbuckets so that older python1.5 programs that used it can still use it. You them also make a python2.2-kjbuckets (2.2.0-port.20011104) package if you want something newer. do we really need 1.5 support? gadfly was just orphaned, someone would have to look at routeplanner. Can these packages use 2.1? routeplanner runs under Python 2.1 with no modifications, and works with the unofficial kjbuckets. I'm mainly waiting on python-gnome to get updated... It will run without kjbuckets at all, but there's about a 15% performance penalty under Python 1.5. Dunno about 2.x... Chris -- Chris Lawrence [EMAIL PROTECTED] - http://www.lordsutch.com/chris/
python-gnome: float weirdness with gnome.ui is back
reassign 119951 python-gnome, routeplanner-gnome retitle 119951 python-gnome: float() works incorrectly after import gnome.ui thanks On Nov 17, Sebastian Rittau wrote: Package: routeplanner-gnome Version: 0.12 Severity: important After starting the Gnome routeplanner frontend and trying to open /usr/share/routeplanner/Basic-USA.rpl3.gz I get the following stack trace on the console: [EMAIL PROTECTED]:~$ grplan Traceback (most recent call last): [...] File /usr/share/routeplanner/rpcity.py, line 36, in __init__ self.longitude = float(data[2]) ValueError: invalid literal for float(): 0.000 The Loading Cities requester then hangs a 0%. I've done some more tracking. Here's the interesting result: $ [EMAIL PROTECTED] rpcli NorthAmerica.rpl3 * This works $ [EMAIL PROTECTED] grplan NorthAmerica.rpl3 * This doesn't work The reason: from gnome.ui import * does something nasty to the locale settings that stops float() from working. Python's float builtin (like int) is supposed to work in the C locale all of the time; even if you do locale.setlocale(LC_ALL, ) in a program, the only things that are affected are in the locale module itself. Even doing import gnome.ui triggers the bug. I don't know what exactly is going on, but it's probably something in python-gnome. I'm passing this along to its maintainer. (Torsten: I suspect the fix for #59713 got rolled back somewhere along the line, or something similar is going on elsewhere in the code.) Chris -- Chris Lawrence [EMAIL PROTECTED] - http://www.lordsutch.com/chris/ Instructor and Ph.D. Candidate, Political Science, Univ. of Mississippi 208 Deupree Hall - 662-915-5765
Re: Python and Emacs
On May 21, Jérôme Marant wrote: I'm sorry, this may be a bit off topic but I don't really know where I can post this question. I'm a bit annoyed with Emacs when editing Python programs because Emacs always replaces TABs with spaces ; this wouldn't bother me if Emacs was the only editor in the world. But when you share programs with others, it is better to have real TABs instead of spaces. I know about the C-q TAB but I don't want to use it every time I want automatic indentation. Does anyone know how to achieve this? When you're done editing... C-x h M-x tabify Of course, we all know that using tabs in Python code is Evil. :-) Chris -- Chris Lawrence [EMAIL PROTECTED] - http://www.lordsutch.com/chris/ Instructor and Ph.D. Candidate, Political Science, Univ. of Mississippi 208 Deupree Hall - 662-915-5765 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bug#148415: jack: should use #!/usr/bin/python
On Jun 23, Michael Banck wrote: Hi, On Tue, May 28, 2002 at 05:22:32PM -0500, Chris Lawrence wrote: Some users may have a local version of Python installed (like Python from CVS), so jack should use the path to the default Debian version of Python rather than using /usr/bin/env. As Python-policy says: 1.3.2. Interpreter Location The preferred specification for the Python interpreter is `/usr/bin/python' or `/usr/bin/pythonX.Y'. If a maintainer would like to provide the user with the possibility to override the Debian Python interpreter, he may want to use `/usr/bin/env python' or `/usr/bin/env pythonX.Y'. I'll close this bug, OK? Not OK, since the locally-installed Python may not/will not have access to jack's site-python files. Using /usr/bin/env python is IMHO only acceptable if the package is self-contained or munges sys.path to include any non-standard modules in the search path. Chris -- Chris Lawrence [EMAIL PROTECTED] - http://www.lordsutch.com/chris/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: python2.2 for sarge?
On Jul 25, Matthias Klose wrote: My current plan is: - upload python2.3 packages soon (when 2.3alpha1 is released) - remove python1.5 from unstable - adopt python-central for 2.1, 2.2 and 2.3, hopefully with the help of the author, hint, hint - upload python2.3 beta to unstable - make it the python default - remove python2.1 from unstable I don't see much sense in making the switch to 2.2 now and then again to 2.3. But anyway, let's make unstable really unstable first by switching to gcc-3.2 as the default compiler (coming soon :-) I don't think python2.1 should be dropped until sarge+1; keeping around the previous default Python in the next release is probably a good idea as general policy. I also wouldn't bother switching to 2.2 as the default if 2.3 is going to be the default by December. Chris -- Chris Lawrence [EMAIL PROTECTED] - http://www.lordsutch.com/chris/ Instructor and Ph.D. Candidate, Political Science, Univ. of Mississippi 208 Deupree Hall - 662-915-5765 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: standard Python build for Debian distributions
On Aug 14, Damon Fasching wrote: Are there any plans to include packages like distutils in the standard Debian distribution? distutils is in the python-dev package; there are other python-* packages with various other components of the batteries included Python distribution. Chris -- Chris Lawrence [EMAIL PROTECTED] - http://www.lordsutch.com/chris/ Computer Systems Manager, Physics and Astronomy, Univ. of Mississippi 125B Lewis Hall - 662-915-5765
Re: Maintaining Python 1.5
On Sep 10, Matthias Klose wrote: Moshe Zadka writes: I was wondering if you mind passing Python 1.5 maintainership to me. I do not mind passing the maintainership, but I do mind keeping it in unstable. Debian is not a museum for old python versions. What hinders you to install the python1.5 packages from woody in unstable? apt tagging is your friend. Well, two problems I can see: 1. Woody will eventually go away to archive.debian.org land, not long after sarge is released. 2. There are woody Python packages that want libdb1, which disappears from libc6 in sid/sarge. I agree we shouldn't keep it around forever, but it seems like as long as people are using python1.5 with post-woody we should keep it. Chris -- Chris Lawrence [EMAIL PROTECTED] - http://www.lordsutch.com/chris/ Computer Systems Manager, Physics and Astronomy, Univ. of Mississippi 125B Lewis Hall - 662-915-5765
[rene@debian.org: Bug#165356: reportbug creates snow mail text]
For the third time, *I THOUGHT PYTHON 2.2 WAS FEATURE-FROZEN*. This email module crap is ridiculous... Chris -- Chris Lawrence [EMAIL PROTECTED] - http://www.lordsutch.com/chris/ Computer Systems Manager, Physics and Astronomy, Univ. of Mississippi 125B Lewis Hall - 662-915-5765 ---BeginMessage--- Package: reportbug Version: 2.5 Severity: grave Justfication: renders package unusable Hi, I just wanted to file a bug report using reportbug: [EMAIL PROTECTED]:~$ reportbug libc6 Using 'Rene Engelhard [EMAIL PROTECTED]' as your from address. Getting status for libc6... Verifying package integrity... Checking for newer versions at packages.debian.org... Your version (2.2.5-15) of libc6 appears to be out of date. The following newer release(s) are available in the Debian archive: unstable: 2.3.1-1 Do you still want to file a report [y|N|?]? y Will send report to Debian. Querying Debian bug tracking system for reports on src:libc6 (Use ? for help at prompts.) [...] Maintainer for libc6 is 'GNU Libc Maintainers debian-glibc@lists.debian.org'. Getting dependency information for libc6... Please briefly describe your problem (you can elaborate in a moment; an empty response will stop reportbug). libc6 2.3.1-1 breaks fetchmail/exim (and others?) [...] Please select a severity level: [normal] critical [...] Please select tags: [none] sid [...] This results in a message as follows in mutt: ---snip--- From: Rene Engelhard [EMAIL PROTECTED] To: Debian Bug Tracking System [EMAIL PROTECTED] Cc: Bcc: Rene Engelhard [EMAIL PROTECTED] Subject: libc6 2.3.1-1 breaks fetchmail/exim (and others?) Reply-To: X-Reportbug-Version: 2.5 X-Operating-System: Debian GNU/Linux X-GnuPG-Key: $ finger [EMAIL PROTECTED] UGFja2FnZTogbGliYzYKVmVyc2lvbjogMi4yLjUtMTUKU2V2ZXJpdHk6IGNyaXRpY2FsClRhZ3M6 IHNpZAoKCgotLSBTeXN0ZW0gSW5mb3JtYXRpb246CkRlYmlhbiBSZWxlYXNlOiB0ZXN0aW5nL3Vu c3RhYmxlCkFyY2hpdGVjdHVyZTogaTM4NgpLZXJuZWw6IExpbnV4IHN0YW4gMi40LjE4ICMyIE1v biBKdW4gMTcgMDM6Mzg6MDkgQ0VTVCAyMDAyIGk2ODYKTG9jYWxlOiBMQU5HPWRlX0RFQGV1cm8s IExDX0NUWVBFPWRlX0RFQGV1cm8KClZlcnNpb25zIG9mIHBhY2thZ2VzIGxpYmM2IGRlcGVuZHMg b246CmlpICBsaWJkYjEtY29tcGF0ICAgICAgICAgICAgICAgICAyLjEuMy02ICAgIFRoZSBCZXJr ZWxleSBkYXRhYmFzZSByb3V0aW5lcyBbZ2wKCi0tIG5vIGRlYmNvbmYgaW5mb3JtYXRpb24KCg== ---snip--- (signature snipped) I tried with another package, another severity, with or with no tags - always the same thing (although the snow is different) Regards, Rene -- .''`. Rene Engelhard -- Debian GNU/Linux Developer : :' : http://www.debian.org | http://people.debian.org/~rene/ `. `' [EMAIL PROTECTED] | GnuPG-Key ID: 248AEB73 `- Fingerprint: 41FA F208 28D4 7CA5 19BB 7AD9 F859 90B0 248A EB73 ---End Message---
Re: Move to python 2.2 as default release?
On Aug 14, Laura Creighton wrote: The new Python Business Forum (www.python-in-business.com) is collaborating with the Python developers to produce Python-in-a-Tie, a business-targetted release of Python. This is a 'Sumo-Release', which will include other useful Python libraries and programs which are not part of the standard Python releases. What we want is a release we tell our cyustomers to run which will give them 18 months or so during which there is no need for them, as users, not developers, to upgrade a to a newer version of Python. Then we will target a next release, and to be the next Python-in-a-Tie. I am the Chairman of the Python-in-a-Tie SIG, and the Python-in-a-Tie release is going to be based on 2.2, not 2.1 or 2.3. Thus 2.2 is the release which we are telling Python developers is the release which they should write for. Therefore I think that skipping the 2.2 release in favour of the 2.3 would be a mistake. Please cc any discussion and replies to me since I do not read debian-devel. Thanks very much, Laura: (and Guido et al.) Debian plans to support at least Python 2.2 and 2.3 in the next release (sarge); unlike other distributors, we do not have a problem with making multiple Python versions available so long as they are useful. If you need to target a specific release of Python (i.e. 2.2), you should use #!/usr/bin/env python2.2. However, the *default* Python shipped by Debian (i.e. /usr/bin/python) affects things within our distribution, and there may be wins for us basing on 2.3 rather than 2.2 (the enumerate builtin being an obvious, immediate example; universal newline support may also be important). Now, if 2.3 won't be stable until well into next year (as opposed to the schedule in PEP 283), then we may want to target 2.2.x as our default version. This is something that largely depends on our anticipated release schedule - which is not very calendar driven, but Q2 2003 is less likely to make sarge than Q4 2002. (Note that debian-python is probably the most appropriate list for followups.) Chris -- Chris Lawrence [EMAIL PROTECTED] - http://www.lordsutch.com/chris/
