Python 3.0 Released

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."

Comments

Comment removed

[account_deleted]

Comment removed based on user account deletion

Libraries

[explodymatt]

Python 3 being out is great, they've fixed a few things that allow bad programming, but does anyone know how long it will take for the libs to start getting ported? Especially numpy and scipy

Re:Libraries

[Yvanhoe]

Last time I checked (several months ago) it was not thought that backward compatibility would be broken very hard. Most of the modification to do should be automatic so I think that a lot of packets that are still maintained will quickly be made compatible for python 3

Re:Libraries

[Bob54321]

I don't think these even work with python2.6...

Re:Libraries

[Anonymous Coward]

Numpy works just fine, though last time I tried to install SciPy on 2.6 (just after 2.6 was released) I had trouble -- and I don't think all of the tests passed. Seemed to work pretty well otherwise, though.

Re:Libraries

[gzipped_tar]

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

[explodymatt]

I had a lot of trouble (and didn't succeed) when trying to install numpy on 3.0rc3, any hints on how you went about it would be appreciated.

Re:Libraries

[Anonymous Coward]

Numpy? Scipy? wtfy?

Are we talking about a professional scripting language here, or Snow White with a bloody lip calling to one of her little bitches for help?

Re:Libraries

[maxume]

It's mostly Windows compiler issues. The python.org 2.6 binary is compiled with VS 2008 and there are a bunch of changes to make to the libraries that numpy includes to get them to compile with VS 2008.

I'm not clear on the Linux situation, but I believe it at least compiles (whether it works 100% is the issue, and I think it is quite close).

Re:Libraries

[morgan_greywolf]

So why don't they just compile it with mingw?

Re:Libraries

[explodymatt]

_Professional_ little bitches, thank you very much.

Re:Libraries

[maxume]

You'd have to ask them.

I think part of it is that the 'recommended' version of gcc in mingw is still version 3.4, which is missing out on 4 years of updates (from a code generation point of view, not a bug fix point of view).

Re:Libraries

[explodymatt]

more information on this would be greatly appreciated, do you have a url for me to start searching and maybe some keywords?

Re:Libraries

[gzipped_tar]

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...

Re:Libraries

[Tatsh]

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

[Alomex]

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:Libraries

[buchner.johannes]

Python provides a 2to3 source-to-source conversion tool...

Re:Libraries

[Anonymous Coward]

The main developer of numpy was an active contributor to the design process of Py3K, if I recall correctly he championed the inclusion of a certain type of C interface for arrays, I always figured that was to facilitate the porting of numpy to Py3K.

Re:Libraries

[Anonymous Coward]

numpy 1.3 trunk builds well with Python 2.6 on OSX and Linux, but there are some issues with Windows left. Scipy 0.7.rc1 is out, but I am not sure what the plan there is. I am unaware of any dependencies that are not Python 2.6 clean.

Re:Libraries

[gardyloo]

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:Libraries

[DiegoBravo]

Yeah, exactly like IPV6.

wait....

Re:Libraries

[Rostin]

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, a new one is being worked on.

Re:Libraries

[gfxguy]

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 do it that way? Problem solved! I love the addition of artificial barriers like being able to make your code fail if you mix spaces and tabs in your indents. Nothing anal retentive about that!

Sorry, just ranting... I really do use and like it, just some of it seems so anal retentive to me, and the thought that you can "fix things" that allowed bad programming seems like it's even more so.

Re:Libraries

[Alomex]

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:Libraries

[Alomex]

Wasn't this exactly the problem with IPv6? Back when it was proposed it was very early in the life cycle and we could afford to inconvenience current users, while at the same it gratuitously ignored (ii). By the time the powers that be agreed on the final version, the net was too large to justify a switch that inconvenience current users. Nowadays people are fast at work in patches that make IPv6 compatible in the sense of (ii).

Re:Libraries

[nurb432]

And all the tools ( and applications ) we are used to using. Editors, GUI's etc.

Re:Libraries

[DiegoBravo]

You're right in the first part. But...

>> Nowadays people are fast at work in patches that make IPv6 compatible in the sense of (ii).

That a lot of systems are capable of IPV6 doesn't means the Internet has been migrated, or will be in short term.

For example, there is a nice (and a bit depressing) article available at http://www.cisco.com/web/about/ac123/ac147/archived_issues/ipj_11-3/113_ipv4.html ... extract follows:

"From this observation it appears highly likely that the demand for IPv4 addresses will continue at rates comparable to current rates across the IPv4 unallocated address pool and after it is exhausted. The exhaustion of the current framework of supply of IPv4 addresses will not trigger an abrupt cessation of demand for IPv4 addresses, and this event will not cause the deployment of IPv6-only networks, at least in the short term of the initial years following IPv4 address pool exhaustion. It is therefore possible to indicate that immediately following this exhaustion event there will be a continuing market need for IPv4 addresses for deployment in new networks"

Re:Libraries

[Anonymous Coward]

"Sorry, just ranting... I really do use and like it, just some of it seems so anal retentive to me [forced indentation]..."

I ranted about that too when I first started using Python. But when I noticed how nice it was to read other peoples' code, I concluded that it was a good thing.

Re:Libraries

[Anonymous Coward]

(unless the language is in the tail end of its life, like Fortran and Cobol).

Yeah, but... where does the tail of a Python begin?

Re:Libraries

[Anonymous Coward]

Backward compatibility is (i) over-rated and (ii) misunderstood.

- Steve Ballmer, Microsoft CEO discussing pending release of Windows Vista

Ok, he didn't really say that but...

Re:Libraries

[blincoln]

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!

Re:Libraries

[Anonymous Coward]

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).

Backwards compatibility--in the sense that code which works today should work tomorrow (maybe modulo changing a few variable names)--should be an important feature for any major language. Backwards-incompatible changes make adoption of the new version much harder.

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 sounds all nice and well, but note that this means you have to lug around two compilers. Nice, bloatish things.

Re:Libraries

[Anonymous Coward]

Backwards compatibility should be an important feature for any major language.

Just because you say so does not make it true. In fact try compiling Java code written in 1995-1998.

his sounds all nice and well, but note that this means you have to lug around two compilers. Nice, bloatish things.

Oh please, this 2008 not 1988.

In this day an age where your music collection takes gigabytes of space, who cares
than one needs an extra 20MB to "lug around" an old version of the gcc compiler.

Re:Libraries

[baxissimo]

2.6 != 3.0rc3

There was discussion on the mailing list recently about making the few changes required to make Numpy work on 2.6. I think those may be done already (maybe only in SVN right now though?). But it sounded like 3.0 support is still a ways off.

Re:Libraries

[Anonymous Coward]

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

[steveha]

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-powerful desk calculator. And since Python has a clean and friendly syntax, it's easier to write and debug Python programs than Fortran.

I really wish I had saved a copy of that article, or at least its URL. I've tried Google searching for it, and I find many hits on using Python in labs but I haven't found the article.

steveha

Re:Libraries

[bnenning]

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:Libraries

[Anonymous Coward]

> 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.
>
The design of the language ensures uniform indentation and reduces the need for delimiters such as { and }. There is nothing petty about that, it is just a design choice. Caring too much about having to use a certain way of indenting does seem petty, though, as long as that way of indenting is reasonably sane, which it is.

For the obligatory car-analogy, think of the laws forcing you to drive in a certain side of the road. One side is no better than the other, the only thing that gives problems is when people don't agree on which side to choose. So someone chooses arbitrarily so that everyone can move on to care about more important things.

Re:Libraries

[644bd346996]

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

[synthespian]

Last year (or was it more?) I looke at these things - because of this continuous non-stop brouhaha about them - for matrix computations and they looked very immature vis-a-vis Matlab.

Re:Libraries

[Vornzog]

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:Libraries

[TheCouchPotatoFamine]

Yeah, because when i'm working on a coding project what i LOVE to see is five developers (precious little snowflakes) each with there own precious little style that totally mungles any reflexive ability to comprehend their code. And I totally LOVE all my screen space being used up by single lines with brackets on them. Hint: think professional.

Re:Libraries

[thesupraman]

Wrong, 3.0 seriously breaks the python-C interface, meaning such small things as wxPython are going to be major porting efforts.

Without the mountain of essential 3rd party libraries that python lives on, python 3.0 is next to useless for major projects.

This is a great pity, so much effort has gone in to providing nice tools to forward-port python code, but without the C extensions..

Unless a LOT of effort is put into porting over the top 20-30 binary extensions, I predict a long and slow birth for python 3.0, which would be a great pity.

It all feels rather rushed, and the 10% slower, with a 'maybe we can one day fix that' hurts as well.

Re:Libraries

[the-matt-mobile]

I often find myself doing code generation for repetitive tasks, or for highly dynamic code. So, all the work in maintenance goes into the generator code, and not the generated code. So, if my generated code comes out looking rough sometimes in terms of whitespace, it's because the generated code isn't as important as the generator. With Python and its significant whitespace, generating code is a pain! Boo got it right with adding a -WSA (WhiteSpaceAgnostic) compiler option which means you can use the Ruby style "end" keyword. It's optional, and isn't the default, but it works. Adding this to Python would "end" this argument once and for all. Instead, every slashdot article about Python degenerates into this topic, and many programmers go on about their lives without giving Python a chance. To each his own I suppose.

Re:Libraries

[steveha]

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.

Why is this done? If your Python program is spending almost all of its time inside a C module, why is it worth converting the whole thing to C? Not a flame, I just don't understand. Is it because you run the whole computation over and over in a loop, and the Python overhead starts to be noticeable?

P.S. You are a mathematician... have you seen Sage? It's basically a whole bunch of math libraries, glued together with Python.

http://sagemath.org/

steveha

Re:Libraries

[Anonymous Coward]

You're kidding. What are they going to do, put curly braces in? Indentation is Python's primary gimmick.

Re:Libraries

[highacnumber]

That's the beauty of Cython, check it out.
I think numpy and scipy will start using it more and more.

Re:Libraries

[maxume]

What does "very early" mean? Python was first released in 1991, so I can see where it is young compared to a lot of languages, but looking at Wikipedia, Fortran was pretty well defined by the time it hit 20.

Re:Libraries

[timmarhy]

while the python app is running a c module, there isn't any difference between it and running the whole thing in C. this is why python is a winner in the speed stakes, even though it has all the nice features.

Re:Libraries

[bnenning]

The other day I grabbed Numpy 1.2.1 and built it against Python 2.6 with no issues. It seems to run fine, but I'm only using a tiny portion of its functionality.

Re:Libraries

[bnenning]

With Python and its significant whitespace, generating code is a pain!

Out of curiosity, why are you generating Python code? It's often necessary in C or Java because those languages are insufficiently expressive so you end up with lots of almost-but-not-quite identical code, but I've found that in Python and similar languages it's rarely needed.

Re:Libraries

[Anonymous Coward]

What does "very early" mean?

That the number of current users is still relatively small compared to its eventual total number. Yes Python was introduced in 1991, but it didn't really get any traction until around 2000 or so, and even then only among a very elite crowd. It is only rarely used for teaching and its use trails Java, C++, JavaScript and C by quite a bit.

I think Python got many things right and it or one of its derivatives will be the next dominant language after Java.

Re:Libraries

[Anonymous Coward]

It's stupid to use whitespace to indicate blocks because multiple characters can be considered whitespace - what do you do if you have a tab followed by a space or vice versa? Is that 2 blocks deep? 1? How can the human tell how many distinct whitespace characters there are, particularly with tabs which hide leading spaces? The reason to use braces is that it explicitly tells both the compiler & the human exactly where the block begins and ends, but more importantly, makes it easy to see for the developer.

Re:Libraries

[mangu]

Fortran will continue to thrive for many years

Define "thrive", please. I agree that fortran will continue to exist for many years, but I wouldn't call it "thriving".

based on my personal experience, it's the preferred language of most computational scientists and engineers

You don't know many computational scientists and engineers, do you? Based on my own personal experience, it's the preferred language of a few engineers who are responsible for maintaining some old application written in fortran and want to keep the kids off their lawn. Fortran is still kept for many old libraries that are stable and well debugged, such as Lapack for instance, but there certainly aren't many new systems being developed in fortran.

Re:Libraries

[daver00]

I'm a mechanical engineering student and we are taught Python and Matlab. In another generation or so I think its possible nobody will be using Fortran, nobody is learning it. Seems like a bit of a baby boomer language to me ;)

The truth about python in the real world is that development time efficiency, even in the sciences, seems to be far more costly than run time efficiency. Of course there are examples that contradict this but then there is also C. I believe a clever use of Numpy arrays and the python opengl library can speed things up a tremendous amount too.

Honestly I think the only reason people are still using fortran in engineering is because thats simply what they were taught and never learned anything new. You certainly don't hear anyone in academia singing it praises, my engineering professors all seem to be of the opinion that fortran is an antiquated memory.

