On 10 Jan, 11:10 pm, email@example.com wrote:
On 10/01/07, firstname.lastname@example.org email@example.com wrote:
I've been assuming for some time that the only hope for Py3k compatibility within Twisted would be using PyPy as a translation layer.
Does this ring as many warning bells for me as it does for others? I know very little about the current state of PyPy, but I read your comment as implying that you expect Twisted to be unavailable (at some level or other) for users of Py3K. Is that right?
This entirely depends on the migration path available. My understanding of the situation is that Py3K is a different, incompatible language. In that sense, Twisted will only be as unavailable to users of Py3K as it is unavailable to users of Ruby, Perl, or any other dynamic-but-not-Python language.
If the 2.x series grows deprecation warnings and gradually has all of py3k's features backported, such that there is a smooth transitional period of a few years where we can support one or two versions of 2.x and a version of 3.x, then eventually perhaps it will be worthwhile.
Alternately, if they really aren't compatible *but* there is such a compelling featureset drawing other developers that there's really a critical mass of projects that migrate to 3.x and stop maintaining their 2.x counterparts, it might be worthwhile to jump the chasm to follow them. At a minimum, for it to be worthwhile for Twisted to attempt this if the following packages are all moved to 3.x:
- pyopenssl - pygtk - pysqlite - PyObjC - win32all - zope interface (and therefore, probably, all of Zope) - pycrypto - pypam - pygame - pylucene
Those projects that do move I'm sure will take the "opportunity" to incompatibly break all of their APIs as well, since no existing code will actually use them, exacerbating the problems involved in porting.