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

[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

[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

[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

[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

[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

[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

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

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

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

[Anonymous Coward]

But I just came in here for an argument!

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

from __future__ import braces

[slumberheart]

SyntaxError: maybe in 3.5

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: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:And now to wait

[morgan_greywolf]

Nope. Python 3.11 for Workgroups.

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

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

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

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

[Slartibartfast]

That'll be when Perl 6.0 ships.

Re:woohoo

[Hal_Porter]

No you didn't.

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

[ValuJet]

Yes it is.

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?