| || swig || According to http://www.swig.org/news.php, Python 3 support was added to SWIG in 1.3.37 (released 2009-01-15); generated C code appears to be compilable against both Python 2 and Python 3 || Fedora 11 onwards has had a version of "swig" capable of generating code for both Python major-versions.

+

−

|-

+

−

| beaker || python-beaker || || In Fedora 14 onwards as '''python3-beaker''', built as a subpackage of python-beaker

+

−

|-

+

−

| chardet || python-chardet || Upstream releasing dual-purpose tarballs || In Fedora 13 onwards as '''python3-chardet''' (was RHBZ [https://bugzilla.redhat.com/show_bug.cgi?id=583186 #583186]), the [https://admin.fedoraproject.org/updates/python3-chardet-2.0.1-2.fc13 update] is now stable. Though not yet in the beta release, it will be in the final one.

| ply || python-ply || 2 and 3 from same tarball [http://www.dabeaz.com/ply/ from PLY-3.0 onwards]; README states "You should not convert PLY using 2to3 -- it is not necessary and may in fact break the implementation."

+

−

|| '''python3-ply''' in Fedora 13 onwards, built as a subpackage of python-ply

+

−

|-

+

−

| postgresql || || [http://python.projects.postgresql.org/ py-postgresql] || In Fedora 13 onwards as '''python3-postgresql''' (was {{bz|579280}}), though F-13 build is only available as [https://admin.fedoraproject.org/updates/python3-postgresql-1.0.0-1.fc13 an update]

| pygments || python-pygments || Upstream reports that [http://dev.pocoo.org/projects/pygments/ticket/448 "Pygments is already ported to Python 3. The same source release can be used for 2.x and 3.x installs"] || In Fedora 14 onwards as a '''python3-pygments'' subpackage of python-pygments (was {{bz|537244}})

| sqlalchemy || python-sqlalchemy || 0.6beta1 has py3k support from a single tarball.|| Packaged for F-14. Needs nose3 for running unittests of '''python3-sqlalchemy'''. Due to incompatible API, decided not to push back to F-13.

+

−

|}

+

==== Python 3 code not yet in Fedora ====

==== Python 3 code not yet in Fedora ====

−

{|

+

Moved to: https://fedoraproject.org/wiki/Python3#Python_3_code_not_yet_in_Fedora

| docutils || python-docutils || Website says: "From version 0.6 Docutils is compatible with Python 3, but requires 2to3." Note: Soft dependency on python-imaging which is not yet ported. We can make python3-docutils not use imaging with reduced functionality compared to the python2 version|| ''Anyone want to help with this? I'm strapped for time but willing to support it once it's in (toshio)'' '''awaiting review from packager''': {{bz|579567}}

| rpm || rpm-python (subpackage of "rpm")|| dmalcolm and pmatilai [http://dmalcolm.livejournal.com/3340.html ported the C extension for librpm to work with both python 2 and 3]; released as [http://www.rpm.org/wiki/Releases/4.8.0 rpm 4.8.0] || '''Needs packaging work''': see {{bz|531543}}

| nose || python-nose || This is the current nose3 branch [http://bitbucket.org/jpellerin/nose3/ on bitbucket]. Googlecode branch is out-of-date. This [http://code.google.com/p/python-nose/issues/detail?id=240 upstream ticket], indicates the trunk will move to python3 only, and python2 will be in maintenance mode but upstream has said that the current py2 branch is being worked on by others and the py3 branch is lagging behind.||

| Cheetah || python-cheetah || As of 2010-02-02, upstream site reports that [http://packages.python.org/Cheetah/roadmap.html#cheetah-v3-0 Python 3.xx support will be in Cheetah v3.0, but that it is "still in planning"]||

| gtk || pygtk2 || Not yet ready: https://bugzilla.gnome.org/show_bug.cgi?id=566641 Question: should we be using [http://live.gnome.org/GObjectIntrospection GIR] instead? (Or do both?)|| Need to finish upstream work

| nss || python-nss || Looks like it hasn't been ported yet, and would be non-trivial ||

+

−

|-

+

−

| PIL || python-imaging || As of 2010-01-28, upstream website says [http://www.pythonware.com/products/pil/ "The current free version is PIL 1.1.7. This release supports Python 1.5.2 and newer, including 2.5 and 2.6. A version of 1.1.7 for 3.X will be released later."] A 2010-02-21 mailing list post suggests that [http://mail.python.org/pipermail/image-sig/2010-February/006124.html the port is stalled] ||

| pylons || python-pylons || As of 2010-04-09, it's [http://wiki.pylonshq.com/display/pylonscommunity/Pylons+Roadmap+to+1.0 on the future roadmap for 1.1]; see also http://pylonshq.com/project/pylonshq/ticket/425 ||

+

−

|-

+

−

| wx || wxPython || As of 2010-02-03, appears not to be ported yet; see http://stackoverflow.com/questions/720806/wxpython-for-python-3-0 ||

+

−

|-

+

−

| xdg|| pyxdg || Appears to not yet be ported; see {{bz|555620}} ||

+

−

|}

+

=== mod_wsgi and mod_python ===

=== mod_wsgi and mod_python ===

Line 313:

Line 169:

=== Follow the "Dive Into Python 3" tutorial ===

=== Follow the "Dive Into Python 3" tutorial ===

−

If you've installed the python3 rpm, it should be possible for you to follow the tutorial on Python 3 given here: http://diveintopython3.org/

+

If you've installed the python3 rpm, it should be possible for you to follow the tutorial on Python 3 given here: http://diveintopython3.ep.io/

This is an excellent tutorial, and working through it with our RPMs makes a good test that all is working as expected (obviously it would be a major task to work through the whole book, but at least you'd learn a lot in the process).

This is an excellent tutorial, and working through it with our RPMs makes a good test that all is working as expected (obviously it would be a major task to work through the whole book, but at least you'd learn a lot in the process).

Line 416:

Line 272:

<!-- After review, the feature wrangler will move your page to Category:FeatureReadyForFesco... if it still needs more work it will move back to Category:FeaturePageIncomplete-->

<!-- After review, the feature wrangler will move your page to Category:FeatureReadyForFesco... if it still needs more work it will move back to Category:FeaturePageIncomplete-->

<!-- A pretty picture of the page category usage is at: https://fedoraproject.org/wiki/Features/Policy/Process -->

<!-- A pretty picture of the page category usage is at: https://fedoraproject.org/wiki/Features/Policy/Process -->

Percentage of completion: 100% - it's difficult to say when this is done; the more packages we have the better. The big-ticket issues are done, but there are plenty of python3 packages waiting on review - Assistance with package reviews would be most welcome

Python 3 is intended by upstream to be the future of Python, but we have
many critical components that use Python 2. Python 2 and Python 3 are
sufficiently different that we need both (try writing "print" in each).
Python 2 will be around for a long time.

How to do this? I propose that Fedora shall have separate,
parallel-installable Python 2 and Python 3 stacks. I believe we can get
things to the point where on a Fedora box you'd be able to install both
stacks, and have some processes running python 2 code, and some running
python 3, simultaneously.

Where I would draw the line is on having both python 2 and python 3
running within the same _process_: the two libraries share most of their
symbol names, but with differing implementations, and the result of
trying to dynamically link the two into the same address space would be
highly unstable.

As an example, you'd be able to install both mod_python and mod_python3
rpms, but you wouldn't be able to (sanely) configure httpd to have both
running simultaneously (I guess we should add a run-time warning for
this case)

[edit] Python modules that appear to not yet be ready for Python 3 packaging

mod_wsgi and mod_python will break if the python2 and python3 versions are both loaded into the same apache process because the symbols in libpython.so.2 and libpython.so.3 will clash. However, an admin may want to run two apache's on a server, one with the python2 version and one with the python3 versions. We should support this. Giving the admin some default conf files that will only let them load one set of modules is probably what we want. The admin who wants to run two servers will need to customize their configuration to make it work. Note that if the admin installs gets mod_python3 running on the default apache and then installs mod_python, their apps will stop working as apache will start loading the python2 version.

This is an excellent tutorial, and working through it with our RPMs makes a good test that all is working as expected (obviously it would be a major task to work through the whole book, but at least you'd learn a lot in the process).

It ought to be possible for you to remove python3 without affecting other components

A better phrasing of this point would be: It ought to be possible to remove python3 without affecting any python2 components. If some app gets ported to python3 upstream in F13, I do think we should allow it.

As of 2009-10-27, if you run the above command as root, the only failure should be in test_httpservers (appears to be a permissions issue with how we've packaged the test scripts). You may also see an error in test_socket if your machine's hostname isn't set up in DNS/hosts.

If you run using sudo, you may see an extra failure in test_distutils (test_check_environ).

If you run as a non-root user, you'll see additional failures due to tests that expect write access to certain directories

It should be possible to have some processes on the system running python 2 code, and some processes on the system running python 3 code. However you won't be able to run both python 2 and python 3 within the same process.

Building out the python 3 stack beyond the core interpreter component will involve working closely with many different upstream projects. The more we can do this, the better, but it's not necessary for achieving the main goal of having the core python 3 interpreter available via rpm.

rpmbuild currently automatically invokes /usr/lib/rpm/brp-python-bytecompile without arguments, thus using "/usr/bin/python" to byte-compile every .py file that's in a package payload, generating a bytecode file for the 2.6 ABI.

This breaks down if we're to deal with multiple python runtimes:

the magic ABI value stored in the .pyc/.pyo file needs to match that of the python binary. .pyc files below /usr/lib/python2.6 need to have the 2.6 magic value, whereas .pyc files below /usr/lib/python3.1 need to have the 3.1 magic value.

the syntax of the python language can change (e.g. 2 vs 3), and the compilation can fail with syntax errors if you use the wrong python runtime

Status: I work around this "by hand" in the python3.spec. Need to fix "properly" before building out python3- stack with further packages.

We will be adding all-new RPMs to Fedora. If there's a problem, we can simply choose to not include them without impacting the rest of the Fedora 13 release.

Note: In order to enact this contingency plan, we must do separate packages for python2 and python3. If we keep pursuing the one srpm to build both python2 and python3 route and we have to back out the python3 stack, we also have to backout the python3 changes in the srpms. The same is also true of bindings to C libraries. --abadger1999 02:04, 13 November 2009 (UTC)

Good point. I've conditionalized support throughout the shared specfile changes, adding a with_python3 boolean. Is this an acceptable compromise? --Dmalcolm 18:06, 13 November 2009 (UTC)

Note: We may want to package this since we have the python2 version of diveintopython packaged already.

--Dmalcolm 23:24, 19 November 2009 (UTC) help packaging it would be appreciated! I tried grabbing this from Mercurial, but the toolchain/licensing appeared to have changed greatly since the python2 version of the book