Slashdot Mirror
Python 3.0 To Be Backwards Incompatible
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."
Will the new Perl or the new Python be the first to shoot itself in the foot with incompatibility?
Intron: the portion of DNA which expresses nothing useful.
Call it "Cobra" or something. Too many kludges will confuse people. A new name and file extension will emphasize that this is "in with the new".
If the editors read the article rather than posting shock stories, Python 2.6 will also be released at the same time and will not break backwards compatibility. Python is not pulling the rug out from under its developers as the summary would lead you to believe.
Just kidding Python fanbois :-)
Chill, it's Friday.
It must have been something you assimilated. . . .
It has something to do with the fact that the fangs curve backwards.
The biggest incompatibility is how you output to stdout. Instead of doing
print "This used to work"
You now have to do
print("This is how 3.0 rolls")
There will be no grandfathering, so everything needs to be refactored accordingly.
A small, but significant change.
- Despite popular opinion, I am not perfect.
While it would be nice if it were otherwise, sometimes you need to break with the past to develop solutions to problems. It's an ugly, but very real truth. Thats not to say that my I will be rewriting my code to 3.0 immediately, but sometime in the next year or two I probably will.
Ubiquitously - A Ubiquity Developer Community
I maintain tens of thousands of lines of Python... and I'm not worried. Why? Because I am sure they will continue to support security and bugs on the 2.x line for a long time to come.
It is not like your favourite Linux distro is just going to drop the 2.x series overnight, or like Python 3 will fight 2.x on your system.
This looks like a shoot yourself in the foot moment. I briefly read through the Py3K stuff and found it difficult to see what the true benefits were for creating this incompatibility. If they want to do this and have folks adopt it, they need to provide a COMPELLING SET OF REASONS for why they are making it incompatible.
If you're going to make a language completely incompatible, you basically have created a NEW language.
We whine when companies break compatability, yet we whine just as loud about bloated software when companies leave in compatibility.
;-)
Tell, me exactly what would satisfy you? How about we just take your computer away.
I'm running for president! FREE PACIFIERS to all Slashdotters.
Mike @ The Geek Pub. Let's Make Stuff!
They really went the Microsoft route on this one.
As long as you can run Python 2 & 3 in the same environment, this shouldn't be a big deal.
It'll just be a case of slowly moving code from one version to the next.
This is a brave move, but you've only got to see the mess you can get into trying to force backward compatibility for too long (Vista, anyone) to know it's the right move.
Of course, this being python, I fully expect some brainbox to come up with an automated conversion routine (v2 to v3) that "WAS WRITTEN IN ONLY 15 LINES OF CODE". etc, etc.
Training monkeys for world domination since 1439
Sounds like they are definitely going for a version 3 of the language. They have identified what they need to fix and add to version 2 and are going to implement it in version 3. I have messed with python so I don't have a heavy code investment in it yet but either way - if it makes Python better than it is, I think its worth considering.
"Enjoy what you're doing! If it becomes drudgery, you're doing it wrong!" - Jim Butterfield
... as I can have them installed side-by-side. Perhaps make the executable python3 or something to use different shebang lines (#!/usr/bin/python and #!/usr/bin/python3). If I recall correctly most OS's use a symlink python to the version anyway.
Would make the transition easier for everybody. My OS of choice (Gentoo) uses Python as the distribution method.
I applaud these guys for having the balls to say "I'm going to take what I've learned from the mistakes I made in versions 1 and 2, and start over with something better". I love Java, but I sure wish some of the 1.1 and 1.2 cruft would go away.
No folly is more costly than the folly of intolerant idealism. - Winston Churchill
Look at C++, they broke backwards compatibility with C ( malloc casting for example ) and because of that it never became mainstream.
\u262D = \u5350
- Python 3 (or Python 3000 as it was called) as a serious effort is more than a year old.
- There is already a working interpreter in its second alpha release.
- Final release is slated for August. (No infinite Perl 6 development.)
- Developers are working very hard to make the 2 to 3 transition as painless as possible.
- The Python team is committed to keeping the 2.x series going until 3.x has clearly been accepted.
You may now proceed to complain having been thus informed.The "What's New for 3.0?" article over on python.org:
http://docs.python.org/dev/3.0/whatsnew/3.0.html
- Despite popular opinion, I am not perfect.
Last year, both Ubuntu upgrades (from 0610 to 0704 and then to 0710) each sent me into Python version mishmash/compatibility hell. But at least they could be mixed together a little, to bootstrap back to a working installation.
I wish these scripting languages were really just APIs, and could all be compiled to binary code instead of depending on different versions of different interpreters. The script source is just too transient without needing to be when working under the hood.
--
make install -not war
This was bound to happen eventually. Legacy compatibility eventually becomes too cumbersome to maintain along with the new standard. This happens in all areas of technology, something new and better comes along, and eventually, the old tech is replaced. Backwards compatibility is nice, but not every developer wants to maintain compatibility with old standards.
I'd like to hear from slashdotters who used to blame Microsoft when Microsoft release software that broke backwards compatibility with existing versions. Is Python's development team following Microsoft's lead here?
This has been known for donkey's years. Guido has been talking about this compatibility break since the 90s. The changes were laid out in detail in PEP 3000, first published in 2006. They have already released two alphas. A conversion tool to automatically make some of the required changes (such as changing print statements to print() function calls) already exists.
Bogtha Bogtha Bogtha
IIRC, even dot-releases of python are not source-compatible. I assume that's why my install of Ubuntu has multiple versions of every library, e.g., /usr/lib/python2.4/smtplib.py and /usr/lib/python2.5/smtplib.py.
I think this is partly a matter of philosophy. The people in charge of a particular language tend to be computer language enthusiasts, and they like to tinker with them. They say things like, "The language has to be able to continue to evolve, or else it will die," or "We don't want to lock in things that, in retrospect, were really mistakes." But people actually using the language typically put a higher priority on not having their code break. Obviously we wouldn't all want to still be writing old-style fortran, with fixed columns, Hollerith codes, etc., but I also don't agree with the philosophy that "bit rot" is inevitable, and every piece of code you write is like a baby that you have to tend for the rest of your life. Personally, one of the things I really like about Perl is that it's got an excellent, mature implementation, and it's been mature for a long time. This is a lot less true for Ruby, for example, in my experience. It's true that Perl 6 is going to break backward compatibility with Perl 5, but the Perl 6 interpreter is going to automatically recognize Perl 5 code, and handle it correctly.
Find free books.
&& you use python, please turn in your developer card
"Thanks for all the money you paid to us. We've used it to buy off ISO among other things" -Microsoft
http://svn.python.org/view/sandbox/trunk/2to3/
And, as others have stated, there'll be the 2.6 branch, which will be backwards compatible.
Or, in other words, the story is stupid and misleading.
if it does, then it will be pointless. I like the whitespace thank you very much.
"Thanks for all the money you paid to us. We've used it to buy off ISO among other things" -Microsoft
While I'm not much of a Python programmer, it is refreshing to see projects are are not afraid to risk breaking compatibility in the name of progress and getting rid of legacy cruft. One thing I noticed about Python the few times I tried it was that there seemed to be a lot of ways (many of them officially "obsolete") of doing the same thing. One bit of confusion I recall is trying to call the "super" method of a parent class when you've overridden a method. In my research I found several long articles about the pros and cons of different ways of doing it and I just got more confused.
Compatibility is often overvalued and tends to add needless complexity and bloat. Just look at Windows.
"THERE IS NO JUSTICE, THERE IS ONLY ME." -Death
The reason I use Python is that I used to use Visual Basic and Microsoft borked me by creating a backwards incompatible version (somewhere around ver. 2 iirc). I have written a lot of python script. The idea of having to fix it all ... it ain't going to happen.
If they change the extension, we can still use our old code with an old installed version of Python. What worries me is that Ubuntu does all these updates. That means that someday, without warning, my Python scripts won't work any more.
Python 3000 (the draft for Python 3) has been in the works since 2006 and it has quickly been made quite clear that backward compatibility would be broken.
Well I guess old news is better than no news at all...
The Wise adapts himself to the world. The Fool adapts the world to himself. Therefore, all progress depends on the Fool.
Why would anyone consider even using python for the next few years ... sounds like someone just killed python to me!
No, sadly, they aren't fixing any of the key problems with the language, they're just not maintaining compatibility. Should be pretty much the death knell for python. I guess ruby wins.
"Who is the Journal of Quantum Physics going to believe?" --Stephen Hawking
Are you doing serious programming in Python with an editor that doesn't understand Python's block style? For that matter, when you do copy/paste with your C++ code, are you saying you don't bother to fix the indentation?
I have seen the future, and it is inconvenient.
Exactly! Now they can force people to buy expensive IDE's and servers to run the new version of Python, and strong-arm people into purchasing licenses to use the language for commercial purposes. It's just a money making ploy.
Oh, wait a minute. All the old versions are going to continue to be available -- even the source code. And it will remain free for commercial use. Hmmmm.
Sorry, but I fail to see how what they are doing is at all like Microsoft.
quiquid id est, timeo puellas et oscula dantes.
Good idea. It hasn't changed in 80 years.
I'm saying the editor fixes the indentation for you.
Have you ever used LISP? The editor reads the parenthesis, you read the indentation.
Indentation is a derived piece of structure, but should never have semantic meaning in a language except as a separator. Anytime you do so you ask for problems, both for editors, for code generators, and for users.
Test your net with Netalyzr
(young buck, slashdot id's not withstanding :))
:)
Whitespace Scoping and Block Scoping are two end of a dichotomy. Before you go wishin' it wasn't this way, well, i'm not going to belabor it but some of us like to actually be able to scan code without having to inspect every darn character to figure out where things start and end. It actually takes brain cycles to do that that could be spent on comprehension instead of syntactical flukery. It's a psychology thing not unlike the HID guideline (hid? in code? you betcha!)
If you doubt still, perhaps this will sate you instead: it is a five line perl script (i misplaced it) to convert whitespace indenting to block indenting. They ARE identical and can be translated between freely. Whitespace indented perl? You Betcha!! "Curly" python? Sure! If it bothers you, go write that script and get outta da way
best, and truthfully!
CS majors know the time/space tradeoff, but they never get taught the 3rd, crucial, tradeoff of the set: comprehension!
They're just delimited with indentation instead of braces. And it's not the language that is stupid, it's you, because you are apparently not indenting your code at all, or you'd realize that indented code in other languages "Fs up" (you do realize you can say "fuck" on Slashdot, right? Watch: Fuck, fuck, fuck, fuck. It's pretty cool.) stuff just as much as indented Python code does. Any decent editor can automatically indent code for you in any language, and in this case Python is even easier because all it uses is the indentation, so you don't have to manually add additional delimiters in the appropriate places; just indent as usual. Copying and pasting code in any language requires you to reindent it just as much as with Python, lest it become an unreadable mess, and again, any decent editor provides the ability to adjust the indentation of whole blocks of text with ease. And if you find yourself utterly stumped by the challenge of generating properly indented code, you simply should not be programming.
You can have C code auto-indent with no problems, because even if it does it wrong it doesn't matter. Since Python's whitespace is semantic auto-indent would change the meaning of the code, which should never ever happen.
Give me Classic Slashdot or give me death!
A couple of tabs away, I have the Python Docs/Tutorial page open learning about keyword arguments. Would have I to learn everything over again in a year?
Whitespace indented perl? You Betcha!! "Curly" python? Sure! If it bothers you, go write that script and get outta da way :)
Really? I can write python without thinking about indentation and whitespace, run it through an auto-indenter when I'm done and have it work correctly? How?
Give me Classic Slashdot or give me death!
It's not just incompatible -- it's also 33% slower.
And if you order today, you'll also get a nice pile of shiny new bugs for only the cost of shipping and handling.
Don't wait! Call now!
The first 100 callers will also receive a free kick to the testicles.
Ian Ameline
It's called Perl 6, and it's THREE TIMES as almost-here* as Mystery Science Python 3000.
* Parrot, Haskell and Common Lisp
...or you could do that with a Perl oneliner ;)
Provided you've got a wide terminal, of course.
Relax.
First of all, the changes are mostly simplifications to the core language (e.g., how to catch exceptions is currently a bit of a mess if you want to catch more than one exception). So for example, range and xrange are now one, iterators become more prevalent, "old-style" classes are going away and so new-style ones will become the standard, a lot of the things that have been deprecated now are being removed, etc. It isn't really a "new language" in any sense. This is far superior to Java's "always backwards compatible" approach which has lead to a lot of cruft building up over the years.
Next, it needs to be understood that 2.6 will be backwards compatible and include a warnings mode to highlight things that won't work in Python 3.0 to ease in the transition. There should be no problem supporting both on one system.
Finally, they are providing a 2.5->3.0 translation tool that runs in 2.5 and does most of the mechanical translation between the two for you.
Integrate Keynote and LaTeX
Python is already a very smooth language, but there are a few corners where it could be better. The Python guys are taking this chance to smooth out the wrinkles.
For example, Python 2.x has both range() and xrange(), and the only difference is that range() actually builds a list and xrange() doesn't (it returns an iterable object that can be expanded into a list if you like, or just used in a for loop or whatever). There is no real need to have both range() and xrange(), so Python 3.x will simply have range() and it will return an iterator. More generally, all the Python features that return a list in 2.x will now return an iterator, and the special variants that return iterators will vanish.
There are many other changes but that one is representative. There is nothing here as dramatic as the changes from Perl 5 to Perl 6. Also, there is a nifty automated tool to help migrate Python 2.6 programs to Python 3.0 programs. There is no huge controversy here, sensational headlines notwithstanding.
I predict that the Python community will embrace Python 3.x when it's available. Python 2.x won't vanish instantly, but people will want to migrate to the new Python, and certainly schools using Python to teach will want to start using Python 3.0 immediately.
steveha
lf(1): it's like ls(1) but sorts filenames by extension, tersely
There's surprisingly little in Python 3.x that's really needed, and much that isn't. The approach to parameter typing (optional and unenforced) is silly. Having it and not enforcing it is just asking for trouble.
It probably would have been more productive to standardize on 2.6 and get a formal standard out the door, instead of using the CPython implementation as the standard. With a formal standard that couldn't be casually changed, the other implementations, all of which are faster than CPython, would have a firm target to implement. Python is twenty years old, and there still aren't multiple, compatible implementations.
Python could be a much higher performance language. Take a look at the Shed Skin implementation. One guy is trying to implement a hard-code compiler for Python that does type inference to determine types at compile time whenever possible. That yields a 10x-30x speedup. If you have rackmount servers running Python, that's a big win - one rack instead of ten.
Python has some optimization gotchas that really should be fixed. The big problem is "undetectable dynamism", or "if the only tool you have is a dictionary, everything looks like a hash". It's rare to store into a local variable of a function, or modify a method of a class from the outside of the class. Most classes don't have attributes added to them after creation. Python allows all these things, which can occasionally be useful. The trouble is that it's really tough to tell at compile time if the hard cases are going to be needed, and thus code has to be pessimized for the worst case.
This could be fixed with a few restrictions:
- Classes which can be dynamically modified from outside themselves should be subclasses of "dynamicobject" instead of "object". This makes everything dynamic but reduces performance. For most objects, the compiler can then find all the variables during
compilation, assign them fixed slots, and avoid having a dictionary in each object.
If an object indulges in self-modification or attribute creation, the compiler can see that at compile time and generate the slow code for the hard case. This is only needed for objects which are patched from outside themselves, something the compiler can't now detect and needs to know about.
- Variables cannot change major type during execution. If a variable is initialized with an integer or float value, it cannot thereafter be changed to an object type. Shed Skin imposes this restriction, which means it doesn't have to "box" numbers in objects and can hard-compile arithmetic.
This would make it possible to boost Python performance up to the Java level, and get it within striking distance of C/C++, yet not require declarations.It looks like there's an opportunity out there - depending on how much people value their time at, or how much companies are prepared to pay to assure their code base. You never know, there may even be some value in having your Python code V3 certified?
politicians are like babies' nappies: they should both be changed regularly and for the same reasons
Just the same way that I can write C++ without using any curly braces or semicolons.
Since the two use BNF form, just write your code with curly braces then write a script to indent on a { and de-indent on a } and strip those characters. Pretty trivial really.
Or you could just learn to write Python instead of whining about how it isn't C++.
Posters here do not seem to be aware of Python's __future__ module. It is the mechanism by which scripts can gracefully move forward before the rug is pulled out from under them. This is not unique to 3.0.
The whole idea is that Python can add features to the language in __future__, that are available at least one version before they become the new default. A script can adopt a new feature ahead of time (e.g. "from __future__ import with_statement").
It wouldn't surprise me if Python 2.6 has __future__ entries for Python 3.0 capabilities.
"Microsoft killed my company, I hold a personal grudge. I don't use Microsoft products and neither should you."-JWZ
I believe his point was that you could write Python without thinking about indentation and whitespace, but you would have to use curly braces instead to denote blocks. Then the auto-indenter would just parse the blocks and indent appropriately for the language.
As to whether or not that's feasible, I don't know—I'm not a Python programmer—but it sounds reasonable on the surface.
Schlock Mercenary
Back in the day we had to count on MS to roll out new versions of languages that would require expensive re-writes of systems working perfectly well on the old platform.
Nice to see OSS getting into the act. Developers, developers, developers, developers...(insert monkey dance here).
That's our life, the big wheel of shit. - The Fat Man, Blue Tango Salvage
Why, exactly, is it that it should never have semantic meaning? Is there a rule somewhere?
Guido is following through on the plans he announced years ago! Let's all discuss it as if it were amazingly novel news!
What makes you think you cannot have python code auto-indented without changing the semantics?
Using two separate mechanisms to denote structure -- curly braces with the real meaning, and indentation as an alleged re-creation of what the curly braces indicate -- also asks for problems. Many people find the whitespace problems less troublesome than the curly-brace problems. Pretending that either solution is perfect is plain nonsense. The Python solution is not hard to use or understand.
I find that your criticism falls at a surprisingly shallow level of thinking. You would think that someone familiar with Lisp would be able to see beyond the first layer of a language and recognize that the strength or weakness of Python has little to do with syntax details that take five minutes to accept. The simplicity, flexibility, and overall utility of a language's cognitive model is more important, and it seems like whining about syntax is little more than noise in an important debate. Yet for some reason, the use of whitespace in Python inspires an obsessive response from people who happily ignore the (debatably worse) syntax crimes of Perl, Ruby, or C++.
I have seen the future, and it is inconvenient.
Because no one can read the code to change it.
If something is so important that you feel the need to post it on the internet... It probably isn't that important.
Hello, my name is Smalltalk. I am a language that actually is designed correctly and works. Thank you for poorly coping my features.
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.
Beware of bugs in the above code; I have only proved it correct, not tried it.
Ah, I love the python defenders...
Guys, block structured languages you can trivially derive pretty-printing formatting. Which means you get the "easy to read" ability trivially. You should NEVER read the Silly Parenthesis in LISP, that gets taken care of for you by any one of a gazillion tools.
But you can't go the other way around.
EG, on C, you can cut and paste trivially. You can't on python, you need an editor which parses the language sufficiently to understand that "This is a code block going into a different code block".
Likewise, code generation. Its trivial to build a recursive code generator targeteing "pick your favorate block structure language". But in Python, you have to explicitly add a notion of "what depth is my recursive code generator actually operating at", and "woe to you if you forget a linefeed".
Next thing you know, slashdot will be full of defenders who insist that Make's treatment of tab and space is a good thing.
Like so much of Windows, whitespace-as-block-structure is a bug, not a feature.
Test your net with Netalyzr
Really? I can write python without thinking about indentation and whitespace, run it through an auto-indenter when I'm done and have it work correctly? How?
I dunno, ask the vim people, their autoindent works for me.
Or better yet, just write in a programming language that doesn't expect you to write pretty code. The only people out there yelling at you to use python are the voices in your head.
Because the auto-indenter can't read your mind. It doesn't know where you want your blocks to begin and end. Whitespace in python is like brackets in perl. If you missed a bracket in perl, how would an autoindenter know where you intended to put that bracket? Same issue with python and whitespace.
Give me Classic Slashdot or give me death!
If you're going to call print as a function maybe you should rename it printf. Or better yet, switch to a real programming language that already has printf.
Support Right To Repair Legislation.
Since the two use BNF form, just write your code with curly braces then write a script to indent on a { and de-indent on a } and strip those characters. Pretty trivial really.
Oh I see how that would work. You'd have to strip the non-semantic whitespace from the curly source before preprocessing too though.
Give me Classic Slashdot or give me death!
And conversely there are Perl5 modules that try to bring forward compatibility by enabling Perl6-like improvement in Perl5-code.
Also, don't forget that one of the major new steps in Perl6 is the Parrot virtual machine which help interoperation between whatever code was compiled to run on it, including Perl6 (compiled with PUGS, for example), Perl5 (once the compiler is stable), C libraries (single binding for any language running on Parrot), or even Python (don't know which version will compile to Parrot).
So you could slowly migrate perl5 to 6 even if they aren't compatible by :
- keeping your perl5 code in backward compatibility mode of Perl6 and only adding the new code as Perl6-native.
- slowly introducing perl6 features with modules in your current perl5 infrastructure so, shall you decide one day to migrate the code, the work would be half-way done
- keep perl5 code running as is on parrot, and only write Perl6 in newer modules and have everything run next to each other thanks to the "one VM to rule them all" approach of Parrot.
TMTOWTDI, you know the drill.
Whereas, according to TFA, the older python 2.x branch will only run Old Python dialect (but will continue to be maintained for some time), and python 3.x branch will only run New Python dialect.
Users either keep using old branch for old code, or rewrite their app before using new branch.
"Sufficiently advanced satire is indistinguishable from reality." - [Tips: 1DrYakQDKCQ6y52z6QbnkxHXAocMZJE61o ]
yay for the grasp (you'd have to lstrip it, to be precise) pass it on! /cool
CS majors know the time/space tradeoff, but they never get taught the 3rd, crucial, tradeoff of the set: comprehension!
There IS no problem. Python 3 will be incompatible with 2.5, yes. That's why there'll be a python 2.6. Duh. It'll be compatible with 2.5 and will provide some 3.0 features when specially asked for (from future import ..), but also warn of deprecations, incompatibilities, etc.
Thank you for posting this. I always find myself going crazy trying to explain the problems to pythoners, but I think you really put it together succinctly in this post.
"Who is the Journal of Quantum Physics going to believe?" --Stephen Hawking
I mean, am I the only one who's been using Python since at least 1.5.2? The made major changes between that version and 2.0 that broke almost all of our 1.5.2 scripts (particularly in the way they handled regular expressions).
I didn't kill Python then, and it didn't stop us from using 1.5.2 for years to come for our old scripts and 2.x for our newer scripts.
If it's for-profit but free, you're not the customer -- you're the product (e.g., the Slashdot Beta's "audience").
"Learn Python" has been a standing entry on my to-do list for quite some time.
What would people suggest -- should I bother learning 2.x or just wait for the shiny
new 3.0?
Granted, by the time I get that far on my to-do list they'll probably be on version 9...
This is why I don't use languages that have a single vendor controlling the standard and tools. At least with C and C++ there are many many vendors and the standards are backwardly compatible (not counting the first C++ standard breaking all the de facto standard C++ source)
Languages like D, Haskell, Python, Perl, Lua, etc are all pretty interesting. but making them a core component of your business seems like a bad idea. The people who put them together are not getting paid by you and don't really care about your company's schedules. Generally you just have to force users of your scripts to install the right version of python/whatever until you can move all your software forward.
Hopefully you can move your source forward before RHEL and Ubuntu switch to the new tools exclusively (there will be a transition period, thankfully). But then you're still stuck having to support customers who run an older RHEL and won't upgrade.
With C I don't have to do any of this. I have other problems to worry about, but they are at least in my control.
“Common sense is not so common.” — Voltaire
If it isn't backwards compatible, it isn't Python, as far as I'm concerned. I'm sure not going to be re-writing a couple hundred megabytes of code. They can take their incompatible new snakelike thing and smoke it. Foregoing backwards compatibility is about as dim a move as I've ever seen anyone outside of Microsoft pull (MS dropping VB underneath Access comes to mind as a comparable clueless act, with exactly the same consequences — it isn't the same product and is useless to me.)
I've fallen off your lawn, and I can't get up.
and you use && instead of 'and', please try to forget your C background.
Well, I write python using vim's quite simplistic autoindenter, and to tell you the truth, this does not happen.
Python 2.5 isn't backward compatible to python 2.4 (!). In-fact, I'm still using python 2.4 only because I cannot upgrade since 50% of my python scripts will not work!
So, that fact that change in major version from 2 to 3, would be backwards incompatible, shouldn't surprise anyone who used same python scripts between 2 different minor versions.
Read and Comment at my BLOG
!!!
Guys, block structured languages you can trivially derive pretty-printing formatting. Which means you get the "easy to read" ability trivially.
You don't get it trivially, you get it in exchange for having block delimiters. Python avoids having redundant delimiters + indentation (the latter you _need_ for readability, hence the reason _why_ all those pretty-print programs exists).
You should NEVER read the Silly Parenthesis in LISP, that gets taken care of for you by any one of a gazillion tools...
EG, on C, you can cut and paste trivially. You can't on python, you need an editor which parses the language sufficiently to understand that "This is a code block going into a different code block".
"You use a smart editor that understands parens in LISP. In Python you need a smart editor that understands whitespace."
rage, rage against the dying of the light
Already written
http://www.intertwingly.net/blog/2007/09/01/2to3
One such project is Cython. It enables you to write in Python which gets compiled to C; trivializes using Python objects in C and vise verse.
Yes, some kind of transition phase is the only approach that makes sense with established APIs. That's precisely why python is doing a 2.6 version to bridge the gap.
This is exactly what I first thought about when I read the complaints regarding Python 3. There is a lot of crud that Java still carries around with it that dates back from it's earliest incarnations. There is talk that Java 7 will ditch much of the cruft and therefore (finally) be backwards-incompatible with previous versions. There are warts that Java currently supports that are making new additions to the language difficult and the solutions to those problems can be ugly, at best. I recall that fixing generics and adding closures are considered two of the big issues.
However, The current track of Java won't just disapear. Java 6 will continue to be supported while Java 7 will become the new-and-improved Java. Whether this actually comes to pass is anyones guess. I heard about it first on The Java Posse and it sounded a bit more like conjecture than fact.
At any rate, I think that with any rapidly evolving language enough junk will build up that eventually you just need to bite the bullet and cut that shit loose. Personally, I think this method of splitting the language into two tracks is best for both languages. Can't wait for the incompatible goodness :)
PHP 5 was a MAJOR over-haul, biggest since PHP 4. When PHP 4 came out, hosts and OSes supported 3/4. PHP 3 has really cool, but extremely insecure, syntax things for web prototyping. When you posted a variable, put it on the query string, or passed it in a cookie, it just came into the script as ${name}. So if you needed to check for setting, it was isset($variable), using it was just using it, etc. This was dangerous because in PHP you don't declare your variables, so if you assumed that a variable you never zero'd/nulled before usage was null at the beginning, this could be exploiting by posting a value.
PHP 4 had a php.ini setting to use the old mode (I think register globals or something similar) that helped in the migration. Also, include_once/require_once massive simplified using libraries. Before that we had to do our own equivalent of ifdef/ifndef in our PHP code to avoid overwriting a function if two included libraries called it.
The PHP 3 -> PHP 4 transition took a while as well. What's the rush, my new systems all include PHP4 AND PHP5. All my new code is PHP 5. My PHP4 stuff happens to be in legacy mode, but if I needed to bring it will us, you put it on a machine and see what works, what doesn't, and add support for 4 AND 5, like we all used to do on PHP 3/4.
Better to introduce some source incompatibility for improvements then not being able to move forward, just make sure that there is a transition strategy. Three years isn't really that long... though when I started in web stuff, 3 years was an eternity, but 8 years later, eh, just a few more years.
Hasn't that been on the Python website for a year or two now? I'm fairly sure it has been, something about how they're re-writing the core stuff, and this re-write would break backwards compatibility. From what I remember, the rewrite has to do with speed and such, which sounds like a good plan to me.
I don't really see this as much of a problem, really. Don't want to re-write your application? Don't move to Python 3000. I have several versions of python installed on my Linux machine at home, simply because there are modules that don't work with version 2.x or version 2.y or what-have-you.
God is dead -- Nietzsche
Nietzsche is dead -- God
Zombie Nietzsche lives! -- Zombie Nietzsche
The point remains that Python cannot be indented automatically. For example, consider the trivial example of There are three valid ways this could be indented, with the possible values of f(1) being None, 1, and 2. It is impossible for a computer to guess which is intended. Therefore, it is impossible in general to auto-indent Python code, QED.
"It's not a problem for me" is not a viable answer to "this is a problem for many people". Some people don't find Perl too hard to read, but that doesn't mean Perl isn't often hard to read. Some people don't find Ruby too slow, but that doesn't mean Ruby isn't often slow. And you don't find Python's significant whitespace a problem, but that doesn't mean it doesn't make life more difficult for the writers of IDEs and automatic code transformation tools.
Observe that the best-known other programming language with significant whitespace, Haskell, provides an alternative brace-and-semicolons syntax as an option for cases where whitespace is not the most readable choice. Python has already been heavily influenced by Haskell (that's where the idea for list comprehensions came from, for example); it's a shame that political and religious issues mean it's unlikely ever to copy this other very practical idea.
Calling the new language "Blackadder" is a plan so cunning that if you put a tail on it you could call it a weasel.
The reason is obvious. Just ask the Fortran guys why they dropped semantic whitespace in the switch from fortran-77 to fortran-90.
Whitespace shouldn't have semantic meaning because then you're stuck with semantic whitespace that might not be the easiest to read. For example, The following is MATLAB code specifying a 10x10 matrix that could be used for future calculations.
A=[[ 77 210 214 133 228 131 200 223 81 214]; [ 138 165 145 225 50 85 174 3 245 160];[ 38 209 94 44 76 110 118 196 186 34];[ 178 169 179 250 169 57 145 248 105 53];[ 96 87 139 69 72 148 203 253 190 155];[ 220 74 113 64 120 194 15 201 68 161];[ 218 87 177 224 16 135 154 112 112 94];[ 151 136 159 188 253 163 12 127 238 147];[ 127 186 203 34 149 53 106 54 174 115];[ 230 79 244 3 108 97 78 164 54 11]]
or
A=[[ 77 210 214 133 228 131 200 223 81 214];
[ 138 165 145 225 50 85 174 3 245 160];
[ 38 209 94 44 76 110 118 196 186 34];
[ 178 169 179 250 169 57 145 248 105 53];
[ 96 87 139 69 72 148 203 253 190 155];
[ 220 74 113 64 120 194 15 201 68 161];
[ 218 87 177 224 16 135 154 112 112 94];
[ 151 136 159 188 253 163 12 127 238 147];
[ 127 186 203 34 149 53 106 54 174 115];
[ 230 79 244 3 108 97 78 164 54 11]]
Which one would you prefer to maintain? Suppose you have to occasionally tweak coefficients stored in the A matrix?
Whitespace is just one tool in many to make your code readable by humans, a necessary condition for ease of maintenance. Horrible formatting can make even good code difficult to comprehend, so why would you want a language to restrict you to one way of doing things? Sure, it lets you write truly atrocious code, if you're an asshole, just like perl. But it also gives you the ability to write extremely legibly.
Can you be Even More Awesome?!
Backwards compatibility is both a blessing and a curse. Python is taking the other approach to C++ where backwards compatibility ismaintained almost regardless of the cost.
I like C++ and I like Python. I'm not interested in an X sucks debate. C++ definitely has warts which will never go away, because the committee will always maintain backwards compatibility. For instance the rather ephemeral nature of arrays makes it hard to use builtin arrays as a type, without causing all sorts of pain and suffering. New syntax can be ugly because introducing new keywords can break existing code. And finally, it looks like the rather abortive "export" is here to stay.
On the other hand, though, I have some quite large C++ libraries with code dating back years. Since it was written in standards compliant C++, it remains in good working order. And furthermore, it will remain in good working order when C++0x rolls out. As a result, I will be able to write new code using the new features of C++ without having to worry about fixing my entire set of libraries in one go.
I'll also be able to resurrect ancient code which I haven't run for years and it will "just work".
These are very valuable, but on the other hand some things in the language will never be fixed. Python, on the other hand will become less warty as time goes on. That's good, and the language will be better as a result. The penalty is that old code will not work quite so easily.
Both are good, and both are bad. My personal preference leans towards compatibility, but not quite as strongly as the C++ committee.
SJW n. One who posts facts.
I had to port Perl 4 code to Perl 5 and there were some issues.
If that code was originally input in that state, then it never had a meaning, since it is not parseable by a python parser. If it was ever indented both in a way it had a meaning and in a way it had the intended meaning, then of course it is possible for an editor to change the indentation in semantically preserving ways---and this does not even require an editor which actually parses the code. So your problem is: "if you have code for which even not the python parser can attach meaning, then an editor cannot attach meaning to it and manipulate it meaningfully". That problem exists for... well... every language.
I fail to see "political and religious" issues in this issue. It is simply a design choice.
Real threading.
Interested in open source engine management for your Subaru?
I'm glad that you brought up the "Cut and Paste" idea. If you are duplicating code, you should be refactoring it out into a function, not creating more lines to maintain. The code will become cleaner and more readable, no matter what the language. You shouldn't have to depend on clever IDE features to defend bad practice.
Python might have problems, but intentional whitespace isn't the biggest.
Will the new Perl or the new Python be the first to shoot itself in the foot with incompatibility?
Unlike closed source languages, Python and Perl are both totally open. If you don't want to switch to the new 3.0 language, don't. If enough people don't want to switch to 3.0, 2.x will live on forever. If everyone leaves 2.x and you're the only one on it.. you can continue to support it yourself for however long you wish.
If porting your code to 3.0 is advantageous, do it. But no one is forcing you either way. There's no foot shooting going on, it's offering an alternative.
AccountKiller
It's been said several times here that Java keeps making pointless sacrifices for backwards compatibility. Some progress requires a breaking change, and a major point release is a perfect place to make that kind of change. Java introduced Generics, but still returns Object from Generic Collections for backwards compatibility. Is anyone actually benefitting? No. Java authors worried about compatibility are still using Java 1.3, while those working with the newer JVM never fully gain the benefits of Generics.
Issues like the non-unified string implementation in Python are perfect for moving forward. Bravo Python.
So the answer to your question is, neither. The question is, how long before somebody gets Java out of its pointless rut?
I guess Smalltalk needs a spell checker.
thanks,
python
Your example is quite absurd, since your pretty matrix code is perfect python, up to changing the ; into commas, and adding the missing commas:
A=[[ 71, 211, 211, 131, 221, 131, 201, 221, 81, 214],
[ 131, 161, 141, 221, 51, 81, 171, 1, 241, 160],
[ 31, 201, 91, 41, 71, 111, 111, 191, 181, 34],
[ 171, 161, 171, 251, 161, 51, 141, 241, 101, 53],
[ 91, 81, 131, 61, 71, 141, 201, 251, 191, 155],
[ 221, 71, 111, 61, 121, 191, 11, 201, 61, 161],
[ 211, 81, 171, 221, 11, 131, 151, 111, 111, 94],
[ 151, 131, 151, 181, 251, 161, 11, 121, 231, 147],
[ 121, 181, 201, 31, 141, 51, 101, 51, 171, 115],
[ 231, 71, 241, 1, 101, 91, 71, 161, 51, 11]]
If that was your argument to show that `python forces you to write horribly formatted code', well, you need another argument.
In any case, have you seen the huge amounts of pretty good python code out there? I have yet to see something which would rightfully be described as `horribly formatted'.
What's the problem with internally changing the indentation-based blocks to some other format, just for some manipulation, and then converting it back? for example:
if foo:
if bar:
doSomething()
for item in collection:
pass
One would like to cut-and-paste first block into the second, replacing the "pass" thing. Internally, the IDE could replace the above code with:
if foo:
if bar:
doSomething()
endif
endif
for item in collection:
pass
endfor
Then simply:
for item in collection:
if foo:
if bar:
doSomething()
endif
endif
endfor
And back to Python:
for item in collection:
if foo:
if bar:
doSomething()
Same for code generators and other magical stuff that "just works" with other languages. Of course use some magic escape sequences to avoid name conflict with symbols that are alrady sitting in the code.
What's the big deal? It's not like Python 2.x is going to go away or suddently stop working.
Old program will continue to use the old version, and new projects will start using the new version.
I don't think anyone is really suggesting that a lot of code be rewritten. Python 2.x isn't going anywhere, for exactly the reasons you bring up. Python 3.0 is going to be almost a completely new product, and I expect it'll only be used for new projects. I'm not really sure why anyone would want to convert their old code, if it works for you the way it is.If it isn't backwards compatible, it isn't Python, as far as I'm concerned. I'm sure not going to be re-writing a couple hundred megabytes of code. They can take their incompatible new snakelike thing and smoke it. Foregoing backwards compatibility is about as dim a move as I've ever seen anyone outside of Microsoft pull (MS dropping VB underneath Access comes to mind as a comparable clueless act, with exactly the same consequences — it isn't the same product and is useless to me.)
The reason for breaking compatibility is to maintain the Python philosophy of not having a lot of ways to accomplish the same thing. Without periodic pruning, eventually you'd just have Perl with indents.
From what I've read, you'll be able to choose the version/style you want, and the 2.x and 3.x series will live alongside each other (I don't know whether the 3.x interpreter will have a compatibility mode, or if you'll have to keep the 2.x version around as a separate program, though).
"Ladies and gentlemen, my killbot features Lotus Notes and a machine gun. It is the finest available."
Gaah! Iterators. I was all enthused about them once until two
things happened: (1) Someone asked me what they were good for,
and (2) I got burned by trying to use an iterator twice.
My answer to (1) was pretty lame -- and it still would be, The number of
cases where they give you are real advantage are few and far between.
(2) is a real usability problem: if you try to re-use an iterator,
it simply produces nothing. This will catch many people many times,
as follows:
def foo():
x = make_some_iterator()
bar(x)
def bar(x):
for i in x:
something
for j in x:
something
The second for loop will do nothing, unexpectedly and silently.
Iterators bad! Bad! BAD! (Unless you only use iterators, of course,
in which case people would expect them. So, it's really this:
Mixing iterators with lists: BAD! BAD!)
Google is 15% Python... and 85% what!? Anybody knows with any degree of accuracy? Which % of Java for instance? And what will be of Yahoo! if Microsoft takes it over? www.yahoo.com/default.aspx making ASP.NET calls to SQL Server? Just thinking about it gives me the shivers!
Google is 15% Python... and 85% what!? Anybody knows with any degree of accuracy? Which % of Java for instance? And what will be of Yahoo! if Microsoft takes it over? www.yahoo.com/default.aspx making ASP.NET calls to SQL Server? Just thinking about it gives me the shivers! What do you think yahoo.com would look like in 5 years if it all goes through? Which technologies would it be using?
Indentation in Python has syntactic meaning, not semantic meaning.
Call it "Cobra" or something. Too many kludges will confuse people. A new name and file extension will emphasize that this is "in with the new".
I'm totally going to invent some certification and call myself a "Cobra Commander" on my resume.
If we're breaking compatibility, can we put in requests? The 3 main things I'd like to see are:
1.) Ditch the silly ":" at the end of the line when starting a block. Why on earth is this needed? I almost always forget to use that darn colon.
2.) Ditch the bolted OO on "self" variable for object methods. Just make "self" a keyword and use it the way "this" works in Java/C#/C++.
3.) Allow for a whitespace agnostic mode with the end keyword the way Boo did for goodness sake! Why on earth is that so hard? If you want significant whitespace, it can still be the default. If significant whitespace drives you mad, then use a -wsa switch and a new "end" keyword and be done with it. It would end the flamewars and make Python a more acceptable language to those of us who prefer to have the option of aligning our code the way that makes the most sense, not the way the language Guido thought it should always be.
And the difference between a tab and a curly brace semantically is exactly what? Except that with curly braces, you need to have two of them for the language to work, and tabs, so that your brain can make sense of it, and in your case, an editor to keep track of it so you don't biff it up. :-)
I suggest that this is fairly obviously a matter of preference, rather than something that has an actual functional issue nearby. Indentation works fine as a block mechanism, and you avoid a whole class of code entry errors. I say that as a long time C, Java, and Perl programmer, who has found my new love, Python. If it's good enough for the geeks at Google, I suspect it's good enough for me.
Common, religion is bad enough in politics.
I was taught to respect my elders. The trouble is, it's getting harder and harder to find some.
Nonsense. There is NO difference between a tab character and those stupid curly braces C uses, or any other block indicator character. If it really bothers you, get yourself an editor that draws out tab characters for you.
Now, I dislike using spaces to indicate blocks. But tabs are great. Naturally there are Pythoners who think the opposite.
And just what do you suppose is the quickest way to move a block of code out from its current location, possibly nested inside various conditionals, loops, etc, to a (presumably top-level) function?
Kiss my ass! It is incompatible! The new version requires that old code be rewritten in order to function. Whether that code is rewritten manually or by a tool makes no difference, the fact remains that the code must be rewritten. That is no exaggeration.
Try this thought experiment, will you?
Suppose I have some Python code, with my blocks indicated by tab characters. I now do a search and replace, replacing every tab with a {. Then I write some trivial code that searches through and sticks in a } wherever there is one less tab beginning a line than the line above.
Now I have C style blocks. The difference between a { character and a ^t character is... well, there is no difference except their ASCII code. There's a trivial difference between the } character and the lack of a ^t character. If you encode the Python equivalent of the } as a ^t^h then even that goes away.
I WOULD be in favour of eliminating the option to denote Python blocks with a space though. I definitely would NOT be in favour of using some stupid visible character PLUS whitespace (if you want your code to be readable) to do the job that ^t does very nicely right now.
Perhaps that's because neither you nor the post you replied to understand what's going on? Python has block delimiters just like any other language. It's a tab character. The only difference is that most editors make it an option to display it.
:P
Yes, you can also use spaces, which I find sloppy. But real Python programers use tabs.
I wrote a LAMP app for my school, a simple tardy slip program. since I had older versions of A(1.3)M(3.x)P(4.x) on my ibook to develop on, and all we had were PC's at school, I downloaded an older version of fedora (I think) with the older versions. since everything copied over easily, install/set up was no problem. it's been up and running for a year and a half. could I do it with 2.x, 5.x, 5.x? sure, but I am not in the mood to rewrite.
My problem? I was perfectly gruntled, until some numbnuts came by and dissed me.
I agree there's a problem. I think the problem is that __iter__ on iterators returns self.
... ...
I think that you don't want a "for" loop or general iteration to just take an iterator and continue where it left off by default.
If it used an explicit syntax, such as:
for item in tillend(iter): # where tillend takes an iterator, and has an __iter__ that returns that iterator.
Is less error-prone than:
for item in iter:
Exactly because of the reason you mention.
It will be clear that:
for item in tillend(iter):
for item in tillend(iter):
is problematic, because tillend makes clear that its a stateful iterator being consumed.
As for a workaround for now, just be careful to always assume you're being given an iterator, and list'ify it when you want to iterate it more than once. Also make sure you name iterators "iter" something so you don't forget that they are stateful.
A few points...
1. How often do block structured language bugs boil down to an extra, missing or misplaced } (or language equivalent), I very strongly suspect that is one of the top 10 most common causes of compile time errors. A smart compiler will give you the line number so it's usually easy to fix but what a waste of time.
2. Being able to 'easily' cut and paste blocks of code without any reformatting is not a serious problem. Most important; cut-n-paste programming is a terrible habit that results in unmaintainable code. Secondarily, even in a fairly stupid editor this is trivial.
3. Recursive code generation?!? You've got to be joking. First; domain specific problems will always be best resolved with domain specific languages. So yes, for all those tasks where you MUST generate code suitable for direct injection into an existing python program you have to do a one-liner to determine the current depth at your injection point. You'll also need to parse through the entire file to see if you are inside a """ or ''' and see if the previous line is a continuation \. Similar ugly and perverse hacks are needed for every block language that supports any multi-line constructs (ie: nearly all of them).
That's what happens when you use brain damaged techniques instead of putting your generated code in its own module with its own whitespace and importing it.
As for suggest LISP-ers should never read parentheses... you're smoking the good stuff.
#!/usr/bin/env python2.2 is the preferred way to call a script which depends on Python 2.2, just as #!/usr/bin/env python2.4 does the same thing but specifying a 2.4 interpreter. If you call "#!/usr/bin/env python", then you get whatever the system default is, and that's your own fault... but point is, having multiple names for the interpreter so you can specify an individual version if you want to is already SOP.
Also, this isn't news. It isn't even sorta-news. This has been planned and publicly announced for years.
Baxter also added another tidbit for attendees, saying that Python accounts for around 15 percent of Google's code base."
Given how much more compact Python programs are than equivalent C++ or Java programs, that must mean that a big part of Google's functionality is written in Python.
Is the indentation thing among the changes? Seriously, that's the number one thing that keeps me from using Python.
Sorry, you lose. Parrot is the virtual machine on which perl 6 will run, not a language. python will also run on parrot.
Intron: the portion of DNA which expresses nothing useful.
Just as importantly, if I have to relearn a language, it isn't the same language, as far as I'm concerned.
That one refers to Perl 6, but I suppose it could be applied to Python 3.
It also killed off any interest I had in learning Python 2.5 if I'm just going to have to relearn it next year anyway.
GLaDOS for President 2016! "Well here we are again. It's always such a pleasure." -- GLaDOS, 2011
The AC meant that there are Perl 6 implementations which run on Parrot, a Haskell backend, and a CL backend. (There's also a Perl 5 backend.)
how to invest, a novice's guide
If it helps, I can whip up a script that would do that and you could just add a make macro that would handle it. That way you'd be able to use the tools you're used to.
The Python 2 to Python 3 transition is not the same as Perl 5 to Perl 6. Perl 6 is a major rethinking of Perl, with a lot of changes. Python 3 is still very similar to Python 2 with very few syntactical changes - the primary motivation for Python 3 to break backwards compatability was to be able to purge implementation cruft from the language that was mostly derived from early design mistakes.
It's true that you'll need to do work to port/test code from Python 2 to Python 3, but learning the syntactical differences can be done in an afternoon, as there aren't that many:
http://docs.python.org/dev/3.0/whatsnew/3.0.html
There should be no problem so long as it is treated as a different language in regard to installations of the Python interpreter and code it recognizes.
In other words the only change that needs to happen is the ability of the interpreter to recognize a header element that tells it whether or not in can run the program.
# !Python
or
# !python3
And I'm sure someoen can com up with a simple preprocessor to direct code execution to the right interpreter.
That's funny. My understanding is that the mods are much more serious than this article lets on. From what I heard they're replacing all the keywords and indentation with some combination of parenthesis, lambda, car and cdr. The language will be SO much improved!
There's no time to stop for gas, we're already late.
ONOZ! Relax indeed. Just find a new job that uses Python 3.0 and leave your old cruft for some poor shmoe to maintain! :D
The CPython developers, actually, and it's free and already in progress.
Speaking about the language, sure. But, actually causing problems, I highly doubted.
It would be trivial to work around this. Change:
#!/usr/local/bin/python
To:
#!/usr/local/bin/python2.4
Then if you really really wanted to, start moving to 3.x at your leisure. There is exactly zero reason why this should cause serious problems if one doesn't have a need to "upgrade."
You sure use a lot of punctuation for someone who thinks whitespace is better indicative of structure.
One is visible. One isn't. One is unmistakable, the other can be confused with spaces.
My biggest problem with python is having a large group of nested "if" statements. It is extremely difficult to eyeball which "else" belong to which "if". At least with braces I can use "%" in vi to walk through the structure of my code, seeing exactly which else belongs to which if.
This script is currently available here. It's called curlyPy. Let me know how it works for you.
this script is available here. Sorry for the earlier busted link.
Nonsense. The braces go at the beginning and end of a block. This is opposed to multiple tabs go at the beginning of every line.
Besides, I thought Guido made it perfectly clear, spaces, not tabs.
Braces and brackets always work (except for a few long-obsolete systems confined to Scandinavia), but it's very common for whitespace characters to be munged by editors, mailers, and browsers. We see it all the time, even in this very forum. Why did you write "^T" in your comment? Because a real tab wouldn't have worked!
(Its codepoint is actually U+0009 or ^I, by the way, though the C escape is \t.)
"Python has block delimiters just like any other language. It's a tab character."
No, it doesn't have to be a tab for the white-space. The space-bar works too.
the problem is at some point they are going to drop support for it, and no modules will begetting written for it either. the fact that you can maintain it yourself is a retarded response to this, because people who say it have pretty much no idea how much extra work that puts back on you, and frankly no one wants that.
If you mod me down, I will become more powerful than you can imagine....
If not maintaining compatibility is the "death knell", then Ruby is eliminated (1.9 isn't backward compatible with 1.8.x), too.
Perhaps you should reconsider that criticism after thinking about the difference between "Cut" and "Copy", and thinking about what the most natural way is to move a large block of already-written code that would otherwise need to be repeated from the inside of one function out into into its own function without creating more lines to maintain.
The tab (or spaces) in Python are not block delimiters. They are per-line block-level markers, which are not, at all, the same thing, though of course there is a direct conversion between code in which blocks are indicated with block-level-markers and otherwise-syntactically-identical code in which blocks are indicated with delimiters (which is why languages with regular, unambiguous delimiters can be automatically indented by editors.)
the problem is at some point they are going to drop support for it
Welcome to software development.
What products don't eventually become unsupported? Even a compiled language like C or C++ has libraries that eventually become unsupported, and maintaining them even if you had the source would become a difficult task.
AccountKiller
Here's what Guido said here on July 27, 2007: Q. I want to learn Python. Should I learn Python 2.6 or Python 3.0?
A. Definitely learn Python 2.x (the latest version out is 2.5). I expect it'll be two years before you'll need to learn Python 3.0, and the differences aren't that great from a beginner's perspective: most of what you'll learn about 2.x will still hold about 3.0. Mid-2009 isn't so bad, and I think what he means is that's when operating systems will start including 3.x by default. Remember -- Guido works for Google now, and last I heard, Google was still using Python 2.2.
I wasn't paying attention to Python back in the time, but wasn't Python 2.0 incompatible with Python 1.0?
The changes in how scope worked must have surely broken things.
"You should NEVER read the Silly Parenthesis in LISP, that gets taken care of for you by any one of a gazillion tools."
Tools do your reading for you? How does that work?
I have a question, isn't Python a programming language? if it is true then what does backwards compatibility means? I mean, if it is going to have different syntax or sentence construction then it is another language, and I think they should not call it Python. It is like C++ and C# or logo /Starlogo/Netlogo they are different languages which have some common features, but are completely different things.
The other issue is, isn't Python 2.0 an open source language (open specification and whatever), if that is true then i believe there is no problem of staying behind because even if the current maintainers start their new improved Python (Python++) a new community around Python can be created. It is like saying that C++ was going to mean the end of C99
Ubuntu is an African word meaning 'I can't configure Debian'
Of course, I'd argue that the requirement a language be able to be re-indented algorithmically is actually the real religious issue.
it simply produces nothing. This will catch many people many times,... It's only a problem insofar as it is a bad habit. If you want a reusable list, do:
x = range(1000)
for i in list(x):
something
for j in list(x):
something
In your case where you have a function that returns an iterator, you can simply replace list(x) with the function call foo(), and you get 2 iterators each starting at index 0. Maybe you should name x something more descriptive like iter?
Iterators are great, in my opinion. Using an iterator instead of a list potentially saves lots of memory and potentially prevents expensive operations being performed until you actually need them to be.
I doubt any people that actually understand python have had problems in this regard. Cut + paste is not the major coding tool as it is in Java. If you're almost repeating code more than once, you need another level of abstraction. Also, if you're nesting deep enough for the indentation to be a problem, you should be breaking that up into functions.
We at slashdot are scientists, specialists and kernel hackers. Your FUD will be found out.
Whitespace shouldn't have semantic meaning because then you're stuck with semantic whitespace that might not be the easiest to read. For example, The following is MATLAB code specifying a 10x10 matrix that could be used for future calculations. Since this discussion is about Python, your example doesn't have any relevance. The only significant whitespace in Python is relative indent level, which is tokenized by the lexer in much the same way as curly braces are in other languages--to delineate blocks. Spaces within arrays/lists are not significant, except in string literals of course.
Huh. huh. huh. He said "do do". /beavis
VB:
SUB MyFunc(ParmA as Integer)
If ParmA = 1 then
Call FuncB(ParmA)
Else
Call FuncC(ParmA)
End If
End Sub
Or....
procedure MyFunc (ParmA : Integer)
begin
if ParmA = 1 then
FuncB(ParmA)
else
FuncC(ParmA);
end;
VB and Pascal are syntatically close enough that you can substitute one for another pretty easily. Then again, so is C compared to Pascal, except C is harder to read later.
apparently AIN'T gettin' rid-of the never-to-be-sufficiently-retyped "self."
This article is trying to imply that Python 3000 (that's what it's called right now) breaking compatibility will be as bad as Perl 6.
But in fact, it's completely different. Perl 6 is actually a completely new language. They're replacing the basics, such as the "." operator, which used to be for string concatenation, and now is for accessing properties and methods of objects (like, they're trying to lose its C heritage and appeal to Java, .NET and Python programmers). There are other silly changes like this, that don't add any new features, they just change it because they thought it would look less ugly that way. On the other side, they didn't change Perl's most ugly side, which is that every variable is global by default! You have to use strict and my this my that... But the result is a language that still has the same shortcomings of Perl 5, and on the other hand, is completely different than Perl 5, in a way that you have to relearn everything you had learned before. If you want my opinion, Perl 6 will fail (not trolling here, just what I really think).
On the other way, Python 3000 changes are on certain core elements, like strings, but the changes are made in a way that the language's general look and feel is still the same. In fact, many scripts will keep working as they are, and the most of those that will have to be changed will need only minimal adjustments. If you're proficient with Python 2 now, you'll probably be as proficient writing Python 3000 in less than an hour.
As for Python 1.5 vs. Python 2, the backwards compatibility was kept. Though, many new constructions were introduced in Python 2, and the "preferred" way to do things changed. Python 2 has cleaner ways to do several common tasks, and the style of writing code actually changed significantly from 1.5 to 2, being much cleaner on 2. However, the 1.5 code kept working. From 2 to 3000, the change will be less in style and more in core concepts that will be reimplemented in a better way (like strings and classes), requiring to break the old and deprecated way to do that before.
I have used a lot of languages in my time time and when I was finally dragged, kicking, screaming, biting, and gnashing my teeth into perl, I thought perl was one of the worst languages ever provided to people who went to college and got some form of "MIS" degree. Then I took a job that had a bunch of stuff written in Python and I praised perl.
Let's face it, Python is another step in the complete destruction of useful languages. Rather than force people to actually understand how things work, we now create "languages" that do everything for us. Perl and Python are not really languages. They are gigantic synonyms that insulate the user from anything remotely like what the underlying operating system or hardware is doing and it is debilitating innovation.
There is nothing that I have ever written in Perl that I could not have accomplished in C using less memory and fewer CPU cycles. The same goes for Python.
If you are interested in remaining ignorant and writing crap code in a crap grammar, great. Otherwise, who cares? Isn't Python 3.0 yet another conduit through which we can obfuscate"programming" and allow a community college 'MIS' major to claim he has the education as an MIT Computer Science graduate?
You mean that in python you hit ENTER BACKSPACE BACKSPACE while in C you hit ENTER CLOSE-CURLY ENTER? The reason why editors can't guess where to end your block is because that is a decision you have to make and signal to the editor. Whether the [CLOSE BLOCK] symbol is a curly brace or a backspace is not really that important now, is it?
I read it. It's broken, won't run old code, it's 100% useless to me. There will be no porting. Incompatibly changing the print statement. How unbelievably ridiculous. It's the kind of thing you do when you have no users yet, not when there are untold numbers of people who trusted you.
Really -- why not just say it has to run under AmigaDOS now, requires Fortran syntax, and be done with it? Wouldn't kill it any deader.
I've fallen off your lawn, and I can't get up.
As long as there are people using it support will continue, since a certain fraction of them will patch things. And writing modules yourself is quite straightforward, really (though why would you need to if this is old working code that you just want to keep working?)
I am trolling
You're talking about technology and a scripting language.
How long do you think you'll still be using the same scripts?
You do realise you can use any variable name for the class reference, right? Calling it "self" is just a convention. In one piece of software I worked on, the convention was to call it "s".
Pirate Party UK
The editor cannot possibly guess when to close a scope in 99% of the situations. Unless you have an über smart editor which needs you to input a formal specification of what your code is supposed to do and... hrm... no, actually... there is no possible way for an editor to do what you seem to want.
As for you particular example, try it in vim: you will see that after a return, vim removes a level of indentation for you.
People who argue against semantic indentation tend to be really really bad at providing examples, from what I can see...
my bad.
Intron: the portion of DNA which expresses nothing useful.
How about this one: US-ASCII consists of 94 printable characters which are delivered reliably and 34 control characters which are frequently munged. Any Python code that goes through any tool (e.g., a Web forum) that doesn't preserve whitespace becomes ambiguous and unusable.
For your specific example: a web forum which does not preserve whitespace where it should is broken. So go fix it. The pre tag has been in HTML since its inception, for a reason.
In any case, your argument is of very little weight. Any non-US-ASCII encoded text which goes through any tool which is not prepared to handle it will become useless quite soon (like anyone which an accent mark in his name, I can tell you) yet that's an absurd objection to, say, UTF-8.
They're all broken, including Slashdot (I tested ecode, because pre is simply ignored). So the Python fans' official solution is to boil the ocean rather than just add an option to support a less fragile syntax?
As for using UTF-8 in the source of a script (not just supporting it in input and output), you'd be getting yourself into a world of pain. Seriously, test every tool any of your peers has ever considered using, and even after that you should expect things to randomly get transcoded or otherwise break. I wouldn't do that on a bet before 2012 or so. I still see screwed-up email from recruiters simply because my résumé was posted on my vanity site in UTF-8 (with the correct HTTP headers).
In the end, the issue comes down to whether people actually use the language and whether they find problems with this semantic-indentation-from-hell, and whether they even find pleasure in it.
As for UTF-8, I have used UTF-8 in source code, and everywhere else for the last 7 or so years, and I have to have trouble with it.
Writing programs in Python is fun. And as we very well know, happy developers are productive developers. I think the porting effort is going to be more fun for its developers than pain :-)
Anyone else agree?
- The world is full of sleeping people... Too many sleeping people... very few wide awake.
Not saying it would make it impossible, just listing another instance where switching out tabs with braces will be a pain.
God invented whiskey so the Irish would not rule the world.