DevHeads.net

The looming Python 3(000) monster

We're just now dealing with Python 2.6, but over on the radar is perhaps
one of the most incompatible upgrades to the language we've seen in
Python 3. I personally haven't tried it yet, but it /aims/ to be
incompatble, which is perhaps one of the most glaring signs a language
designer has lost it that I've seen.

<a href="http://docs.python.org/3.0/whatsnew/3.0.html" title="http://docs.python.org/3.0/whatsnew/3.0.html">http://docs.python.org/3.0/whatsnew/3.0.html</a>

This isn't a huge problem to those who are only developing on the latest
Fedora, per-se (other than getting over the initial hump), but it's
pretty bad for someone who wants to keep a single codebase across EL 4
(Python 2.3) and up, which I think a lot of us do. That gets to be
darn impossible and we have to double our involvement with code because
we essentially have to maintain a differently-compatible fork for each
project.

(NOTE: this requires the viewpoint that not everyone care just about the
latest Fedora, which might be controversial... but to me, the latest
Fedora is what I'll run as my dev environment but not everyone can
upgrade -- and many folks are also running EL and EPEL deserves our full
support and consideration)

So, what of plans?

Are we looking at also carrying on with packaging 2.N indefinitely when
we do decide to carry 3, because as I know it, the code changes to make
something Python 3 compatible will be severe and that's a big item for
any release, and will probably result in some undiscovered bugs even
after the initial ports (if applied).

I haven't seen /anything/ regarding a compatibility mode for
/usr/bin/python, and I'd hate to have to develop a non-core library that
allows for functions that work the same way on both versions and use
that instead. That would be heinous.

Short of porting everything over to Ruby, oCaml, or
enterprise-Fortran.NET#4000, any ideas on planning for this?

--Michael

Comments

Re: The looming Python 3(000) monster

By Toshio Kuratomi at 12/05/2008 - 13:32

This is a problem that hasn't been brought up before. We can keep
Fedora going on python-2.6, 2.7 (and 2.8 if it occurs) and gradually
move code close to py3.x-ish syntax by using the "from __future__ import
*" mechanism. But that doesn't help with older distros running
python-2.5 or less. I don't believe there's anyway around that, though.

As we move to python-2.6+ w/ 3.x features we'll have this problem no
matter when we actually move to python-3. So we eventually (unless we
hold off on moving to python3 until python-2.6 is standard on all RHEL
releases) will be maintaining two trees of code no matter what.

If we maintain a python2 package and a python3 package in one version of
Fedora we'll have even more work. Right now we can have an EL-5 and
Fedora-9&10 package that are compatible with 2.5. A different version
can run on Fedora11 with the syntax ported to python-2.6's understanding
of what 3.x will be like. If we have both python2-2.6 and python3-3.0
in Fedora11 we'll have to maintain separate py2 and py3 packages for
every python module we ship as well. We should avoid this if we can.

Note that I think this decision is only partially within the powers of
the Fedora Project to decide. If 80% of our upstream libraries move to
py3, we'll need to move to py3 sooner. If 80% refuse to move off of
py2, we can take our time working on migration code.

-Toshio

Re: The looming Python 3(000) monster

By Arthur Pemberton at 12/05/2008 - 13:40

2008/12/5 Toshio Kuratomi <a. ... at gmail dot com>:

Maybe I am oversimplifying. But what about using 2.6+ (<3.0) and
ensure that all code is compatible with 3. And still have 3 in
parallel for those who want it. So we target 2.6+ , but have 3.0 there
to ensure everything would work with it, and for early adopters/devs

Re: The looming Python 3(000) monster

By Toshio Kuratomi at 12/05/2008 - 14:04

It is an oversimplification but how much is something we need experience
in order to discover. 2.6 != 3.x even though they are close. There
will be a 2.7 and a 3.1 and some of those problems should be addressed
in those two releases. Until we actually build experience trying to do
this, though, we don't know to what extent our work on making things
work on 2.6 will carry over to 3.x.

Note, the port we've just done to 2.6 is not all that's needed.
python-2.6 tries to have a 2.x mode and a 3.x mode (some changes are too
deep to truly have this but it tries). We'll have to start porting code
to 2.6 with 3.x features turned on at some point.

Also note, this is a valid plan for Fedora but it doesn't address
mpdehaan's issue with supporting python <= 2.5 (which I don't think is
solvable in any elegant manner.)