Re:Libraries

[The_Beige_Volvo]

Yes and no. Python has certainly replaced the majority of scientific workstation coding applications in my field of view (i.e. biophysics). But anyone who gets time on a supercomputer and writes their app in python is..well...to put it delicately probably not going to maximise the job distribution across the platform (I haven't checked for python support, but the big selling point for fortran 90 is things like variable-dimension array arguments). I caveat this by saying I don't yet have to write the supercomputer code for what I'm doing, so any clarification on why fortran 90 is so preferred would be welcome... So, I am noticing a bunch of jobs coming up in Fortran for massively parallel processing app building, whereas the jobs for the workstation app development is generally in Python/Perl/Java now. R.A.D. rules when the overheads on runtime are low, but as illustrated by my salary as an academic scientist my time is less important (to the people that administer the multimillion dollar supercomputer) than the time of the mainframe.

Re:Libraries

[daver00]

I agree, completely. I'm a mechanical engineering student and we learn Python at university.

There are three things that hold python back in scientific computing as far as I am aware and they are iteration, recursion and multithreading. Python iteration is just plain slow, its stack is small, and it doesn't support parallel processing without extra libraries, but you can get parallel processing going with some add ons and hack work. However if you just think a little differently what you do is use Numpy arrays instead of loops (Numpy is awesome), then use opengl libraries to solve your arrays on a decent GPU, suddenly you have a high level language with some scientific muscle, and I think if your stack is getting that big then recursion is not the right choice for the task.

Of course C will always be faster, however you can have a python script out and running days before the C equivalent is near finished. That kind of makes up for the overheads in most cases.

Re:Libraries

[daver00]

I thought the same thing when I first started learning python, and there were one or two other things that annoyed me. But now I'm learning some other languages and I just want my python back! I started learning php but I have decided that in the days of AJAX methods I can do it all with javascript and python. As much as I don't like Javascript, I hate php.

Python is a great language.

Re:Libraries

[daver00]

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 half decent text editor can be set up to do this when you press the 'tab' key. Rather than bitch and moan from the sidelines why don't you try it. Python kicks ass in so many ways and I haven't met any coder who has tried it and thinks its a bad language. It has pitfalls and quirks but all languages do, Pythons pros outweigh its cons easily.

Re:Libraries

[ITEric]

I believe it's directly posterior to the hip:P

Re:Libraries

[ITEric]

...I love the addition of artificial barriers like being able to make your code fail if you mix spaces and tabs in your indents. Nothing anal retentive about that!

I'm actually just starting to learn programming and decided to start with Python. I knew that the indents had to be consistent, but didn't realize it would matter if you mixed tabs and spaces. I understand why this could be a problem, but am frankly surprised this issue wasn't forseen and accounted for...perhaps it might be fixed in a future release?

(Yeah, I'm kinda anal retentive myself so I expect to deal with the formatting issues pretty well:P)

Re:Libraries

[Capsaicin]

"Sorry, just ranting... I really do use and like it, just some of it seems so anal retentive to me [forced indentation]..."

I ranted about that too when I first started using Python. But when I noticed how nice it was to read other peoples' code, I concluded that it was a good thing.

Since we all indent our code nicely in any language we use, I don't even know how people notice that Python enforces indentation. ;) Yeah I thought it was stupid too when I first used python, now I cuss when I have to use curly braces, not to mention end lines with a semi-colon and a return, Sheesh!

Re:Libraries

[el americano]

No its not petty stupidity, not using Python because of your reasons is sadly what I would call petty stupidity.

It's just a matter of personal preference. It's not as though I need to program anything in Python. Like the GP, I skipped learning Python when a need arose, but I picked up Ruby instead. Code was written, it still worked, it cost me the same amount of time. I would still like to learn Python some day, but I know I'll have to deal with this annoyance, so I'm still putting it off. This is my preference, and it's not wrong or petty.

BTW, I indent my code properly in every language I use. I rarely encounter code that doesn't. I always assumed that you are just saving braces, or an extra line ending blocks. This feels like the need to be different, rather than an actual improvement to the coding process.

Re:Libraries

[HiThere]

There's lots of places where that's practical, but ...

Well, the thing is that multi-dimensional arrays in C are quite slow compared to the same thing in Fortran. For lots of math applications, this means that C is seen as a slow cousin to Fortran. When you add on the Python interface ... you'd best not be going back an forth very much.

What's really needed is a better interface between Fortran and C, This is a really tricky thin, and no language manages that kind of interface well. (OTOH, it's possible that Ada is as good at multiple dimensions as Fortran. I don't know. But it, also, doesn't have a good interface with C. Python probably has the best, via Pyrex, but that adds a third language with a third set of rules. UGH!)

What would be really nifty would be if Pyrex would put more effort into being a complete implementation of Python. It couldn't ever really do it, since it's compiled to native code with a C interface, but it could come close. As it is Pyrex was designed as an easy interface from Python to C. For such a purpose it's hard to beat. What I'd like to see is Pyrex expanded into a full implementation of Python. Admittedly this would involve a large run-time library, but using only the "statically compilable" features in a module would execute as fast as equivalent C code, and it would link seamlessly to code that used the run-time features. Unfortunately, I think this might require a basic rewrite of the language. The current implementation is full of PyStrings and PyObjects. (I may have gotten the name slightly wrong.) Only small pieces run at full C speed, and they use a syntax incompatible with standard Python. But "there ought to be a way!".

Re:Libraries

[da cog]

Actually, the best way that I've seen this done is in Haskell. There are braces and statement separators, but they are put in implicitly if you use whitespace to indent things properly. If you ever don't want to use indentation, however (say if you have just a couple of small things you'd rather have on a single line), then you can always bust out the braces.

Re:Libraries

[Anonymous Coward]

It's just a matter of personal preference.

No doubt, it's just that the personal preference in question is based on petty stupidity. You're both right.

Re:Libraries

[Anonymous Coward]

The idea of forcing me to use curly braces to denote code blocks offends me, which is why I'll only ever use python!

^^ see how stupid this sounds? curly braces denote code blocks.. or whitespace denotes code blocks.. or whatever crazy unicode character your particular language choses to use (Can I suggest â ?).

Your argument is flawed because in python you can indent one char, or 2000 chars, as long as you are consistent it is still valid, 4 chars is just a convention like every other language, noone is forcing their indenting style on you, the poor parser would just like a clue as to what you're thinking.. that is all.

Re:Libraries

[chthonicdaemon]

There's an old joke: "What will the language of scientific computing look like in 10 year's time?" -- "I don't know, but it will be called Fortran".

Fortran has been reinvented many times. Fortran2003 is not your daddy's Fortran. Free-form formatting, implicit matrix and vector operations, smart support for parallel operations. If you like Matlab or Python with NumPy, you will probably like Fortran 2003. The thing is, that Fortran has been around for so long that Fortran compilers are typically crazily efficient. Of course, there's nothing there that can't be done in C, but Fortran makes a lot of it easy as part of the standard language, while in C/C++ you are left wondering which of the (many) matrix libraries you should use.

I think Fortran gets a bad rap because students like you talk to their profs, who remember 'old' fortran (77). A lot has happened since then.

Re:Libraries

[chthonicdaemon]

Most of the engineers I know couldn't be bothered to really learn something as vast as Java or C++. Fortran is simple enough that you can start doing productive work in a day. In the 'hot' languages of today, you need to get the language, then do tons of research about how to handle matrices and vectors, download them, get them installed. With Fortran you download gfortran (or just get it with your package manager) and start writing productive code. Then you compile it and it runs really, really fast with little effort from your side.

If you can point me to a set of tools for the language you propose is squeezing fortran out that makes it as easy to work with vectors and matrices as Fortran, I would be thankful, but I haven't found it yet. I think the major problem is that the average researcher is writing small (1000 lines) programs, while stuff like c++ only starts paying dividends when you are writing big programs.

Re:Libraries

[the-matt-mobile]

DSL's mainly.

Re:Libraries

[sentientbrendan]

>they've fixed a few things that allow bad programming

They've fixed some organizational and syntactic annoyances, but bad programming is something caused by bad programmers. A language can't save you from yourself.

Sun promised Java would do this, back in the day, and a million shitty Java programmers went forth to prove them wrong.

Re:Libraries

[mangu]

If you can point me to a set of tools for the language you propose is squeezing fortran out that makes it as easy to work with vectors and matrices as Fortran, I would be thankful, but I haven't found it yet

SciPy makes it *much easier* to work with vectors and matrices in Python than Fortran. Besides vectors, it has a wide variety of scientific fucntions. F2Py lets you call your existing Fortran routines from a Python script. It even lets you access global common data from the Fortran program in a Python script. F2Py also lets you call routines compiled in C from Python. A similar program that lets you access C routines from Python is Swig

Using vectors and matrices in Fortran only seems easy to you because you are used to it, but once you get used to doing it in a modern language you'll realize what a mess Fortran is. Both Frotran and C suffer from the problem of handling variable-sized arrays, you have to allocate the arrays. In Fortran-77 and older versions you don't even have the option of dynamical memory allocation, you had to declare the dimension of the arrays at compile time.

With Python you have an almost perfect development environment for scientific computation. You get the fast development cycle of Python, with the quick execution time of Fortran or C. All that with a huge set of libraries and utilities for every conceivable need. Do you have data that you get from an external website, for instance? Python lets you automate the download. Need to get data from a database? Format the output into a PDF file? Create pretty graphics for a presentation? Save data to excel spreadsheets? Etc, etc? Python has libraries for all that.

Re:Libraries

[Anonymous Coward]

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!

Spot the 'petty stupidity': the idea of forcing that style on everyone annoys me enough to put me off of the language as a whole.

Re:Libraries

[chthonicdaemon]

I use Python (and scipy) extensively for gluing all my stuff together. That said, the Fortran syntax for handling matrices is infinitely superior.

For instance: "forall (i=1:3,j=4:5) x(i,j) = i+j" as opposed to (perhaps) x = array([[i+j for j in [4,5]] for i in [1,2,3]]). And the forall automatically parallelizes. The where statement is also really cool, and I can have arrays with any indexing scheme I choose. Functions with the elemental property automatically apply to all elements of an array, and parallelize. All of this of course doesn't work so well for non-sparse matrices and so forth, but for the stuff I do (and many engineers do), it rocks.

I know python and sciypy and the built-in support for vectors and matrices that Fortan supplies is better because there is good syntax. To top it all off, the compilers for Fortran are pretty damn efficient, so many low-level algorithms code almost the same in Fortran and Python, they just run about 10 times faster.

My strategy at the moment is to use Python for the high-level stuff and Forrtan for the heavy lifting, using f2py. Python will no sooner replace Fortran than replacing C -- they play in different arenas. My real point in the previous post was that for languages that have efficient compilers, none come close to Fortran for ease of use with my kind of scientific computation. Python and other scripting languages (even Matlab or octave or similar) offer more interaction, but then it comes to the speed, Fortran is better than C, C++ or Java (the most common proposed alternatives).

Re:Libraries

[Vornzog]

You *can* run Python on Linux cluster supercomputers - distribute tasks to nodes with mpich, write the code in Python. I know people who do. I just don't know why.

For the truly hardcore number crunchers, use C or Fortran. Take the time. Do it right. Maximize the utility of your cluster time.

Here's the thing. Many people don't need or want that, but still think they need the speed of C or Fortran. The prejudices about scripting languages are still handed down though most computer science programs and science departments.

My longest running scripts can usually run overnight on a single core with a decent chunk of RAM, and I'll have results by morning. Python is good enough, and I'll have my results before you have working code.

Re:Libraries

[maxume]

Mixing tabs and spaces has long been legal. Not allowing mixing is the fix (the problem comes up when someone mixes tabs and spaces with 1 tab = x spaces, and then someone else who has their editor setup to automatically convert tabs to a different number of spaces edits that code).

Not allowing them to appear together is based on it being less painful to require people to fiddle with their editor than it is to deal with the occasional breakage.

Re:Libraries

[maxume]

Cython is a fork of pyrex that is actively working to increase coverage of the language (with the goal of being a standard library).

From what I have noticed, the fork is not hostile, the development goals are different enough to justify it.

Re:Libraries

[__aavljf5849]

"it's guaranteed to be "good" programming?"

No. But some common newbie bads are no longer possible.
Here is one example:
http://regebro.wordpress.com/2008/06/06/python-3-will-make-you-a-better-programmer/

Re:Libraries

[__aavljf5849]

"Doing so would even retain backwards compatibility with prior versions!"

Eh. No. It would require you to have brackets, which would break backwards compatibility.

Yes, the indenting thing is annoying. In the beginning. Then you get used to it.

The thing with the indentation is that because you indent anyway, the brackets are simply superfluous. Getting rid of them makes the code more readable. Also, this way there is no war about the One True Bracing Style, since the brackets aren't there. ;)

Re:Libraries

[Anonymous Coward]

You need to come and give a lecture in my physics department.

good

[Anonymous Coward]

previous releases were incompatibilie with earlier ones unintentinally.

Release notes

[Max Romantschuk]

The release notes might interest people:
http://docs.python.org/dev/3.0/whatsnew/3.0.html

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:Release notes

[neoform]

Ohhhhh, python.ORG.. for a second there I thought we were talking about backwards incompatible porn.. whatever that means.

Re:Release notes

[hawk]

presumably, that it is not arousing to neanderthals, homo erectus, and so forth . . .

hawk

You got time machine!

[gzipped_tar]

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!

[makapuf]

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:You got time machine!

[gzipped_tar]

Oops. Slashdot ate my sentences.

It's "from __future__ import FEATURE_NAME"

I shouldn't have put it in angle brackets.

Re:You got time machine!

[Yvanhoe]

Ironically, the XKCD referring to python is now false : Hello world is not

print "Hello world"

anymore but in 3.0 :

print("Hello world")

But I guess the point is still valid.

Re:You got time machine!

[SilentGhost]

import __hello__ doesn't work any more. that's backward-incompatibility for you.
doesn't work the way it used to in python2, that is

Re:You got time machine!

[Anonymous Coward]

I always knew that Python wasn't all that efficient, but I never realized that it needed 1.21 jiggawatts!

Re:You got time machine!

[m50d]

from __future__ import braces has been there for a while.

Re:You got time machine!

[gzipped_tar]

Ummm. I should have piped my post to my grammar checker written in Python 3000 before I hit the "Submit" button :-P

Re:You got time machine!

[compro01]

use < and > to get angle brackets that the parser won't eat.

Re:You got time machine!

[thornomad]

So I was just thinking of starting to learn Python (been meaning to pickup a language here) and Google's new app engine thing piqued my interest -- but now that 3.0 is out (app engine is 2.x) what's the best way to go about learning Python without having to re-learn everything as things migrate? Or do I just have to suck it up?

Re:You got time machine!

[Anonymous Coward]

It is really not that different. They just fixed some things that turned out to be not so great design decisions like making strings not Unicode except when you used a special Unicode type. Anyway, you will probably end up seeing 2.x code at some point and should be at least somewhat aware of the differences.

Re:You got time machine!

[TheLink]

I think the print in python is a bit of a mess.

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:You got time machine!

[maxume]

Sucking it up will not be painful.

If you are using libraries in 2.x and they suddenly decide to only support 3.x, you might have some issues. For the most part, the changes take a few minutes to review (many of the changes are related to removing things that have been replaced (but not yet removed) as of 2.5, so if you pay some attention to how you do things, you won't even notice those).

Re:You got time machine!

[maxume]

Is getting a "<" left as an exercise for the reader?

What about <?

Re:You got time machine!

[Random BedHead Ed]

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".

As I understand it, having many similar statements and functions is exactly what the architects of Python were trying to avoid. Python 3.0 is somewhat incompatible with earlier versions precisely because they didn't want to litter it with messy hacks and many parallel methods of doing the same thing, but rather to design a new version as if they were getting a clean slate. In a way I wish Perl had done the same thing, as I'd love to be able to read other people's Perl.

Re:You got time machine!

[MikeBabcock]

You're free to use sys.stdout.write("Hello World") if you want.

Re:You got time machine!

[thornomad]

Cool - thanks for the insight. I put a Python book on my Amazon Christmas Wish list. Here's hoping...

Re:You got time machine!

[Anonymous Coward]

from future import dot_net

(we'll all be working for Bill Gates)

Re:You got time machine!

[maxume]

One thing to watch out for is that a lot of libraries are wrappers around some C library or another, and the python API gets marked as changed for minor versions, so, for instance, if you are using an extension with python 2.1, the library may not be compatible with 2.2 right away. This is more painful on Windows than other platforms, but for the most part, things get updated on a reasonable schedule.

(A lot of people end up commenting on this with new python releases "I was using xyz and it didn't work any more, Python is teh suck.", and I'm not sure they realize the why, and they blame it on 'language changes', where it is really about reducing the headaches involved in maintaining the implementation)

Re:You got time machine!

[shutdown -p now]

I think the print in python is a bit of a mess.

True. By the looks of it, it was largely stolen from BASIC (complete with that crazy idea of trailing comma suppressing newline). That's why they reworked it in 3.0 to work like you'd reasonably expect it to.

I like the sprintf style % part.

It's not a part of print, it's a general-purpose formatting operator on strings.

Couldn't they just call it something else and keep the old weird print the way it is and thus not break so much?

The old print was weird enough to just proclaim it to be broken by design, and make a properly behaving library function out of it.

Re:You got time machine!

[TheLink]

That's a lot more typing than print "Hello World".

Yes I could wrap it with a different function, but it means one more nonstandard function for other people to figure out when they look at my code.

A good programming language should provide concise standard ways for doing popular stuff.

Programming is a form of compression.

Instead of zillions of "if ... then ..." statements, you compress them to loops and other stuff.

Note: you don't usually compress everything to max because if some bits need to be changed later you'd have to do a lot more unpacking and repacking...

Re:You got time machine!

[geminidomino]

&ampamp;lt;

Re:You got time machine!

[mzs]

It's definitely the meds:

If you want the newline:
perl: print "hello world\n";
py3k: print("hello world")

If you don't want the new line:
perl: print "name: "
py3k: print("name: ", end="") #WTF

Re:You got time machine!

[MikeBabcock]

Programming is a form of expansion :-) It expands your thoughts into the individual commands required to do them.

def debug(stuff):
        import sys
        sys.stderr.write(stuff)

debug("Got here, and it works.\n")

And now to wait

[Anonymous Coward]

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

[maxume]

That'll be 3.0.1.

Re:And now to wait

[morgan_greywolf]

Nope. Python 3.11 for Workgroups.

Re:And now to wait

[Random BedHead Ed]

This post was reserved for the Python NT 3.5 joke, but it has been postponed until the next release (along with a database-driven filesystem the Python developers swear they're working on).

Re:And now to wait

[maxume]

sqlite support was added to 2.5.

Re:And now to wait

[WolverineOfLove]

Joke

____

Your Head

Re:And now to wait

[An ominous Cow art]

Unless you really believe that Python will someday include a filesystem based on sqlite, it's your head over which the joke has arced gracefully. :-)

Re:And now to wait

[maxume]

Many slashdotters prefer the subtlety of a hammer.

Re:And now to wait

[Anonymous Coward]

I think you got that wrong. A hammer usually isn't considered very subtle.

Re:And now to wait

[Random BedHead Ed]

sqlite support was added to 2.5.

I think you got that wrong. A hammer usually isn't considered very subtle.

There have been a lot of wooshing noises on this thread since I left it.

No mac version yet?

[neoform]

Where's the mac version..?

Re:No mac version yet?

[Pope Raymond Lama]

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:No mac version yet?

[Anonymous Coward]

Mmmmmmm...tart.

Re:No mac version yet?

[hawk]

>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:No mac version yet?

[geminidomino]

WTF are you talking about? Visual Basic has been around since 1991!

Unfair headline there, Bubba

[Ancient_Hacker]

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:Unfair headline there, Bubba

[makapuf]

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.
The idea is that some needed changes cannot be made backward-compatible (new keywords, ...). 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.

Re:Unfair headline there, Bubba

[Anonymous Coward]

No, this is not slashdot sensationalism.
The summary is straight from the release page.

Re:woohoo

[Anonymous Coward]

But I just came in here for an argument!

Hey!

[blackjackshellac]

Well that's nice, any braces for blocks yet? Just kidding.

BTW, whatever happened to Ruby? It just seemed to have dropped off the map in the past 6 months or so.

Re:Hey!

[drewness]

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!

[Constantine XVI]

For the lazy (or those who don't have python installed at work):

>>> from __future__ import braces
  File "<stdin>", line 1
SyntaxError: not a chance

Re:Hey!

[metamatic]

I was wondering if Python 3000 would end the whitespace problem by (say) adding an "end" keyword like Ruby, but apparently not.

Given that Guido von Rossum allegedly said he now viewed the whitespace thing as a big mistake that has crippled Python adoption, it's a pity religion prevented it from being fixed in Py3K.

(So I'll stick with Ruby.)

Re:Hey!

[Anonymous Coward]

Work? What work?

Oh right ...

Re:Hey!

[Ragzouken]

What whitespace problem?

Re:Hey!

[caldodge]

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:Hey!

[Daishiman]

If you dislike whitespace, don't use Python. Whitespace is a design decision and most python users consider it wonderful. Go away.

Re:Hey!

[Abreu]

Mandatory whitespace in python is not a bug, its a feature!

Re:Hey!

[Anonymous Coward]

I think the Algol-alikes need to do something about their semicolon problem.

Re:Hey!

[MikeBabcock]

Whitespace makes code readable. Forcing people to use whitespace intelligently is good. Feel free to read obfuscated PERL if you don't like it.

Re:Hey!

[glenstar]

Absolutely! And it applied to EVERY language. I am currently working with a codebase that is full of things like:

if($x){
if($p) do_something();
if($o){
foreach($a as $_a){
if ($_a) print $_a;
}
}
}elseif ($y){
do_something_else();
}else{
do_something_even_elser();
}

Worse:

if ($x)do_something();

Worst of all:

if ($x){?>hello<?}else{?>goodbye<?}?>

It makes me want to kill myself... hundreds of times a day.

Don't even get me started on randomly spitting out HTML from PHP... it makes me so mad I can't even see straight!

Re:Hey!

[Nevyn]

You're right, all code should look equal good ... then it's much harder to tell if a moron wrote it, or someone with some taste.

Besides it's much more fun to have your program crash because someone accidentally got the indentation for a doc string wrong.

Re:Hey!

[WolverineOfLove]

I know this is an unpopular sentiment on /., but I agree with you 100% on the HTML/PHP thing.

PHP is well and good, and can be well done. But let's face it, when random IT guy with no computer science background wrote your timecard site in hacked-together PHP, it's NASTY to even look at.

Which... is why I like the ASP.net separation of markup and logic. I always have, it just made more sense than putting them both into a blender and hitting "Puree."

Re:Hey!

[glenstar]

:-) It is popular to bash MS but I gotta say that .NET does nearly everything RIGHT when it comes to web applications. That being said, it's not like PHP forces developers to write shitty code. Using something like Smarty can help create clean PHP code where the view is entirely separated from the logic.

Re:Hey!

[MikeBabcock]

Yes, I've seen those too. Its nasty some days. Worse is people who do that with unbraced if-then's in C. Trying to figure out which result goes with with 'if' becomes a nightmare.

Ironically, somehow I got moderated a troll for the comment in question though :-)

Re:That marks my end of use for Python

[neoform]

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").

Is it possible to do automatic code migration?

[jopet]

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?

Re:Is it possible to do automatic code migration?

[maxume]

There is. Search on 2to3 if you want to read about it.

Re:Is it possible to do automatic code migration?

[stuntpope]

Like http://docs.python.org/library/2to3.html, perhaps?

Re:Is it possible to do automatic code migration?

[explodymatt]

Yes, there are both the 2to3 and the 3to2 (now somewhat redundant) packages. 2to3 will convert (most) python 2 code to python 3, but there are some limits on its abilities. Large libraries tend not to work very well, especially anything involving other languages (ie. c) 3to2 was for developers going the other way, maintaining python 2 compatibility whilst writing 3.0 code.

Re:Is it possible to do automatic code migration?

[gzipped_tar]

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.

RTFA

[jopet]

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

from __future__ import braces

[slumberheart]

SyntaxError: maybe in 3.5

Re:from __future__ import braces

[gzipped_tar]

I read it as: there will never be a 3.5.

It used to be "not a chance"...

Re:from __future__ import braces

[nneonneo]

It still is. He's joking.

Re:from __future__ import braces

[Anonymous Coward]

Python 2.5.1 (r251:54863, Jan 17 2008, 19:35:17)
[GCC 4.0.1 (Apple Inc. build 5465)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> from __future__ import braces;
    File "", line 1
SyntaxError: not a chance

Re:from __future__ import braces

[idlemachine]

That's a lot more optimistic that in 2.x:

SyntaxError: not a chance

Re:Language fragmentation...

[maxume]

Instead, write everything in smug.

Yay, Unicode!

[shutdown -p now]

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:Yay, Unicode!

[rubycodez]

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:Yay, Unicode!

[LEMONedIScream]

My initial thinking leads me to believe that how would you know that "a" in encoding X is the same or different to "a" in encoding Y. You'd have to have a mapping of all encodings to a common encoding to know this sort of thing.

Just my 2 cents.

Re:Yay, Unicode!

[Anonymous Coward]

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?

Your first premise is false. For example, take this byte string : "\xC2\xC5\xC4\xD3\xC9\xC4\xC5". Hint: if you think this word does not appear in an English dictionary, it's you who has made a mistake, not me.

Bonus points if you can render it fully in HTML.

Re:Yay, Unicode!

[Anonymous Coward]

methods exist to examine what the encoding of a string is

These methods can merely intelligently guess, and they can easily go wrong. See this well-known example.

Re:Yay, Unicode!

[Abcd1234]

You'd have to have a mapping of all encodings to a common encoding to know this sort of thing.

If I understand Unicode correctly, the entire point is that Unicode provides a code point space, which defines all the possible characters available. The various encodings are then ways to represent those code points as a set of bytes. So if you're comparing a UTF-8 string to a UTF-16 string, you just decode both and compare the code points.

Right?

Re:Yay, Unicode!

[nneonneo]

Since when was ROT-128 a popular encoding?

Re:Yay, Unicode!

[nneonneo]

"Bush hid the facts" is the more popular version of this particular bug.

Re:Yay, Unicode!

[Tetsujin]

You'd have to have a mapping of all encodings to a common encoding to know this sort of thing.

If I understand Unicode correctly, the entire point is that Unicode provides a code point space, which defines all the possible characters available. The various encodings are then ways to represent those code points as a set of bytes. So if you're comparing a UTF-8 string to a UTF-16 string, you just decode both and compare the code points.

Right?

Well, the thing is, Unicode doesn't quite represent all possible characters. There are some different representations of (approximately) the same character in East Asian encodings, for instance, which map to the same character in Unicode... Or if you're processing Japanese text, the SHIFT-JIS encoding defines a range for katakana, and then another whole range for the same characters displayed at half width. Converting this to Unicode would preserve the meaning, but not the full character of the original source data...

This is why it's useful for a programming language to support different character encodings besides Unicode... And, of course, if you're going to give different strings different encodings, you need to keep information about what the encoding is in order to handle the string correctly...

Re:Yay, Unicode!

[Tetsujin]

methods exist to examine what the encoding of a string is

These methods can merely intelligently guess, and they can easily go wrong. See this well-known example.

You misunderstand.

In Ruby 1.8, a "string" stored just a sequence of bytes, generally used to represent text. The application was responsible for knowing what encoding a string was in and handling the contents appropriately.

In Ruby 1.9, the string object includes some extra data fields: one of these explicitly records the encoding of the string. Obviously, some piece of application code must be responsible for setting this field correctly - but once it's set, no one has to guess what the encoding of a string is.

The "method" rubycodez referred to is a "method" of the string class, called "encoding".

Obviously, to explicitly store the encoding for a string as part of the string object requires more storage space than just mandating that all strings will encode Unicode... But the result is that the string object is better suited to safely handling other character encodings that you might want to process natively (without cross-encoding) due to the sort of (usually minor) losses of information that can occur in such translations.

Re:Yay, Unicode!

[shutdown -p now]

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?

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 to some common encoding that is safe to process, because there may not be a common encoding (Ruby intends to support some Japanese encodings that do not have a well-defined Unicode mapping). You cannot even safely pass it on another library function, because it may not be able to handle a string in arbitrary encoding for the reasons mentioned above. In effect, it means that Ruby 2.0 are "arrays of characters", where a "character" is some opaque value from which no meaning can be derived in a general case.

Note that the above means that this Ruby code has a bug of sorts for 1.9.1+:

def foo(str)
  if str == "abc" # oops! who says str encoding is compatible with ASCII?
end

Cute, eh?

Re:Yay, Unicode!

[shutdown -p now]

If I understand Unicode correctly, the entire point is that Unicode provides a code point space, which defines all the possible characters available.

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 - basically, Unicode assigned a single codepoint for every Han glyph, whether it's used in Chinese, Japanese, or Korean. Japanese were particularly unhappy about it.

Re:Yay, Unicode!

[Anonymous Coward]

lol... I should have seen that one coming. It's actually ATASCII; the Atari system used the 8th bit as markup information (invert color), which is why I mentioned the "render in html" challenge.

But I chose this example because it translates to BEDLIDE in EBCDIC encoding; maybe I should have used that (substitute E2 for D3) as my example coding; but using plain EBCDIC could probably identified correctly by some algorithm. The point I was making that without additional information (for example, in which language) you cannot distinguish between encodings, especially Windows codepages.

Re:Yay, Unicode!

[hawk]

>Good to see it move to doing things the Right Way

They converted it to Fortran??? :)

hawk

Re:Yay, Unicode!

[Estanislao Mart�nez]

If I understand Unicode correctly, the entire point is that Unicode provides a code point space, which defines all the possible characters available. The various encodings are then ways to represent those code points as a set of bytes. So if you're comparing a UTF-8 string to a UTF-16 string, you just decode both and compare the code points.

Yes, if the encodings of all the strings have a precisely defined mapping into Unicode code points, then this is true. Abstractly, they're all just sequences of Unicode code points. However, there's no point in allowing different string objects to use different encodings in that case; you might as well use the Java/Python model, where all text strings are stored in some internal Unicode representation that's hidden from the clients, and encoding translation is done for byte I/O.

The issue with Ruby 2.0, however, is that their planned string type will support encodings that don't have a precise mapping to Unicode codepoints--and even harder, were defined to not have any such mapping. So basically, you can have two strings in separate encodings where what you describe does not hold.

Re:Yay, Unicode!

[spitzak]

I got flamed for this before, but I am very concerned about their use of UTF-16 in the string constants by default. But if anybody more informed can correct me, please tell me.

The problem is that I have an arbitrary byte string that *MIGHT* be UTF-8. I want to test if it is a particular Unicode string. I do this:

      if byte_string=="UTF-8 constant":

The above describes the actual sequence of bytes in my Python source file. Where I say "UTF-8 constant" I mean the Python source file has the correct sequence of bytes to encode some piece of Unicode in UTF-8.

In Python 2.0, the string constant is converted to a byte string without change. The UTF-8 will then compare exactly like I intended.

In Python 3.0, I am very unsure what happens. It appears the compiler will have converted the UTF-8 string constant into a Unicode string long before this statement is executed. So what happens? Here are the possibilities:

1. The statement is an error as the types don't match. Quite a few people claimed this in response to my previous posts. But I find it hard to believe this as it would break vast amounts of Python software and I don't see this mentioned in any of the porting guides.

2. The byte string is converted to Unicode before comparison. This will fail to do what I want if the current translation is not UTF-8. I am willing to set it to UTF-8 (though it would be great if Python defaulted to that!). But then there is the problem of what to do if the byte_string contains invalid UTF-8. It cannot be translated to Unicode. But I don't want an exception, I obviously intend this to return false in that case!

3. In this example the Unicode could be converted to a byte string before comparison, and it would work (provided I set the current translation to UTF-8). However this does not work for the much more common case of a function defined to take a "string" parameter, which would require #1 or #2 above.

It also appears to be impossible to make an unadorned string constant that contains an *invalid* UTF-8 encoding, since the translation is done at compile time, so no changes to the current encoding will help.

I also see serious difficulties with programs that use backslash escapes to insert UTF-8 into string constants. In Python 2.0 and in most other languages "\xC2\xA2" is a cent-sign (or at least the UTF-8 encoding of a cent sign). In Python 3.0 it is two Unicode characters, and does not compare equal to b"\xC2\xA2"!!!

Also the documentation claims that b"\u00A2" is invalid, but that makes it really difficult to make byte string constants containing arbitrary UTF-8 in a more readable way. It would be really nice if they fixed this.

I know a lot of people don't believe me, but I see nothing but grief from this decision. If you can actually state how the above work and/or why they are not a problem I would love to hear it.

Re:Yay, Unicode!

[Anonymous Coward]

Hurrah, Python finally takes one more long-overdue step towards the same level of maturity as Perl, which has done Unicode everywhere since 2002.

Now, when is Python going to get proper lexical scoping, like Perl's had since 1994?

Re:Yay, Unicode!

[shutdown -p now]

The statement is an error as the types don't match. Quite a few people claimed this in response to my previous posts.

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.

Now you can still have byte array literals if you want them, but they are opt-in via "b" prefix (much like Unicode strings were opt-in via "u" in 2.x). So:

if byte_string == b"UTF-8 constant":

works.

It also appears to be impossible to make an unadorned string constant that contains an *invalid* UTF-8 encoding, since the translation is done at compile time, so no changes to the current encoding will help.

Well, if it's invalid, it's no longer UTF-8, right? So not a valid Unicode string anyway - why would you want it to pretend to be one? You can still make a byte array like that (though of course it will fail if you then try to decode it as if it was UTF-8 - because it's not).

In Python 2.0 and in most other languages "\xC2\xA2" is a cent-sign

True for Python 2.0, false for "most other languages". It's not true for most post-Java mainstream and/or generally well-known languages (C#, VB, Haskell, R6RS - to name a few). So Python is simply standardizing on what's already widely accepted. Of course, it also makes most sense when you deal with Unicode strings - forget about bytes, work with codepoints. In-memory representation of the string shouldn't be your concern, anyway.

Also the documentation claims that b"\u00A2" is invalid, but that makes it really difficult to make byte string constants containing arbitrary UTF-8 in a more readable way.

Well, of course it's invalid - it's a byte array, not a string! And why do you think that it would have to be UTF-8 even if it was allowed? Why not UTF-16 or UCS4?

Of course, nothing stops you from using str.encode, e.g.: "\u00A2".encode("utf-8") - which is quite explicit about what's going on, and yet short enough at the same time. By the way, if you omit the argument to encode, it will just use the default system encoding for non-wide-chars, which is usually precisely what you want on Unix.

Re:Yay, Unicode!

[Haeleth]

Unicode doesn't quite represent all possible characters. There are some different representations of (approximately) the same character in East Asian encodings, for instance, which map to the same character in Unicode...

No they don't, unless you want them to. Unicode provides the CJK Compatibility Ideographs (U+F900-U+FAFF), which contain duplicate copies of various characters, specifically to ensure that it is always possible to do a perfect round-trip mapping from any East Asian encoding, to Unicode, and back again, without losing any information.

Or if you're processing Japanese text, the SHIFT-JIS encoding defines a range for katakana, and then another whole range for the same characters displayed at half width. Converting this to Unicode would preserve the meaning, but not the full character of the original source data...

No it wouldn't, unless you wanted it to. Unicode provides the Halfwidth and Fullwidth Forms (U+FF00-U+FFEF), which includes a full set of hankaku katakana, specifically to ensure that it is always possible to convert from Shift-JIS to Unicode and back again without losing any information.

That's why it's possible for a programming language to use Unicode throughout as its internal string representation, and only convert to and from other encodings when doing I/O. This makes life much simpler. There is no technical reason not to do it; the only excuses people ever make are based on politics (effectively, "why should the English letter 'A' use the same codepoint as the letter 'A' used in French?") or ignorance.

Re:Yay, Unicode!

[shutdown -p now]

Now, when is Python going to get proper lexical scoping, like Perl's had since 1994?

It had always been there. If you mean the fact that it was previously not possible to access variable from outer non-global scope, then it is fixed in 3.0 with the new "nonlocal" statement.

Re:Yay, Unicode!

[shutdown -p now]

For more details on why things are what they are in new Ruby, and what can go wrong, read this thread. For those who might be unfamiliar with the names - Yukihiro "Matz" Matsumoto is the Ruby mastermind, and another well-known person there is Tim Bray, these days mostly known as the editor of W3C XML spec, and the author of the very first XML parser.

Re:Yay, Unicode!

[spitzak]

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 problem in that their code will no longer compile. I can't see this being any good.

Checking the web pages, I am certainly not alone in this worry. A more popular solution however seems to be to stop throwing errors. The conversion to Unicode would instead translate invalid bytes to U+DCxx (ie unpaired UTF-16 lower-half surrogates). This would avoid the exceptions and also make the translation lossless. I have examined this before and it has a big problem in that the translation of (possibly invalid) UTF-16 to UTF-8 is no longer lossless (imagine the UTF-16 had a sequence of these invalid symbols that actually match a valid UTF-8 encoding), which might lead to bad security holes.

if it's invalid, it's no longer UTF-8, right?

You are parroting the same crap used by people who don't like UTF-8 and try to make it more difficult than it really is. It is indeed UTF-8, just because it has errors in it does not make it not be UTF-8, anymore than a misspelled word makes this post not be English.

It's not true for most post-Java mainstream and/or generally well-known languages

You seem to have forgotten languages called "C" and "C++". I heard they were pretty popular...

I think you might also check exactly what some of those languages do, you can't put more than \xff into most of them so they are actually doing exactly what I am saying, except they are assuming ISO-8859-1 as the encoding. If the encoding can be changed to UTF-8 then it would work exactly like I am stating. (if values greater than 0xff are accepted they could ignore the encoding and you would remain compatible).

What you are saying is that there is no difference between \x and \u, which seems pretty stupid to me.

The main reason I want this is so that a string constant can be changed between bytes and unicode by just changing the 'b' to a 'u'. This is also why I want \uXXXX to work in byte strings.

On b"\u00A2": Well, of course it's invalid - it's a byte array, not a string! And why do you think that it would have to be UTF-8 even if it was allowed? Why not UTF-16 or UCS4?

The compiler is already assuming UTF-8 when it parses u"abÂ" so I see no reason it can't assume UTF-8 here as well.

Re:Yay, Unicode!

[Anonymous Coward]

Unfortunately, they just abandoned some critical byte-string interfaces, which makes it impossible to write non-"toy" programs in Python 3.0. E.g. there's no way to get the original argv[], which is a pretty fundamental omission. So Python 3.0 on Unix is entirely unsuitable for writing system utilities, particularly for systems where multiple locales are in use.

Re:Yay, Unicode!

[Anonymous Coward]

> it is always possible to do a perfect round-trip mapping from any East Asian encoding, to Unicode, and back again, without losing any information

This isn't true. It's possible to do a perfect round-trip for any *character set*, but not *encoding*. In particular, you can't round-trip ISO-2022 without the risk of losing information. If the data really is text, it doesn't matter, but if anything is interested in the actual byte string, you lose.

Re:Yay, Unicode!

[shutdown -p now]

Unfortunately, they just abandoned some critical byte-string interfaces, which makes it impossible to write non-"toy" programs in Python 3.0. E.g. there's no way to get the original argv[], which is a pretty fundamental omission.

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?

Re:Yay, Unicode!

[shutdown -p now]

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 problem in that their code will no longer compile. I can't see this being any good.

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.

You are parroting the same crap used by people who don't like UTF-8 and try to make it more difficult than it really is. It is indeed UTF-8, just because it has errors in it does not make it not be UTF-8, anymore than a misspelled word makes this post not be English.

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?

You seem to have forgotten languages called "C" and "C++". I heard they were pretty popular...

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.

I think you might also check exactly what some of those languages do, you can't put more than \xff into most of them so they are actually doing exactly what I am saying

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.

What you are saying is that there is no difference between \x and \u, which seems pretty stupid to me.

Yet that's how it is. Do you want quotes from the respective language specifications?

The compiler is already assuming UTF-8 when it parses u"abÂ" so I see no reason it can't assume UTF-8 here as well.

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:Yay, Unicode!

[spitzak]

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 at a very low level. That is wrong and is the main reason why there is so much confusion about UTF-8. Nobody seems to care that UTF-16 can have illegal sequences (Python handles them without complaint) and nobody cared for 10 years that the Japanese encodings could have illegal sequences. But for some reason UTF-8 brings out this complaint over and over again. I suspect the problem is that people have invested too much effort in UTF-16 and don't want to admit they made a huge mistake, and the only way is to try to make UTF-8 hard.

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.

Well of course. Therefore THAT function should throw the damn exception! Not every single string manipulation!!!!

Also you amazingly did the same bogus example of "move by 10 characters" I have seen before. Please look at real software and you will see that NOBODY EVER MOVES BY "10 CHARACTERS". 1 maybe. Otherwise the only use EVER of such code is because "10 characters" was previously calculated by another function looking at the EXACT SAME STRING and therefore a byte offset or UTF-16 word offset or whatever will work just as well.

L"\xC2\xA2" is not a cent sign in either C or C++. It's a wide (string with two characters.

It is byte values converted using ISO-8859-1 encoding. What I want is the ability to change that encoding.

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.

That is wrong, because it would not be possible to create a byte string containing an invalid UTF-8 sequence. This would break any software that has a string constant with ISO-8859-1 encoding in it (the programmer will still need to put a 'b' in front of it, but that is a lot easier and readable than going and replacing all the foreign letters with \x sequences).

In any case I don't see any reason why the Lexer should assume a different locale than the parser. That would be pretty confusing.

Re:Yay, Unicode!

[rubycodez]

Unicode is sloppy for many asian languages (Japanese), done poorly or standard rammed through by non-native speakers over objections of experts (for example, Khmer)

so yes, Ruby will support better representations than the shitty Unicode crap for languages that have superior representations available.

Re:Yay, Unicode!

[rubycodez]

but your example is the "sloppy coding" I mentioned, you didn't check the encoding of the string before you just went off and dicked with it.

and the reason for Ruby having support for string data other than Unicode is that for many asian languages, Unicode is ass, committees of native speakers were ignored while a bunch of pasty white honkies crammed their limited knowledge and incorrect world-view down everyone's throats. Quite a few asian countries with pissed off standards committees over this

Re:Yay, Unicode!

[shutdown -p now]

but your example is the "sloppy coding" I mentioned, you didn't check the encoding of the string before you just went off and dicked with it.

So, you admit that in Ruby 2, I'll have to check encoding for every input string, even for the most trivial string operations such as string comparison - something that I don't have to do in any other language to date. Good.

Okay, so I've checked the encoding of the string. Now what? At best, I have some encoding object that can be absolutely anything. I can ask for its name - some string that may be absolutely meaningless to me (I can't expect to know all possible encodings, especially when it can be one that didn't even exist when I wrote the code). I can check it for compatibility with my own string; but if I get a negative reply, then what am I supposed to do? Just throw an exception? Then every client of my function is now in the same situation that I myself was as a client of operator ==. What's worse, I had effectively exposed an implementation detail - the fact that my function performs a string comparison with some internal value.

and the reason for Ruby having support for string data other than Unicode is that for many asian languages, Unicode is ass, committees of native speakers were ignored while a bunch of pasty white honkies crammed their limited knowledge and incorrect world-view down everyone's throats. Quite a few asian countries with pissed off standards committees over this

Thank you for perpetrating this myth. In fact, CJK unification was done by the Unicode committee in which all those Asian countries (and particularly the Japanese, who now whine the loudest) had representation, and the final proposal that ended up in the standard was approved by their representatives. To day, I mainly hear two reasons for the whining: first, apparently, Japanese had long used the difference between Chinese and Japanese characters with the same glyphs in email to emphasize text (which is fucked up in and of itself, and no surprise that the Unicode consortium didn't even bother to treat this - if you need extra markup, use a markup language, not dirty encoding tricks!). Second, some scholars working with ancient texts actually have the genuine need to distinguish those characters - which is fine, but it is not a problem specific to Japanese, as many other ancient forms of modern languages still lack representation of some characters in Unicode. However, this is a very specific and small niche, and those people can use specialized tools (including software libraries) and encodings to do their job now - just as they do in many other countries, including my own - while Unicode remains a working and useful tool for the vast majority of day-to-day needs.

Of course, if the Ruby community wants the language to become a specialized tool for Japanese philologysts, then it's their right. But that won't help the adoption of Ruby as a mainstream language - not when it makes simple and common things much harder than they need to be for virtually everyone out there save for a few people, and harder than they are in any competing language/platform.

Re:That marks my end of use for Python

[lahvak]

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:That marks my end of use for Python

[Pope Raymond Lama]

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.

backwards not needed

[BountyX]

multiple versions of python can live happily together and will be seperatly maintained, no worries about backwards compatibility. sorry for typos ;)

Re:That marks my end of use for Python

[shutdown -p now]

It's also cleanup of some stupid syntax that was there for ages. For example, exception handling. Old style:

try:
...
except (TypeError, ValueError): # catch both types of exceptions
...
except os.error, e: # catch exception and store into variable 'e'
...

New style:

try:
...
except (TypeError, ValueError): # catch both types of exceptions
...
except os.error as e: # catch exception and store into variable 'e'
...

It's fairly obvious that the latter is much clearer.

I'll still avoid it

[doti]

As they didn't fixed the stupid forced-indentation thing.

Re:I'll still avoid it

[upside]

Ah. Yes. That one. Once I got over it I dropped Perl almost completely. Perl was my big love, once.

Re:I'll still avoid it

[m50d]

That's OK. We don't want the kind of programmers who let a superficial difference like that put them off actually trying a language.

Re:I'll still avoid it

[Anonymous Coward]

Forcing you to do what you should be doing anyway. Ill avoid working with you.

Re:I'll still avoid it

[Anonymous Coward]

It does make it a pain in the ass to play around and test with because often cut-n-paste (from random sources) completely fucks up the indention which you then have to fix. Which is even harder when you don't know the language well.

Between Python's extremely verbose syntax (not very script-friendly-like), syntactically significant indention, and relatively poor performance... well... meh

Re:I'll still avoid it

[m50d]

It does make it a pain in the ass to play around and test with because often cut-n-paste (from random sources) completely fucks up the indention which you then have to fix.

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 the ease of remembering wtf to write. Compare it with Ruby or, *struggles to think of another scripting language* TCL, say, and the verbosity is pretty similar.

and relatively poor performance...

Really? It's not going to win races against C, but performance is very much on a par with say Perl (which yes, has a lot of improvements coming in v6, but that's not here yet), and ahead of other similar languages. Couple with the fact that it's easier to bind from python than any of the alternatives, and you end up with code that in practice is as fast as you could write anywhere (because you use e.g. NumPy, which just binds to the fastest libraries available for doing what it does).

Of course python does sacrifice some things - but the ease of code writing and most of all maintainability are well worth it in most cases, in my experience.

Re:I'll still avoid it

[MightyYar]

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:I'll still avoid it

[Kent Recal]

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

[totally bogus dude]

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:I'll still avoid it

[horza]

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:I'll still avoid it

[stuntpope]

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

[Andy Dodd]

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:I'll still avoid it

[Anonymous Coward]

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>

Yeah, I totally avoid all languages which require any old-fashioned-1970s-crap like syntax. I just tell my computer to "make a really cool game with super graficz or I'll smack the shit out of you. Respect my authoritaa!". Way to go VB!

Re:I'll still avoid it

[Anonymous Coward]

Cut-n-paste is not a good way to learn.

Oh really? I often will take examples off of web-pages or whatever so I can hit the ground running as it were. This allows me to make small changes to see what effects they have will still having something that runs. Once I learn what I need I can then write my own version or cut out the pieces of that experimental code.

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 the ease of remembering wtf to write. Compare it with Ruby or, *struggles to think of another scripting language* TCL, say, and the verbosity is pretty similar.

The API reads like a C/C++ API. The Python API's have a similar looking interface as the lower level languages. For example, look at how you do regular expressions. Yeesh, it's nearly the same difficulty as coding in C against PCRE. Practically no scripting niceness at all. The other API's are similar. If you're just going to translate the C API into the "scripting" language then what's the point?

Really? It's not going to win races against C, but performance is very much on a par with say Perl (which yes, has a lot of improvements coming in v6, but that's not here yet), and ahead of other similar languages. Couple with the fact that it's easier to bind from python than any of the alternatives, and you end up with code that in practice is as fast as you could write anywhere (because you use e.g. NumPy, which just binds to the fastest libraries available for doing what it does).

Lua is faster and has arguably the best C binding API of any scripting language.

Re:I'll still avoid it

[cleatsupkeep]

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.

Re:I'll still avoid it

[maxume]

x=1; y=2; z=3; is valid python...

Re:I'll still avoid it

[Kent Recal]

Well, developers that can't even configure their editor properly are a no-go anyways, regardless of language.
If you tolerate that then Python is the least of your problems because you'll need a checkin-hook to sanitize the submitted files anyways. Otherwise you'd get broken/bloated diff's constantly...

Re:I'll still avoid it

[cleatsupkeep]

Well, the issue I had was that I was writing software that runs off a liveCD, and that is not a feasible development environment all the time, so I did some development in a normal development environment, and testing and bugfixes on the liveCD. This means that if I wanted to configure the editor, I would have had to do it on every bootup of the liveCD, which I didn't feel was feasible. However, I still very much enjoy developing with Python, it was just frustrating the first few times when I wrote code with a different text editor and saw quite a few compile errors.

Re:I'll still avoid it

[papna]

Hmm. All three of those work fine in Python. The meaning of x, y, and z would affect how I stored my variables, but I would probably use something like your first option (though I would probably add spaces around the operator). I would also use something like that in C and maybe even PHP. I would only use your most pythonic solution if x, y, and z should be thought of together in some way. If really wanted to save space, I would go with the top solution of x, y, and z don't relate in some way.

Shorter does not mean better. x,y,z = 1,2,3 does not make source code clearer, as you defend meaningful whitespace as doing.

Re:I'll still avoid it

[doti]

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

[Kent Recal]

Well, that's a fairly exotic scenario you're describing and imho it's *very* far fetched to blame your problems on python.
The real problem obviously was that you were too lazy to set up a proper developement environment (e.g. by virtualization or with a simple shell script to copy your editor config over to the running liveCD with a single keystroke).

Re:I'll still avoid it

[Abcd1234]

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:I'll still avoid it

[Abcd1234]

Have you considered using a decent editor which can fix the indentation for you?

Except that it can't. Python doesn't provide block end markers, and so it's impossible for the editor to know what lexical level a given piece of code belongs in. Worse, the programmer can't, either. Example:

if a > b:
a = a + 1

print(a)

So, tell me, what should the indentation be? 'course, this will all be solved if Python added just one more keyword: end.

Re:I'll still avoid it

[cleatsupkeep]

I don't feel like I was blaming it on Python, I was saying it was a design decision that I didn't agree with, but agreed, it is a far-fetched scenario.

Re:I'll still avoid it

[Anonymous Coward]

It doesn't trip up python--it's a violation of the syntax. If it's really a problem for you to have your editor configured correctly for your language, run indent when you save.

Re:I'll still avoid it

[Anonymous Coward]

Good Python style says don't mix tabs and spaces. Set your editor to substitute spaces for tabs. I've found that it even works for languages with braces.

Re:I'll still avoid it

[Anonymous Coward]

If I copy something like this

                        a = a + 1

                        print(a)

Then, when I paste, the two lines of code must end up on the same indentation level

if a > b: #old code
        a = a + 1

        print(a)

If, on the other hand, I copy something like this


                                a = a + 1

                        print(a)

Then, when I paste, the likes have to be at different indentation levels.

if a > b: #old code
        a = a + 1

print(a)

I can't think of a situation off the top of my head in which a sufficiently clever text editor cannot properly indent pasted code.

Re:I'll still avoid it

[AlexMax2742]

This is a non-issue in any editor which allows you to switch to a 4-space [Tab]. I can't think of a single editor or IDE that supports Python syntax highlighting and somehow doesn't support 4-space tabs.

Re:I'll still avoid it

[Abcd1234]

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_something_else

    last_thing

    one_other_thing

There is *no way the editor can handle this correctly*. It will always get it wrong somehow. After all, how can it know that the if block *and* last_thing should be indented so it's included in the while statement? Worse, when it gets it wrong, it'll change the semantics of the code. And *you won't know*, because the code will continue to parse correctly.

Of course, this is just one, somewhat contrived example. But I have, on numerous occasions, endured cases where refactoring has been made *much* harder thanks to Python's lack of a block termination marker. If you haven't encountered such cases, I would contend you've never had to maintain a non-trivial Python codebase.

Re:I'll still avoid it

[shutdown -p now]

Also, of course, CPython (what is downloadable from http://python.org/ is the reference Python implementation, but it isn't the only one, and it's certainly not the fastest one. There's Psyco, and then there are Jython and IronPython, which can both be pretty impressive performance-wise thanks to JIT.

Re:I'll still avoid it

[anothy]

ew.
tabs are tabs. spaces are spaces. confusing this has always been stupid.

Re:I'll still avoid it

[Alpha830RulZ]

I dropped Perl like a hot rock once I took up Python, and never felt that the forced indentation was anything but a highly desirable feature that eliminates an entire class of annoying compile bugs.

Re:I'll still avoid it

[Alpha830RulZ]

It's not going to win races against C, but performance is very much on a par with say Perl

I just did a performance test against Perl for a text file reformatting script I needed. This reformats one file into three other formats. I did a close to statement to statement translation, including the regexes. The python program ran in 60% of the time that the Perl program required on the same hardware. It's at least as fast as Perl, which is almost always fast enough for my needs.

Re:I'll still avoid it

[Alpha830RulZ]

May I suggest that you obtain either Notepad++ or Kdevelop? Both are free, and both handle the indentation problem neatly. NetBeans will do so as well.

I don't find the indentation corrections to be any different than fixing braces/indentation in Java. Python is different if you're used to leaving sloppy brace indentation around after a paste, but otherwise, it's the exact same issue.

Re:I'll still avoid it

[Anonymous Coward]

I think if you ran a poll on what's keeping people from using Python, this one would rank pretty high. I know it's my number one reason.

Shame, really. Then again, there's Perl, PHP, and Ruby, so no point in whining, I guess.

Re:I'll still avoid it

[cleatsupkeep]

Even with this, I still don't mind using Python. It was just a very special set of circumstances that made tabs an issue. I use RoR for web development, but when it comes to scripting languages, I still prefer Python for getting something working, its GTK bindings are pretty slick.

Re:I'll still avoid it

[totally bogus dude]

If you're the one doing the refactoring, then you'll know how far the indentation is wrong, and you can apply the correction. This should be a simple matter if you're using a reasonable editor. I think most IDEs have buttons you can press to increase or decrease the indentation of the selected block of text; with vim you can use < and > in visual select mode and then use . to repeat the action as needed. So no, I wouldn't think anyone should be even slightly inconvenienced by this when refactoring their own project's code.

Code copied from websites would also be properly indented, however it may not be the right indentation level for your project. The markers will all be there though so the editor should be able to get it right, and if not the programmer should.

At most, having to re-indent the code is a minor inconvenience; arguably a small price to pay for the visual clarity it enforces on all Python codebases. I don't particularly understand the hostility towards braces or other syntax to mark code blocks, but in practice it doesn't seem like a big enough issue to avoid using the language.

Re:I'll still avoid it

[Anonymous Coward]

This seems to trip up Python

And rightfully so! In C, messed up tabs and spaces only trip up the developer. That's bad.

Re:I'll still avoid it

[Anonymous Coward]

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.

Thank you. Thank you. Thank you. Thank you.

And yet, when you confront a Pythoneer about this sort of thing, they'll either tell you the programmer of the text editor is stupid, you should be using vi, or ASCII is broken (tab character shouldn't exist). Amusing, since one of the big tenants of Python is that code is readable when it is shared; apparently readability takes a backseat to portability in Python...

I want to learn Python; I really do. I just don't want to be treated like a kid equipped with water wings being taught how to drive. I mean, come on; there's no need to be so damn condescending in some of the tutorials, for Pete's sake.

Re:I'll still avoid it

[ggvaidya]

I'm curious: what sort of compile bugs?

Re:I'll still avoid it

[Abcd1234]

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 be even slightly inconvenienced by this when refactoring their own project's code.

Except, of course, I already have, so you're demonstrably wrong.

The markers will all be there though so the editor should be able to get it right, and if not the programmer should.

And those markers would be what? Oh, right... there aren't any, which was my original point. 'course, if the Python devs simply added an 'end' keyword, this entire conversation would be moot.

but in practice it doesn't seem like a big enough issue to avoid using the language.

Given the plethora of competing offerings, I humbly disagree. Why deal with Python's silliness when I could just use, say, Ruby instead? Or Perl (assuming you're not an undisciplined hack)?

Re:I'll still avoid it

[Abcd1234]

May I suggest that you obtain either Notepad++ or Kdevelop? Both are free, and both handle the indentation problem neatly.

They can't. The lack of an 'end' keyword makes automatic indentation impossible. Go read my other posts on the topic if you're curious why this might be the case.

Re:I'll still avoid it

[maxume]

They can't automatically indent the code to the proper depth, but they have keyboard shortcuts for indenting and dedenting entire blocks of code (often ctrl-[ and ctrl-]).

I understand what you are saying, that if there were explicit end markers, the code could be automatically indented to the proper level upon being pasted in, but the block handling mitigates the pain. So it isn't as convenient, but the additional mental burden over knowing where to put the code is not significant.

Re:I'll still avoid it

[Anonymous Coward]

Here in the real world, however, we *do* have to cut and paste blocks of code occasionally, and Python makes that annoyingly difficult.

... only if you are using Notepad for Python coding?

Re:I'll still avoid it

[__aavljf5849]

They did fix it. Now you can't mix tabs and spaces anymore. So it's fixed.

Re:I'll still avoid it

[__aavljf5849]

"There is *no way the editor can handle this correctly*. "

Funny. Mine does. You paste it in, select the code you pasted, type tab, and it indents it one level. Correctly.

Re:I'll still avoid it

[Alpha830RulZ]

Missing colons and braces.

Re:I'll still avoid it

[mgiuca]

So in another language, you'll settle for pasting code into your project, then just leaving it wrongly-indented?

I shudder to think about reading/maintaining your code.

I'm perfectly happy with you cutting+pasting code, but do me a favour and tidy it up so it's consistent with at least the containing FUNCTION block! Surely Python forcing you to do this can only mean good in the long run?

(I find going through pasted code to fix up its formatting is a good way to lightly check it over).

As I and many others have said: Python's syntax forces you to format your code to the bare minimum standard I would expect from any half-competent developer.

print function

[togofspookware]

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:print function

[gzipped_tar]

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

[maxume]

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:print function

[moranar]

You seem to want Perl. You can find it at http://www.perl.org/

Re:print function

[jonaskoelker]

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. ...

Re:print function

[Anonymous Coward]

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)).

The parse tree of "f x, y, z" is f(x y z) not ((f x) y z). That would seem to imply that commas bind more tightly than white space, so "f x, g y" should be (f x (g y)). Unless, of course, you want to argue that it's ((f (x y)) g).

Re:print function

[spitzak]

This might be clearer if you showed the equivalent Python syntax. I think you are saying it that "f x, g y" might either mean "(f(x),g(y))" or "f(x,g(y))". However I really can't see any reason for the first interpretation, it looks to me that it is unambiguoulsly the second one.

I do agree however there must be ambiguous statements, but they are more complex than this. One area is that two string constants seem to concatenate, this appears to be done by the tokenizer, not the parser?

Since the purpose is to provide back-compatability with the print statement, maybe only the first token is special. "f a,b,c" turns into "f(a,b,c)" but "a+f a,b,c" is a syntax error just like now.

Somebody else pointed out that the Python shell could do this without changing Python internals at all and most people would be happy.

Re:print function

[CarpetShark]

Why not make print a function, but then change the language to not require parentheses for any function call?

Good idea. While we're at it, let's remove all punctuation from the English language. Writing books is so hard with all those stops and commas and such.

Re:print function

[bnenning]

Why not make print a function, but then change the language to not require parentheses for any function call?

Then you get into syntax ambiguities; does "foo -1" subtract 1 from foo, or call foo with the argument -1? Sure, you can specify precedence rules, but one of Python's major selling points is simplicity and lack of special cases.

Re:print function

[togofspookware]

While we're at it, let's stop attacking people's ideas with straw man arguments.

Re:print function

[jonaskoelker]

However I really can't see any reason for the first interpretation, it looks to me that it is unambiguously the second one.

Maybe I overspoke. It's possible that one can write an unambiguous grammar that captures the rules one wants. But I think maybe it's going to be hard (or impossible) writing a LALR(1) grammar.

And there's an interesting third tree I missed: f(x, g)(y).

And "f x, g y, h z, i w, j v" is _really_ interesting. Is it "(f(x), g(y), ...)", or "f(x, g(y, h(...", or "f(x, g)(y, h)(z, i)(w, j)(v)", or ....

Somebody else pointed out that the Python shell could do this without changing Python internals at all and most people would be happy.

You'd have to maintain two different grammars, and you'd have to know that one is a subset of the other. I don't know about the python internals enough to predict how far out the different grammars would ripple.

Re:print function

[CarpetShark]

Got a claim to make? Then make it.

Re:Language fragmentation...

[Anonymous Coward]

Damned straight! I can't stand all those kids and their silly computer "languages". That's why I write only UNIVAC 1100 machine code. By writing for a dead platform, I know that I will NEVER have to waste time patching my work with updates.

Re:That marks my end of use for Python

[shutdown -p now]

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.

I don't know why this story's flagged "endofdays"

[Slartibartfast]

That'll be when Perl 6.0 ships.

Not all it's cracked up to be

[Gracenotes]

1. >>> import antigravity
2. Automagic xkcd in browser!
3. >>> print "Hello, world!"

4. File "", line 2
   print "Hello, world!"
   SyntaxError: invalid syntax

5. :(

Re:Not all it's cracked up to be

[maubp]

I know you may have been joking, but instead of this:

>>> print "Hello, world!"

for Python 3.0+ you must do this:

>>> print("Hello, world!")

It makes sense in the long run. Anyway, see the very start of the "What's New" page, "Print Is A Function":
http://docs.python.org/dev/3.0/whatsnew/3.0.html

Re:Not all it's cracked up to be

[tristanreid]

Pretty sure the parent was joking, fwiw.
The comic itself refers to the simplified syntax of
print "Hello, world!"
as a primary example of python's superiority. Lot's of irony!

-t.

Re:Not all it's cracked up to be

[eabrek]

Haha! Now Tcl wins the challenge:
puts "Hello, world!"

Re:I don't know why this story's flagged "endofday

[Anonymous Coward]

AFAIK Perl 6.0 is already there, in the form of Pugs (which is said to be compatible with all the specs), and it's just the implementation of Perl 6 in perl6 itself what people are waiting for. You can go and write actual Perl 6 code, and run it on Pugs, and it'll work.

Porting? Instantly!

[jonaskoelker]

I heard they're going to use Python 3.0 for the impending from-scratch rewrite of DNF.

Re:woohoo

[Hal_Porter]

No you didn't.

could someone at Apple fix the OS X Python mess?

[bball99]

please, please, please!

Re:That marks my end of use for Python

[moranar]

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:I don't know why this story's flagged "endofday

[jgtg32a]

Which will also be the point of singularity

Re:woohoo

[Chapter80]

GREAT!

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

[Chapter80]

oops I really screwed that joke up... crap. somebody fix it.. you know what I was trying to do!

Re:woohoo

[Chapter80]

Do over.... (shoulda installed Python 3 and tried it! oh well) I think this version might work a little better...

Dang, my FIRST slashdot mistake!

GREAT!

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!)

Changelog: added two minus signs. Is that better? Am I going too far with this?

ubuntu make fail

[rla3rd]

too bad it doesnt install from source out of the box, even with libgdbm-dev installed

make
running build
running build_ext

Failed to find the necessary bits to build these modules:
_dbm
To find the necessary bits, look in setup.py in detect_modules() for the module's name.

see bug here. Why they would announce a release that wouldn't build for a major distribution such as ubuntu baffles me.

Re:ubuntu make fail

[pm_rat_poison]

Real question is: "Why wouldn't they?"
Sure, they should build it, or teh ubuntu people should build it, but if it's ready in one format, why should it NOT be released? Besides, if you can build it, share your skills and contribute!

Re:ubuntu make fail

[Anonymous Coward]

Except it does build. I'm looking at a >>> prompt right now.

Re:ubuntu make fail

[gzipped_tar]

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.

Re:ubuntu make fail

[shutdown -p now]

It's up to Debian/Ubuntu to make sure that other packages build on their system (and, preferrably, package them natively). Do you seriously think that Python guys should painstakingly check for correct build on all, what is it these days, several hundred Linux distros (not to mention FreeBSD etc)?

duck updating

[snark23]

You're right that backward compatibility isn't broken hard, but it's going to be broken EVERYWHERE because they've changed the syntax for print and the semantics for list operations by moving everything to iterators.

Prints will be easy to fix, because the old style will cause syntax errors... but old-style code that assumes range() and zip() return lists will break at runtime. Bugs will turn up months after you thought you fixed some code because you forgot some corner-case that isn't called often.

(I'm not complaining - I agree with most of the changes in 3 - I'm just saying that updating code won't necessarily be trivial)

Re:I don't know why this story's flagged "endofday

[Abreu]

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

[Anonymous Coward]

what's amazing is that he seemed to have sobered up in less than 3 sentences. he has one hell of a metabolism.

Re:woohoo

[Random BedHead Ed]

I think you should use a few more posts to explain the joke. The more you go on the funnier it gets. :)

Re:That marks my end of use for Python

[Random BedHead Ed]

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:woohoo

[ragefan]

An argument isn't just contradiction!

Re:woohoo

[ValuJet]

Yes it is.

Re:woohoo

[revery]

keyword or positional?

Re:I don't know why this story's flagged "endofday

[Abcd1234]

And Rakudo, aka Perl6 on Parrot, is coming along quite nicely, as well.

Readline support for intel mac?

[danceswithtrees]

I was able to install python3.0 but as usual, there is no readline support.

Has anyone been successful in getting readline to work with python3.0?

Re:Readline support for intel mac?

[mzs]

Yeah I don't have readline support either, pyconfig.h shows that configure found it all, so I don't get it.

Re:woohoo

[Anonymous Coward]

I told you once.

Re:That marks my end of use for Python

[tristanreid]

It's a similar decision to "should I change lanes because that other one is going faster". See the intro to 'Office Space' for the inevitable result.

In other words: if you want to minimize your exposure to backwards-incompatibility, shouldn't you just stay in the language that just got it out of the way? Of course, my logical flaw is the assumption that language migrations of this sort are uniformly distributed, in reality it's probably a function of the languages' owners.

-t.

Re:That marks my end of use for Python

[An ominous Cow art]

> thoguth migration paths

Sounds like a good basis for a "Call of Cthulhu" adventure.

Re:I don't know why this story's flagged "endofday

[Anonymous Coward]

Perl 6 will be released (soon?)

Re:I don't know why this story's flagged "endofday

[omuls are tasty]

Wish I had mod points. Thank you for a good laugh, sir.

Function invocation with no parens

[Tetsujin]

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.

There's a specific problem there with Python - which is that not requiring parenthesis on a function call (but allowing them) creates an ambiguity... Is "f (x, y)" a one-argument function call (tuple of x and y) or two? This is in addition to the usual ambiguities involving nested calls and the general disparity between that form and the syntax that governs the rest of the language.

Still, Ruby does OK with that strategy, right?

My impression of Ruby so far (not having done much with it) is that it's a little more Perl-like in its treatment of syntax. Syntax isn't always consistent (for instance, some kinds of invocations will automatically "splat" an array, others won't) - it's more heuristically determined in some cases. Generally I find that a bit distasteful - though on the other hand, if it truly is a successful approach (including in terms of long-term maintenance of the parser, etc.) I want to learn more about it.

Re:Function invocation with no parens

[togofspookware]

My favorite way to deal with the issue you mentioned with the ambiguity of f (g x, y) was is to base the decision by looking at whitespace. f( g x, y ) is calling f with 2 arguments, while f (g x, y) is calling it with one. This could have something to do with that's how I happen to think about argument lists, anyway, so other people might not agree with that convention. :) Ruby actually treats the 2 expressions the same (both are passing 2 arguments to f), but issues a warning when you use the latter syntax. In Python's case (since f (x, y) is not valid Ruby syntax), f (x, y) could call f with a tuple, while f( x, y ) would call it with 2 arguments.

A simple way to deal with f x, g y, h z would be for the parser to always try to read as much as it can of the current parameter list. So this expression would be parsed as (f x (g y (h z))). You shouldn't write code like that, but I think you can define the rules of the language in a simple way so that at least it is not ambiguous.

All that said, Ruby doesn't handle things quite as I expect.

Re:Function invocation with no parens

[Tetsujin]

My favorite way to deal with the issue you mentioned with the ambiguity of f (g x, y) was is to base the decision by looking at whitespace. f( g x, y ) is calling f with 2 arguments, while f (g x, y) is calling it with one. This could have something to do with that's how I happen to think about argument lists, anyway, so other people might not agree with that convention. :) Ruby actually treats the 2 expressions the same (both are passing 2 arguments to f), but issues a warning when you use the latter syntax. In Python's case (since f (x, y) is not valid Ruby syntax), f (x, y) could call f with a tuple, while f( x, y ) would call it with 2 arguments.

I've been working on a design where I face similar issues - in that it'd be totally unnatural in the basic language design to have parens for an invocation (It's Unix shell-based)...

I have a real problem with the language being whitespace-sensitive in the way you describe... In my design, to a certain extent it can't be avoided - it just seems like making the language do two totally different things depending on a slight difference in whitespace is asking for trouble...

A simple way to deal with f x, g y, h z would be for the parser to always try to read as much as it can of the current parameter list. So this expression would be parsed as (f x (g y (h z))). You shouldn't write code like that, but I think you can define the rules of the language in a simple way so that at least it is not ambiguous.

All that said, Ruby doesn't handle things quite as I expect.

But (assuming Python tuples are in play), this expression...

(f x, g y, h z)

could be a three-member tuple (f(x), g(y), h(z))
or a call to f with three arguments (f(x, g(y), h(z))
or (as you described) a call to f with one argument (f(x, (g(y, h(z))))

It's possible to define a rule that disambiguates the invocation, but it seems like going that far would create a language that looks ambiguous - which is nearly as bad as a language that is ambiguous.

Python 3000! Halting State, anyone?

[tachyonflow]

Man, all this time I thought "Python 3000" was just a fictional, futuristic-sounding version of Python that Charles Stross made up for his book Halting State. In Stross's world set in 2018, Python 3000 is one of the dominant languages used for distributed peer-to-peer networks running on cellphone nodes. (FWIW, I blogged about this briefly here.)

Re:Porting? Instantly!

[shutdown -p now]

Yes, for the prototyping stage. The actual game is going to be written in Perl 6.

Re:argghhh

[Dan Ost]

I expect the transition to run so smoothly that in 5 years, nobody will care that it happened at all.

Re:woohoo

[Chapter80]

OK. well, what I was aiming for was:

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:That marks my end of use for Python

[Anonymous Coward]

No, he's typing while Brazilian.

Re:woohoo

[eabrek]

Int math:
(-2+1)/2 = -1/2 = -1
(-3+1)/2 = -2/2 = -1

Re:That marks my end of use for Python

[Anonymous Coward]

those changes were mostly to fix poor coding practices like being able to run certain functions without braces (e.g print "hi").

Minor quibble: print wasn't a function, it was a statement. That is, it was on the same level as if/then, while, import, etc.

The thought is, though, that print is nowhere near as "central" to the language as if/while/import, and its functionality could just as well be handled with a function. - Which is what they did with 3.0

Here you go

[tehdaemon]

print (x)

Re:I don't know why this story's flagged "endofday

[Jeremi]

Python 3000 is released - December 4, 2008

991 years ahead of schedule, no less. Take that, Microsoft!

Re:could someone at Apple fix the OS X Python mess

[kyrre]

What is messy about Python in OS X?

I still won't take Python seriously...

[odysseus_complex]

..until Guido finally figures out the correct use of whitespace.

Re:I still won't take Python seriously...

[Anonymous Coward]

I'm glad you brought that up, I can't believe that there is not a single other post or discussion thread here regarding whitespace in Python. I've always wondered why, whenever there's a story about Python on Slashdot or Ars or wherever, there's never, ever, ever even one single comment about how Python deals with whitespace. But you, sir, have broken the seal! Bravo.

Re:I don't know why this story's flagged "endofday

[jonadab]

I heard that Perl 6 is scheduled to be released in time for Christmas :-)

Besides, the _real_ end of days will be when Perl and Python and Ruby and Emacs are finally included in out-of-the-box Microsoft Windows installs.

UTF other than 8 is bloat to us

[tepples]

Reworked Unicode support is a big deal.

The servers that run our in-memory database handle UTF-8 data that consists overwhelmingly of code points below U+0080. But if Unicode in Python is anything like Unicode in Java (that is, UTF-16), we may have to double the RAM in our servers. In fact, if it's compiled as UTF-32, we may have to triple the RAM.

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.

But is it standardized on UTF-8, UTF-16, or UTF-32? These are all encodings of Unicode code points.

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

I don't see how it would lead to disaster. When comparing differently encoded strings, convert them both to Unicode (either UTF-8 or UTF-16) and then compare them.

Re:UTF other than 8 is bloat to us

[maxume]

The default compile is UCS2 (which, I think, is pretty much UTF-16). UCS4 is an option.

If the edges of your system are pretty well defined, it seems like you might be able to get away with storing your text as encoded byte strings (which is essentially what you are doing if you are using 2.x, the words used to describe that way of doing things are changing, and it isn't the 'default' anymore, but it isn't going away either).

Re:UTF other than 8 is bloat to us

[shutdown -p now]

The servers that run our in-memory database handle UTF-8 data that consists overwhelmingly of code points below U+0080. But if Unicode in Python is anything like Unicode in Java (that is, UTF-16), we may have to double the RAM in our servers. In fact, if it's compiled as UTF-32, we may have to triple the RAM.

Unicode is not new in Python, it had been there for ages. They have simply changed the way string literals are treated, and removed the magic conversion rules between byte strings and Unicode strings. So if you're using Python on your server today, and if you're using Unicode strings, then you won't see any memory difference.

But is it standardized on UTF-8, UTF-16, or UTF-32? These are all encodings of Unicode code points.

They're standardized on Unicode - that is, a Python string is a sequence of Unicode codepoints. The actual representation is an implementation detail, and is not part of the language specification. I do not know what the representation is in Python 3.0, but assuming it is the same as 2.x, it's UTF-16, with the ability to use UTF-32 on Unix by recompiling.

I don't see how it would lead to disaster. When comparing differently encoded strings, convert them both to Unicode (either UTF-8 or UTF-16) and then compare them.

The whole reason behind having this scheme is that there are some encodings that are not convertible to Unicode (they have characters which aren't in Unicode) - such as some national Japanese and Chinese encodings. So there isn't any common encoding that could be used for that purpose. Read the mailing list thread I've linked to in another reply here for details.

Re:UTF other than 8 is bloat to us

[tepples]

So if you're using Python on your server today, and if you're using Unicode strings, then you won't see any memory difference.

Right now, we're using Python 2's str type (which becomes bytes in Python 3) and assuming UTF-8 encoding. Another issue that complicates migration is that our software uses the csv module to interact with file formats used by other software on our system and software used by our suppliers, but "Note: This version of the csv module doesn't support Unicode input."

They're standardized on Unicode - that is, a Python string is a sequence of Unicode codepoints. The actual representation is an implementation detail

So whether the program runs smoothly or unacceptably slows down other services on the same machine by hammering swap is an implementation detail. Some people can live with that.

But Google still hasn't shown me how to have Python 2 and Python 3 installed side-by-side on a Windows server, to the point where I can double-click .py files and have the correct interpreter run. It's not like *n?x, where the #! file determines which interpreter runs; Windows uses the file name suffix exclusively.

Re:UTF other than 8 is bloat to us

[shutdown -p now]

Right now, we're using Python 2's str type (which becomes bytes in Python 3) and assuming UTF-8 encoding.

As I understand, you can keep doing so if you want in Py3, you'll just have to decorate all your literals with "b" prefix (and make sure that you don't call functions that return Unicode strings).

So whether the program runs smoothly or unacceptably slows down other services on the same machine by hammering swap is an implementation detail.

Well, few people write Python applications that store hundreds of megabytes of strings in-memory.

Of course, using UTF-8 is no panacea, either - what if, tomorrow, your database gets a few thousand hundred records with strings of Chinese or Japanese characters added? In fact, it could be an interesting concept for a DoS attack :)

But Google still hasn't shown me how to have Python 2 and Python 3 installed side-by-side on a Windows server, to the point where I can double-click .py files and have the correct interpreter run. It's not like *n?x, where the #! file determines which interpreter runs; Windows uses the file name suffix exclusively.

Yup, that is correct. The best you can do is name your Python 3000 files differently (e.g. ".py3"), and associate that.

Re:UTF other than 8 is bloat to us

[tepples]

what if, tomorrow, your database gets a few thousand hundred records with strings of Chinese or Japanese characters added?

We do next to no business in China, Japan, or Korea because overseas shipping is so expensive.

The best you can do [for side-by-side Python 2 and Python 3 in a Windows environment] is name your Python 3000 files differently (e.g. ".py3"), and associate that.

That won't work so well. Python already relies on file name suffixes being .py.

Re:UTF other than 8 is bloat to us

[shutdown -p now]

We do next to no business in China, Japan, or Korea because overseas shipping is so expensive.

I understand why you stick to UTF-8, then :)

Well, I still think you can't blame the Python guys for moving in the same direction as most anyone else. For fully Unicode-enabled languages, either UTF-16 or UCS4 has been the de facto standard for in-memory string quite a while now; it just seems to work best for vast majority of users. For corner cases where memory load is important, well, byte arrays are still there, even if not quite as convenient.

That won't work so well. Python already relies on file name suffixes being .py.

That was an interesting read, thank you.

Re:UTF other than 8 is bloat to us

[maxume]

The ugly way to do it is to create a .py3 (or .py2) filetype and associate it with that interpreter.

That won't teach python to import modules with that extension (so things could get irritating if you have complicated imports or your paths are messy), but it will work for creating entry points to scripts.

Python 2 and 3 side-by-side in Windows?

[tepples]

multiple versions of python can live happily together

How do I install Python 2.x and Python 3.x on a single computer running Windows, and then have the shell automatically choose the right EXE when I double-click a .py file? Unlike Linux and *BSD, Windows doesn't look at the #! line when determining which interpreter to use; it looks only at part of the file name.

Re:woohoo

[nd]

True Part:
In Python version 2, 1/2 = 1 (integer math)

1/2 in Python 2.x is actually 0.

Re:woohoo

[The_Beige_Volvo]

OK. well, what I was aiming for was:

True Part: In Python version 2, 1/2 = 1 (integer math) In Python version 3, 1/2 =0.5 (floating point math)

Accidental comedy microcosm of the pitfalls of dynamic typing. However, if you declare a var as int or float then the dynamic typing is a lovely feature. Out of interest, why did they decide to calculate 1/2 as float in Python 3?

The next South Park episode

[Profane MuthaFucka]

I can see it now - they're going to have Guido van Rossum holding Python down and raping it.

SPOILER WARNING PLZ!

[toriver]

You ruined Python for me!

Re:woohoo

[teh moges]

I believe it was because its "expected behaviour". To me, it makes sense, as something like:
for i in range(0, x/2):
Will still work either way for both types (int or double), and the int conversion is easier to do later then the conversion back.

My first reaction is HATE!!!

[mangu]

I took a look at that page, and I became worried. Take the new string formatting, for instance. It's *much* easier to migrate existing software from C to Python using the old % format. The argument that % is a binary operator is stupid, that's what tuples are for.

Also, making the keys() method not return a list doesn't make sense. I often use mixed data sets, it's very convenient to be able to do somelist.append(x.keys()).

And so on, several of those changes will make it harder to do simple tasks without any advantage. Unfortunately, I can't say I'm enthusiastic about Py3k. Python was so good while it lasted....

Re:My first reaction is HATE!!!

[Capsaicin]

Take the new string formatting, for instance. It's *much* easier to migrate existing software from C to Python using the old % format.

Calm down. The new string formatting is an addition not a replacement. AFAIK printf style placeholders still work as they always have done, even though print is now a function. e.g.

from math import pi;print('%.3f' % pi) => 3.142

Re:My first reaction is HATE!!!

[Capsaicin]

Doh! Should have read the docs before posting. OK, % will be depricated in 3.1 and removed at some time in the future. So it is a replacement. Better start learning the new way.

Re:My first reaction is HATE!!!

[mangu]

Better start learning the new way.

What is quicker to write and easier to see at a glance:

'%.3f' % pi

or

'{0:.3f}'.format(pi)

I'm seriously thinking of creating an http://ihatepy3k.org/ site.... :(

Re:My first reaction is HATE!!!

[XNormal]

Also, making the keys() method not return a list doesn't make sense. I often use mixed data sets, it's very convenient to be able to do somelist.append(x.keys()).

This one will actually work just fine. The result of .keys() is iterable so you can pass it as an argument to append() with no problem. What you can't is do something like indexing the result of .keys() with the [] operator. Dictionaries are unordered so you should consider the result of .keys() as a set, not a list.

UTF-8b

[spitzak]

The scheme of turning errors into U+DCxx is called "UTF-8b"

As currently stated it has a big problem in that it destroys the current lossless conversion of UTF-16 to UTF-8. This would mean that a system using UTF-16 but translating to/from byte streams using UTF-8b could not safely operate a backend that uses UTF-16, though it can now operate a backend that uses UTF-8. This is somewhat counter-intuitive.

But I'm wondering if in fact a true bidirectional lossless scheme between UTF-8 and UTF-16 is possible. I'm trying to figure it out, but it makes my head hurt:

1. Invalid UTF-8 would convert each byte to U+DCxx.

2. The conversion from UTF-16 should undo U+DCxx to the matching bytes. But it has to look at the result and make sure it is *not* a valid UTF-8 encoding. If so then it should translate the first one as in CESU to 3 bytes.

3. The UTF-8/CESU encoding of U+DCxx normally should be considered invalid. But the UTF-8 decoder has to look at the following bytes and determine if the result would be something the encoder would turn into CESU according to rule 2 above.

That is as far as I can figure it out. Unfortunately my impression is that each rule requires the opposite direction to detect more cases. I cannot tell if there is a stable result that is practical to implement.

Re:That marks my end of use for Python

[Anonymous Coward]

No, he just sampled everything in the medicine cabinet... again

yes i love typing parenthesis over and over and ov

[Anonymous Coward]

nothing better to do with my time than type parenthesis over and over. thank god they removed that silly ability to print 'hello world'.

Re:woohoo

[Anonymous Coward]

Out of interest, why did they decide to calculate 1/2 as float in Python 3?

We got sick of explaining integer math to newbies on the python list each and every single day. So it was decided that if we used '//' for integer division and let '/' do what newbs expect we'd be saving ourselves muchos keystrokes in the long run.

print() bites again

[Capsaicin]

Do over.... (shoulda installed Python 3 and tried it! oh well) I think this version might work a little better...

You really should have. I haven't installed yet, but your code, even the corrected version, should raise a TypeError since print(arg) returns None.

Re:print() bites again

[Chapter80]

congrats, you passed the test. I was an epic fail. tried to post while working. bad mistake!

Re:print() bites again

[Capsaicin]

congrats, you passed the test

It was a test?! Do I get a prize, an onlineDiploma, or something? ;) Don't worry, I stuffed up with the next comment I posted on this story. %/

Your mistake did teach me one thing though, the dangers of forgetting those damn parens are not limited to raising a SyntaxError. A TypeError in that kind of context might be fairly confusing if it occured at the wrong time in the caffeine ingestion cycle.

Re:woohoo

[neoform]

Well, that was never an argument.

Re:woohoo

[Chapter80]

you're right.

Sorry, I was sober when I wrote that.

Re:woohoo

[fractoid]

I use that excuse a lot. Conversely, it's scary to code something while drunk then come back the next day and think "god, whoever wrote this is clever".

Re:woohoo

[Capsaicin]

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.

Why whitespace really is a problem

[walterbyrd]

>>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 of those cases.

I believe that even Guido has admitted the forced whitespace was a mistake.

Re:Why whitespace really is a problem

[Kent Recal]

Do you have a quote of Guido "admitting" that? Because all statements I have seen from him were the opposite.

Furthermore I can only repeat that all the problems you mentioned are non-issues if you just configure your editor properly.
My editor shows me the difference between a space and a tab and will happily convert spaces to tabs and back when asked to. If yours can't do that then maybe it's not a good choice for python editing? (at least when you have to deal with copy/paste a lot - which indicates bigger problems btw)

In my years of working with python I did indeed have the occassional snippet go through e-mails or pastebins - and I can't remember it being any more troublesome than with any other code.

And yes, when I started with python I was irritated by the mandatory indendation just like everybody else.
But I learned soon that this kind of enforced readability is a great advantage *especially* when working with others people code...

So what does that mean for recent newcomers?

[Anonymous Coward]

Disclaimer: dumb guy here.

I used to program a lot for fun, spending countless hours of my childhood in front of our *gasp* Apple //e. But lost that spark, the closest I ever came to programming for years was hand-coding basic HTML pages.

Having been largely on the end-user side computing for a long time I've been trying to get back into programming. After many failed attempts (got lots of books on the shelf I bought then never read past page 7,) I stumbled upon Snake Wrangling for Kids Admittedly it's rather elementary, but I've been enjoying it.

Now I read in the summary, "intentionally backwards-incompatible"? What exactly does that mean? What I learned was for naught? I imagine (hope) little that affects me since my instruction has been fairly basic, but it still put some worry in my mind.

Re:So what does that mean for recent newcomers?

[maxume]

It doesn't matter. First, the changes are manageable. Second, 2.x will likely be well supported for at least another 5 years, probably a decade or more.

Re:woohoo

[tifkap]

Yes, it was.

Perfect time to ditch the GIL

[try_anything]

There are three things that hold python back in scientific computing as far as I am aware and they are iteration, recursion and multithreading.

Finally somebody mentioned threading! I came in here specifically to find out whether 3.0 has any threading improvements. The Python FAQ has long said that they can't get rid of the global interpreter lock for two reasons: It might make Python twice as slow, and it would break all C extensions. If Python 3000 is going to break the C extensions anyway, this would be a perfect time to ditch the GIL. (I don't think anyone would object to making single-threaded Python twice as slow, except maybe web developers.)

I don't see any mention of it anywhere, though, so I'm not optimistic :-(

Re:That marks my end of use for Python

[Anonymous Coward]

I read the grandparent post and it looked fine.

I looked at your post and and it all luked rong.

Wht idd you doo!

import antigravity [misleading?]

[scrum_hp]

import antigravity is very cool but it's a darn shame that the print "Hello World!" example from the comic gives a syntax error. Sad.

Oh great.

[DaVince21]

Oh great. Just as I finished my first complete Python application. At least I made sure it's as compatible as possible with 3.0...

Anyway, 3.0 is great news! Can't wait to try it out.

any use for Zope?

[axxackall]

Zope is among the best Python applications (along with Twisted and others of course). How would Zope be better if re-written into Puthon-3.0?

Re:woohoo

[Anonymous Coward]

But but but...

xkcd will fail the 2to3 checker.

Re:woohoo

[mgiuca]

That's great and all (no seriously, I got a good chuckle out of it), but it would work even if they hadn't changed division, because (-3+1)//2 is also -1.

Re:I don't know why this story's flagged "endofday

[mgiuca]

Wait ... where's "profit!"?