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

Comment removed

[account_deleted]

Comment removed based on user account deletion

Release notes

[Max Romantschuk]

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

Also note that in the end of the release notes are info on the migration path from Python 2 to 3. I'll leave the rest to people who bother to RTFA... ;)

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

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

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.

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 [python.org]

Re:Is it possible to do automatic code migration?

[stuntpope]

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

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

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

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

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

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

[nd]

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

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

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