-Toshio

Re: The looming Python 3(000) monster

By Michael DeHaan at 12/06/2008 - 18:09

Exactly, it's not solvable in any elegant manner.

The parallel versions provides a solution for upstream, if at any point
at which we go from 2.X to 3.0 by dropping 2.X will cause us to lose a
lot of packages -- or lose package updates for EPEL as maintainers stop
being able to focus on that. Requiring an EPEL user to upgrade his
Python to use an app isn't going to happen -- that defeats most of the
points of stability for EL.

Source conversation cannot be mathematically proven and definitely
cannot be fully automated. It's a developers tool that results in two
separately maintained branches. For many applications this will be way
too much for developers, and they will continue to maintain one or the
other -- with differing preferences. (Upstream's goals aren't always to
work with a compatible Python version that we have in Fedora -- perhaps
it's an app who's main audience is EL 5 but also wants to work in
Fedora). For this, we really /do/ need the split versions.

I understand why this was shot down in the past. Then changes were
minor, now they are intentionally larger.

These have to be treated as two different languages, even if they are
95% similar. (Imagine if you will, Python 2.X and 3.X being chimp and
human, and Perl 5 and Perl 6 perhaps being archeopetryx and more
modern-day bird) -- they still cannot interbreed.

For those who have implied I haven't know about this, yes, I've known
about this, I've been writing Python code for at least 5-6 years. It's
just an excellent time to talk about it since it was just now
"released", so that we have a solid plan for now, and if we need to
start thinking incrementally we can.

I'm not so much trying to spell out doom, but we need to know what we
are going to do -- and more importantly -- what the impact on our
package list will be if we do something like drop 2.X.

--Michael

Re: The looming Python 3(000) monster

By Basil Mohamed Gohar at 12/05/2008 - 13:45

It would be very hard to write 2.6 code that is completely compatible
with 3.0, because 3.0 has changed many fundamental language constructs,
including even the "print" statement, which in 3.0 is a function (syntax
change).

I am not sure how far the from __future__ import feature will work for
such changes as that.

Re: The looming Python 3(000) monster

By James Antill at 12/05/2008 - 14:11

Sigh...

from __future__ import print_function

...can everyone who isn't involved in writing python code, and/or not
read about 2.6 / 3.0 before this thread please not comment?

As Toshio Kuratomi said extremely well, in the grand parent to this
post:

Note that I think this decision is only partially within the
powers of the Fedora Project to decide. If 80% of our upstream
libraries move to py3, we'll need to move to py3 sooner. If 80%
refuse to move off of py2, we can take our time working on
migration code.

...so as I said, we don't have concrete plans yet ... and some of that
is because it depends on available resources within the project, but a
lot of that is because we have to follow upstream and it's not obvious
how fast (the majority of) python developers upstream will move.

Re: The looming Python 3(000) monster

By Michael DeHaan at 12/06/2008 - 18:30

Not defined in older versions of python however, hence the need to
branch code, hence a problem with EPEL supporting code.

--Michael

Re: The looming Python 3(000) monster

By James Antill at 12/07/2008 - 02:08

True, 2.5.x and earlier won't be compatible. Which means that
RHEL-5/CentOS-5 python won't be compatible with any code that uses this
feature of py3k and/or 2.6.x (via. the from future import).

This is _far_ from unprecedented though, lack of decorators and/or
yield alone makes the python in RHEL-4/CentOS-4 incompatible for any
modern development. And I've had to upgrade boxes because of this, and
told a lot of people "Yeh, any recent yum just isn't going to work
there ... sucks".
This wasn't the end of the world then, and didn't mean we wanted/needed
to hold python back in Fedora. I don't see anything materially different
now.

Re: The looming Python 3(000) monster

By Michael DeHaan at 12/07/2008 - 13:51

That's a backwards compatibility example.

I'm talking about a break in forwards compatibility.

(A) This is a different issue than the above. This is equivalent to
older Python targetting code not being run on the /new/, not newer code
running on the old.
Completely different problem.

(B) Nobody said the world was ending :)

Re: The looming Python 3(000) monster

By Arthur Pemberton at 12/05/2008 - 13:50

On Fri, Dec 5, 2008 at 12:45 PM, Basil Mohamed Gohar

I believe 'print' is a poor example as it is very easy to fix. Are
there other, more problematic ones?

