

Python 3.0: What's The Point? - twampss
http://mooseyard.com/Jens/2008/12/python-30-whats-the-point/

======
ninjackn
According to the Zen of Python (<http://www.python.org/dev/peps/pep-0020/>),
and the whole idea upon which python is created: "There should be one-- and
preferably only one --obvious way to do it."

That right there sums up the whole point of Python 3, necessary evil (reverse
incompatibility) for future good.

------
zapadoo
UNICODE support would be reason enough to answer "what's the point".

Also, some operations in Python 3, particularly those that are relevant to me
as a web application developer, are as fast as 2.6 and in fact significantly
faster than 2.5.x.

If for no other reason than the much better support for Unicode - an advantage
that will pay off dividends across all products built on 3 in the future -
that would be reason enough.

As it is when you look at third party packages that claim to support Unicode
you'll frequently find all sorts of cruft that doesn't play well with other
packages.

With respect to Unicode and Python, what was once less than intuitive, is now
easy. It just works.

~~~
tptacek
What, specifically, are the areas in Py3k that you use regularly as a web
developer that are faster in Py3k than they were in Python 2.5?

~~~
zapadoo
Certain libraries (both standard and 3rd party) perform significantly better -
in part because there appear to be some performance improvements in 2.6 which
3.0 also benefits from.

Standard ElementTree (pure python) is roughly 40% faster in Python 3 than in
2.5. cElementTree is likewise about 40% faster. A templating package I use
runs 3 times slower on 2.5 than on 2.6 and 3.0 (similar performance on 2.6 and
3.0).

Bearing in mind that optimization work will follow on, I believe being "fast
enough" is a good achievement for Python 3 and I'm personally pleased that
performance will not be a roadblock for my own adoption. Where I can live on
the bleeding edge I plan to.

------
bdfh42
Sounds a bit like all the VB Classic guys moaning about VB.NET. I joined in a
bit myself (mind .NET 1.0 was pretty bad) but now quite happily work in C#,
VB.NET and VB6 - whatever makes the customer happy.

Many thousands of VB programmers (hundreds of thousands?) bridged the gap and
a great many work in both versions just like me. It just is not a problem.

~~~
giardini
Nope, thousands at best.

Most abandoned Microsoft. Or better said, Microsoft abandoned them. Choosing
to release an incompatible set of new languages with no upgrade path was hint
enough that Microsoft had purely it's own interests at heart and not that of
the lowly VB and ASP developers who made their OS and web server successful.
Most took the hint and are now happily supporting Java, Ruby, PHP, Python and
Perl web apps (with a side-business supporting VB6 legacy apps and ASP -
apparently still alive and kicking after all these years) -in short, anything
non-proprietary.

"Fool me once; shame on you. Fool me twice; shame on me." For Microsoft, no
second chance.

~~~
gaius
I think MS misjudged its audience there (a rare stumble for them). Visual C++
people thought of their work as _code_ and expected to have to change it for a
new version. For them the transition to managed C++ or C# was natural. Visual
Basic people thought of their work as _documents_ and were as surprised as if
MS had released version of Word that couldn't read documents from the previous
version.

~~~
giardini
I have never heard or read a VB programmer describe his work as a _document_!
No, the problem was not how "Visual Basic people thought of their work".

The problem was that VB.NET _was a completely different language from VB6,_
with the full consequences therof: no upgrade path for existing code,
retraining of all personnel, etc.

On IIS the upgrade to ASP.NET required purchase of a new IDE (Visual Studio)
for all developers and retraining of all personnel, (ASP required no IDE). And
ASP.NET abandoned support of VBScript which was by far the most popular ASP
language.

~~~
bdfh42
Not quite.

The "document" might perhaps be how some VB programmers conceived of their
code - as a totality not just a collection of code lines delivering an
algorithm - but perhaps you are right and this is not an idea that you can
take very far.

I am not sure that I agree that VB.NET was "completely different" - different
yes, but still clearly a dialect of Basic (of which there have been many - and
some new ones popping up all the time). I suspect that you overstate the
difficulty in migrating from one dialect to another - sure it is going to take
time to reach similar levels of productivity but time and languages move on -
it's something that programmers above all should be glad to embrace.

On your final point - ASP.NET does not in fact require the Visual Studio IDE.
There are many advantages to be gained from the IDE but it is not a
requirement and there are many texts around that demonstrate development
outside of VS. OK VBScript was coming to the end of it's life but in any case
it's client side (browser) utility was very limited and something more
powerful was certainly needed server side. Oddly - the next generation of
VB.NET will include a dynamic option - son of VBScript perhaps?

------
tptacek
I wanted to like Jens' article, as a fellow Rubyist who had left a few 10klocs
of Python in his wake. But I thought this was really weak. Instead of coming
across like genuine tough questions, I think Jens wears his bias on his
shoulder, even commenting that he's been "tipped more towards Ruby" by this
"fork in the community" (a particularly funny comment from a Rubyist).

His worst argument: a comment that claims he's worried that Py3k will get
security fixes that Python 2.6 won't --- a borderline-irresponsible cheap
shot.

It's too bad, because I actually agree with his assessment; I get a whiff of
"second-system syndrome" from this whole Py3k project, and the idea of
breaking random bits of code in an interpreted, dynamically typed language and
then fixing them with a code translator seems like lunacy.

~~~
llimllib
"second-system syndrome" sounds like exactly the opposite of what I think
about py3k. (Pythonista with more than 10kloc, rubyist at my day job, many
less).

Mainly, I see this release as cleaning up the warts that python had
accumulated. {imap, ifilter, izip, iterkeys, itervalues, iteritems, xrange}
all becoming default and their non-stream counterparts ceasing to exist is a
huge upgrade.

Unifying new-style and old-style classes is a huge cleanup and upgrade. (Which
simplifies code for newbies quite a bit, too).

The move to default unicode strings is a huge upgrade.

The library cleanup is a huge upgrade.

The inclusion of multiprocessing (actually 2.6, but who uses that?) is a huge
upgrade.

I don't see any of this as "breaking random bits of code", but rather as
stepping back to regroup the language into a much more coherent whole.

But then, I'm in the tank for python, I freely admit.

~~~
tptacek
I knew when I wrote "second-system syndrome" that I was going to get hammered
for it, because I agree that it's not a perfect match for what they've done.

Many millions of lines of Python code work in the field right now; a decent
subset uses Unicode (for instance, most Win32 Python code has to). I buy that
the new Unicode model is better, but I don't buy that it's so much better that
a code port is worth it.

The library cleanup is a major win, but they could have done that in Python
2.7.

It's hard to say multiprocessing is a huge win in 3.0, since it's already in
2.x.

~~~
llimllib
> It's hard to say multiprocessing is a huge win in 3.0, since it's already in
> 2.x.

Yeah, I was just joking about that bit.

I don't see why it would be any different for the 2.7 library have been
reorganized than it is for the 3.0 library reorganization; it would have
broken just as much code. And while you're breaking code, you should break the
code that needs to be broken, right?

And it's not just unicode, it's unicode/new style classes/iterators throughout
(which I think is an underrated change). None of these could have happened
without breakage, and I think it's better to clear the decks once every 15
years than it is to just grow by accretion forever.

Those lines of python in the field that work are not going to stop working;
python 2.x is not going to go away or go unmaintained, as you point out
yourself. Writing new code will shortly become more difficult in the 2.x
series, as libraries start switching to 3, but the old code will be
maintainable for a long while.

In order for the language to keep growing in a clean, pythonic fashion, it
needed to be cleaned up a bit, and I think they did a great job of it.

~~~
tptacek
So, I agree with you. But one of Jens' subtexts is, if they're going to clear
the deck every 15 years, you might hope for something more interesting than
"better Unicode support". There's a _lot_ of stuff that would be nice to have
in Python that can't be added without a 3.x-level flag day.

~~~
llimllib
> There's a lot of stuff that would be nice to have in Python that can't be
> added without a 3.x-level flag day.

 _that_ I can definitely agree with.

------
jackdied
As a sometimes Python core developer allow me to say stuff. The main goal was
to remove mistakes; an all-at-once deprecation. The release was actually much
less ambitious than the original name "Python 3000" implied. Guido read one of
Joel's posts on rewriting software [the one on the Mozilla rewrite] and
dictated that 3.0 be done in a year or two. See the list of PEPs [Python
Enhancement Proposals] for silly big changes that were shot down.

As for python 3.0 being 10% slower than 2.5 - that means that it is is just
1.9 times faster than Ruby instead of a clean 2x? And the backwards
incompatible version took just two years instead of infinity like Perl and two
years instead of the UNK for Ruby? Python 2.5 benefited from a corporate
sponsored "Need For Speed" sprint where twenty of the core devs went on a paid
vacation with a mission to just sprint on speed issues. There hasn't been a
corresponding sponsored event for 3.0.

A huge amount of volunteer time has been spent on backwards compatibility
issues. When the Python 3.0 issue was first floated the Twisted and Django
folks had lots of worries about the transition and supporting two versions
(2.x and 3.x). Hundreds of hours were spent on the email lists and PyCon
dinners hashing out the details. Thousands of hours were spent adding warnings
and best practices docs to 2.6 as well as on the "2to3" translation tool.

Time will tell but there will certainly be lessons learned from the Python 3
release.

------
olefoo
Python3 won't be standard until it's adopted as the main python of several
widespread linux distros and available in a clean, batteries included way for
OSX and all 36 flavours of windows.

Bitching about py3k is basically whining about being forced to learn new
things.

The one question I have is are people going to start using different filename
conventions?

I could see temporarily associating .py3 with a /usr/local/bin/py3k for
testing purposes and porting 2.6 to 3, but I really hope it doesn't become a
widespread practice.

~~~
Rhamphoryncus
The ideal approach is "#!/usr/bin/env python3.0".

~~~
kteague
If you install Python 3 with "make fullinstall" then the binary will be named
just "python". I've always used just "#!/usr/bin/env python" and just kept
track of what version of Python a collection of code was targeted for.
Changing all scripts from "#!/usr/bin/env python3.0" to ""#!/usr/bin/env
python3.1" and so on is too cumbersome.

But it depends upon how you manage your code - whether it's just a few loose
scripts, part of a larger project, a web app or a desktop app or a command-
line script, or what your deployment and install processes looks like, etc.
etc. I usually install my Python scripts with Buildout these days, so I let
Buildout autogenerate the shebangs to point to the required Python
installation.

------
gcheong
Anyone have any insight on the comment about Python 3 being 10% slower?

~~~
jmtulloss
It's because they left out a lot of the old optimization hacks when they
reworked the interpreter. They'll either be reinserted or better solutions
will be found now that the language is stable.

