On Fri, Jan 15, 2010 at 11:45:05AM -0500, David Malcolm wrote: > On Fri, 2010-01-15 at 10:55 -0500, Toshio Kuratomi wrote: > > This reasoning (needed for testing) doesn't appeal to me at all. The > > general case should be that we switch applications in rawhide from python2 > > to python3. Test those packages in rawhide. If it works, then the nex > > version of Fedora ships with those scripts using the python3 interpreter. > > I ran this on my F-12 laptop (running a mix of software, with a local > build of python3 and python3-setuptools): > [david@brick ~]$ (for f in /usr/bin/* ; do (file --brief $f | grep > python > /dev/null) && echo $f ; done) > python-executables.txt > [david@brick ~]$ wc -l python-executables.txt > 142 python-executables.txt > > I think that we can usefully split these python scripts into two > categories, as follows. For those in the first category it makes sense > to keep both python 2 and python 3 versions around. For those in the > second, we'd want to gradually move them over to Python 3 as the > dependencies are ported (which in itself is a large task...) > I think this is the right general approach. I wouldn't express the categoriesin quite the same manner, though: > = Support files for the Python language = > These scripts are for working with the language itself, or a stack/major > library built on top of Python; a Python developer would typically want > both versions available for use, or for testing: > /usr/bin/2to3 > /usr/bin/2to3-3 > /usr/bin/bpython > /usr/bin/coverage > /usr/bin/django-admin > /usr/bin/easy_install > /usr/bin/easy_install-2.6 > /usr/bin/easy_install-3.1 > /usr/bin/g-ir-scanner > /usr/bin/idle > /usr/bin/idle3 > /usr/bin/pydoc > /usr/bin/pydoc3 > /usr/bin/pygtk-demo > /usr/bin/python2 > /usr/bin/python2.6-config > /usr/bin/python3.1-config > /usr/bin/python3-config > /usr/bin/python-config > /usr/bin/testosterone > When I look at these, I think the basic test I'd make is: do the binaries provide different functionality depending on whether you run the python2 or python3 version? Something like 2to3 is an example of something that does not need to have both a python2 and python3 version. It takes py2 input files and outputs py3 files. There should not be any difference whether it's invoked with the python2 interpreter or the python3 interpreter. (OTOH, I can see making an exception to the general rule for things that are shipped in the python3 upstream package, which would allow 2to3 in). Some of these I know are correct to be in this list (bpython, easy_install [although that's a limitation of easy_install; could be fixed in the future]), pygtk-demo, python*-config. Others I'm not sure: coverage, django-admin, g-ir-scanner, idle, testosterone. The question is basically: Does the program only operate on python2 xor python3 depending on which interpreter it was built with? Are coverage and testosterone only able to evaluate python modules that are of matching type? (Could be yes if they're attempting to run those modules in process). Does django-admin generate python2 or python3 templates depending on which it was built for and does not have a commandline switch to generate templates for the other (or other functionality... maybe there's a django-admin shell command where the python interpreter and the build of django-admin must match). Does g-ir-scanner only create python2 or python3 output? It can't do one or the other based on a command line switch? Does idle3 not do something that idle2 can do (like dosource highlighting of python2 files)? (Thisisbundled with the python3 package, though) -Toshio
Attachment:
pgp9aFyNvxSut.pgp
Description: PGP signature
-- devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/devel