Neither am I.

Re: The looming Python 3(000) monster

By Toshio Kuratomi at 12/05/2008 - 14:11

Yes, print is a poor example for the 2.6=>3.0 compatibility test (it is
a good example for 2.5=>3.0 compatibility, though, as there's no way to
redefine a keyword from within python.)

The problem area that I'm most aware of is unicode handling. There have
been some major improvements to this that make it more sane. However,
there's also been some regressions. Some of those regressions lead to
code that looks like it should work but silently fail to do what's
expected on *nix in some corner cases.

-Toshio

Re: The looming Python 3(000) monster

By Arthur Pemberton at 12/05/2008 - 14:25

2008/12/5 Toshio Kuratomi <a. ... at gmail dot com>:

Fair enough. Think I'll shutup for now as there seem to be smarter
stakeholders involved than I. However, would just like to say that it
will be nice to have 3.0 in parallel (but not built against) as soon
as possible. Especially as Python is pushing a head in areas such as
web dev.

Re: The looming Python 3(000) monster

By Arthur Pemberton at 12/05/2008 - 11:06

Was that last line really necessary for your post?

Re: The looming Python 3(000) monster

By Les Mikesell at 12/07/2008 - 16:42

Incompatibility isn't a relative thing. More/most, etc., are irrelevant
because compatibility is a yes or no question. If you want a language
that you can expect to run your programs unchanged in the future, you
should have learned years ago that python wasn't it.

Re: The looming Python 3(000) monster

By Les Mikesell at 12/05/2008 - 14:25

Just push the problems of changing API on regardless of the damage it
causes to users who will be running their own and 3rd party code?

The only reasonable way to ship changes that aren't backwards-compatible
once you have a user base is to allow multiple versions to run
concurrently so everyone can migrate their components separately and at
their own pace.

Re: The looming Python 3(000) monster

By Dominik 'Rathan... at 12/05/2008 - 13:57

Sure it is not to follow blindly. Talking with upstream about problems
and solutions will earn you extra points.

Regards,
R.

Re: The looming Python 3(000) monster

By Jeremy Katz at 12/05/2008 - 10:28

[snip]

You do realize that this thread has occurred multiple times now? :)

Carrying multiple versions of python becomes pretty infeasible very
quickly. It's easy enough to package just python itself, but any
non-trivial user is going to require modules also. So how do you decide
which modules to bring in, how to handle the fact that they may have
moved on to python 3 only, etc. It's a big huge mess.

We'll likely stick with 2.x for a while and watch as python3 matures and
fix things up as we can against 2.6+. Once there seems to be a critical
mass or compelling reason, we'll get to have a flag day. Yes it will
hurt. And for those who also develop things for older distros, yes,
they'll probably need to fork off an old-python or whatever branch and
probably only do bugfixes for some of those distros. But this is no
different from apache 1.x -> 2.x, anyone doing kernel development, or a
number of other cases that have occurred over the years.

Jeremy

Re: The looming Python 3(000) monster

By Daniel P. Berrange at 12/05/2008 - 10:09

IMHO the only viable option is to maintain both python 2.x and 3.x
in parallel. It is essentially a brand new language which just
happens to share the same base name. Like Perl 5 & Perl 6.

It is going to be a very long time before every upstream for all our
python bits support 3.x syntax and we don't want to have to undertake
the work to re-write them all ourselves.

