"Python 3.0 (a.k.a. "Python 3000" or "Py3k") is a new version of the language that is incompatible with the 2.x line of releases. The language is mostly the same, but many details, especially how built-in objects like dictionaries and strings work, have changed considerably, and a lot of deprecated features have finally been removed. Also, the standard library has been reorganized in a few prominent places."
I have never seen a release for a new language be so clear and straightforward. That's awesome.
The report gives a defining description of the programming language Scheme. Scheme is a statically scoped and properly tail-recursive dialect of the Lisp programming language invented by Guy Lewis Steele Jr. and Gerald Jay Sussman. It was designed to have an exceptionally clear and simple semantics and few different ways to form expressions. A wide variety of programming paradigms, including functional, imperative, and message passing styles, find convenient expression in Scheme.
So much cleaner and more consistent. Classic classes are gone for good!
Unlike with other languages (which I won't name for fear of offense!) I think Pythonistas will actually migrate to this much improved Python (well, forgetting the 10% performance hit) especially as such focus has been put into making tools to make it easier, unlike with PHP 4->5 (oops..!)
Sorry, no. I do most of my work in Python and would love to see quick Py3k adoption. But 2.3 was released 29-Jul-2003 and is still the baseline for portable code. Pythonistas are just as much a victim to the forces against migration as PHP and "other language" coders.
Just for kicks, try getting a stable webapp stack running on 2.6. I'm still not near ready to put that into production (and I run tiny, tiny websites).
The Python LDAP and psycopg2 libraries are my biggest culprits.
My point is not that it's impossible to run 2.6; but setting it up requires a level of sophistication with Python/*nix that I can't put on the shoulders of my organization, yet.
If I were working with a couple of smart hackers, this would be a non-issue. But my feeling is my organization is like a lot of others, where anything that's not a tagged, stable "sudo apt-get install" away is not going to fly.
Ahh, yeah it does require a good bit of familiarity with both python and *nix environments.
I'm a lone guy, managing my own servers, with complete control over their environments. That's quite a bit different than a business environment, corporate or not.
The latest draft of Linux Standard Base appears to specify Python 2.4. I wish we could rely on everyone having ctypes and ElementTree in the standard library, but no luck.
(I think web.py 0.3 and possibly the trunk of Django can handle Py2.6, but obviously they're not going to drop support for older versions any time soon.)
The net result of the 3.0 generalizations is that Python 3.0 runs the pystone benchmark around 10% slower than Python 2.5. Most likely the biggest cause is the removal of special-casing for small integers. There’s room for improvement, but it will happen after 3.0 is released!
I expect it's just a case of removing optimizations in order to get everything stable, then they can start work on new optimizations. I'm not a Python dev though, so elaboration would be cool ;-)
True, migrating to PHP4 to 5 wasn't pretty, but 5 was an order of magnitude improvement over 4 and so worth the cost. Not sure if the same can be said for this new Py release. I'm still doing everything in 2.6(which was a recent move from 2.5). Too many libraries that aren't out for 3 yet.
Also, a lot of the scripts that power Gnome and Debian are written in Python. Ubuntu also seems to do most new work in Python. So I expect Python 2.X to be the default in distros for quite some time, probably until a 3.1 release or later.
I agree that it's a good time to learn Python... because it's always a good time to learn Python.
However, be aware that no one in the Python community expects 3.x to be used widely for a few years. Even for new projects, if you want to depend on an existing 3rd party library that hasn't yet been ported, you'll probably have to stick with 2.6.
To accommodate this, they allow you to import almost all of the 3.0 features in 2.6 on a file-by-file basis. So you can pretty much write code in Python 2.6 as if it was 3.0 provided you do the necessary "from __future__ import XXX" at the top of your file to do things like make "print" a function rather than a language keyword, etc. You won't have the reorganized standard library, but for most tasks there's either no difference or minor differences.
So yes, definitely learn Python, but be sure to install both 2.6 and 3.0. I recommend learning with 3.0, but you may have to do "real" projects in 2.6 for some time.
The download link for Python 3.0 is now featured prominently on the front page, above Python 2.6. I think this is a bad move, since many Python newbies will probably download Python 3.0 instead of 2.6, and then get frustrated when none of their 3rd-party packages work. python.org should keep Python 3.0 more hidden away for the time being to give time for the greater Python development community to migrate to 3.0.
Babo's right--remember that Python is "batteries included," which means all the standard libraries (which cover a huge range of uses) are already 3.0-ized.
Good point. But http://www.python.org/download/ says in its discussion of 2.6/3.0: "if you don't know which version to use, start with Python 2.6." To me, this advice is inconsistent with the layout on the front page, since most people who don't know what to use will click on the 3.0 link.
They could be going for two different types of user:
A) Brand-new programmer or language nomad who wants to dive right into Python. It's for personal enrichment, so they might as well learn the latest dialect and not pick up archaic habits.
B) Wary/professional programmer, or someone who wants to get something else done and thought Python might do the trick. This is the user who will actually bother to stop and read the instructions on the download page, probably because something else they want to use says it requires Python. (Perhaps a library with skimpy documentation.) If it works right away, they'll keep using Python; if not, they'll probably blame Python as a whole instead of the particular version they downloaded and use some other language to solve their problem.
Anyone in charge of a real production system is presumably beyond the "I guess I'll try Python" stage and is able to find out exactly which version they need.
A base python installation is good enough for most of the tasks for a newbie. Python 3.0 is out in a quite stable form for early migration testing, it's not as bad as you describe.
I loved it, but I still want better threading and multi-core support in CPython... Most desktops now have two cores and it doesn't seem likely that number will fall anytime soon...
Python 2.6 and 3.0 ship with a new library called multiprocessing which provides mechanisms for process control and intercommunication, which conveniently sidesteps the GIL limitation that prevents multiple core usage.
The library is loosely based around the existing threading API, and allows for seamless transfer of Python objects between processes (unlike other forms of IPC).
I know. The library is available to 2.5 as "processing", but starting OS processes when all you wanted were threads is somewhat ugly. I agree it's not possible to do it properly with the GIL in place and attempts to remove it did have less than amazing results on single-thread applications.
That's annoying... Even more annoying when I think it's easier to do in Java ;-)
For some definitions of "are" maybe. Fact is that processes don't share address spaces and thus pointers, which means that all data structures have to be serialised in some shape or form before they can be accessed by multiple processes. This makes some use cases infeasible in Python and other GIL based languages.
This is important and I'm concerned that so many advocates of Python (and Ruby and PHP) try to talk this huge issue away. I do use and love Python myself and I'd like to do more with it, so this is not pointless language war fighting.
Under Linux, the only difference between a thread and a process is not sharing the address space. Both POSIX threading libraries for Linux (NTPL is the current, LinuxThreads is the old one) do a clone() system call for every pthread_create(). The clone() system call is basically fork() with extra functionality (such as sharing the address space).
Inside the kernel, your "threads" and "processes" are both represented by the task_struct data structure. So, on Linux, threads and processes are the same thing in different flavors.
I brought this up since the parent said "starting OS processes when all you wanted were threads is somewhat ugly." My point is that on Linux, starting a "process" and starting a "thread" is fundamentally the same action and have the same cost.
I said same thing with different flavors. Literally, they are both represented by the same data structure in the kernel. The salient point of the discussion - cost of forking a process versus cost of spawning a thread - is the same. They require different styles of programming, but I was responding to your point on cost.
If you ever need to reason about scheduling in the Linux kernel, then you need to understand this concept. In the eyes of the scheduler, they're all the same.
I understand I was less than clear on my concern about the cost of starting a process versus starting a thread, but that was not all of my point. Besides the convenient shared memory space, threads also should take a little less to start because they don't need a new memory context. In long running threads, this is not much of a problem but if you decide to start a lot of threads, that could make a difference. I don't know if the Linux kernel makes a big deal out of this but I am sure that, as programs get more threaded, the cost of starting a thread will approach the theoretical minimum thanks to our skillful kernel developer friends.
I am not familiar with current (less than 10 year-old) processor architectures, but, back when I was familiar with that stuff, switching context between threads of the same process was a lot less costly than switching between different processes because the memory context is the same and set-up and tear-down was a somewhat costly operation. As processors start getting more cores, it also allows schedulers to keep threads of the same process to the same cores, reducing context-switch overhead (or to power-down less used cores to conserve energy).
If I had a very good threading/multi-core support, I would probably go with Solaris on a 64-thread T2 SPARC thingie, not Linux on 6-thread x86. And that's a good reason for Sun to invest some money on helping convince Guido the GIL is bad and will become worse with time. Because Intel will probably catch up.
Not so seemless. Things need to be serialised to transfer them. You need to specially craft code so that it is pickle safe... things don't just work automatically.
Also serialising 100MB or so worth of objects around is really slow. So the process module is not good for many cases of use.
Guido (BDFL) has said that the GIL will not be removed in 3.x, so we'll have to look for other implementations to tackle this problem head-on. As someone else remarked, there's a new multiprocessing library that attempts to make this more palatable.
This official announcement and summary is a lot better than that linked from that old post. Of course, the HN comments there are worth reading nonetheless.
Having taught a couple beginners, I can tell you that what you see when you print a variable is very important. So, I guess it depends how these objects convert to strs, but I was assuming it would show a zip or map object rather than the result.
Remember python 3.0 is supposed to be an intermediate for migration release... not for production use. That's what 3.1 is for.
It's going to take ages for modules to get converted over... but most projects have been preparing for it for a while. However hopefully the migration scripts will get better over the 3.0 - 3.1 timeline.
For now I'm sticking with python 2.5 - since it's the best one considering it's far better module, and platform support.
> It's going to take ages for modules to get converted over...
You underestimate the power of the ... wait a sec. :)
Anyway, there's broad support and excitement in the community about this release. I think you'll see modules being updated more quickly than you suspect.
That said, I also plan to keep my core projects on 2.x for a few more months till django, ipython, debian repos etc. move to 3.x. But I do plan to play with 3.x some.
Initially I was excited about 3.0 but as you pointed out it will take some time for modules to get converted over. I think this is very important. For me, one of the big selling points of Python is the large number of libraries written for it. With my luck I will need to use an obscure library that won't be updated any time soon by the author. So I'll have to stick with 2.5 or 2.6 because I need to get my job done rather than migrate a library.
It's sort of a chicken-and-egg problem because without widespread use of 3.0 no one will feel pressure to upgrade their library. I'm hoping, out of the goodness of their own hearts, that everyone will upgrade their libraries (for no immediate benefit but the gratitude of 3.0 users!). Maybe a website badge should be created for this accomplishment!
Python 3.0 includes a script that tries to automatically convert 2.6 code to 3.0 code, named 2to3. It's also incorporated into the package setup library, so in theory simply installing a Python 2.6 package with 3.0 will automatically convert the source code.
Of course, that means making your code work with 2to3 to begin with, but that's a much lower barrier to adoption than outright porting and dual maintenance.
If I install the 3.0 package on Ubuntu, will the "python" shell command be forced to 3.0? In other words, what are the basics of doing and using a dual 2.x/3.0 installation?
-goldie
"Python 3.0 (a.k.a. "Python 3000" or "Py3k") is a new version of the language that is incompatible with the 2.x line of releases. The language is mostly the same, but many details, especially how built-in objects like dictionaries and strings work, have changed considerably, and a lot of deprecated features have finally been removed. Also, the standard library has been reorganized in a few prominent places."
I have never seen a release for a new language be so clear and straightforward. That's awesome.