will python 3000 break my code?
Michal Wallace
Hey all,
I noticed this just recently on http://www.python.org/1.5/ ...
> 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
http://www.sabren.com/
Aahz Maruch
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 aa...@netcom.com)
Androgynous poly kinky vanilla queer het <*> http://www.rahul.net/aahz/
Hugs and backrubs -- I break Rule 6
Nostalgia just ain't what it used to be
Fredrik Lundh
> > 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.
>
> 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.
</F>
chris patti
> In article <87tkoi$hql$1...@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 aa...@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
--------------------------------------------------------------------
Aahz Maruch
chris patti <cpa...@atg.com> wrote:
>aa...@netcom.com (Aahz Maruch) writes:
>> In article <87tkoi$hql$1...@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.
>
> 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 aa...@netcom.com)
Androgynous poly kinky vanilla queer het <*> http://www.rahul.net/aahz/
Gerrit Holl
> In article <87tkoi$hql$1...@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.
I don't think that's a nice explanation on a Python newsgroup :(
regards,
Gerrit.
--
Homepage: http://www.nl.linux.org/~gerrit
-----BEGIN GEEK CODE BLOCK----- http://www.geekcode.com
Version: 3.12
GCS dpu s-:-- a14 C++++>$ UL++ P--- L+++ E--- W++ N o? K? w--- !O
!M !V PS+ PE? Y? PGP-- t- 5? X? R- tv- b+(++) DI D+ G++ !e !r !y
-----END GEEK CODE BLOCK----- moc.edockeeg.www//:ptth
Michal Wallace
>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...
-michal
http://www.sabren.com/
Doug Landauer
> 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 land...@apple.com (work)
land...@scruznet.com (not-work)
Ronald L. Dilsavor
> 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?
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
Tim Peters
> I am in the process of deciding whether to have a team of folks
> 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.
it's-not-really-that-scary!-ly y'rs - tim
Steve Holden
>
> [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.
>
>
> 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"
Fredrik Lundh
> 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 ;-)
</F>
Fredrik Lundh
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:
http://www.python.org/consortium/
(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>
Emile van Sebille
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 <sho...@bellatlantic.net>
Newsgroups: comp.lang.python
To: <pytho...@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...
>
> regards
> Steve
> --
> "If computing ever stops being fun, I'll stop doing it"
> --
> http://www.python.org/mailman/listinfo/python-list
>
Moshe Zadka
> (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.
Fredrik Lundh
> > (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.
</F>
Ronald L. Dilsavor
> 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?
>
>
>> [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
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
Bijan Parsia
> [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.
Cheers,
Bijan Parsia.
Bruce Dodson
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.
Alex
> 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.
Alex.
Fredrik Lundh
>
> > 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...
</F>
<!-- (the eff-bot guide to) the standard python library:
http://www.pythonware.com/people/fredrik/librarybook.htm
-->
Gerrit Holl
>
> > 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
> 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.
</quote>
regards,
Gerrit.
--
Gerrit Holl
> <quote name="Alex" date="951861012" email="al...@somewhere.round.here">
> >
> > > 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.
</quote>
Fredrik Lundh
> 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...
</F>
Gerrit Holl
> 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.
</quote>
regards,
Gerrit.
Alex
Fredrik and Gerrit, thanks for the info. I didn't realize it would be a
type error. I wasn't complaining, though, just giving an example of why
I think some rewriting will be necessary. And I'm not suprised that it
turns out to be bad form. I'm not a professional coder, and I'm
learning those sorts of aesthetics as I go along.
Alex.
Fredrik Lundh
fwiw, I'm consider myself a professional coder, and
I also have a several hundred lines to fix ;-)
</F>
Fredrik Lundh
> This is the silliest thing i've ever heard.
really?
> Sorry, that's just not the way it works.
> This is a *BUG*. NOT A FEATURE.
then why is the 1.5.2 standard library (huge parts of which
are written by Guido) using this all over the place?
> Mainly Idiot programmers (sorry, but i'm referring to the idiots specifically
> coding assuming a *BUG* would always exist. It's different to make a mistake,
> or check for a bug. But to simply assume no one will ever fix it is idiotic)
the fix breaks PythonWin, Medusa, Zope, PIL, the current
standard library, and tons of other major libraries and
applications.
are we all Idiot programmers? maybe. but you obviously
have far more serious problems. please grow up. when
you've done that, consider posting an apology.
</F>
bjorn
Daniel Berlin wrote:
> >>>>> "bjorn" == <bj...@roguewave.com> writes:
>
> >> [snippage]
> >> 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...
>
> bjorn> I must say I was kind of concerned when Guido announced this
> bjorn> change. Where I work, source code incompatible changes are an
> bjorn> almost complete no-no, even for major releases. The impact to
> bjorn> customers is just too great. The moral is probably, if you made an
> bjorn> implementation boo-boo, you better learn to live with it quickly.
>
> Oh. I see. MS syndrome.
>
> This is the silliest thing i've ever heard.
> If your C++ compiler has an implementation bug, and accepts some code it
> shouldn't, then they shouldn't fix it because too many customers might depend
> on buggy code?
> Sorry, that's just not the way it works.
> This is a *BUG*. NOT A FEATURE.
> Why is this so hard to understand.
> You don't deprecate bugs.
> You fix them.
> Anyone who made a bug in their code, has to fix it.
> But they didn't know, you say?
> Now they know.
> When I worked at MS (MS Research, but I knew intimately what went on inside
> MS, obviously), there was way too much of this mentality of "We can't fix
> bugs because customers depend on them".
> They were right of course, that it would break programs.
> Mainly Idiot programmers (sorry, but i'm referring to the idiots specifically
> coding assuming a *BUG* would always exist. It's different to make a mistake,
> or check for a bug. But to simply assume no one will ever fix it is idiotic)
> would program assuming bugs would always be there.
> MS wouldn't fix the bug, because it would break too many programs.
> So they were damned either way.
> If they fixed it, it would break programs.
> If they left it, they get yelled at for not fixing bugs.
> So invariably, they left it.
> This isn't the right answer.
> The answer is to try to fix the bug as quickly as possible, so the least
> number of people have the chance to write buggy code.
> But if, later on, you find the bug, and it's existed for quite a while, that
> doesn't mean you don't fix it.
> If it was a feature, i might agree. It's not.
> It's a bug.
> Bugs don't get deprecated.
> I don't see g++ saying "Warning: Doing this will no longer work in the next
> version because you shouldn't have been doing this in the first place.".
> It says "ANSI C++ forbids ...".
> It's an error.
No, it's a design change by a standards committe, that has evaluated all the
options, giving individual vendors the chance to veto any changes that would be
too radical for their customers (I know, I've been there). It's an enormous leap
from that to deciding that list.append(1,2,3) might be so confusing to some
newcomers that people who know what they were doing have to change their code
(ask Frederik if he doesn't have more interesting things to do than fixing
multiargument appends ;-)
> Unless you turn on a flag turning compliance errors into warnings.
> Most people will actually turn off the warning rather than fix the broken
> code.
>
> Does this break a lot of code?
> Sure.
> Should that code break?
> Yup.
>
> Should people stop fixing bugs in the python implementation cause some major
> customer has programmers who wrote buggy code?
> Nope.
Was this a bug? Not really. Was it a source incompatible design change? You
bet.
> bjorn> I suppose I can agree with his analysis of the "evils" of
> bjorn> multiargument append, but I'm not sure I think it's a big enough
> bjorn> deal to break source compatibility.
>
> God damn it. It's not a feature. It's a bug. A bug. It should have been an
> error nit he first place. It's only by the grace of Guido and a slip of the
> eye that it wasn't.
And nobody would have complained if it _was_ an error in the first place.
> | the-days-of-legacy-code-are-upon-us'ly y'rs
> No they aren't.
If you're going to have any luck getting a company (vs. individual dedicated
programmers) to use your tools, is if the tools are stable enough that a company
doesn't have to spend money every time you do a new release. If you do think a
change is neccessary, and they often are although I'm not sure this particular
one rises to that level, you should at least warn customers by upping a major rev
number (or waiting until it's time to do so).
The-price-of-purity-is-obscurity'ly y'rs
-- bjorn
ps: since Guido hath spoken, there really is no reason to discuss this further,
so this'll have to be my last words on the issue -- I know we're all heartbroken
<wink>
Fredrik Lundh
> > (ask Frederik if he doesn't have more interesting things to do than fixing
> > multiargument appends ;-)
>
> changes in g++. It's just the implementation happened to be allowing
> illegal (by the language standard) things because nobody had gotten around
> to saying "that's illegal".
last time I checked, Python had no formal standard.
(the language reference is pretty good, but it's no
ISO/ANSI level standard. and nobody reads it any-
way ;-)
> Not a bug?
depends. "append" used old method calling syntax
(ml_flags == 0), under which all arguments are passed
to the function as a tuple. the code just added that
to the list.
given that lots of old code in the standard library used
this feature, someone must once have thought that
this was a good idea. or at least acceptable.
however, it was deprecated as of 1.4 (where you around
at that time?), but as far as I know, nobody remembered
to add a warning to the documentation.
so what we're seeing is an innocent looking minor change,
that turns out to:
1. break lots of code
2. result in a runtime error, not compile-time
error. we've already seen cases where code
expected a TypeError to have a certain mean-
ing, and misbehaved when append and not ord
was the one throwing the exception (written by
a programmer that knew his tool too well,
obviously...)
3. be impossible to identify by automatic tools.
Tim's excellent checkappend.py can spot many
cases, but not all.
given this, arguing whether this is a bug or a feature is
rather meaningless. I'd call it a "CPython implementation
wart".
the BDFL wants to get rid of it. that's okay with me.
calling professional programmers idiots is not okay.
</F>
Daniel Berlin
>>>>> "FL" == Fredrik Lundh <eff...@telia.com> writes:
>> (ask Frederik if he doesn't have more interesting things to do than
>> fixing multiargument appends ;-)
>> Actually, it's not a design change in about 95% of the incompatible
>> changes in g++. It's just the implementation happened to be allowing
>> illegal (by the language standard) things because nobody had gotten
>> around to saying "that's illegal".
FL> last time I checked, Python had no formal standard.
Given. But it does have a language and library reference.
| (the language reference is pretty good, but it's no
| ISO/ANSI level standard. and nobody reads it any-
| way ;-)
Oops. I read it. Maybe that's why i've become a language lawyer.
>> Not a bug?
| depends. "append" used old method calling syntax
| (ml_flags == 0), under which all arguments are passed
| to the function as a tuple. the code just added that
| to the list.
Right (I examined the code before i stuck my foot in my mouth).
| given that lots of old code in the standard library used
| this feature, someone must once have thought that
| this was a good idea. or at least acceptable.
| however, it was deprecated as of 1.4 (where you around
| at that time?), but as far as I know, nobody remembered
| to add a warning to the documentation.
I was around at the time, but I was lurking, and doing other things.
And also writing a DWARF2 debug info reader in python.
(It's a much bigger job than it sounds. DWARF2 is very very evil. Most end up
being about 300k of C code. Mine was 2000 lines of python, or just about 10
time less. Just as quick, too. )
| so what we're seeing is an innocent looking minor change,
| that turns out to:
> 1. break lots of code
Not unusual.
Too many years of working on C++ compilers and debuggers i guess.
| 2. result in a runtime error, not compile-time
| error. we've already seen cases where code
| expected a TypeError to have a certain mean-
| ing, and misbehaved when append and not rod
| was the one throwing the exception (written by
| a programmer that knew his tool too well,
| obviously...)
| 3. be impossible to identify by automatic tools.
| Tim's excellent checkappend.py can spot many
| cases, but not all.
Actually, this isn't true (that it's impossible).
If you really like, i'll take a few days of my spring break and write one
guaranteed to catch every single case.
You can do it by looking at the byte code.
If you are trying to call function "append" with more than 1 argument on an
object whose type is a list, it's bad.
| given this, arguing whether this is a bug or a feature is
| rather meaningless. I'd call it a "CPython implementation
| wart".
FL> the BDFL wants to get rid of it. that's okay with me.
FL> calling professional programmers idiots is not okay.
I didn't. I apologize if you think I did (It's also midterms week, so i'm a
little er, agitated, to say the least).
Then again, i don't consider programmers who write code that depends on the
existence of bugs (knowingly, intentionally, and with the assumption that the
bug will *never* ever be fixed, in such a way that if the bug was fixed, the
program would blow up in horrible ways) to be very professional.
Their is a world of difference between the people i was calling idiots (I had
a particular group of windows programmers in mind), and a python programmer
who didn't know it was a bug.
FL> </F>
| --
| http://www.python.org/mailman/listinfo/python-list
Fredrik Lundh
> | 3. be impossible to identify by automatic tools.
> | Tim's excellent checkappend.py can spot many
> | cases, but not all.
>
> Actually, this isn't true (that it's impossible).
> If you really like, i'll take a few days of my spring break and write one
> guaranteed to catch every single case.
how about this one:
foo = list.append
for bar in range(100):
foo(bar, bar, bar)
or this one:
class Foo:
def __init__(self):
self.setup()
self.add = self.list.append
def setup(self):
self.list = []
foo = Foo()
foo.add(bar, bar, bar)
</F>
Martijn Faassen
[snip]
[effbot]
> 3. be impossible to identify by automatic tools.
> Tim's excellent checkappend.py can spot many
> cases, but not all.
> Actually, this isn't true (that it's impossible).
> If you really like, i'll take a few days of my spring break and write one
> guaranteed to catch every single case.
> You can do it by looking at the byte code.
> If you are trying to call function "append" with more than 1 argument on an
> object whose type is a list, it's bad.
Are you sure you've thought this through? How would you know the
type of an object is a list? That's the tricky part, to know you're
dealing with a list and not something else that happens to have a method
'append'.
Anyway, if you can write a static typechecker for Python in a few days
during spring break the types-sig will be happy; doing this isn't *that*
much easier than writing a full fledged static typechecker, it seems to
me.
Regards,
Martijn
Daniel Berlin
>>>>> "MF" == Martijn Faassen <m.fa...@vet.uu.nl> writes:
MF> [snip]
MF> [effbot]
>> 3. be impossible to identify by automatic tools. Tim's excellent
>> checkappend.py can spot many cases, but not all.
>> Actually, this isn't true (that it's impossible). If you really like,
>> i'll take a few days of my spring break and write one guaranteed to
>> catch every single case. You can do it by looking at the byte code.
>> If you are trying to call function "append" with more than 1 argument
>> on an object whose type is a list, it's bad.
MF> Are you sure you've thought this through? How would you know the type
MF> of an object is a list?
This can only be done at runtime, of course, without getting into very heavy
analysis.
However, i can instrument the code rather easily, so that even really tricky
things would still tell you where the problem is really being generated (IE
where foo became an append method, which is why when you passed it to some
random function that called it's arguments, you had problems.
That's the only way to catch things passed as arguments.
I was talking about a tool that both looked at the bytecode, and instrumented
it.
It's automatic in the same way "BoundsChecker" is an automatic tool.
MF>That's the tricky part, to know you're dealing
MF> with a list and not something else that happens to have a method
MF> 'append'.
Right.
I realize this.
MF> Anyway, if you can write a static typechecker for Python in a few days
MF> during spring break the types-sig will be happy; doing this isn't
MF> *that* much easier than writing a full fledged static typechecker, it
MF> seems to me.
God no. I shudder at the thought of the analysis required.
MF> Regards,
MF> Martijn
| --
| http://www.python.org/mailman/listinfo/python-list
Ivan Van Laningham
Daniel Berlin wrote:
>
[snip]
> God damn it. It's not a feature. It's a bug. A bug. It should have been an
> error nit he first place. It's only by the grace of Guido and a slip of the
> eye that it wasn't.
>
<now-tell-us-how-you-*really*-feel<wink>>-ly y'rs,
Ivan;-)
----------------------------------------------
Ivan Van Laningham
Callware Technologies, Inc.
http://www.pauahtun.org
http://www.foretec.com/python/workshops/1998-11/proceedings.html
Army Signal Corps: Cu Chi, Class of '70
Author: Teach Yourself Python in 24 Hours
Daniel Berlin
>>>>> "IVL" == Ivan Van Laningham <iva...@callware.com> writes:
IVL> Daniel Berlin wrote:
>>
IVL> [snip]
>> God damn it. It's not a feature. It's a bug. A bug. It should have been
>> an error nit he first place. It's only by the grace of Guido and a slip
>> of the eye that it wasn't.
IVL> <now-tell-us-how-you-*really*-feel<wink>>-ly y'rs, Ivan;-)
If your really must know, i feel like someone who was forced to write a Part
of Speech tagger (HMM based) in Perl in one week (handling unknown words and
all), and had to watch it do 6-fold cross validation.
It takes it 118 minutes to tag a 12 meg file in perl, because it sucks for
number crunching.
I rewrote it in C++ while waiting for it to finish the validation, and it
took 38 seconds.
It's not an algorithm issue, either. Perl just sucks that badly at number crunching.
To quote Professor Allen, when I asked if i could turn in the C++ version,
and said that i didn't think perl was the right language to be doing the
number crunching in, "Yes. I really didn't realize it would be this bad"[1].
The kicker?
Mine is the fastest tagger of the class.
So besides my midterms, I have perl angst.
Forgive my anger.
--Dan
Footnotes:
[1] I have a feeling this isn't a rare statement about perl programs.
Chuck Esterbrook
So I came into this discussion very late. What is Python 3000? :-)
(Seriously, got a URL or posting or something? My earliest article in this thread doesn't clue me in.)
-Chuck
Chuck Esterbrook
So when is Apple going to provide Foundation and AppKit bindings for Python and support the language in Project Builder? :-)
(Or are you one of those Carbon people...)
Doug Landauer wrote:
> > 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 land...@apple.com (work)
> land...@scruznet.com (not-work)
Charles Hixson
thus:
foo.appendA_List(1, 2, 3)
which would act the way in which append has historically acted. The deprecation
would be fair warning that it would be going away soon, and the ugly name would
further disincline folk to use it. This should facilitate the automated
conversion of current code, and allow it to be corrected at a humane rate.
Daniel Berlin
>>>>> "CH" == Charles Hixson <charle...@earthlink.net> writes:
CH> thus: foo.appendA_List(1, 2, 3) which would act the way in which
CH> append has historically acted. The deprecation would be fair warning
CH> that it would be going away soon, and the ugly name would further
CH> disincline folk to use it. This should facilitate the automated
CH> conversion of current code, and allow it to be corrected at a humane
CH> rate.
Actually, while thinking if there was any way around having to do lots of
static analysis to be able to do this at compile time with just bytecode,
something came to me:
You can automatically fix every instance of this on the fly if you
can afford to take a performance loss.
(Yes, i know, i'm stupid, and should have realized it before).
Rather than just notify that the code needs to be fixed, you can
automatically, patch the bytecode to fix the problem, as it occurs.
The costs may seem prohibitive at first, but i ran a few tests and it's
really not.
In fact, most of the cost associated with determining the type at runtime and
fixing the append call can be removed by a bit of smart optimization at
runtime.
--Dan
| --
| http://www.python.org/mailman/listinfo/python-list
Manuel Gutierrez Algaba
I do think that the difference between a real good programmer
and a bad one is that the good programmer produces code that
eventually get fixed and evolved, the bad programmer produces
code that can't be fixed nor evolved. The bad programmer
produces always a single version. Bad programmers are common
in professional world, specially in the Microsuck environment.
OO helps to create good programmers.
--
MGA
Doug Landauer
following up on...
Lemme shake up this 8-ball...
> So when is Apple going to provide Foundation and AppKit bindings for Python
Reply hazy, try again later.
> and support the language in Project Builder? :-)
Reply hazy, try again later.
Dang, it must be broken.
> (Or are you one of those Carbon people...)
Well, when I step on the old spectrometer, it says that there's Carbon
somewhere in there, as well as Nitrogen, Oxygen, Hydrogen, and Chocolate,
but no, I don't work on Carbon. Or AppKit or Foundation. Just gcc. I
barely have time to just compile up a bare python (not even shared-libraries
or a readline library) for my own use, let alone write bindings for something
the size of AppKit.
I haven't even managed to convince them to ship Python on the
system yet :-( -- I just use it to make little tools to help me debug
stuff.