Python 3.0 Released 357
licorna writes "The 3.0 version of Python (also known as Python3k and Python3000) just got released few hours ago. It's the first ever intentionally backwards-incompatible Python release."
This discussion has been archived.
No new comments can be posted.
Python 3.0 Released
Related Links Top of the: day, week, month.
Think of it! With VLSI we can pack 100 ENIACs in 1 sq. cm.!
Comment removed (Score:5, Informative)
Re:woohoo (Score:5, Funny)
But I just came in here for an argument!
Re:woohoo (Score:5, Funny)
No you didn't.
Re:woohoo (Score:4, Funny)
An argument isn't just contradiction!
Re:woohoo (Score:5, Funny)
Yes it is.
Re:woohoo (Score:4, Funny)
Interestingly, it IS backwards compatible in areas that you wouldn't think it should be. For instance, the following program takes the version number, adds one to it, and divides by two. You'd think it'd give a different answer between version 3 and version 2. Glad they kept this program working for me, as it's the secret production code that runs my multi-million dollar business.
import sys
version=int(sys.version[0])
print (version+1)/2
Prints 1 in either version. (on the bright side, 1/2 is now 0.5!)
Re:woohoo (Score:4, Funny)
Re:woohoo (Score:5, Funny)
Re:woohoo (Score:5, Funny)
True Part:
In Python version 2, 1/2 = 1 (integer math)
In Python version 3, 1/2 =0.5 (floating point math)
Funny part:
You can do some math on the version number and it comes out the same, even though the version number has changed. Because the divide operation changed too.
wait, it's not so funny after all. What was I smoking?
Re: (Score:3, Funny)
It's scary to code something while drunk then come back the next day and think "god, whoever wrote this is clever".
I don't even need to be drunk! That happens to me regularly ... ah the ageing process.
Libraries (Score:5, Interesting)
Re:Libraries (Score:5, Informative)
Re:Libraries (Score:5, Insightful)
Backward compatibility is (i) over-rated and (ii) misunderstood.
It is over-rated in the sense that the number of current users which are inconvenienced is a very small percentage of the total number of users of the language (unless the language is in the tail end of its life, like Fortran and Cobol).
It is misunderstood in that with the use of a simple header or import declaration it is possible to have two different versions co-exist while the transition happens. This is done in HTTP where the first thing that clients exchange is the version of the protocol they'll use. It is also done in LaTeX, where the first declaration informs the compiler which major version is being used (pre-2e or 2e).
Kudos for Python for not being afraid to rock the backwards compatibility boat.
Re: (Score:3, Funny)
unless the language is in the tail end of its life, like Fortran and Cobol
Thus the phrases "The looooooooooong tail" and "You're ALL tail, baby".
Re: (Score:2)
Yeah, exactly like IPV6.
wait....
Re:Libraries (Score:5, Informative)
unless the language is in the tail end of its life, like Fortran...
Fortran will continue to thrive for many years. I don't know numbers, but based on my personal experience, it's the preferred language of most computational scientists and engineers. The most recent revision occured in 2003. According to this [acm.org], a new one is being worked on.
Re:Libraries (Score:5, Insightful)
Fortran will continue to thrive for many years.
I agree. The point is that the number of current users is a non-negligible percentage of the universe of future users. It is in that sense that it is "near the tail end".
For languages which are very early in their life cycle, such as Python, the number of users inconvenienced today are negligible compared to the total number of users that it will have and benefit from the changes.
Re: (Score:3, Interesting)
I wonder if Fortran may eventually be replaced by Python.
A few years ago, when I was first getting into Python, I read an article where a guy from a science research lab talked about his lab's transition from Fortran to Python. Python has some nifty heavy-duty math modules, written in C; and everyone at the lab who tried out the Python stuff strongly preferred it to Fortran.
Since C code is doing all the heavy lifting, it's nice and fast. Since Python is interactive, scientists can use it as a really-power
Re:Libraries (Score:4, Informative)
Python can't replace Fortran, but C can (and to a large extent, is). For most serious scientific computation, the initial software is written in a language like MATLAB or Python, which make use of number crunching libraries written in C or Fortran. When that code needs to be modified to run on a supercomputer instead of a workstation, it is usually converted to pure C or Fortran.
Interpreted and interactive languages like MATLAB and Python make it easy to prototype and test a new algorithm, but C and Fortran are still necessary to make an efficient implementation.
(Disclosure: I am a mathematician, currently using all the above languages for ongoing research, though I am studiously avoiding having to write any Fortran myself.)
Re:Libraries (Score:5, Insightful)
I wonder if Fortran may eventually be replaced by Python.
Already has been, in my world. I know plenty of people around the chem department who still use Fortran because 'it is the language of scientific computing, dammit!'
Here is the thing. Most of the time, they were so panicked about how long the program would take to run, they lost sight of how long it took them to write it.
I replaced many Fortran programs with Python in my time, because I could write the data IO so much faster, and then just use the C-level numerical libraries to do the analysis. The program would end up running just as fast, and the code could be written in an hour instead of a week.
Some people will die before they change languages. The rest of us just want our results. Hopefully, the switch to py3k goes easy and the community continues to grow.
Re: (Score:2)
Re: (Score:2)
Agreed. It is very unfortunate GCC in Mingw is still using such old utilities. It generally works for all the code I write but I would like to have 4.x on Mingw (it is possible to have but it does not work well).
Re:Libraries (Score:4, Interesting)
IIRC numpy and scipy have dependencies on other libraries that are not 2.6-clean. They also have a lot of issue themselves. Currently it's not a priority for them to migrate.
Can't remember when did I read about that... and I'm too lazy to dig it out from their Trac :-P
Re:Libraries (Score:5, Informative)
I just did a Google search site:scipy.org ("2.6" OR "3.0") -"ipython" -"nipy" and there are a lot of results turning up (and of course lots of bogus ones).
It seemed things are much better that I thought of. Those guys are making progress every day and my news were old news...
The difficulty with numpy/scipy is they need a great amount of C-level coding. There's 2to3 for Python code but tweaking C code is not that easy...
Porting? Instantly! (Score:3, Funny)
I heard they're going to use Python 3.0 for the impending from-scratch rewrite of DNF.
Re: (Score:3, Insightful)
Python 3 being out is great, they've fixed a few things that allow bad programming
Really? So if I write code in Python 3, it's guaranteed to be "good" programming?
Honestly, I didn't look at the article... have they actually made things MORE rigid?
I use python... I like python... but I can't help but think it was designed by someone who was pissed off that people didn't format their code the way he formatted his code. Since his way was obviously the "right" way, why not write a language that forces you to
Re: (Score:3, Interesting)
I can't help but think it was designed by someone who was pissed off that people didn't format their code the way he formatted his code. Since his way was obviously the "right" way, why not write a language that forces you to do it that way? Problem solved!
This is actually the main reason I haven't worked with Python beyond tweaking a few existing scripts. The funny thing is that (unless I'm misremembering the syntax) I already code using that style in other languages. But the idea of forcing that style on
Re:Libraries (Score:5, Insightful)
I can't help but think it was designed by someone who was pissed off that people didn't format their code the way he formatted his code. Since his way was obviously the "right" way, why not write a language that forces you to do it that way? Problem solved!
This is actually the main reason I haven't worked with Python beyond tweaking a few existing scripts. The funny thing is that (unless I'm misremembering the syntax) I already code using that style in other languages. But the idea of forcing that style on everyone annoys me enough to put me off of the language as a whole.
I was really hoping that 3.0 would remove that petty stupidity. Doing so would even retain backwards compatibility with prior versions!
I just don't get it when people say that, its sorta like saying you don't use language X because you have to store numbers as floats or integers instead of char variables.
I honestly like the fact that Python forces a coding format, I hate opening someone else's source and spending the first minutes trying to understand how they layout things if at all. And yes if people were smart it would be easy to pickup anyones code, sadly that world doesn't exist.
No its not petty stupidity, not using Python because of your reasons is sadly what I would call petty stupidity.
Re:Libraries (Score:5, Informative)
But the idea of forcing that style on everyone annoys me enough to put me off of the language as a whole.
I had that exact reaction when I first came across Python. But after giving it a chance (many years later), I realized that it doesn't force a style any more than C forces the "style" of putting braces around blocks. Indentation levels are just syntax elements that happen to correspond to what most developers naturally do. Really, having to indicate blocks to the compiler in one way and to humans in another way is a DRY violation, which Python eliminates.
Re: (Score:3, Informative)
You don't use tabs in the first place. And in any case Python enforces no standard of block indent, it simply requires that you use the same indent for all blocks. So you can tab+space all you want so long as all of it is the same. The human reader merely requires that you use a unicode font and everything lines up. What exactly is hard about that? The reason to use braces is to speak to the computer, humans still indent to make it readable.
The recommended way to indent in python is to use 4 spaces, and any
good (Score:4, Funny)
previous releases were incompatibilie with earlier ones unintentinally.
Release notes (Score:4, Informative)
The release notes might interest people:
http://docs.python.org/dev/3.0/whatsnew/3.0.html [python.org]
Also note that in the end of the release notes are info on the migration path from Python 2 to 3. I'll leave the rest to people who bother to RTFA... ;)
Re: (Score:2)
Ohhhhh, python.ORG.. for a second there I thought we were talking about backwards incompatible porn.. whatever that means.
You got time machine! (Score:5, Informative)
The cool thing about Python is it's "time machine". In Python 2.x you can "from __future__ import " to use features scheduled for future releases. With the release of Python 2.6 there's also a "2to3" tool that will point out revisions needed for 2.x code to be 3.0-compatible, and generate patches for you.
The Python developers have been aware of the difficult road of migration long before the release of Python 3, and they did a lot of careful planning and hard work for it. One of them being the __future__ module that has been there for quite long time just for this reason.
As a Python user, my hat off for them. I wish them success heartily.
BTW: In case you don't know, there's an Easter egg in the time machine: "from __future__ import braces" ;)
Re:You got time machine! (Score:5, Informative)
You can also use the python 2.6 "-3" option to have warnings about non future-proof constructs (ie things that can't be handled by 2to3)
in fact there are others python easter eggs :
import this
import __hello__
and ... a new one in 3.0, related to xkcd.
Re: (Score:3, Informative)
print "Hello world"
anymore but in 3.0 :
print("Hello world")
But I guess the point is still valid.
Re: (Score:2)
I like the sprintf style % part. But I don't like the weird rules- e.g. "A space is written before each object is (converted and) written, unless the output system believes it is positioned at the beginning of a line."
And now they change the syntax of print a lot.
Couldn't they just call it something else and keep the old weird print the way it is and thus not break so much?
For instance I think Perl 6 uses "say".
Re: (Score:2, Offtopic)
Oops. Slashdot ate my sentences.
It's "from __future__ import FEATURE_NAME"
I shouldn't have put it in angle brackets.
Re: (Score:2)
use < and > to get angle brackets that the parser won't eat.
And now to wait (Score:2, Interesting)
Sounds great! Now to wait a few weeks while smart people find and fix all the security holes, so I can go and safely get version 3.1.
Re:And now to wait (Score:5, Funny)
Nope. Python 3.11 for Workgroups.
Re:And now to wait (Score:5, Funny)
No mac version yet? (Score:3, Funny)
Where's the mac version..?
Re: (Score:2)
Just there alogn with all the other versions
You download the .tart.gz or .tar.bz2 source packages and build it. Took less than 15 minutes on my machinne
Re: (Score:3, Funny)
>You download the .tart.gz or .tar.bz2 source packages and build it. \
At last, what the world has been waiting for: a language for bimbos and airheads! :)
hawk
Re: (Score:3, Funny)
WTF are you talking about? Visual Basic has been around since 1991!
Unfair headline there, Bubba (Score:4, Interesting)
Yes, Python 3.0 is a break.
But in the past and forseeable future, Python has been exceedingly helpful, much more than most languages, during upgrades.
Usually one has several months to try out new features-- they're in the current version but turned off until you ask for them with "future_builtins".
Plus there's often a backwards feature in the next version to revert back to old behavior.
Not to mention a -3 option to point out the lines in your old program that will need changing for version 3.
But sometimes the changes are so big they can't be encompassed by a compiler switch. Such it is with 3.0.
Re: (Score:3, Interesting)
But sometimes the changes are so big they can't be encompassed by a compiler switch. Such it is with 3.0.
While I agree with your post, here it's not a problem with implementation but with syntax and backward compatibility within a given python version. ...). So you group them and call that a new version of the language. I doubt you couldn't implement most of it with compiler switches.
The idea is that some needed changes cannot be made backward-compatible (new keywords,
Is it possible to do automatic code migration? (Score:2)
If the syntax differences and the differences in the standard library are well-documented, shouldn't it be possible to write a program that migrates 2.x code to 3.x code automatically? Does such a program exist?
RTFA (Score:3, Informative)
OK, never mind, I just saw it, there seems to be such a beast: http://docs.python.org/dev/3.0/library/2to3.html#to3-reference [python.org]
Re:Is it possible to do automatic code migration? (Score:4, Informative)
Like http://docs.python.org/library/2to3.html [python.org], perhaps?
Re: (Score:2)
Yes, there's the official tool "2to3" and an interpreter flag "-3" in the 2.6 release.
They work pretty well. However, you can't leave everything to the machine. They can't replace programmers' insights.
from __future__ import braces (Score:5, Funny)
Re: (Score:2)
I read it as: there will never be a 3.5.
It used to be "not a chance"...
Yay, Unicode! (Score:5, Interesting)
Reworked Unicode support is a big deal. It was there before, of course (unlike Ruby - meh), but all those Unicode strings vs 8-bit strings, and the associated comparison issues, complicated things overmuch. Not to mention the ugly u"" syntax for Unicode string literals which was too eerily like C++ in that respect. Good to see it move to doing things the Right Way by clearly separating strings and byte arrays, and standardizing on Unicode for the former.
Now, if only we could convince Matz that his idea for Unicode support in Ruby 2.0 - where every string is a sequence of bytes with an associated encoding, so every string in the program can have its own encoding (and two arbitrary objects of type "string" may not even be comparable as a result) - is a recipe for disaster, and take hint from Python 3...
Re: (Score:2)
since methods exist to examine what the encoding of a string is, and to change it, how would there be a disaster unless the coder was sloppy?
Re: (Score:3, Interesting)
Assume a simple case: a function taking two strings as arguments. In Ruby 2.0, you cannot safely concatenate those two strings, or even compare them (because encodings may be incompatible). You cannot properly interpret it, because the set of possible encodings is not closed (the client may pass you a string with an encoding he defined himself). You cannot convert it t
Re: (Score:3, Interesting)
You understand almost correctly :) The problem here is, what is a "possible character"? It is in many ways a political issue, and apparently some people aren't happy about the way Unicode handled some characters. One particular sore point is that of Han unification [wikipedia.org] - basically, Unicode assigned a single codepoint for every Han glyph, whether it's used in Chine
Re: (Score:3, Interesting)
They are correct. "UTF-8 String" is not really an UTF-8 constant, it's just a plain Unicode string now. It makes sense, too, as comparing a byte array with a string is not generally well-defined operation. And yes, of course, it's a breaking change, and is on the changelog [python.org].
Now you can still have byte array literals if you want them, but they are opt-in via "b" prefix (much like Unicode strin
Re: (Score:3, Interesting)
Reading the changelog, it sure does sound like b"abc"=="abc" will produce an error. I do find this extremely suprising as I would think this would break enormous amounts of software.
It sounds like Python 3.0 will throw an error if you read a file that contains invalid UTF-8, until the program is rewritten to read the file as "bytes". Then it will throw errors when you convert the bytes to "str", until you rewrite the functions reading the files to return bytes instead of str. Then the users will hit this pr
Re:Yay, Unicode! (Score:4, Informative)
Why isn't it? If your input file is supposed to be UTF-8 text, and is not, then surely it's an error? As you say yourself, you can always load it as raw bytes if you want to work with it nonetheless. But, of course, as soon as you want to start treating it as an actual string - so that you can say things such as "give me the 10th character" (and not "10th byte") - it has to be valid, otherwise all string-specific operations would simply be undefined.
I like UTF-8, but UTF-8 with errors in it is clearly not valid UTF-8, no more than XML with a missing closing tag in the middle of the file is valid XML. The problem with such UTF-8, as I've mentioned earlier, is that no string processing function would know what to do with it. If you, say, try to convert it to uppercase, what should it do with invalid sequences? What about the earlier example of indexing by characters, or taking the leftmost or rightmost N characters - how should it could the unterminated sequence?
No, I did not. C and C++ actually work in precisely the way Python 3 does. The only difference is that in them, a plain unadorned string literal is a "byte array", and you have to explicitly request wide chars (to simplify, let's assume it means always means "Unicode" for now) by prefixing it with "L". Otherwise, it's precisely the same. In particular, L"\xC2\xA2" is not a cent sign in either C or C++. It's a wide (string with two characters. Plain "\xC2\xA2" is a non-Unicode (i.e. byte) string of two bytes, which produces a cent sign when treated as UTF-8 - and so is byte string b"\xC2\xA2" in Python.
It's a legacy of C/C++ - they couldn't extend the "\x" escape sequence to use more than 2 digits without breaking existing string literals, so they left it as is. In C/C++, Java, C# etc, if you want a full-length Unicode escape, you use "\u1234". However, note that it doesn't really change anything - inside a Unicode string literal, in all these languages, "\xFF" is the same as "\u00FF", which is the same as "\U000000FF". None of them allows to define individual bytes in Unicode string literals.
Yet that's how it is. Do you want quotes from the respective language specifications?
This decision is made on different levels. The compiler isn't assuming UTF-8, the code which reads the file as a sequence of characters (before lexing, much less parsing, takes place) does that. On the other hand, processing the content of the string literal is (most likely) done by the lexer, including character escapes. Also, keep in mind that non-UTF input files are still legal - should escape sequences in literals suddenly change meaning for them?
Re: (Score:3, Interesting)
If your input file is supposed to be UTF-8 text, and is not, then surely it's an error?
UTF-8 with errors is STILL UTF-8. It just is not "valid UTF-8" which is a mostly uninteresting subset. The set of UTF-8 strings is every single possible byte sequence. The set of "valid UTF-8" strings is a SUBSET that a tiny portion of software (mostly validators) should have to care about.
People are trying to make this far more difficult than it really is by somehow saying that we must restrict ourselves to that subset a
Re: (Score:3, Informative)
Given that you can always do encode() on the Unicode string to get its byte representation in default encoding of the current locale, what's the problem?
backwards not needed (Score:2)
print function (Score:4, Interesting)
First thing mentioned on the 'what's new' page (http://docs.python.org/dev/3.0/whatsnew/3.0.html)is that you'll have to change your code from
print x, y, z,
to
print(x, y, z, end="")
I can see the value of making things more consistent, but it seems to me whenever they update things in Python, it's usually to make programming in it a little bit harder.
Why not make print a function, but then change the language to not require parentheses for any function call? You'd still have to use them when calling a function with zero arguments, and in sub-expressions, but to not require parens for top-level function calls would, if nothing else, make playing around in interactive mode or with short scripts a lot more pleasant.
Granted, I come from a Ruby background, so I may not know what I'm talking about. My experience with Python is trying to write some scripts on my OLPC, where the craptacular rubber keyboard made typing parentheses all the more agonizing. I finally caved and installed Ruby so I could get some work done. Maybe people who prefer Python really like typing parens. And underscores.
Re: (Score:3, Interesting)
The IPython (nothing Apple-related) interactive shell hacked the Python lexer to allow exactly this. You type this at the shell prompt:
foo a, b, c
it will be interpreted as a call foo(a, b, c).
IPython still has some bugs with this feature, though. It can be turned out, but I still prefer it in interactive use just as you've mentioned.
Anyway, I think the current Python syntax is OK.
Re:print function (Score:4, Interesting)
I would say that it makes typing python a little bit harder, but I would also argue that it makes programming python easier, not harder (it eliminates print as a statement, but it also eliminates special syntax that existed only for redirecting print output, and makes it trivial to change the default behavior of print within a module (by defining a local print function)).
Re: (Score:3, Funny)
You seem to want Perl. You can find it at http://www.perl.org/ [perl.org]
Re: (Score:3, Insightful)
Why not make print a function, but then change the language to not require parentheses for any function call?
A good argument is that it would make the grammar ambiguous.
What's the parse tree of "f x, g y"? I think it can be both (tuple (f x) (g y)) and (f x (g y)).
One could of course detect and disallow ambiguous strings, at the expense of the parser having to do a little more work. It may be a little, or it may be a lot. ...
I don't know why this story's flagged "endofdays" (Score:5, Funny)
That'll be when Perl 6.0 ships.
Re: (Score:2, Informative)
Re: (Score:2)
Re:I don't know why this story's flagged "endofday (Score:5, Funny)
Signs of the apocalypse:
* A black man was elected President of the US - November 4, 2008
* Chinese Democracy was released - November 23, 2008
* Python 3000 is released - December 4, 2008
* ?
* ?
* Large Hadron Collider starts operations - ?
* Duke Nukem Forever is released - ?
Re:That marks my end of use for Python (Score:5, Informative)
I'm fairly certain they got all these non-backward compatibility issues out of the way with this release so they don't have to do this kind of thing again for a long while. My guess is, they wont ever put out a non-backwards compatible release, since those changes were mostly to fix poor coding practices like being able to run certain functions without braces (e.g print "hi").
Re:That marks my end of use for Python (Score:5, Informative)
It's also cleanup of some stupid syntax that was there for ages. For example, exception handling. Old style:
New style:
It's fairly obvious that the latter is much clearer.
Re:That marks my end of use for Python (Score:5, Funny)
So what are you going to do, take all your existing Python applications and rewrite them in a different language, in order to avoid the "significant amount of work to maintain existing functionality with new language version"?
Re: (Score:2)
I'd suggest rewriting in COBOL. This would make sure that one's precious code is not going to be broken by a new incompatible release.
And if OOP is strongly desired, try Simula-67.
Re: (Score:3, Insightful)
Besides teh above remark of well thoguth migration paths - it is importante to remakr that support for python 2.x has not ended in any way.
As far as Iam aware, the recomendation is to keep working with python 2.6 - and use the py2to3 script to regularly to make 3.0 releases if you you can (i.e. if your dependencies have 3.0 versions already).
No need to worry about anything, this will be a smooth, years long, transition. Chances are we will even see a python 2.7 before 2.x is officially deprecated.
Re:That marks my end of use for Python (Score:5, Funny)
Besides teh above remark of well thoguth migration paths - it is importante to remakr that support for python 2.x has not ended in any way.
As far as Iam aware, the recomendation is to keep working with python 2.6 - and use the py2to3 script to regularly to make 3.0 releases if you you can ...
Are you typing while drunk?
Re: (Score:3, Funny)
Besides teh above remark of well thoguth migration paths - it is importante to remakr that support for python 2.x has not ended in any way.
As far as Iam aware, the recomendation is to keep working with python 2.6 - and use the py2to3 script to regularly to make 3.0 releases if you you can ...
Are you typing while drunk?
No, he generated that comment with Python 2.6 code but ran it with the new release.
Re:Hey! (Score:5, Funny)
As someone mentioned above, try
from __future__ import braces
and see what happens. ;)
As for Ruby, I don't really follow its development or use it, but I was reading just the other day that they're really focused on finishing 1.9, which does byte-compiling and some optimization. The current version (like JS before spidermonkey, V8, and squirrelfish) walks and executes the AST (as I understand it), which is slooow.
Re:Hey! (Score:5, Informative)
>>> from __future__ import braces
File "<stdin>", line 1
SyntaxError: not a chance
Re: (Score:3, Funny)
Re: (Score:3, Insightful)
Care to cite a reference for the Rossum's alleged comment? I think "the whitespace problem" is actually one of Python's big advantages, since it greatly enhances program readability.
Re: (Score:2)
Mandatory whitespace in python is not a bug, its a feature!
Re: (Score:2)
Ah. Yes. That one. Once I got over it I dropped Perl almost completely. Perl was my big love, once.
Re: (Score:2)
Same here, and that was almost 2 years ago now.
Any coder worth his salt is already indenting his code the way python likes it anyways, no matter which language he's using, so this part of the transition is normally a non-issue.
Re:I'll still avoid it (Score:5, Insightful)
Well, the big issue I've run into with Python is when you are editing across multiple text editors, where some might use tabs, and some might use spaces. This seems to trip up Python where it wouldn't mess with a brace delimited language or something with an "end" syntax like Ruby.
Why whitespace really is a problem (Score:3, Insightful)
>>Any coder worth his salt is already indenting his code
As long as you are using your own code, and stick to your own conventions, then it's not a problem.
But what about when you are working with code from somebody else? You can not just look at it and tell if the original developer used spaces, or tabs. You have to do a hex dump, or something - what a pain.
And what if you want to cut and paste from a website? Or email code? Or post code to a news group, or whatever? Whitespace can be an issue in any
Re: (Score:2)
I dropped Perl for Python as well, and I never had to "get over" the indentation thing. Never understood why the big gripe. Programmers type braces and semicolons all the time without giving it a thought, someone elsewhere in this story asked why not an End statement in Python... yet somehow indenting code in a standard, readable way is noxious to them.
Re:I'll still avoid it (Score:4, Insightful)
As they didn't fixed the stupid forced-indentation thing.
Same reason I don't use C... that stupid forced-curly-brace thing. Why can't the language just know what I want to do?
</sarcasm>
Re: (Score:3, Insightful)
It's good thing when you get used to it as it makes source code much clearer. If you find that the forced indentation is bulking up your code too much then you are probably missing a trick... in Python there is always a short-cut and you just have to think more Python-like. For example in C/PHP I would type:
x=1; y=2; z=3;
When you first look at Python you are tempted to write:
x=1
y=2
z=3
Quickly you find you can:
x,y,z = 1,2,3
Phillip.
Re: (Score:2, Interesting)
Cut-n-paste is not a good way to learn.
Between Python's extremely verbose syntax (not very script-friendly-like)
It's not extremely verbose; take a look at Java if you want that. If you compare with e.g. perl, yes it's longer, but the difference is because it's using words rather than random characters, which in my book is worth it for
Re: (Score:3, Insightful)
the biggest problem is not copying from external sources, but moving your own code around.
of course the final code should get the right indentation anyway, but it's annoying to force the indentation when you just want to do a quick test.
and I don't write messy code. on the contrary, I'm a perfectionist zealot when it comes to the details of code aesthetics. it's just that forcing it is a bad design decision.
Re:I'll still avoid it (Score:4, Insightful)
Cut-n-paste is not a good way to learn.
Ah, I see, you've never refactored code before. Well, good for you, apparently everything you write is either immediately perfect, or you never have to maintain it!
Here in the real world, however, we *do* have to cut and paste blocks of code occasionally, and Python makes that annoyingly difficult.
Re: (Score:2)
Have you considered using a decent editor which can fix the indentation for you?
Just a thought.
I actually prefer Perl to Python, but I'll admit that I'm not actually sure why.
Re: (Score:3, Insightful)
For a little bit I avoided Python because of the whitespace sensitivity.
At some point I gave it a try, at which point I was already using emacs. It took 5 minutes to get used to the whitespace sensitivity since emacs took care of indentation for me.
Re: (Score:3, Insightful)
I have this code:
def myfunc()
if some_thing:
do_something
do_something_else
last_thing
def myfunc2()
while another_thing:
myfunc()
one_other_thing
And I decide i want to collapse those loops, so I copy and paste the code:
def myfunc2()
while another_thing:
if some_thing:
do_something
do_som
Re: (Score:3, Insightful)
If you're the one doing the refactoring, then you'll know how far the indentation is wrong, and you can apply the correction.
I *shouldn't have to*. Besides which, the fact that I do introduces a major source of potential error: because indentation is semantically significant in Python, if I screw up during the refactoring process (particularly large scale refactorings), I can actually introduce bugs simply by not getting the indentation right. That's just unacceptable.
So no, I wouldn't think anyone should
Re: (Score:3, Insightful)
It seems some headers are not installed (BerkeleyDB? Dunno what's the Ubuntu package name for that. It's "db4-devel" here on Fedora). Just check them out and rebuild?
Anyway, I never expect some 3rd party source tarball to be able to "build right out of the box" for me. If you do something outside a distro's package management system, you'll have to manage the dependencies all by yourself.