

Python 3.0 Released - zain
http://www.python.org/download/releases/3.0

======
stillmotion
Wow, even the introduction is incredible.

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

~~~
omouse
What about Scheme R6RS?

<http://www.r6rs.org/final/html/r6rs/r6rs-Z-H-1.html>

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

~~~
fh
For one thing, the quoted paragraph doesn't explain what they changed in R6.

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

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

~~~
kaens
I run a stable CherryPy app on 2.6 . It was a bit painful for about a week
after 2.6 came out, but became stable pretty fast.

There are a whole lot of possibilities for a "webapp stack" in python. What
are you running your sites on top of?

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

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

------
FiReaNG3L
Guess it's a good time to learn Python!

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

~~~
mechanical_fish
_from __future__ import XXX_

"I'll borrow features from myself in the future!"

[time passes]

"Hey! That guy from the past just copied all my features!"

~~~
kirubakaran
So what? He gave you all his money.

~~~
LogicHoleFlaw
Actually, he spent a big chunk of it before I could get it :(

~~~
netcan
Actually he borrowed a bunch of you money promising to pay it back in the
future.

~~~
eru
Or better: Actually he borrowed a bunch of your money promising you pay it
back.

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

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

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

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

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

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

~~~
rbanffy
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
;-)

~~~
scott_s
If you're running on Linux, then all threads _are_ processes.

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

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

~~~
rbanffy
They are not the same thing. Threads share address space and processes don't
and that's a crucial difference.

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

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

------
makecheck
<http://news.ycombinator.com/item?id=384897>

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

------
bdr
I'm ambivalent about changing so many functions to return iterators. It's
cleaner for experienced coders, but harder to understand for beginners.

~~~
dnaquin
Most of those changes get masked behind loops that I don't think either is
very different for understanding.

I think the plusses outweigh the edge cases.

~~~
schtog
what are the edge cases? what are the advantages of iterators? less memoryuse?

~~~
eru
Iterators get some of the benefits of lazy evaluation.

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

~~~
msie
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!

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

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

------
nihilocrat
Now the question is: when is Stackless Python going to go 3.0?

------
pavelludiq
I love Py3k

