We've been at a deadlock for a few weeks now, our previous coding pace has turned into a lot of contemplation and side discussions about the greater issues with the PySoy codebase.
I think we have a roadmap forward, or enough of one to post these in a blog entry:
First, PySoy 1.0 will not be released until after Python 3.0 this Fall, and it would be pointless to continue developing with 2.x in target. Python 3.0 also has a large number of useful changes for our project. Our target platform should therefore be 3.0 (and it's alpha/beta's for now).
Second, with the release of Pyrex 0.9.7 Greg has, once again, introduced a major language change (the "for" statement) without even soliciting input from the community. This has sealed the deal for us, even if our immediate issues are fixed we cannot continue to subject ourselves to a language that changes in incompatible ways between 2 micro versions (0.9.6 -> 0.9.8, when the old syntax will not be supported).
We earlier started a Cython variant to support PySoy's codebase, but given recent developments in their community, the timelines of our projects, and their choice to stick with Python 2.x for now, we're moving forward on a Pyrex replacement written from scratch and targeting Python 3.0.
We're going to use a similar language style to Pyrex, Greg certainly had some good ideas, and will keep language porting in mind, but there will be changes. We will also not be using any of his code including his Plex module, Pyrex and Cython's lexical analyzer which is the core of those packages.
PySoy Beta3, earlier aimed for release in "early Spring", has been indefinably postponed as we work on that. The subversion repository is of course open, and development can and will continue, but we cannot release until the new build system is complete.
Subscribe to:
Post Comments (Atom)
7 comments:
The comment about Pyrex caught my eye. I looked it up, the change does not seem to be all that substantial, it says:
The integer for-loop syntax has been streamlined. Instead of for i in x < i < y it is now simply for x < i < y
Nor was the change from __new__ to __cinit__, or any of the other changes made in the Pyrex language over the last few years
Being incompatible though, all the code that uses Pyrex needs to change the syntax of their "for" loops, and once done older versions of Pyrex can't be used to compile it. Some distros are often 2-3 micro versions behind.
Pyrex is a language, just like Python (and very similar to it). Imagine if Python 2.4.8 didn't support for-loop syntax that 2.4.6 did.
To be fair, it is 0.x versioned. It's just unfortunate that Greg promotes it as ready for use when it's not frozen against incompatible changes yet.
Interesting stuff as always.
I agree that you're being fair with regard to Pyrex's 0.x version, but it does create some very specific problems for developers, I can see that.
Interesting about Python as well. It's coming up more and more for me. While the new features in 3.0 may be useful, I can't imagine that the change in 3.0 will cause the same issues as Pyrex has done. And, as you've mentioned many distros are behind somewhat in versioning. Given all that, I'd still stick with Python 2.5 for now, but that's me.
As I said, Python is coming up more and more on my radar. Looks like I'm going to the National Virtual Observatory Summer School in Santa Fe in September and I expect a lot of their code examples will either be in Python or Java. Python also won Best Scripting Language in this year's Linux Journal poll. Aaron has said if he was staying in the programming end of things he'd learn Python. The vast majority of our stuff, including what I've written, is in Perl.
And on we go... :-)
Being realistic with the release schedule, the /earliest/ we're likely to get 1.0 out is Winter 2008-2009.
By that point many Python modules will still be struggling to port themselves to Python 3.0, with Python 2.6 sticking around for migration only as the last minor release in the 2.x family.
It just makes sense, IMHO, to aim for it now and develop on the alpha releases than target a soon-to-be-depreciated version.
As a side note, we have been targeting Python 2.3, and this is an ideal point to implement newer language features like decorators that either Python 2.3 or Pyrex didn't support.
Sorry about the abruptness of the for-loop syntax change. I don't regret the change, but the deprecation warning might have been a bit much. I'm willing to remove it or provide an option for turning it off if it causes people too much angst.
I never said I was going to remove the old syntax in the next release (I only said that about the __cinit__ change, and I haven't actually done that yet). The old for-loop syntax will be supported for considerably longer than that.
BTW, "micro release" isn't really the right term for the 0.x.y versions. It's taking me longer to reach what I would consider a 1.0 version than I expected, and the version numbering has become somewhat compressed. Currently the micro releases are the 0.x.y.z ones.
Concerning stability, I do understand that people need something stable to work with. That's why I want to get all the incompatible changes I have in mind out of the way as soon as possible. Once I break the 1.0 barrier, I intend to be much more conservative.
Concerning promotion, I don't remember ever using the exact words "ready to use" when promoting Pyrex. Not only is the version number below 1.0, the web site describes it as a "Development Version". It's still a work in progress, and I've never claimed otherwise.
I find it ironic that you're willing to embrace the change to Python 3, which is going to break backwards compatibility in a much bigger way than anything I've ever done with Pyrex -- and is going to force Pyrex itself to change in radical ways, and probably break most existing Pyrex code in the process.
Having said all that, you are of course welcome to develop your own version of Pyrex from scratch if doing so meets your needs better. It'll be interesting to see whether it gets you where you want to be faster than updating your existing Pyrex code. Whatever you do, I wish you all the best.
- Greg
Hey Greg
I think you've misread, issue at hand is not that the language is changing, but that it's changing without community input. This underlines the core issue and why we're dropping Pyrex;
Pyrex is your personal project. You are listed as the author on the website, the website is hosted as part of your personal website, the normal dev community tools such as a public source repository and ticket tracker have not been established, and community input isn't even solicited before major changes.
In contrast, while Guido is highly respected and certainly sets constraints, the larger Python community provided input on Py3k for a long time before any code was written for it. PEPs were written, debated, discussed, commented on, and resolved before committed to.
Regarding "micro" release, version elements are named major.minor.micro. This naming convention is almost universal.
I hope for the remaining Pyrex community's sake that you do freeze the language for 1.0.
I've decided to remove the deprecation warning and continue to support the old for-from syntax for the foreseeable future.
If you don't want to wait for the next release, you can apply the following patch to remove the warning:
http://www.cosc.canterbury.ac.nz/greg.ewing/python/Pyrex/undeprecate-for-from.patch
Also, rather than wait until 1.0, I'm going into conservative mode now. I can't promise a complete freeze, but I won't make any more incompatible changes without consultation, and only for a very good reason.
Post a Comment