Python 3.0 unfit for serious work?
Yo, On Feb 16, 6:07 am, Steven Bethard <[EMAIL PROTECTED]> wrote: > Python 3.0 is determined not to be hampered by backwards incompatibility > concerns. It's not even clear yet that your average 2.6 code will work Then Python is pretty much determined to remove itself from consideration from various kinds of international projects like the one I work on. We're already catching flack from people due to a few things that were valid in 2.2 that are not valid in 2.3 (I don't have the details but could scare them up). The project we work on contains code from many different people and has to run on thousands of computers all over the world. The installed base at the moment is a mix of RHEL 3, RHEL 4, and Debian, with a few other machines thrown in. The relevant Python versions at this moment IIRC are 2.2.3 and 2.3.4, because these are the native versions on those platforms. We are estimating, due to the speed at which our applications follow OS releases, that we can drop RHEL 3 (and hence Python 2.2) support a year from now. Go figure when you think we might be ready to require that all programs run on python 3.0. If it's not backwards compatible, meaning if 2.4 code doesn't run on 3.0, it's rather likely that strong pressure will be applied to port *away* from Python into something less capricious. Bottom line: practicality and beauty is always a tradeoff. Oberon is the most beautiful language I ever saw, but there is almost nobody using it any more. Too many beauty contests over who had the best proposal for a standard library. -- http://mail.python.org/mailman/listinfo/python-list
Re: Python 3.0 unfit for serious work?
Jay Tee wrote: > Yo, > > On Feb 16, 6:07 am, Steven Bethard <[EMAIL PROTECTED]> wrote: >> Python 3.0 is determined not to be hampered by backwards incompatibility >> concerns. It's not even clear yet that your average 2.6 code will work > > Then Python is pretty much determined to remove itself from > consideration > from various kinds of international projects like the one I work on. You snipped the rest of that comment: "It's not even clear yet that your average 2.6 code will work on 3.0 -- though there's a pretty large contingent trying to make this true." If you want to make sure average 2.6 code works on 3.0, please help contribute to Python. You can find out where best to focus your efforts by asking on python-dev: http://mail.python.org/mailman/listinfo/python-dev > If it's not backwards compatible, meaning if 2.4 code doesn't run on > 3.0, it's rather likely that strong pressure will be applied to port > *away* from Python into something less capricious. Well, Python 2.4 code will work on Python 2.6 and 2.7 so just because your code isn't yet compatible with Python 3.0 doesn't mean you should give up on Python. Python 2.2 was released in early 2003 and you said you'd be dropping support for 2.2 in early 2008, so I conclude that since Python 2.5 was released in late 2006, you'll be ready to drop Python 2.5 support (and have 2.6/3.0 compatible code) by late 2011. Sure, it's a long way off, but you're writing 2.2 compatible code *now*. Is it really that bad to wait four years for Python 3.0? STeVe -- http://mail.python.org/mailman/listinfo/python-list
Re: Python 3.0 unfit for serious work?
What a load of bull crap. Python is one of the simplest packages to have multiple version of installed. When Python 3.0 is released, all Linux distros will acquire a symlink at /usr/bin/python2 pointing to the latest Python 2.x version installed. Or something equivalent. Rest assured that Linux distributors will not drop Python 2.x support in the nearest decade. They are not stupid. On 20 Feb 2007 08:49:10 -0800, Jay Tee <[EMAIL PROTECTED]> wrote: > Yo, > > On Feb 16, 6:07 am, Steven Bethard <[EMAIL PROTECTED]> wrote: > > Python 3.0 is determined not to be hampered by backwards incompatibility > > concerns. It's not even clear yet that your average 2.6 code will work > > Then Python is pretty much determined to remove itself from > consideration > from various kinds of international projects like the one I work on. > We're already catching flack from people due to a few things that were > valid > in 2.2 that are not valid in 2.3 (I don't have the details but could > scare them > up). The project we work on contains code from many different people > and has to > run on thousands of computers all over the world. The installed base > at the > moment is a mix of RHEL 3, RHEL 4, and Debian, with a few other > machines thrown in. > The relevant Python versions at this moment IIRC are 2.2.3 and 2.3.4, > because these > are the native versions on those platforms. > > We are estimating, due to the speed at which our applications follow > OS releases, that > we can drop RHEL 3 (and hence Python 2.2) support a year from now. Go > figure when you > think we might be ready to require that all programs run on python > 3.0. If it's not > backwards compatible, meaning if 2.4 code doesn't run on 3.0, it's > rather likely that > strong pressure will be applied to port *away* from Python into > something less capricious. > > Bottom line: practicality and beauty is always a tradeoff. Oberon is > the most beautiful > language I ever saw, but there is almost nobody using it any more. > Too many beauty contests over who had the best proposal for a standard > library. > > -- > http://mail.python.org/mailman/listinfo/python-list > -- mvh Björn -- http://mail.python.org/mailman/listinfo/python-list
Re: Python 3.0 unfit for serious work?
Hi, On Feb 20, 8:59 pm, Steven Bethard <[EMAIL PROTECTED]> wrote: > You snipped the rest of that comment: > > "It's not even clear yet that your average 2.6 code will work on 3.0 -- > though there's a pretty large contingent trying to make this true." Thanks for pointing this out. I voted for the comp.lang.python newsgroup back in the early 90's, my active days of python 'development' are over, it's all i can do to hang on to the code i've been posting about. > have 2.6/3.0 compatible code) by late 2011. Sure, it's a long way off, > but you're writing 2.2 compatible code *now*. Is it really that bad to > wait four years for Python 3.0? As long as when python 3.0 shows up, i don't have to do a massive rewrite. I think I've really only had to change two or three things over the years .. one was that I used to use words like "dict" and "list" in my code, which broke in subtle ways when d = dict() became legal. I just dug out some code laying around on disk from 1994, and ran it, unchanged, under python 2.3.5. If I can achieve this (running 2007 code under python3.0 in 2011 with no modifications), that'd be OK. JT -- http://mail.python.org/mailman/listinfo/python-list
Re: Python 3.0 unfit for serious work?
Steven Bethard wrote: > > Well, Python 2.4 code will work on Python 2.6 and 2.7 so just because > your code isn't yet compatible with Python 3.0 doesn't mean you should > give up on Python. Perhaps the most important concern in the context of Python 3.0 is what the term "Python" will come to mean to the different communities using the language. Some people will be maintaining software that needs to be compatible with older releases; these people aren't technologically backwards: they just find that such older releases provide sufficient capabilities for the implementation of their solutions. For such people, "Python" will be the language they've always used, with a gradual accumulation of features, some known quirks, and some relatively minor incompatibility issues over the years. Meanwhile, the risk is that the core developers will only consider Python 3.0 as "Python" and that people doing anything with older releases will be on their own. If the gap is too wide between 2.x and 3.x, any lack of maintenance in the 2.x series will be perceived as an abandonment of "Python" for certain kinds of user, and the result will probably be a loss of confidence in both variants of the language. Although I believe that some of the recent attempts to lower the disruptiveness of Python 3.0 may have helped to maintain "Python" as a single narrow continuum, I think some people overlook how fortunate the relationship between Python's evolution and momentum has been, and how easily such a relationship can be broken. Paul -- http://mail.python.org/mailman/listinfo/python-list
Re: Python 3.0 unfit for serious work?
yo, Bjorn, I am not sure I see why my post is bull crap. I think all you are doing is agreeing with me. My post was entitled "Python 3.0 unfit for serious work", you just indicated that the Linux distros will agree with me, in order to be taken seriously, the distros will have to include 2.x python for a very long time. If 3.0 and 2.x have any serious degree of incompatibility, python will be a favorite subject for religious rants and heated arguments for many people. And if we don't manage to restrain our developers from using features that force us prematurely to move to 3.0 ... and don't underestimate what this means, because this means other things will have to move as well, which may have dependencies on yet other things like C++ library versions ... then I would have to, for reasons of maintainability, argue against continuing to allow python code development in the project. I love python, but not enough to make 20+ people's lives difficult. There are already people making this sort of argument in our project. JT On 2/20/07, BJörn Lindqvist <[EMAIL PROTECTED]> wrote: > What a load of bull crap. Python is one of the simplest packages to > have multiple version of installed. When Python 3.0 is released, all > Linux distros will acquire a symlink at /usr/bin/python2 pointing to > the latest Python 2.x version installed. Or something equivalent. > Rest assured that Linux distributors will not drop Python 2.x support > in the nearest decade. They are not stupid. -- http://mail.python.org/mailman/listinfo/python-list
Re: Python 3.0 unfit for serious work?
Hi, Paul, thanks for this, I didn't realize the scope of the situation. I agree with your assessment to the extent that I understand what the whole python 3.0 thing is about. Let's see if I can scare up something I wrote about ten years ago on a now-dead language that I really wanted to use (wound up sticking with python instead because "it was supported" ;-) === to figure out how to work things. The fact that there are three (or four depending if you count Linz V4) different Oberon System implementations, and several different compilers, and even four or five separate dialects of Oberon with none of them appearing to be really "official", gives the impression of a fragmented, directionless development effort, and a probability bordering on 1. that whatever you try to do will be incompatible with all but a small subset of what's available (unless you stick to writing small programs like in the books.) It does not matter if you tell people that this is not so; something has to clearly stand out as being THE STANDARD STUFF and all the other stuff as INTERESTING BUT NONTHREATENING SIDE PROJECTS. The STANDARD STUFF must include a sufficient number of = Oberon is really really cool, seriously, ... but nobody is using it. People working on python development are of course free to do what they want, but so are the users ... J "actie-reactie is what my ex-brother-in-law would say" T -- http://mail.python.org/mailman/listinfo/python-list
Re: Python 3.0 unfit for serious work?
Jay Tee wrote: > Let's see if I can scare up something I wrote about ten years ago on a > now-dead language that I really wanted to use (wound up sticking with > python instead because "it was supported" ;-) > > === > to figure out how to work things. The fact that there are three (or > four depending if you count Linz V4) different Oberon System > implementations, and several different compilers, and even four or > five separate dialects of Oberon with none of them appearing to be > really "official", gives the impression of a fragmented, directionless > development effort, and a probability bordering on 1. that > whatever you try to do will be incompatible with all but a small > subset of what's available (unless you stick to writing small programs > like in the books.) It does not matter if you tell people that this > is not so; something has to clearly stand out as being THE STANDARD > STUFF and all the other stuff as INTERESTING BUT NONTHREATENING SIDE > PROJECTS. The STANDARD STUFF must include a sufficient number of > = Well, the problem of multiple standards shouldn't really apply in the same way to Python. Right now, Python 2.X is the standard. Python 2.6, 2.7 and any later 2.X versions are intended to be transitional versions while the standard is migrating to Python 3.X. At some point, the 2.X line will almost certainly be discontinued. So as a Python programmer, the path is clear. As soon as possible, you should make your code compatible with Python 3.0. That will likely mean taking advantage of some new features in Python 2.6, so "as soon as possible" may still mean many years for projects that need to support older versions of Python. Still, once Python 2.6 is installed everywhere by default, it shouldn't be difficult to start making code compatible with the new standard, Python 3.0. STeVe -- http://mail.python.org/mailman/listinfo/python-list
Re: Python 3.0 unfit for serious work?
Jay Tee wrote: > > Paul, thanks for this, I didn't realize the scope of the situation. I > agree with your assessment to the extent that I understand what the > whole python 3.0 thing is about. I don't know if I've delimited the scope of any situation, really. However... [...] > The fact that there are three (or > four depending if you count Linz V4) different Oberon System > implementations, and several different compilers, and even four or > five separate dialects of Oberon with none of them appearing to be > really "official", [...] The fortunate thing about different Python implementations and in contrast to a lot of other languages and their implementations is that the most actively developed Python implementation, CPython, is very portable and is present on all major operating systems of consequence (capable of running it). Other languages have suffered because there'd be a UNIX version and then a version for Windows or the Mac which wasn't as well maintained, or perhaps no version at all for one or more of these platforms. So with Python, even if one implementation is lagging behind (eg. Jython) there's still likely to be some deployment solution on one's operating system of choice, given some level of flexibility. Where incompatibilities may arise with Python implementations is in the level of support for recent language developments and additions. Again, CPython's portability prevents this from becoming an operating system issue, but we see rifts between implementations targeting different runtime platforms, and whilst CPython 2.x and CPython 3.x may continue to cover similar operating systems (although a desire to drop support for various operating systems was stated), it's the rift between them that presents the risk to any common notion of what Python actually is. Paul -- http://mail.python.org/mailman/listinfo/python-list
Re: Python 3.0 unfit for serious work?
On 2/20/07, Jeff Templon <[EMAIL PROTECTED]> wrote: > Bjorn, I am not sure I see why my post is bull crap. I think all you > are doing is agreeing with me. My post was entitled "Python 3.0 unfit > for serious work", you just indicated that the Linux distros will > agree with me, in order to be taken seriously, the distros will have > to include 2.x python for a very long time. If 3.0 and 2.x have any > serious degree of incompatibility, python will be a favorite subject > for religious rants and heated arguments for many people. And if we > don't manage to restrain our developers from using features that force > us prematurely to move to 3.0 ... and don't underestimate what this > means, because this means other things will have to move as well, > which may have dependencies on yet other things like C++ library > versions ... then I would have to, for reasons of maintainability, > argue against continuing to allow python code development in the > project. I love python, but not enough to make 20+ people's lives > difficult. > > There are already people making this sort of argument in our project. This is why I said that your post was a load of bull crap: "Then Python is pretty much determined to remove itself from consideration from various kinds of international projects like the one I work on [unless py3k is backwards compatible with python 2.x]." You did not explain why this is so. "if 2.4 code doesn't run on 3.0, it's rather likely that strong pressure will be applied to port *away* from Python into something less capricious." Who are these people that are applying the strong pressure? How can you run a international and seemingly very important project without knowing basic things about how to handle versioning problems? I mean, they would rather port this big system, deployed on thousands of computers all over the world, to an entirely different programming language than to continue using Python 2.x because Python 3.x, when it is released, MIGHT cause them some problems several YEARS from now? -- mvh Björn -- http://mail.python.org/mailman/listinfo/python-list
Re: Python 3.0 unfit for serious work?
Steven Bethard wrote: > So as a Python programmer, the path is clear. As soon as possible, you > should make your code compatible with Python 3.0. There's always the possiblity that Python 3 won't happen. Look at what happened with Perl 6. That's been talked about for seven years now. The user base just wasn't interested. Perl 5 was good enough, and users migrated to PHP for the little stuff and other languages for the bigger stuff. As Wikipedia says, "As of 2007, Perl 6 was still under development, with no planned completion date." John Nagle -- http://mail.python.org/mailman/listinfo/python-list
Re: Python 3.0 unfit for serious work?
John Nagle <[EMAIL PROTECTED]> writes: > There's always the possiblity that Python 3 won't happen. Look at > what happened with Perl 6. That's been talked about for > seven years now. The user base just wasn't interested. > Perl 5 was good enough, and users migrated to PHP for the > little stuff and other languages for the bigger stuff. > As Wikipedia says, "As of 2007, Perl 6 was still under development, > with no planned completion date." I like to think PyPy will replace CPython as the main Python implementation. Python 3.0 can then fork the language fairly radically, like C++ vs C (ok, not so attractive an example) or Scheme vs Lisp. Both dialects would stay active. It seems to me that the flavor of Python programming has changed significantly over the past few releases. That trend will likely continue and even accelerate. -- http://mail.python.org/mailman/listinfo/python-list
Re: Python 3.0 unfit for serious work?
Steven Bethard wrote: > So as a Python programmer, the path is clear. As soon as possible, you > should make your code compatible with Python 3.0. John Nagle wrote: > There's always the possiblity that Python 3 won't happen. That's not really a possibility. Unlike Perl 6, Python 3 is not a new language. And you can see Guido's release plan here: http://www.python.org/dev/peps/pep-3000/ In brief: * An alpha in the first half of 2007 * First real release in the first half of 2008 STeVe -- http://mail.python.org/mailman/listinfo/python-list
Re: Python 3.0 unfit for serious work?
Paul Rubin wrote: > John Nagle <[EMAIL PROTECTED]> writes: > >> There's always the possiblity that Python 3 won't happen. Look at >>what happened with Perl 6. That's been talked about for >>seven years now. The user base just wasn't interested. >>Perl 5 was good enough, and users migrated to PHP for the >>little stuff and other languages for the bigger stuff. >>As Wikipedia says, "As of 2007, Perl 6 was still under development, >>with no planned completion date." > > > I like to think PyPy will replace CPython as the main Python > implementation. Well, something faster really should take over. It's a bit embarassing that the main implementation of Python is still a pure interpreter. Even Javascript has a JIT compiler now. And it's tiny, under 1MB. John Nagle -- http://mail.python.org/mailman/listinfo/python-list
Re: Python 3.0 unfit for serious work?
John Nagle wrote: > It's a bit > embarassing that the main implementation of Python is still a > pure interpreter. Even Javascript has a JIT compiler now. Pure interpreted Python has always seemed more responsive to me than any Java application I've tried to use. So I can't help feeling that this JIT business is over-hyped. -- Greg -- http://mail.python.org/mailman/listinfo/python-list
Re: Python 3.0 unfit for serious work?
On Feb 21, 1:41 am, "BJörn Lindqvist" <[EMAIL PROTECTED]> wrote:
[ citing me ]
> "if 2.4 code doesn't run on 3.0, it's rather likely that strong
> pressure will be applied to port *away* from Python into something
> less capricious."
>
> Who are these people that are applying the strong pressure? How can
> you run a international and seemingly very important project without
> knowing basic things about how to handle versioning problems?
This isn't versioning. At least not the way I see it. Versioning has
to do with changes in your own product. Indeed one needs to know how
to handle it. Lately our project has been doing OK on this front, a
couple years ago was a different story.
Underlying technology is a different story. This should be reasonably
stable. Small changes are inevitable but even these are a major pain,
since we have dependency links like the following:
OS release links to
Python release which changes an
Third-party extension module which requires
A third party library whose
Version needs to be upgraded but which
Is used by some other non-python means that
Requires the earlier version.
Or the earlier problem, an OS upgrade comes with a new python version
on which existing code breaks.
The fraction of code in our system that's written in python is
something like 10% -- it's not a big pure-python system.
Now you're talking about major changes in the underlying technology,
forcing, at some point in the future, an extensive rewrite of the
python code. Yes, at that point, some people would make the comment
that a language which changes to that extent by major versions is not
fit for production work, and if one was going to have to rewrite, it
would be better to rewrite in a more stable language.
And finally, remember the original post I replied to said that python
3.0 was determined not to be hampered by backwards compatibility.
This is quite a bit different than what you say here ("MIGHT cause
problems"):
> language than to continue using Python 2.x because Python 3.x, when it
> is released, MIGHT cause them some problems several YEARS from now?
If backwards compatibility is not a consideration, then it would be a
miracle if there were no problems.
JT
--
http://mail.python.org/mailman/listinfo/python-list
Re: Python 3.0 unfit for serious work?
On Tue, 20 Feb 2007 21:19:26 -0800, John Nagle wrote: > Well, something faster really should take over. It's a bit > embarassing that the main implementation of Python is still a > pure interpreter. Even Javascript has a JIT compiler now. > And it's tiny, under 1MB. Python has a compiler, just like Java. That's where the .pyc files come from. You might also notice the built-in function "compile", which compiles text strings into byte-code and puts it into a code object. The dis module may also be of interest. -- Steven D'Aprano -- http://mail.python.org/mailman/listinfo/python-list
Re: Python 3.0 unfit for serious work?
In article <[EMAIL PROTECTED]>, Jay Tee <[EMAIL PROTECTED]> wrote: > >If backwards compatibility is not a consideration, then it would be a >miracle if there were no problems. Backwards compatibility is a consideration AND there will be problems. That is, the goal of 3.0 is to lower the priority of backwards compatibility enough to make some incompatible changes, but not to reduce the priority of compatibility to zero. Just for example, "foo" will become a Unicode string. Note that I believe it will be many years, perhaps even a decade, before "python" on a Unix system starts up Python 3.0. Python 2.x will have at least two releases after 3.0 gets released, and I can't imagine that any OS will have "python" refer to 3.0 while 2.x is still under active development or even for a while after. I'd expect any OS to provide a python3. -- Aahz ([EMAIL PROTECTED]) <*> http://www.pythoncraft.com/ "I disrespectfully agree." --SJM -- http://mail.python.org/mailman/listinfo/python-list
Re: Python 3.0 unfit for serious work?
On Feb 20, 9:04 pm, "Jeff Templon" <[EMAIL PROTECTED]> wrote: > yo, > > Bjorn, I am not sure I see why my post is bull crap. I think all you > are doing is agreeing with me. My post was entitled "Python 3.0 unfit > for serious work", you just indicated that the Linux distros will > agree with me, in order to be taken seriously, the distros will have > to include 2.x python for a very long time. If 3.0 and 2.x have any > serious degree of incompatibility, python will be a favorite subject > for religious rants and heated arguments for many people. And if we > don't manage to restrain our d evelopers from using features that force > us prematurely to move to 3.0 ... and don't underestimate what this > means, because this means other things will have to move as well, > which may have dependencies on yet other things like C++ library > versions ... then I would have to, for reasons of maintainability, > argue against continuing to allow python code development in the > project. I love python, but not enough to make 20+ people's lives > difficult. > > There are already people making this sort of argument in our project. > >JT I don't know the specifics of your app, but why does everyone insist that they need to use the 'system' python? At least one commercial python app I work with installs it's own completely independant version of python. For many apps where predictible behaviour is required you can install 'your' python, under /opt/myapp or /usr/local/myapp or whatever instead of python, python2.2, python3, etc. The downside is that you'll waste another 15Mb harddrive space, and you'll need to update your internal source tree 4 or 5 times when maintenance releases come out. Apologies if this sounds like a rant, I really mean it in a constructive way. -Grant -- http://mail.python.org/mailman/listinfo/python-list
Re: Python 3.0 unfit for serious work?
On Feb 21, 8:06 pm, [EMAIL PROTECTED] wrote: > I don't know the specifics of your app, but why does everyone insist > that they need to use the 'system' python? Hey Grant, don't worry it's not a rant. A completely valid question. Again it's a problem of dependency management ... one of the things we've had to deal with is one of the applications : they have a framework largely built in python, and I think they were indeed at one point shipping their own python because they used features not present in the "system" python. However, they did use the middleware installed on the system, and this middleware is also partially written in python ... except it was expecting the system python. So you get into very tricky things having to sanity check the PYTHONPATH, that the "user" python path is not getting exported into middleware land, nor is the application's desired PYTHONPATH being destroyed by middleware. We had just such an issue here last week, we had solved the problem for bourne shell users, but csh for some reason had a different behavior, and the user app could not longer find its python modules. About the only code for which we don't seem to have these issues is compiled C. C++ is nasty because the compilers are still catching up to the standard; the last I heard, a big segment of C++ code was stuck because it was full of apparently illegal constructs that the previous compiler (the g++ shipped stock with RHEL3) accepted, but the RHEL-4 native version refused to compile. A colleague of mine pointed out today that this is an old problem, and used to be handled by automake at compile time, with code full of ifdefs ... now we've moved the problem to run time. Which I think is harder, because sometimes we don't find the problem until our binary is halfway across the world ... JT -- http://mail.python.org/mailman/listinfo/python-list
Re: Python 3.0 unfit for serious work?
On Feb 21, 1:44 pm, [EMAIL PROTECTED] (Aahz) wrote: > > Note that I believe it will be many years, perhaps even a decade, before > "python" on a Unix system starts up Python 3.0. That's a pretty safe bet considering that the factory-installed "python" on my Linux system is still 1.x and you run "python2" to get 2.x (I haven't done a new OS install in a couple of years, but 2.x had been out for years when I did the install). And 2.x is much less likely to break 1.x code than 3.x will be to break 2.x code. -- http://mail.python.org/mailman/listinfo/python-list
Re: Python 3.0 unfit for serious work?
Jeff> My post was entitled "Python 3.0 unfit for serious work", you just Jeff> indicated that the Linux distros will agree with me, in order to Jeff> be taken seriously, the distros will have to include 2.x python Jeff> for a very long time. If 3.0 and 2.x have any serious degree of Jeff> incompatibility, python will be a favorite subject for religious Jeff> rants and heated arguments for many people. The notion that Python 3.0 was going to fix design/implementation issues in earlier versions of Python and thus cause some breakage has been known for a long time, at least since Guido's UK Python talk in March 2003. Python 2.x released will continue to be created for some time after Python 3.0 is released. From PEP-3000: I expect that there will be parallel Python 2.x and 3.x releases for some time; the Python 2.x releases will continue for a longer time than the traditional 2.x.y bugfix releases. Typically, we stop releasing bugfix versions for 2.x once version 2.(x+1) has been released. But I expect there to be at least one or two new 2.x releases even after 3.0 (final) has been released, probably well into 3.1 or 3.2. This will to some extend depend on community demand for continued 2.x support, acceptance and stability of 3.0, and volunteer stamina. The whole intention is to give authors a long period of time to port to Python 3.x. I believe your fear is just a knee jerk reaction to the notion that there will be some stated incompatibilities between 2.x and 3.x without having done any investigation of the transition process. Nobody is forcing you to do anything right now or completely abandon your code base. Python 2.x still has a long shelf life. Hell, 3.0a1 isn't even out yet. If you hang on for a few days I'm sure Guido's keynote about Python 3 from the PyCon just wrapping up in Dallas will be available online. There might be something in there of interest to you. If you poke around a bit you will probably find nearly live blogs from the conference as well. Skip -- http://mail.python.org/mailman/listinfo/python-list
Re: Python 3.0 unfit for serious work?
Hey, > Python 3.x. I believe your fear is just a knee jerk reaction to the notion > that there will be some stated incompatibilities between 2.x and 3.x without > having done any investigation of the transition process. Nobody is forcing > you to do anything right now or completely abandon your code base. Python > 2.x still has a long shelf life. Hell, 3.0a1 isn't even out yet. If you Thanks to the pointer to PyCon, if there is anything relevant maybe you can send me off a mail (or post here) with some links. About the above : it isn't fear, I'm just telling you what I suspect might happen. My own little piece of code in the giant picture will remain in python, unless i am mandated to move it to something else : I *like* python. I threw in my few cents here just because I suspect the python community does not intend to move itself into the realm of "interesting but not serious languages" like Oberon did. I could be wrong, both in the sense that maybe that *is* the intention, or maybe making a backwards-incompatible "evolution" of the language won't hurt python or it's users. We now return to your regularly scheduled program. J "back to the grind" T -- http://mail.python.org/mailman/listinfo/python-list