The delibrate break of syntax is going to cause a major PITA for
upstream projects because there's no way they can stop shipping
2.x compatible code just because some people want to use 3.x. So
every upstream pretty much has to now maintain two sets of python
bindings :-(

Daniel

Re: The looming Python 3(000) monster

By James Antill at 12/05/2008 - 10:32

It's much less like Perl-5/Perl-6, IMO, but even if you convince FESCo
of this mental contortion and you have dual sets of _every_ python
module. The API is very similar and uses the same shared library
name ... so what do you do about all the C programs that link with
libpython?

repoquery --whatrequires 'libpython2.5.so.*'

...are you going to offer two versions of rhythmbox?

Re: The looming Python 3(000) monster

By Kevin Kofler at 12/05/2008 - 15:29

The same thing we do about kdelibs3 and kdelibs 4 coexisting: move one (or
both) of the 2 conflicting -devel symlinks to a subdirectory of the libdir
and have the dependent packages use -L flags.

But is there even a conflict at all? libpython2.5.so != libpython3.0.so.

And if there is one, maybe try to get upstream to fix it?

But Python is not an application, it's a programming language and a set of
libraries. Shipping 2 versions of an application doesn't make much sense
(and in fact we don't do that for KDE 3 and 4), but libraries (e.g.
kdelibs3/kdelibs4) and programming languages are different. Getting
everything which depends on the library/language ported at the same time is
almost always infeasible for incompatible versions.

Kevin Kofler

Re: The looming Python 3(000) monster

By James Antill at 12/05/2008 - 16:46

You are confused, this isn't the same as KDE because _KDE isn't a
programming language_.

Again, you are confused. Yes, you can ship two different libraries that
two different applications can use ... like gtk1/gtk2, but you can't mix
them within an application.
And that's much more common within a programming language. For example:

<a href="http://live.gnome.org/RhythmboxPlugins/WritingGuide" title="http://live.gnome.org/RhythmboxPlugins/WritingGuide">http://live.gnome.org/RhythmboxPlugins/WritingGuide</a>

...you have:

application => libpython* => plugin [ => python modules ]

...here you _must_ ship one layer of python throughout, saying "it
should be compatible" works about as well as saying "we should be able
to run kde3 and kde4 in a single applications" ... you can ask for it,
and a pony at the same time, but don't hold your breath.

Re: The looming Python 3(000) monster

By Kevin Kofler at 12/05/2008 - 16:54

Rhythmbox will have to pick one version of Python to support (probably the
default version in Fedora), but that doesn't mean other programs won't want
to use the other version.

Kevin Kofler

Re: The looming Python 3(000) monster

By Richard W.M. Jones at 12/05/2008 - 10:09

For Windows cross-compilation of Python libraries, we decided that
Python 2.x's build system is crazy, so we would only support Python 3
from the beginning. The reason is so that we can get build system
patches upstream easily without having to maintain patches against all
the different branches (ie. against 2.5, 2.6, 3.0, devel).

So if you want your Python program to work with the Fedora MinGW
cross-compiler, you'd better try it out with the 'python -3' option
and fix any deprecated bits.

Rich.

... Or take the opportunity to jump to a safe language .. we've
already got an OCaml cross-compiler.

Re: The looming Python 3(000) monster

By Bill Nottingham at 12/05/2008 - 10:18

Richard W.M. Jones (<a href="mailto: ... at redhat dot com"> ... at redhat dot com</a>) said:

Yes, let's move to something 'safer', which doesn't have ABI compatibility
ANYWHERE. That makes perfect sense.

Bill

Re: The looming Python 3(000) monster

By Richard W.M. Jones at 12/05/2008 - 10:42

You can get the same illusion of ABI compatibility as in C by simply
wrapping your OCaml library in a C wrapper and publishing the C header
file as the ABI. I even wrote a tool to do this automatically. Real
ABI compatibility is a tricky problem that only works in very limited
cases (eg. you extend the interface with new functions and never
modify even the internals of existing functions).

Rich.

Re: The looming Python 3(000) monster

By James Antill at 12/05/2008 - 11:07

[snip pointless trolling]

ABI does not mean what you think it means:

<a href="http://en.wikipedia.org/wiki/Application_binary_interface#Content" title="http://en.wikipedia.org/wiki/Application_binary_interface#Content">http://en.wikipedia.org/wiki/Application_binary_interface#Content</a>

Re: The looming Python 3(000) monster

By Matej Cepl at 12/05/2008 - 09:51

Guido was preparing on this incompatibility for years, so unless
you were sleeping you should not be surprised.

The party line is that you should develop against python 2.6
(which doesn't block you from being compatible with Python 2.3)
and then conversion from 2.6 to 3.* would be guaranteed to be
done just with a script.

Matěj

Re: The looming Python 3(000) monster

By Les Mikesell at 12/07/2008 - 16:54

Not being surprised is one thing, but I don't see how anyone could be
prepared other than not using any python code.

Is there some shortage of names? Why can't a new and incompatible
language be given a different name so people don't try to use it with
the old and different code?

Re: The looming Python 3(000) monster

By Toshio Kuratomi at 12/08/2008 - 12:47

Before we go too far down the argument of whether we need one or two
python interpreters in Fedora we need to see what the nature of the
problems are. Python-2.6 plus the from __future__ import * stuff gets
us something very close to compatibile with python-3.0. Python-2.7 and
python-3.1 are supposed to be even closer. The last time I tested, it
was possible to turn on the from __future__ import * features on a file
by file basis. So -- if the compatibility of python-3 and python-2.6+
are good enough Fedora could run python-3 and python-2 targeted
upstreams together under python-2.6+. We need to gather experience
trying to do this before we know, though.

-Toshio

Re: The looming Python 3(000) monster

By Les Mikesell at 12/08/2008 - 13:35

The problem I see here is that even if you decide that you can manage a
cutover for everything included/upstream in fedora, it is a bad idea to
assume that users are ready and willing to do the same with their own
code on the same day - or that they will know not to update until they
can. You'll probably cover most of the cases if you can update mailman,
rhythmbox, yum and the system* tools on the same day, but you never
know. And what is the backout strategy for someone whose apps are broken?

I just don't get why any sane person, especially anyone familiar with
computer languages, would ever want to give something that is not the
same the same name. Does anyone know how the developer(s) manage this
themselves? I have to think they are keeping multiple concurrent
versions installed (and that that is the only reasonable approach).

Re: The looming Python 3(000) monster

By Horst H. von Brand at 12/08/2008 - 16:42

[...]

You mean like C? There was plain K&R C, then futzing around with lint, then
several popular C extensions, then along came ANSI C (C89), then C99; all the
while there were all sorts of "interesting" GCC extensions included,
changed, retracted, added in the standard or replaced in it by a completely
different way of doing the same thing...

Re: The looming Python 3(000) monster

By Les Mikesell at 12/08/2008 - 18:12

And yet, in all that time, I never had a problem continuing to run a
previously working C program even in the extremely rare cases where an
updated compiler wouldn't build a new copy. Python doesn't work that way.

Re: The looming Python 3(000) monster

By Rahul Sundaram at 12/09/2008 - 05:24

New major versions of GCC have almost always resulted in a few C
programs within the distribution needing to be updated to work with it.
You might not have to run it this much but any major distribution
certainly would have. It is not a python specific problem though python
does change more often than C does.

Rahul

Re: The looming Python 3(000) monster

By Daniel P. Berrange at 12/09/2008 - 05:33

This is not a comparable scenario. The new GCC releases are identifying
bugs which always existed in your code, not changing the language. As
such once you fix the bugs, your code continues to work on old & new
GCC just fine. The equivalent scenario would be a new GLibC release
which changed a bunch of APIs you were using, making it impossible to
write code which works on both old & new at new. Even then, the linker
provides version scripts which allow you to provide multiple definitions
of the same ELF symbol so you can maintain ABI compatability across old
and new version even if you changed API contracts.

Daniel

Re: The looming Python 3(000) monster

By Rahul Sundaram at 12/09/2008 - 09:16

It is not the exact same scenaro but we are talking about backward
compatibility of languages in general. If new GCC breaks my C code or a
new Python interpretor breaks my python code, it is still breaking what
was working before. C specification is not breakfast reading so almost
everybody just go with what a compiler like GCC supports.

Isn't a similar situation responsible for

<a href="https://fedoraproject.org/wiki/Common_F10_bugs#DNS_Resolver_not_Reliable" title="https://fedoraproject.org/wiki/Common_F10_bugs#DNS_Resolver_not_Reliable">https://fedoraproject.org/wiki/Common_F10_bugs#DNS_Resolver_not_Reliable</a>

Rahul

Re: The looming Python 3(000) monster

By Simo Sorce at 12/09/2008 - 09:27

I hope you realize the difference between a few programs not *compiling*
anymore, but that keep working no problem.
And *all* programs not running, until you fix them, *and* all the
modules not yet converted you depend on, including C bindings which are
not exactly breakfast coding for python programmers...

Simo.

Re: The looming Python 3(000) monster

By Rahul Sundaram at 12/09/2008 - 09:52

Sure but that is a side effect of interpreted (python) vs compiled ( C)
code and not the strength of backward compatibility of a language. When
it comes to Free software within a Fedora environment which is supposed
to be self hosting, working but not compiling code is certainly a issue
as well.

Rahul

Re: The looming Python 3(000) monster

By Jesse Keating at 12/08/2008 - 13:47

I'm pretty certain that if you look at any language, they've all faced
similar scenarios, major version upgrades that may in fact not be
forward no backward compatible. People have dealt with it and moved on.
No language is perfect.

Re: The looming Python 3(000) monster

By Simo Sorce at 12/08/2008 - 17:19

Never seen C/C++ break backward compatibility on a scale like Python 3.0
will.
And they are compiled, where the impact is 100 fold less than for
interpreted languages ...

I would personally strongly consider having 2.x and 3.0 parallel
installable ...

Simo.

Re: The looming Python 3(000) monster

By Arthur Pemberton at 12/08/2008 - 17:36

Isn't Python designed to be parallel installable?

Re: The looming Python 3(000) monster

By Toshio Kuratomi at 12/09/2008 - 11:54

Yes it is. We just want to avoid having to do that if possible because
it could be very painful to do so.

Here's the fear:

python2.x
- python-libfoo-2.0
- spiffy-app-1.2

python3.x
- python-libfoo-2.1
- excellent-app-1.1

python-libfoo-2.0 uses the 2.x API. python-libfoo-2.1 uses the
python-3.x API. In order to get spiffy-app and excellent-app into the
distro we need to have both python2.x and python3.x versions of the
library installed.

Now a security fix is released for python-libfoo-2.1. Does that also
affect python-libfoo-2.0? Can we backport the fix or are the py2.x and
py3.x versions too different? Do we need to have more python coders
available to fix these errors?

Here's the ideal (For Fedora, once again, this does not address
mpdehaan's concerns):

python2.6
- python-libfoo-2.1 (with from __future__ import *)
- spiffy-app-1.2
- excellent-app-1.1 (with from __future__ import *)

If this is possible we can maintain one version of python and one
version of the library. The apps can both consume the library even
though one was coded for python-3.x and the other was coded for python-2.x.

Is this going to be possible or will deepseated assumptions in the new
language prevent this? That's something we can't know for sure until we
actually start trying to run code in mixed mode like this. Some people
had great luck with this earlier in the year[1]_ but I think there were
changes to the stdlibrary since then and I didn't trust that the author
had done a thorough job with the unicode/string/bytes testing.

So let me reiterate:

* python-3.x will not be in Fedora-11 unless it becomes obvious in the
next few weeks that we absolutely must be running it for the next release.
* we need more experience with python-2.6+ & python-3 compatibility
before we decide whether parallel versions of python are necessary.

.. _[1]: <a href="http://python-incompatibility.googlecode.com/svn/trunk/README.txt" title="http://python-incompatibility.googlecode.com/svn/trunk/README.txt">http://python-incompatibility.googlecode.com/svn/trunk/README.txt</a>

-Toshio

Re: The looming Python 3(000) monster

By Arthur Pemberton at 12/09/2008 - 14:05

2008/12/9 Toshio Kuratomi <a. ... at gmail dot com>:

Well again. Some people (like Toshio) seem to have a grasp on the
matter. All this banter hasn't produced anything more of use. How
about forming a temp SIG to take care of this trusting they do the
right thing?

Re: The looming Python 3(000) monster

By Arthur Pemberton at 12/09/2008 - 21:40

2008/12/9 Ignacio Vazquez-Abrams < ... at gmail dot com>:

No. Seems like the ideal body to come to a decision and let the rest
of us know.

Re: The looming Python 3(000) monster

By Arthur Pemberton at 12/10/2008 - 12:55

2008/12/10 Ignacio Vazquez-Abrams < ... at gmail dot com>:

Just to be clear, does that mean no Python 3.0 in parallel either?

Re: The looming Python 3(000) monster

By Les Mikesell at 12/10/2008 - 13:29

How do you expect people to modify and test their own code without a
parallel install?

Re: The looming Python 3(000) monster

By Toshio Kuratomi at 12/10/2008 - 13:59

As stated multiple times, the initial port will be to python-2.6+ with
python-3 features turned on. Then we'll see where we're at.

It's possible that the remaining porting work will be small at that
point and we can migrate easily. It's also possible that it's still a
major undertaking to go from py-2.6 w/ python-3 features to py3. But we
won't know until code starts being ported so there's no use trying to
guess what we need to do now.

-Toshio

Re: The looming Python 3(000) monster

By Arthur Pemberton at 12/10/2008 - 14:17

2008/12/10 Toshio Kuratomi <a. ... at gmail dot com>:

I think he meant "unofficial" work, as in not official porting of
packages. Just regular dev work.