> The new release schedule provides for a 1.7 > release later in 2000 (or early 2001); after that, > we'll be working on "Python 3000" (the new code > name for the grand Python redesign; the language > will be incompatible).
I did a search for "Python 3000" on the SIGS, and came up with only a handful of hits... It looked like maybe the import style and type checking might change, but from what I could tell, everyone wanted to avoid breaking old scripts...
"The language will be incompatible" seems like kind of a dangerous statement to be making without backing it up... As much as I love python, for example, I can't very well recommend using it if everything I write will have to be thrown out in a year or two.
Anyone know what, specifically, will not be compatible, and compared to what? :)
Michal Wallace <sab...@manifestation.com> wrote: > > The new release schedule provides for a 1.7 > > release later in 2000 (or early 2001); after that, > > we'll be working on "Python 3000" (the new code > > name for the grand Python redesign; the language > > will be incompatible).
> I did a search for "Python 3000" on the SIGS, and came > up with only a handful of hits... It looked like maybe > the import style and type checking might change, but > from what I could tell, everyone wanted to avoid > breaking old scripts...
> "The language will be incompatible" seems like kind > of a dangerous statement to be making without > backing it up... As much as I love python, for example, > I can't very well recommend using it if everything I > write will have to be thrown out in a year or two.
> Anyone know what, specifically, will not be compatible, > and compared to what? :)
given that 1.6 isn't finished yet, and there will be a 1.7 release after that, don't you think it's a bit early to decide what to do in python 3000? ;-)
(personally, I'd be very surprised if the changes were such that old code couldn't be automatically translated).
and if GvR should go berzerk and turn Python 3000 into something completely different, I can assure you that the 1.X thread will continue to be maintained.
a...@netcom.com (Aahz Maruch) writes: > In article <87tkoi$hq...@nntp1.atl.mindspring.net>, > Michal Wallace <sab...@manifestation.com> wrote:
> >Anyone know what, specifically, will not be compatible, and compared to > >what? :)
> Nope. I get the feeling that it will be similar to moving from Perl 4 > to Perl 5. > -- > --- Aahz (Copyright 2000 by a...@netcom.com)
E-gads.
I _fear_ for that particular comparison :)
-Chris (Perl's 'object system' introduced in Perl5 is one of the things that made me switch to Python! :) -- -------------------------------------------------------------------- Chris Patti \ Art Technology Group \ 617-386-1649 \ cpa...@atg.com --------------------------------------------------------------------
In article <yu1vh3xkn85....@black-racer.atg.com>, chris patti <cpa...@atg.com> wrote:
>a...@netcom.com (Aahz Maruch) writes: >> In article <87tkoi$hq...@nntp1.atl.mindspring.net>, >> Michal Wallace <sab...@manifestation.com> wrote:
>>>Anyone know what, specifically, will not be compatible, and compared to >>>what? :)
>> Nope. I get the feeling that it will be similar to moving from Perl 4 >> to Perl 5.
>E-gads. I _fear_ for that particular comparison :) >(Perl's 'object system' introduced in Perl5 is one of the > things that made me switch to Python! :)
Well, I wasn't talking about the relative degree of improvements made in moving from one major version to another. My point was that most basic functionality should remain the same (or close enough that simple scripts will continue to run correctly), but that anyone exploiting quirks of the language will almost certainly face problems. -- --- Aahz (Copyright 2000 by a...@netcom.com)
Androgynous poly kinky vanilla queer het <*> http://www.rahul.net/aahz/ Hugs and backrubs -- I break Rule 6
Fredrik Lundh wrote in message ... >given that 1.6 isn't finished yet, and there will be >a 1.7 release after that, don't you think it's a bit >early to decide what to do in python 3000? ;-)
>(personally, I'd be very surprised if the changes were >such that old code couldn't be automatically translated).
I guess that makes sense... As a programmer, I say bring it on... but as a businessperson, that unqualified statement on the website gave me the chills.. I suspect I'm not alone in that - what company wants to invest in (software) technology that may be obsolete in two years?
An upgrade is one thing, but an upgrade that breaks stuff is dangerous... especially when there's no clear sign saying what to avoid...
> Rule of Software Systems: Upgrade software when it fixes bugs you > need fixed, or adds features you need added. Never anytime else.
Aw, c'mon, this is comp.lang.python. Upgrade your software any time it looks like it will make programming more fun!!! Oh, ya, and those other things times you suggested. -- Doug Landauer landa...@apple.com (work) landa...@scruznet.com (not-work)
> From: "Michal Wallace" <sab...@manifestation.com> > Organization: MindSpring Enterprises > Newsgroups: comp.lang.python > Date: Thu, 10 Feb 2000 19:32:13 -0500 > Subject: Re: will python 3000 break my code?
> Fredrik Lundh wrote in message ...
>> given that 1.6 isn't finished yet, and there will be >> a 1.7 release after that, don't you think it's a bit >> early to decide what to do in python 3000? ;-)
>> (personally, I'd be very surprised if the changes were >> such that old code couldn't be automatically translated).
> I guess that makes sense... As a programmer, I say > bring it on... but as a businessperson, that unqualified > statement on the website gave me the chills.. I suspect > I'm not alone in that - what company wants to invest in > (software) technology that may be obsolete in two years?
> An upgrade is one thing, but an upgrade that breaks > stuff is dangerous... especially when there's no clear > sign saying what to avoid...
Ditto here, I am in the process of deciding whether to have a team of folks invest in implementing our product in Python and this was one of the "cons" on my list. I would like to assume that automatic translators will be developed - but at this point its just an assumption. If nobody knows what is going to be in 3000 then how do they know it will be incompatible? Ron
> I am in the process of deciding whether to have a team of folks > invest in implementing our product in Python and this [presumed > incompatibility of Python 3000] was one of the "cons" on my list.
As it should be! Don't overvalue it, though. For example, even if Python 3000 is an *entirely different language*, no C program stopped working the day C++ was released -- or a decade later, either. That is, you won't be alone no matter what, and the current implementation of Python is extraordinarily clean and maintainable: it still needs Guido's help to guide its evolution, but not at all to keep it running in top shape. Many people understand the current implementation, and can handle that fine. So if Python 3000 turns out to be wholly incompatible, I fully expect someone else (i.e., other than Guido) would jump in to continue work on the current Python line.
So nothing is going to break your product -- the question will be whether you like Python 3000 enough to justify whatever it may take to move to it.
> I would like to assume that automatic translators will be > developed -
I personally would not count on that, but then I am a bit of a pessimist about such things. The world of free software is great at delivering what developers want to write; it's not so hot at delivering what would be most useful, unless that happens to coincide with the former. For example, I wouldn't work on such a translator for love, but may for pay. And if you were in my shoes, you'd be typing the same thing <0.5 wink>.
> but at this point its just an assumption. If nobody knows what is > going to be in 3000 then how do they know it will be incompatible?
Educated guesses, of course. For example, the type of every instance (of every class) today is InstanceType. Nobody likes that; it was a flaw in the original design, and there's no clean way to repair it without possibly breaking somebody's code. Or perhaps "do" will become a keyword, to enable a new loop construct that obviates the need for an often-complained-about clumsy Python idiom today. Anyone with a variable named "do" would then get hosed. Etc.
There are a number of things that Guido may like to clean up, and this is his chance to do it. You can try to guess how "bad" things will break, but you really have no solid info to go on (my guess is "not so bad", but nobody knows at this stage). So a conservative worst-case plan is to assume that Python as we know it will be around forever (& there will at *least* be a new Python 1.6 and a new Python 1.7 to come in this line), while Python 3000 is some other new language entirely.
> [Ronald L. Dilsavor] > > I am in the process of deciding whether to have a team of folks > > invest in implementing our product in Python and this [presumed > > incompatibility of Python 3000] was one of the "cons" on my list.
> As it should be! Don't overvalue it, though. For example, even if Python > 3000 is an *entirely different language*, no C program stopped working the > day C++ was released -- or a decade later, either.
> [much other reassuring and sensible stuff]
> it's-not-really-that-scary!-ly y'rs - tim
With trepidation, I write to ask what the appropriate forum is for suggesting language improvements -- and I don't mean introducing redundant bracketing for block delimitation. However, recent threads have persuaded me that this probably isn't the forum for my lame suggestions: you guys are busy enough. I would have talked to people at the conference, but then the weather and a client emergency meant that all I got for my fee was an email acknowledgement. Next year, maybe...
regards Steve -- "If computing ever stops being fun, I'll stop doing it"
Steve Holden <shol...@bellatlantic.net> wrote: > With trepidation, I write to ask what the appropriate forum is for > suggesting language improvements -- and I don't mean introducing > redundant bracketing for block delimitation. However, recent threads > have persuaded me that this probably isn't the forum for my lame > suggestions: you guys are busy enough.
nah. if you have great ideas, feel free to post them here.
just remember to:
1) check if there's a SIG that might be more appropriate (types, compilation issues, etc)
and
2) check the newsgroup archive, especially if you think that someone might have had the same idea before you... (this list have been around for 10 years, you know...)
make signal, not noise.
(if your ideas are good enough, someone will drop by your home some night, and teach you the secret handshake ;-)
Tim Peters <tim_...@email.msn.com> wrote: > [Ronald L. Dilsavor] > > I am in the process of deciding whether to have a team of folks > > invest in implementing our product in Python and this [presumed > > incompatibility of Python 3000] was one of the "cons" on my list.
> As it should be! Don't overvalue it, though. For example, even if Python > 3000 is an *entirely different language*, no C program stopped working the > day C++ was released -- or a decade later, either. That is, you won't be > alone no matter what, and the current implementation of Python is > extraordinarily clean and maintainable: it still needs Guido's help to > guide its evolution, but not at all to keep it running in top shape.
just to add a few extra points to Tim's excellent treatment of this issue:
if you plan to use python in a commercial context, you have a number of ways to make sure you don't get into trouble. they all involve small amounts of $'s, though:
1. join the consortium and put some pressure on the technical director to make sure nobody's left behind by Py3K:
(yes, the consortium's technical director do have some influence in these matters ;-).
2. make it clear to commercial python tool vendors (Secret Labs, Active State, etc) that you're willing to support vendors providing a clean upgrade path from Python 1.X to Py3K.
3. set aside some time to study Python internals, and make sure you have local expertise to make necessary modifications, if necessary. also avoid designing your application to be overly dependent on implementation details in CPython 1.X (reference counting, types, access to bytecodes, etc. looking at JPython might help here).
4. buy beer to everyone at the python conference! (or join the consortium and buy beer to everyone at the consortium meetings)
Until someone picks the short straw and has to go monitor an advocacy group this is the right place. It's only when you get into the 'asked-and-answered' stage of responses that things won't progress. At that point, you make it your own, a la VIPER or Stackless, or simply accept that Guido will continue to do-the-right-thing.
Emile van Sebille em...@fenx.com -------------------
----- Original Message ----- From: Steve Holden <shol...@bellatlantic.net>
Newsgroups: comp.lang.python To: <python-l...@python.org> Sent: Friday, February 11, 2000 5:02 AM Subject: Re: will python 3000 break my code?
> The timbot wrote:
> > [Ronald L. Dilsavor] > > > I am in the process of deciding whether to have a team of folks > > > invest in implementing our product in Python and this [presumed > > > incompatibility of Python 3000] was one of the "cons" on my list.
> > As it should be! Don't overvalue it, though. For example, even if Python > > 3000 is an *entirely different language*, no C program stopped working the > > day C++ was released -- or a decade later, either.
> > [much other reassuring and sensible stuff]
> > it's-not-really-that-scary!-ly y'rs - tim
> With trepidation, I write to ask what the appropriate forum is for > suggesting language improvements -- and I don't mean introducing > redundant bracketing for block delimitation. However, recent threads > have persuaded me that this probably isn't the forum for my lame > suggestions: you guys are busy enough. I would have talked to people > at the conference, but then the weather and a client emergency meant > that all I got for my fee was an email acknowledgement. Next year, > maybe...
On Fri, 11 Feb 2000, Fredrik Lundh wrote: > (if your ideas are good enough, someone will > drop by your home some night, and teach you > the secret handshake ;-)
Fredrik, if you keep uncovering PSU tactics, someone might drop by *your* house. For nothing as pleasent as handshakes, you know.
totally-unhelpful-to-the-s/n-ration-ly y'rs, Z. -- Moshe Zadka <mza...@geocities.com>. INTERNET: Learn what you know. Share what you don't.
Moshe Zadka <mos...@math.huji.ac.il> wrote: > > (if your ideas are good enough, someone will > > drop by your home some night, and teach you > > the secret handshake ;-)
> Fredrik, if you keep uncovering PSU tactics, someone might drop > by *your* house. For nothing as pleasent as handshakes, you know.
you drove that white audi? didn't look like you, but you sure scared the hell out of me.
> From: "Fredrik Lundh" <eff...@telia.com> > Organization: Telia Internet > Reply-To: "Fredrik Lundh" <eff...@telia.com> > Newsgroups: comp.lang.python > Date: Fri, 11 Feb 2000 14:17:02 GMT > Subject: Re: will python 3000 break my code?
> <F note="posted and mailed">
> Tim Peters <tim_...@email.msn.com> wrote: >> [Ronald L. Dilsavor] >>> I am in the process of deciding whether to have a team of folks >>> invest in implementing our product in Python and this [presumed >>> incompatibility of Python 3000] was one of the "cons" on my list.
>> As it should be! Don't overvalue it, though. For example, even if Python >> 3000 is an *entirely different language*, no C program stopped working the >> day C++ was released -- or a decade later, either. That is, you won't be >> alone no matter what, and the current implementation of Python is >> extraordinarily clean and maintainable: it still needs Guido's help to >> guide its evolution, but not at all to keep it running in top shape.
> just to add a few extra points to Tim's excellent > treatment of this issue:
> if you plan to use python in a commercial context, you > have a number of ways to make sure you don't get into > trouble. they all involve small amounts of $'s, though:
> 1. join the consortium and put some pressure on > the technical director to make sure nobody's left > behind by Py3K:
> (yes, the consortium's technical director do have > some influence in these matters ;-).
> 2. make it clear to commercial python tool vendors > (Secret Labs, Active State, etc) that you're willing > to support vendors providing a clean upgrade path > from Python 1.X to Py3K.
> 3. set aside some time to study Python internals, and > make sure you have local expertise to make necessary > modifications, if necessary. also avoid designing your > application to be overly dependent on implementation > details in CPython 1.X (reference counting, types, > access to bytecodes, etc. looking at JPython might > help here).
> 4. buy beer to everyone at the python conference! (or > join the consortium and buy beer to everyone at the > consortium meetings)
> </F>
Thanks a lot for your response. I was not expecting big reassurances but I thought it was worth asking. Its not going to make or break my decision. Also, I think your item 4 below has real possibilities. Bud Lite or microbrew? Ron
Tim Peters <tim_...@email.msn.com> wrote: > [Ronald L. Dilsavor] > > I am in the process of deciding whether to have a team of folks > > invest in implementing our product in Python and this [presumed > > incompatibility of Python 3000] was one of the "cons" on my list.
> As it should be! Don't overvalue it, though. For example, even if Python > 3000 is an *entirely different language*, no C program stopped working the > day C++ was released -- or a decade later, either. That is, you won't be > alone no matter what, and the current implementation of Python is > extraordinarily clean and maintainable: it still needs Guido's help to > guide its evolution, but not at all to keep it running in top shape. Many > people understand the current implementation, and can handle that fine. So > if Python 3000 turns out to be wholly incompatible, I fully expect someone > else (i.e., other than Guido) would jump in to continue work on the current > Python line.
Not to mention that there are (at least) two alternative implementations that do not derive from the CPython code base (i.e., they aren't forked implementations, but *re*implementations). One of thes is sufficently mature for production work (JPython). Plus, there is sufficient documentation to make yet another implementation fairly straightforward.
I wouldn't worry about that. You won't have to throw or rewrite old code, unless you want to take advantage of features in Python 3000. That is, if your app doesn't need anything from Python 3000, it can go on using the 1.x interpreter for which it was designed.
>"The language will be incompatible" seems like kind >of a dangerous statement to be making without >backing it up... As much as I love python, for example, >I can't very well recommend using it if everything I >write will have to be thrown out in a year or two.
> I wouldn't worry about that. You won't have to throw or rewrite old > code, unless you want to take advantage of features in Python 3000.
It wouldn't suprise me if some rewriting were needed. For instance, Guido said that he will be changing the list.append method so that l.append(1,2) gives a syntax error. That will mean that I am going to have to change a hundred or so lines of code.
> > I wouldn't worry about that. You won't have to throw or rewrite old > > code, unless you want to take advantage of features in Python 3000.
> It wouldn't suprise me if some rewriting were needed. For instance, > Guido said that he will be changing the list.append method so that > l.append(1,2) gives a syntax error.
note it will give a TypeError at run time, not a SyntaxError.
make sure you run checkappend.py over and over again...
> > I wouldn't worry about that. You won't have to throw or rewrite old > > code, unless you want to take advantage of features in Python 3000.
> It wouldn't suprise me if some rewriting were needed. For instance, > Guido said that he will be changing the list.append method so that > l.append(1,2) gives a syntax error. That will mean that I am going to > have to change a hundred or so lines of code.
1) l.append changes in Python 1.6, not in P3K, 2) it's such a small change; it will be able to be done automatically, 3) it's considered Bad Style to use multi-argument append, IMHO.
> > > I wouldn't worry about that. You won't have to throw or rewrite old > > > code, unless you want to take advantage of features in Python 3000.
> > It wouldn't suprise me if some rewriting were needed. For instance, > > Guido said that he will be changing the list.append method so that > > l.append(1,2) gives a syntax error. That will mean that I am going to > > have to change a hundred or so lines of code.
> 1) l.append changes in Python 1.6, not in P3K, > 2) it's such a small change; it will be able to be done automatically, > 3) it's considered Bad Style to use multi-argument append, IMHO.
4) it won't give a SyntaxError but a TypeError instead.
Gerrit Holl <ger...@nl.linux.org> wrote: > 1) l.append changes in Python 1.6, not in P3K, > 2) it's such a small change; it will be able to be done automatically,
nope. the only way to fix this automatically is to patch the python interpreter to support the old behaviour.
"checkappend" can only spot obvious cases. to make sure your program works fine, careful regression testing is the only thing that will help.
> 3) it's considered Bad Style to use multi-argument append, IMHO.
ahem. does your HO really matter to all those who have to spend time and money changing their existing code base.
preliminary results indicate that *all* our applications and libraries (including PIL) are affected by this change. given that, it's quite likely that a few other companies will also stumble upon this one...
> Gerrit Holl <ger...@nl.linux.org> wrote: > > 1) l.append changes in Python 1.6, not in P3K,
> > 2) it's such a small change; it will be able to be done automatically,
> nope. the only way to fix this automatically is to patch the > python interpreter to support the old behaviour.
I think the Python interpreter can be patched to give warnings, like it does when exceptions are raised in __del__ or when you use the -t flag.
> "checkappend" can only spot obvious cases. to make sure your > program works fine, careful regression testing is the only thing > that will help.
OK.
> > 3) it's considered Bad Style to use multi-argument append, IMHO.
> ahem. does your HO really matter to all those who have > to spend time and money changing their existing code base.
No, it doesn't. But IIRC, it's nowhere documented and it only works because of the current implementation.
> preliminary results indicate that *all* our applications and > libraries (including PIL) are affected by this change. given > that, it's quite likely that a few other companies will also > stumble upon this one...
I *think* it's also Guido's HO, otherwise I don't understand why he changed the implementation.
