Python 3.0 To Be Backwards Incompatible 438
Stony Stevenson writes "Organizations using Python will be affected in a major way by changes in store for the language over the course of the next twelve months, Linux.conf.au attendees were told this morning. The Python development community is working towards a new, backwards-incompatible version of the language, version 3.0, which is slated for release in early 2009. Anthony Baxter, the release manager for Python and a senior software engineer at Google Australia, said "We are going to break pretty much all the code. Pretty much every program will need changes." Baxter also added another tidbit for attendees, saying that Python accounts for around 15 percent of Google's code base."
Just rename it. (Score:5, Interesting)
Re:Another Shock Story (Score:5, Interesting)
Yet everyone makes fun of me when I say that I am a C++ programmer.
Re:Another Shock Story (Score:5, Interesting)
Hopefully the Python team will learn from PHP's experience.
Re:print as function vs. keyword (Score:3, Interesting)
If you're wondering why statements are stupid: they are not first class values you can pass, use and manipulate; they introduce a special, harder to learn and very quirky syntax; they cannot be used anywhere and thus subtract flexibility; and they are an extra form or feature that's actually unnecessary ("Programming languages should be designed not by piling feature on top of feature, but by removing the weaknesses and restrictions that make additional features appear necessary." - R6RS, Introduction, best piece of insight on software design ever).
The difference between print >>lol, wtf and print(wtf, file=lol) is that, in the later case, print is a first-class value (a function, in this case) that I can pass to another function should I need it to call it back, or use in the middle of an expression.
Re:It's a race (Score:2, Interesting)
Re:It does have block statements. (Score:3, Interesting)
Re:It's a race (Score:3, Interesting)
Breaking backwards comp. in languages good (Score:5, Interesting)
You know, sometimes a little backward incompatibility can be good. You can shoot yourself in the foot more by not breaking things when something needs fixing. As an example I point to VB.Net.
Back in the days of VB 6 and prior, VB was an entry sort of language that was designed with novice programmers in mind, and strayed quite a bit from normal programming constructs. With the advent of the .Net platform looming, Microsoft wanted to move VB to .Net, but didn't want to break existing code out in businesses. So they opted instead for kludges and workarounds in the language, and that's the reason I can't wait to get done with VB .Net project I am currently writing. If you are an experienced programmer in other languages such as Java, C++, etc, VB .Net can drive you mad. Here are just a couple examples:
There are many other examples in VB like this, so I say this to the Python developers: If you have a good reason to break backwards compatibility with the language, then do it. Keep backwards compatibility whenever reasonably possible, but break it before accepting a kludge into your language. Your future coders will thank you, and will not run away screaming to the other, newer languages that will inevitably follow.
Re:Just rename it. (Score:3, Interesting)
Seriously, what really matters is:
#!/usr/bin/python2
or
#!/usr/bin/python3
And I'm betting someone will come up with
#!/usr/bin/python
that will automatically determine which python it is from the syntax.
Re:It's not like this is the first time. (Score:3, Interesting)
Re:It's a race (Score:2, Interesting)
No one has to fix bugs in Perl 5 besides a couple of people at ActiveState, which has customers. People work on Perl 5 because they want to. (I still send in patches occasionally, even if I spend most of my available time working on Parrot.)
Re:Whiners (Score:1, Interesting)
If companies did the equivalent thing -- "the new version won't be backwards-compatible, but we're open-sourcing the old version" -- I don't think anybody would complain.