
About Python 3 - jnoller
http://alexgaynor.net/2013/dec/30/about-python-3/
======
agentultra
I like Python 3. I prefer it. It is better to program in than 2.x. Iterators
everywhere, no more unicode/encoding vagueness, sub-generators and more. It is
a much better language and it's hard to see how it could have evolved without
a clean break from its roots.

However it has been interesting to follow over the last five years. It has
been a sort of, "what if p5 broke the CPAN," scenario played out in real-life.
Breaking compatibility with your greatest resource has a painful trade-off:
users.

Everything I work on is not even considering a migration to Python 3.
OpenStack? A tonne of Django applications that depend on Python 2-only
libraries? A slew of automation, monitoring and system administration code
that hasn't been touched since it was written? Enterprise customers who run on
CentOS in highly restrictive environments? A migration to Python 3 is
unfathomable.

However my workstation's primary Python is 3. All of my personal stuff is
written in 3. I try to make everything I contribute to Python 3 compatible.
I've been doing that for a long time. Still no hope that I will be working on
Python 3 at my day job.

Sad state of affairs and a cautionary tale: "Never break the CPAN."

~~~
keyme
I don't like Python 3.

Iterators everywhere are incredibly annoying, especially with my development
workflow, where I don't put a line of code into a file before I run it
manually in the interpreter. When I run a map over a list, I just want to see
the freaking results.

Default unicode strings are obscenely annoying to me. Almost all of my code
deals with binary data, parsing complex data structures, etc. The only "human
readable" strings in my code are logs. Why the hell should I worry about text
encoding before sending a string into a TCP socket...

The fact that the combination of words "encode" and "UTF8" appear in my code,
and str.encode('hex') is no longer available, is a very good representation of
why I hate Python 3.

In Python 2, the rule of thumb was "If it makes sense, it's going to work". In
Python 3, this isn't true. Not often, but often enough to annoy. This makes
Python "feel" like Java to me.

And worst of all, Python 3 has so many excellent features, like sub-
generators, a better performing GIL, etc. These sometimes force me into coding
with Python 3. I hate it every freaking time.

I said to myself that with Python 3.4, due to great stuff like the new asyncio
module, I'll have to make the switch. It's really sad that this is because I
"have to" do it, and not because I "want to".

~~~
tungwaiyip
Keyme, you and I are the few that have serious concern with the design of
Python 3. I started to embrace it in a big way 6 months ago when most
libraries I use are available in Python. I wish to say the wait is over and we
should all move to Python 3 then everything will be great. Instead I find no
compelling advantage. Maybe there will be when I start to use unicode string
more. Instead I'm really annoyed by the default iterator and the binary string
handling. I am afraid it is not a change for the good.

I come from the Java world when people take a lot of care to implement things
as streams. It was initially shocking to see Python read an entire file into
memory, turn it into list or other data structure with no regard to memeory
usage. Then I have learned this work perfectly well when you have a small
input, a few MB or so is a piece of cake for modern computer. It takes all the
hassle out of setting up streams in Java. You optimize when you need to. But
for 90% of stuff, a materialized list works perfectly well.

Now Python become more like Java in this respect. I can't do exploratory
programming easily without adding list(). Many times I run into problem when I
am building complex data structure like list of list, and end up getting a
list of iterator. It takes the conciseness out of Python when I am forced to
deal with iterator and to materialize the data.

The other big problem is the binary string. Binary string handling is one of
the great feaute of Python. It it so much more friendly to manipulate binary
data in Python compare to C or Java. In Python 3, it is pretty much broken. It
would be an easy transition I only need to add a 'b' prefix to specify it as
binary string literal. But in fact, the operation on binary string is so
different from regular string that it is just broken.

    
    
      In [38]: list('abc')
      Out[38]: ['a', 'b', 'c']
      
      In [37]: list(b'abc')       # string become numbers??
      Out[37]: [97, 98, 99]
      
      In [43]: ''.join('abc')
      Out[43]: 'abc'
      
      In [44]: ''.join(b'abc')    # broken, no easy way to join them back into string
      ---------------------------------------------------------------------------
      TypeError                                 Traceback (most recent call last)
      <ipython-input-44-fcdbf85649d1> in <module>()
      ----> 1 ''.join(b'abc')
      
      TypeError: sequence item 0: expected str instance, int found

~~~
keyme
Yes! Thank you.

All the other commenters here that are explaining things like using a list()
in order to print out an iterator are missing the point entirely.

The issue is "discomfort". Of course you can write code that makes everything
work again. This isn't the issue. It's just not "comfortable". This is a
_major_ step backwards in a language that is used 50% of the time in an
interactive shell (well, at least for some of us).

~~~
agentultra
The converse problem is having to write iterator versions of map, filter, and
other eagerly-evaluated builtins. You can't just write:

    
    
        >>> t = iter(map(lambda x: x * x, xs))
    

Because the map() call is eagerly evaluated. It's much easier to exhaust an
iterator in the list constructor and leads to a consistent iteration API
throughout the language.

If _that_ makes your life hard then I feel sorry for you, son. I've got 99
problems but a list constructor ain't one.

The Python 3 bytes object is not intended to be the same as the Python 2 str
object. They're completely separate concepts. Any comparison is moot.

Think of the bytes object as a dynamic char[] and you'll be less inclined to
confusion and anger:

    
    
        >>> list(b'abc')
        [97, 98, 99]
    

That's not a list of numbers... that's a list of bytes!

    
    
        >>> "".join(map(lambda byte: chr(byte), b'abc'))
        'abc'
    

And you get a string!

~~~
dded

      >    >>> list(b'abc')
      >    [97, 98, 99]
      >That's not a list of numbers... that's a list of bytes!
    

No, it's a list of numbers:

    
    
      >>> type(list(b'abc')[0])
      <class 'int'>
    

I think the GP mis-typed his last example. First, he showed that
''.join('abc') takes a string, busts it up, then concatenates it back to a
string. Then, with ''.join(b'abc'), he appears to want to bust up a byte
string and concatenate it back to a text string. But I suspect he meant to
type this:

    
    
      >>> b''.join(b'abc')
    

That is, bust up a byte string and concatenate back to what you start with: a
_byte_ string. But that doesn't work, when you bust up a byte string you get a
list of _ints_ ; and you cannot concatenate them back to a byte string (at
least not elegantly).

~~~
agentultra
> No, it's a list of numbers:

Well, yes. Python chooses the decimal representation by default. So? It could
be hex or octal and still be a byte.

My example was merely meant to be illustrative and not an example of real
code. The byte object is simply not a str; so I don't understand where this
frustration with them not being str is coming from. If you use the unicode
objects in Python 3 you get the same API as before. The difference is now you
can't rely on Python _implicitly_ converting up ASCII byte strings to unicode
objects and have to explicitly encode/decode from one to the other. It removes
a lot of subtle encoding bugs.

Perhaps it's just that encoding is tricky for developers who never learned it
in the first place when they started learning the string APIs in popular
dynamic languages? I don't know. It makes a lot of sense to me since I've
spent years fixing Python 2 code-bases that got unicode wrong.

~~~
tungwaiyip
You are not making useful comment because you don't understanding the use
case. Python 2 is very useful in handling binary data. This complain is not
about unicode. This is about binary files manipulation.

I'm thrill about the unicode support. If they only add unicode string and
leave the binary string alone and just require an additional literal prefix b,
it will be an easy transition. Instead the design is changed for no good
reason and the code are broken too.

~~~
agentultra
I have a hard time believing that the design was arbitrarily changed.

The request to add string-APIs to the bytes object have been brought up before
[0]. I think the reasoning is quite clear: byte-strings are not textual
objects. If you are sending textual-data to a byte-string API, build your
string as a string and encode it to bytes.

[0] [http://bugs.python.org/issue3982](http://bugs.python.org/issue3982)

For working with binary data there's a much cleaner API in Python 3 that is
less prone to subtle encoding errors.

 _edit_ : I realize there is contention but I'm of the mind that .format
probably isn't the right method and that if there were one it'd need it's own
format control string syntax.

------
thatthatis
I'm going to go against the grain here and say that moving slowly is one of my
absolute favorite features about python and its libraries.

Rails and django were released about the same time, rails is on version 4,
django is on 1.6.

Moving slowly means I can spend more of my time writing code and less of my
time upgrading old code. More importantly, every release requires a perusal:
did the API change, what's new, are there breaking changes I need to be aware
of?

I didn't appreciate how nice a slow but consistent and deliberate release
cycle was until I started using Ember which seems to release a new version
monthly.

Its generally acceptable to be one or two x.x versions back, but much more
than that and the cost of maintaining libraries skyrockets, so you start
losing bug fixes and library compatibility.

With python there's not really a question of if I can run my code for a year
between non-security upgrades, even with a few dozen third party libraries.
That stability is immensely valuable.

~~~
Argorak
This is where the Ruby and Python communities fundamentally disagree. The Ruby
community is great at moving fast and replacing bad things, while the Python
community takes a much slower approach to the whole thing.

I wouldn't say any approach is better or worse, it has to fit your personal
style. I like the Ruby approach, others love the Python approach. This means
that Ruby breeds a lot of interesting stuff, but with less stability
guarantees.

At the same time, Rails still builds on the ideas of Rails 1, which is an
achievement in itself. So Rubyists is not totally not caring about backwards
compatibility - they just tend to throw out bad ideas quickly again.

On the other hand, the quick pace allows the MRI team to build improved
interpreters with a reasonable chance of quick adoption.

This is a much more fundamental difference than any snickering about the
garbage collector of the main interpreter, from a users perspective.

~~~
_delirium
Differences in userbases could be part of it. Scientific computing is an
increasingly important part of the Python community, for example, and they
tend to be averse to backwards-incompatible changes. In part that's because
you have many good but very lightly maintained libraries that stick around
forever, so people prefer if they stay working when nobody touches them,
rather than bitrotting and needing constant updating by thinly stretched
maintainers. Heck, old Fortran stuff is still in regular use, some of which
hasn't been touched in years.

~~~
userbinator
It seems that communities that mainly use programming languages for reasons of
"getting stuff done" value backwards compatibility the most; they are the ones
who would rather not have to spend the time "upgrading" things that used to
work perfectly fine, and would rather use that time to do something more
_useful_ and related to their ultimate goals. Personally I think backwards
compatibility is getting less attention than it deserves, and that software
should evolve slowly and gradually and not suddenly make huge leaps, because
all these breaking changes start to look like they're just creating
unnecessary, wasteful work. Imagine if things like mains plugs changed every
few months, with appliancemakers all adopting the newest backwards-
incompatible version. In some ways software is easier to change than hardware,
but at the same time we must remember that effort needs to be expended to
perform these changes as well, effort that could be used in other ways, and
often there is a lot of interconnectedness in the systems we are trying to
change.

~~~
q845712
"Imagine if [...] plugs changed every few months, with appliancemakers all
adopting the newest backwards-incompatible version"

like apple?

~~~
wilg
_iPod /iPhone_

October 2001 - Original iPod - FireWire

April 2003 - Third-Generation iPod - 30-pin Dock Connector

September 2012 - iPhone 5 - Lightning Connector

 _Apple Laptops_

1998 - PowerBook G3 - Unnamed Circular Power Connector

2001 - PowerBook G4 - Smaller Unnamed Circular Power Connector

2006 - MagSafe

2012 - MagSafe 2

------
themgt
It's fascinating to compare this with ruby 1.9, released around the same time,
but seemingly with a slightly better cost/benefit ratio, having nice new
features and also significantly improved performance, and with ruby 1.8 being
deprecated with a lot more speed and force. It got everyone to actually make
the switch, and then ruby 2.0 came along, largely compatible and with a more
improvements, and now ruby 2.1 seems to be an even smoother upgrade from 2.0.

The ability of the ruby core team to manage not just the technical aspect of
making the language better, but smooth the transition in a way that actually
succeeded in bringing the community (and even alternate ruby implementations)
along with them, hasn't been given nearly enough credit. You could analogize
it to Apple with OS 9 -> OS 10.9, versus Microsoft with people still running
XP

~~~
w1ntermute
> You could analogize it to Apple with OS 9 -> OS 10.9, versus Microsoft with
> people still running XP

No, you couldn't. The difference in upgrade rates between Windows and OS X is
primarily due to their differing customer bases. Windows is very popular in
enterprise, which avoids unnecessary upgrades in order to ensure compatibility
with in-house software.

OS X, however, has almost no presence in enterprise, and consumers don't mind
upgrades nearly as much, since the consumer software they use has to be
compatible with all OS versions. Also, you can't buy Macs with old versions of
OS X, whereas Microsoft makes it trivial to buy a new machine and install an
older version of Windows.

~~~
zackmorris
I just want to chime in and say that Apple has done an abysmal job with
backward compatibility, and it's not just due to the enterprise vs consumer
market. I would wager that if you looked at the total list of apps ever
released for Mac OS, the majority of them would not run today. That's because
Apple's primary strategies are 1) innovate and 2) put the user first. Putting
the developer first is not part of their profit motive like it would be for
say Oracle or MathWorks. So without constant recurring effort, developers and
the apps they create get left behind.

Apple frequently deprecates APIs that they endorsed just a few years ago. And
they claim that apps can be rewritten to work with new APIs in a few hours,
when in reality it can take weeks, months or even longer due to refactoring
issues. If you want to be an Apple developer, you will likely be rewriting a
portion of your code at some point to run on a new OS release. I was
optimistic that the practice might end but history is already repeating itself
with Apple insisting on iOS 7 compliance. The kicker is that Apple could have
ported a lightweight version of Mac OS to run directly on arm for iOS, but
they didn't, and I disagree with it being a performance issue (iPads are
orders of magnitude more powerful than NeXT machines, or even the early
PowerPCs that ran OS X). They created a vast array of nearly duplicate code
prefixed with UI instead of NS. This looks like more of an anachronism every
day to me with tablets running at multiple GHz with GBs of ram, when the only
major difference between desktop and mobile is the touch interface.

Contrast this with Microsoft, where I am finding very old examples designed
for Windows XP that still run today. Now Microsoft is certainly burning its
developers with the major breaks in various versions of DirectX, or subtle
differences in APIs between desktop/mobile/Xbox, but in my opinion this isn't
happening nearly to the extent that it is with Apple.

~~~
ido
> Contrast this with Microsoft, where I am finding very old examples designed
> for Windows XP that still run today.

xp? Up until a couple years ago when I switched to 64bit windows (first
computer I had with more than 4gm ram) I could still run win3.1 and dos
programs in (32-bit) windows 7. Including dos programs designed for the very
original ibm pc (1981!).

Even today with 64bit windows I can still run most windows 95 programs.

------
GuiA
Python 3 came from a good place, and it definitely fixes many problems that
sorely needed fixing, but it was doomed to failure from the start (and many
developers said that in 2008 already).

For all intents and purposes, Python 3 is pretty much a new, separate
programming language. Sure, it's very close to Python 2.x, but you don't have
out of the box retro-compatibility so that pretty much kills it right there.

Python 2.x is so huge in terms of its use around the world and available
libraries and resources for it that you just can't say "hey, the new version
of Python will in practice break everything" and expect it to fly.

I love Python and the community around it (and have several packages on pypi
myself), but Python 3 is a joke.

If we didn't want to kid ourselves, we'd kill Python 3 and back port the
interesting features, like Alex suggests. At this point though, too much
effort and egos are involved to make this realistic.

~~~
benburton
> but you don't have out of the box retro-compatibility so that pretty much
> kills it right there.

I don't know if that's necessarily a foregone conclusion. Scala releases
aren't always/usually backwards-compatible, and you'd be hard-pressed to find
people still using much older versions.

~~~
TylerE
Scala releases are usually not BINARY backwards compatible. Very different
from SOURCE backwards compatible.

~~~
wyuenho
Scala also was often not source compatible during 2.7 -> 2.8 because of the
huge changes in the standard library.

~~~
eropple
I'm pretty sure they'll never be doing that again though due to the mess it
caused.

------
evmar
I like to think of engineering as "solving problems within a system of
constraints". In the physical world, engineering constraints are things like
the amount of load a beam will bear. One of the primary easily-overlooked
constraints in the software world is backwards compatibility or migration
paths.

There are many examples of systems where many look at them today and say:
"This is terrible, I could design a better/less-complicated system with the
same functionality in a day". Some examples of this dear to my heart are HTML,
OpenID, and SPDY. It's important to recognize the reason these systems
succeeded is they sacrificed features, good ideas, and sometimes even _making
sense_ to provide the most critical piece: compatibility with the existing
world or a migration plan that works piecemeal. Because without such a story,
even the most perfect jewel is difficult to adopt.

The OP, about Python 3, is right on except for when it claims making Python 3
parallel installable with 2 was a mistake; doing that would make it even more
impossible to migrate to 3 (unless the single binary was able to execute
Python 2 code). (Also related: how Arch screwed up Python 3 even more:
[https://groups.google.com/d/topic/arch-
linux/qWr1HHkv83U/dis...](https://groups.google.com/d/topic/arch-
linux/qWr1HHkv83U/discussion) )

~~~
pron
Exactly. This is why something like Java 8 is admirable. They've been able to
introduce two major new features from newer "productive" languages – lambdas
and traits – without breaking anything; not only that, old libraries will
actually enjoy better APIs thanks to the new features without recompilation.
Sure, there might be better ways to implement these features, but introducing
them in a way that feels natural to a language with millions of professional
developers without breaking source or binary compatibility is a commendable
achievement.

~~~
Too
Same with C#. That language has really exploded with new features, and still
code and precompiled libraries written for 1.2 compiles and runs perfectly on
5.0.

------
thezilch
It wasn't until 3.3 that py3 was really palatable. Easier to support unicode
running the same codebase in py2 and py3. yield from -- look, a py3 feature
worth porting for! 3.3 was released in late 2012, and so, we can probably
shift this "5 year" expectation to start from there.

In fact, it's 3.4 that really starts to wet the beak with asyncio and enum.
I'm not sure 2.8 needs to happen, if 3.x simply, and finally, has good reasons
to get on board.

~~~
Ixiaus
This. While there are many wonderful features in Py3 (I use it 100% in
production at work) it still needs a killer feature to really inspire people
to move over. Python's lack of solid asynchronous I/O is definitely one of
those features I think.

~~~
ak217
That's coming in 3.4.

------
cturner
Static platforms are great for developers. The best years of WebObjects' life
were after Apple had mothballed it. Returning to a project years later - all
the old code, scripts, and patterns worked just the same. Nothing else in the
java world was like that. Similar story with BSD. The python 2/3 migration has
been well managed. There is no rush. Celebrate it.

~~~
seanwoods
I think this is exactly right. Often people rush to conclusions in favor of
the new and shiny, but Python is a great language that works pretty darn well
at the moment, even in v2.7, giving the community the freedom to fully vet
their ideas and make a valuable product.

I remember reading commentary on HN when a new version of PuTTY was released,
and there was general sentiment that PuTTY is - for all intents and purposes -
a "finished" product in that it does what you need it to do.

[https://news.ycombinator.com/item?id=2758696](https://news.ycombinator.com/item?id=2758696)

Python v2.7 is similar in that it's a tool that does many amazing things and
is very stable. Could it be improved? Sure! But for the most part it's a great
piece of software.

The care and planning that went into creating the tool is also going into the
upgrade process, and I think that's a good thing.

------
falcolas
As a development lead, we recently abandoned our plans to migrate to Python 3.
Here's a short summary of why:

To begin the migration, we needed to move from Python 2.6 (which is the
default on our CentOS6 production boxes) to Python 2.7. This transition is
actually rather hard. We can't use the packages provided in CentOS base or
EPEL, because they are all complied against Python 2.6. To re-produce all of
our package requirements would require us to either build new packages of the
compiled libraries (such as MySQL-python, python-crypto, PyYAML, etc), or load
down our production environment with a compiler and all of the development
libraries.

Migrating from Python 2.7 to Python 3 would have required a nearly identical
effort (there's not a lot of Python 3 packages for CentOS, in particular the
packages that we need for our application).

Frankly, it's just not worth that effort at this time. Python 2.6 is the
default environment, there's solid package support for it, and it just plain
works. We'll make that dive when Python 3 becomes the default for CentOS
(scheduled for 8 or 9, IIRC), and probably not before.

~~~
marcosdumay
Even Debian is using Pyhon 2.7 for a while already, looks like CentOS is being
quite slow.

~~~
SwellJoe
CentOS keeps the same major version of _everything_ through the entire life of
the OS; so, five years plus two more for vital security updates. This is by
design, and a completely reasonable choice.

Often, you can install additional packages that bring newer versions into the
system, but they don't become the "default". So, for PHP in CentOS 5, there
was a php53 package (and maybe later ones, too, I dunno), that installed
alongside the standard php package and didn't break compatibility but gave
users the option of using a newer PHP version.

I'm pretty sure Python 3 is available in CentOS repos (it certainly has been
in Fedora repos for a long time). It's just not the default system Python you
get when you type "python".

~~~
yxhuvud
It is a reasonable choice until the day when you get hacked because you use a
prehistoric version of something that doesn't get security updates anymore.

Sure, sometimes that will get backported security fixes, but that is not
always possible. Heck, sometimes the installation _depends on_ said security
hole.

~~~
SwellJoe
I still think you don't understand. RHEL (and thus CentOS) backports security
fixes. An Apache package downloaded today from the CentOS 5 repository will
have the security fixes, and many stability related bugfixes, that the latest
tarball from apache.org would have, while still being an old version of Apache
(and having the same configuration file syntax and working with whatever code
you've deployed and tested on that version).

That's what companies are paying Red Hat for: A stable platform on which to
build their business. It really is a good thing with quite a lot of value.

If you want bleeding edge versions of software, RHEL or CentOS might not be
the right OS for you. But, I happen to love it for servers; I know that what I
deployed three years ago is still gonna work after upgrading packages provided
by the vendor. That's not something you can count on with faster moving
distros, and it's why I always use CentOS (or RHEL or Scientific Linux) on my
servers...while I generally use Fedora or Ubuntu on desktops.

Security is a hard thing to quantify, but I really think that a slower moving,
but more carefully vetted, platform is going to be more secure. I believe this
is why OpenBSD is so solid...moves _very_ slow, but is very carefully
constructed and maintained. RHEL/CentOS is somewhere in between OpenBSD and
Ubuntu on that continuum, and I strongly suspect CentOS is going to have a
better security record than Ubuntu.

~~~
yxhuvud
And I think you didn't understand my point. Sometimes these security fixes
will not be compatible with the application you are running. It will usually
not be an issue if every single line of code you run is from the distro
manager, but I've had CentOS security fixes breaking my apps because the
security fix forced some other way of doing things, and because they didn't
bother backport the subsequent bug fixes to the security fixes.

Yes, it may be less work with a stable system. I'm not arguing that part, but
it is an idealized pipe dream to install once and then let the system be. You
still have to have the machinery to do maintenance work, and you still need
proper testing. Security fixes are NOT exempt from that in any way.

~~~
SwellJoe
Certainly, software is complicated, and we're always managing risk and
complexity when choosing our tools.

The reality is that CentOS is a more stable platform than most of the
alternatives. It doesn't provide cutting edge software across the board
(though it is possible to get newer versions of common tools that people want
to stay on top of, like languages), but it does provide a reasonable level of
confidence that what you deployed years ago will continue to run today. Moreso
than any other Linux distro out there (in my, not at all limited[1],
experience), most likely. And, the security concerns you raised are the ones I
wanted to address in my original reply to you; you alleged that CentOS/RHEL
provided old and thus insecure software. I wanted to make it clear that's not
the case; all software is subject to bugs, including security bugs, but
CentOS/RHEL are not shipping software with known exploits. It gets fixed,
along with the upstream. In fact, the RHEL developers are often providing the
upstream fixes, as well; Red Hat employs huge swaths of FOSS
developers...really good ones.

1-I work on systems management software that is installed a million times a
year, on every Linux distro and nearly every UNIX variant, and have done so
for ~15 years. I don't know everything, but I know which Linux distros provide
a stable platform and which ones have a good security record.

------
saurik
Reading the comments on Hacker News whenever someone brings up the issues with
the Python 3 transition are horribly painful due to a systemic bias in that
the people who care to read and talk about Python 3: they are mostly people
who are in the 2% of people who apparently care enough to have upgraded
already; everyone [edit: "here who is saying" was incorrect; "here who
normally says" <\- today the discussion has been much more balanced, which is
really nice] "engh, its fine, I upgraded, I know tons of people who upgrade"
are ignoring the actual statistics cited by this developer [maybe having these
actual numbers changed the discussion, pushing out the people who just insist
nothing is going wrong?] that show "no, you are wrong, you have a bunch of
anecdotes because you know people like you and people like you actually wanted
to upgrade for some extrinsic reason that your friends are more likely than
the normal population to share with you". :(

If you cast a wider net, and talk to people at conferences that have nothing
to do with fancy programming languages (and certainly not about Python
itself), people aren't using Python 3, and the feelings about Python 3 are
mostly "sarcastic bitterness" (where like, you bring up Python 3 and they kind
of laugh a little like "yeah, no, obviously") surrounding the problem
mentioned by this author that "for the last few years, for the average
developer Python, the language, has not gotten better" while being told that
upgrading is easy or somehow intrinsically valuable to them, which as this
author points out comes across as the Python community just saying "fuck you"
to their needs.

~~~
aidos
I'm not sure there's any substance to what you're saying. The comments on here
certainly don't reflect the attitude you've suggested they should.

I obviously can't speak for anyone but myself but for me the reason not to
change has been that there's a critical core of libraries that weren't ported
over. Now the list isn't looking too bad and it's probably time to make the
switch. It's taken a long time to get to that stage, but was always going to.

~~~
saurik
So, I'm going to agree with your first comment: today things are much better
than normal, and I apparently skimmed the top-level comments too quickly and
didn't give them enough credit. I've taken the parts of what I said that I
believe you are correct for pointing out "are in error", modified them, and
will go so far as to apologize for not giving today's thread enough
consideration.

> I obviously can't speak for anyone but myself but for me the reason not to
> change has been that there's a critical core of libraries that weren't
> ported over. Now the list isn't looking too bad and it's probably time to
> make the switch. It's taken a long time to get to that stage, but was always
> going to.

However, reading your continuation kind of brings back the bias problem to me
(although not in a way that is problematic, as you aren't trying to say the
people who aren't upgrading are wrong; but sufficiently that it is interesting
to discuss): you are assuming there is some intrinsic value to making the
switch to Python 3, and that the strategy is simply to wait for the pain to be
sufficiently low that it becomes "time to make the switch", as if that switch
were inevitable, and as if this is all going well for everyone.

I would say that instead, the Python 3 community needs to start looking at
itself over again with the hard realization that if there are any serious
costs involved to using it over an alternative (whether that alternative is
Python 2 or some new kid on the block like Scala) it needs to prove that
worth: making it slightly purer or slightly simpler or even slightly more
consistent is not something that a lot of developers are going to value over
the kinds of costs Python 3 has chosen to make part of the tradeoff of
switching.

~~~
donaldstufft
Realistically there is a value to porting to Python 3, in a year and some
months Python2 will no longer be receiving security updates from Python Core.
This will get taken care of by third parties for awhile but I fully suspect
this support to be incomplete and eventually relegated only to RHEL.

~~~
dded
> in a year and some months Python2 will no longer be receiving security
> updates from Python Core

Is this an official statement? A few minutes with Google produced a number of
articles that claimed five (or sometimes six) years of support for 2.7
starting in 2010, but I couldn't find a clear statement on python.org.

------
cool-RR
I don't share Alex's concern. The migration to Python 3.X is a slow, but in my
opinion sure process. Already many of my small internal programs run on Python
3.4, and I believe that in 1-2 years from now I'll be writing most new Django
client projects in Python 3.4 (hopefully running on Pypy3).

~~~
marcosdumay
I was even a bit surprized when he complained that people don't develop for
Django using Python 3. There isn't even a year that Django supports it (with a
year of "we support, but don't recommend"), and quite a few of its libraries
already got ported.

Yep, people underestimated the time to migration. So what? I completely agree
that migration is happening. Now, let's talk about IPv6...

~~~
baq
ipv6 actually doubles year over year, so it's not that bad. if py3 also
doubles year over year, we'll see both making an impact in 5 years or so.

------
dvirsky
The irony is that what's keeping Python from moving forward is its own
ecosystem.

PyPi makes it so easy to just add small libraries as dependencies to your
project. This is part of what I like about it, but it comes with a cost - this
exact problem.

I actually find the unicode thing a good enough reason to move to Py3, and
porting my company's own code is hardly and issue. But I just had a quick look
at how much of our dependencies support Py3. No surprise - we can't move. Not
without porting a huge amount of code we don't know by ourselves and hoping
the pull requests get merged, or by dropping big dependencies from our code.

How big? Thrift, boto, MySQL-python, hiredis (the native C redis connection
layer), fabric, mrjob - just to name a few. Some of these have big non
compatible dependency trees themselves.

Neither of those are going to happen. So not having a big enough incentive is
not my problem here. The price of migrating is simply too big compared to the
incentives.

I think the only big enough incentive that would cause me to consider
replacing or porting all this huge chunk of dependencies, is something indeed
along the lines of GIL-less massive concurrency a-la Go.

But that doesn't seem to be happening any time in the foreseeable future.
Python 2.8 is a good idea for me as a user, but it will only persist the
problem, not solve it. I don't have any better idea other than Python should
grow one huge carrot to create a tipping point, and enough pressure on library
maintainers to hop on.

------
a3n
Consider the new programmer, or the programmer new to python, or the
corporation/workgroup new to python whose focus is not at all python as python
but just GSD.

They read this, or you show it to them: Should I use Python 2 or Python 3 for
my development activity?
[https://wiki.python.org/moin/Python2orPython3](https://wiki.python.org/moin/Python2orPython3)

It starts off very encouraging: "Short version: Python 2.x is legacy, Python
3.x is the present and future of the language"

Then we skim down to the meat of the page: Which version should I use?

Two short version stating that 3 is great, and you should use it. If you can.

And about 20 paragraphs of caveats.

To the person who's been around the block once or twice, or doesn't want to be
seen as that pie in the sky programmer to his boss whose focus is not
programming and doesn't give a shit about new, what stands out is "you can use
virtually every resource available in 2, and almost mostly totally in 3 also."

And if you're new in any sense, do you really want to spend the time
researching _if_ 3 is going to work for you or your group/boss/career? No, you
pick 2 and GSD.

When that page is gone, or its caveats are substantially reversed, 3 will be
the choice.

~~~
psycovic23
Totally agree. And when one of the suggestions for porting to Py3 is "Decide
if the feature is really that important. Maybe you could drop it?", you know
something is wrong.

------
captainmuon
Python fell into the Winamp trap. If anyone remembers, version 3 was pretty
much crap, and many users stayed with 2.95 for ages. Now, I'm not saying
Python 3 was bad, not at all, but the benefits don't outweigh the cost of
switching for many people.

Here's my idea. Make a new "Python 5" (2+3=5, or call it whatever you want),
based on Python 3. Put back everything that was deprecated or removed along
the way, including the `print` statement. Provide `from python2 import xx` or
`from python3 import xx` if there are incompatible module changes. To deal
with the string changes, introduce an idiom like:

    
    
        bytes, str, unicode = python2_strings
        bytes, str, unicode = python3_strings
    

or:

    
    
        from python2 import bytes, str, unicode
        from python3 import bytes, str, unicode
    

which always maps "bytes" to the byte array (py2 "str", py3 "bytes"), unicode
to the unicode char array (py2 "unicode", py3 "str"), and "str" to whatever
the legacy code needs.

The goal would be to have 95% of legacy code run without modifications, or
with a minimal addition of 2 lines to the top, or a command line switch.

~~~
Too
Your idea is good but i think it has to be taken one step further. You should
be able to import ANY module, third party or not, and specify under which
version to run it. What we need is interop between python 2 and 3.

Just look at this thread. Everybody who disses python 3 does it for library
support, library support and library support. If you could write your own code
in python 3 but still use libraries remaining on 2.7 most people would switch
in a heartbeat. After that it's just a matter of time before the libraries
transition to 3. Now we are stuck in a chicken and egg situation where nobody
wants to make a move.

~~~
dded
> Everybody who disses python 3 does it for library support, library support
> and library support

I like to think I'm somebody, I diss Python3, but I don't diss it for library
support (which is good enough for me). The trouble for me, and at least a few
others, is that Python3 has replaced C strings with byte strings and Unicode
strings and uses the later where Unix expects and provides the former.

If byte strings were actually used instead, there would likely be other
issues. Near as I can tell from this discussion, those who have actually tried
to use byte strings in Python3 have found they don't work well.

------
hansjorg
My last few Python projects have started out as Python 3, but ended up as 2
due to missing library support.

Would it be at all feasible to enable Python 3 to import Python 2 code? I
imagine this could be done without making Python 3 fully backwards compatible,
but I might be wrong.

~~~
chuto
That'll be the crux. When you can run most/all existing python 2 code under
python 3 we'll see the transition. Until then most of us have no plans to even
look at python 3.

~~~
dvirsky
+1, but I'm ont sure how that's going to work. Even if you support Py2 syntax,
some of the internals are different and might cause code to misbehave,
especially the str/unicode/utf stuff.

------
justinph
Something that might help is OS vendors shipping with 3.x installed, rather
than 2.x most seem to.

OS X ships with 2.7.5. For a casual python user, sticking with what is there
and working is safe, especially when the benefits of 3.x are unclear.

~~~
claudius
OS X (at least the version on the Macbook I got from IT) also ships with a
horribly outdated Bash, so I don’t think it healthy to put it up as a standard
for anything…

~~~
plorkyeran
In that case (and all of the other GNU stuff) it ships with the final GPLv2
version, since Apple is unwilling to ship GPLv3 code.

~~~
claudius
Is there a particular reason for that? I can understand not wanting to ship
GPLv3 code if it is embedded sufficiently deeply into the hardware, but it
shouldn’t be a problem to ship GPLv3 Bash, as the user can change the binary
delivered on the harddrive at any time?

~~~
TylerE
GPL has all kinds of non-corporate friendly clauses. I wouldn't touch GPLv3
code in anything I ship either.

Likewise Torvalds refuses to let GPLv3 touch the kernel.

~~~
cma
Torvalds didn't put the "or any later version" clause in the Kernel's GPL
license. And he hasn't required copyright assignments. Because of this, the
kernel simply can't be converted to GPLv3. You would never be able to contact
all the individual copyright holders and have them agree with complete
consensus to re-licensing.

~~~
TylerE
"I think it's insane to require people to make their private signing keys
available, for example. I wouldn't do it. So I don't think the GPL v3
conversion is going to happen for the kernel, since I personally don't want to
convert any of my code."

He's spoken out against it personally - he cleary _doesn't like it_.

~~~
richardfontana
That quote referred to an interpretation of the initial public draft of GPLv3,
which was radically different from the final version published in June 2007,
including with respect to the so-called anti-Tivoization provisions. Of an
interim draft of GPLv3 in March 2007, fairly close to what ended up being
final, Linus said "Unlike earlier drafts, at least it does not sully the good
name of the GPL".

However, you're correct that Linus clearly does not like even the released
version of GPLv3.

[edited slightly]

------
dekhn
I used Python 3 for the first time a few days ago (I've been programming in
Python for 18 years). When I used python heavily (I've switched back to C++
and now Go) I depended a lot on a small number of really good libraries-
ElementTree, NumPy, SciPy, etc. Unless/until all of those get ported to Python
3 (along with hundreds of other programs), and those ports are considered
Correct (in the QA validation sense), it's hard for me to consider wholesale
conversion.

I did it because I was trying to parse Unicode in XML (Apple iTunes music
files) and Python 2 is completely broken when it comes to unicode.

I consider Python 3 a big "fuck you" from Guido to the community. I don't
think he intended it to be so, but the effect of the long transition, and the
lack of backported features in Python 2 (which could be easily accomodated),
coupled with only limited adoption of Python3, demonstrate the leadership
needs to pay closer attention to user pain.

Finally, I don't think Python will ever address the simple and most important
core issue: lacking good multithreading support will make the language
continue to be more and more marginal. CPUs aren't getting much faster, the
CPython serial runtime isn't getting any faster. Multiple cores on a single
chip, and multiple threads in a core, are getting more numerous- and not being
able to take advantage of them using the obvious, straightforward memory-
sharing, multi-threaded techniques the chips are design to run well- is just a
clear ignorance of the future of computing designs.

I switched back from Python to C++ when shared_ptr and unique_ptr, along with
std::map and std::vector became standard enough that programming in C++ became
easy: convenient memory management, and maps/vectors are the two things that
C++ adds to C that are valuable. Then I switched to Go because C++ compilation
times are so bad, and writing high quality concurrent code is hard.

~~~
toyg
ElementTree has always been in 3.x. I believe NumPy and SciPy are finally
making the leap just about now.

~~~
claudius
Numpy supports Python 3 since version 1.5, released in August 2010. Ubuntu
12.04 and the current Debian stable carry this version. Scipy supports Python
3 since version 0.9, apparently released in 2010 as well with releases in the
current Debian stable and Ubuntu 12.04.

‘Just now’ is hence a bit too late, but it is correct that many users have
only been able to use Python 3 some four to five years after 2008.

~~~
toyg
I believe those versions were saddled with "experimental" wording and bugs,
which made people steer away from them. This is all second-hand though, I
personally never used them.

------
martincho
What is needed is a very high quality Python 2.x to 3.x migration or
conversion tool to make library conversions trivial. If developers knew they
could convert any 2.x code to 3.x code with no effort at all and with absolute
certainty of proper operation they would probably migrate to the latest 3.x
release en-masse.

How difficult would something like this be?

This might be really naive on my part. I haven't really taken the time to
study the differences between 2 and 3. I have avoided 3.x out of entirely
selfish reasons: I simply don't have the clock cycles to run into roadblocks.

These days languages are only as valuable as the breath and quality of the
libraries around them. The issue with 3.x is that it created fear of not
having access to small and large libraries developers leverage every day to be
able to focus on their problem and not the problem addressed by the library.
In that regard it is easy to be inclined to criticize Python leadership for
approaching the transition with what might be perceived as a lack of
consideration and understanding of the factors that might hinder it.

EDIT:

Just learned about 2to3:

[http://docs.python.org/2/library/2to3.html](http://docs.python.org/2/library/2to3.html)

Not sure how good it is. A quick look at the page gave me the sense that it
might be somewhat involved. A true converter would be something that is as
easy to use as the the import statement. Something like:

    
    
        import2to3 <some_module>, <some_destination_directory>
    

It should not require any more thought than that and it should be 100%
reliable.

~~~
sly010
TBH i never understood the reason for 2to3. Wouldn't a 3 to 2 compiler would
be much better? Then people could start using python3 as intended, and simply
compile back to python2 if they need to. I doubt there is anything it python3
that would be impossible to emulate with machine generated python2. And no one
would care how the compiled python2 code looks, because it would be temporary.

------
DonGateley
Backwards ecosystem compatibility is a law of nature, not an option. Guido
blithely broke a law of nature and the consequences, which should have been
completely obvious to him, are just as anyone with history in the industry
could have predicted (and most did.)

I'm at the decision point of which one to learn for a long languishing project
I want to use it for. If I could write in 3.x and use the 2.x library
ecosystem there would be no glitch whatsoever in my decision process. 3.x
seems sufficiently advantageous _as a language_ to make the choice easy. As
is, however, since I do not yet know what within the 2.x ecosystem will prove
to be important or essential, my only intelligent choice is to maximize my
options and go with 2.x. The advantages of the 3.x language don't even begin
to outweigh the potential disadvantages of coming up short.

I consider this irrevocable break with backward ecosystem compatibility (given
the magnitude of the ecosystem) to be the worst, most egotistical decision
I've ever seen in the computer field. Almost a death wish.

------
anilshanbhag
Python3 is not exciting because well there is nothing to be excited about.

Consider me an average programmer, I have been using python for a year+ now.
Most of the everyday stuff can be done in 2.7, some functionality I need /
can't do I google and get a solution which works in 2.7. Why Py3 is not
adopted is because there is not much benefit you get for doing the extra work
(think chemistry - activation energy)

On another note, why can't we port it the little goodness back to 2.7 ?

~~~
dded
> Python3 is not exciting because well there is nothing to be excited about.

I think this depends on whether or not you use, or will ever need to use,
Unicode. I don't, and so Python3 is not only not exciting, but it creates a
new problem for me: suddenly, I need to think about the difference between
bytes and strings. Now maybe this is healthy for me, maybe it builds
character. But it also adds effort and work that bring me no benefit. I'd like
to see some of the smaller improvements of Python3--I'd like _print_ to be a
function, but in the big picture I'm better off with Python2.

I wonder if the Unicode problem could be solved in a way that I wouldn't need
to think about it: perhaps utf-8 everywhere somehow.

~~~
Flimm
Separating byte strings from Unicode strings is as close to solving the
Unicode problem without thinking about it as you'll get.

~~~
dded
Perhaps you misread my intended meaning, or I didn't state my position well. I
_don 't have_ a Unicode problem. There _is_ one (suppose HN forum software
were written in Python2, for example). Python3's approach to solving an
important problem that I don't have makes solving problems that I do have
awkward. So I stick with Python2. I have to believe that there are people with
_both_ problems.

------
tristanperry
I'm looking to learn Python, so it's a pitty that there's a schism of sorts
within Python.

This sort of reminds me about PHP 6: a project with initially high momentum
and various ideas to clean up the language. But over time it became clear that
upgrading from the land of magic quote and register globals (PHP 4) to PHP 6
would have been too much of a jump.

So instead they slowly started deprecating and making improvements within the
PHP 5 stream, and bit-by-bit PHP has moved on.

The change from Python 2 to 3 doesn't look dramatic, but I can understand why
there's an air of lethargy regarding the upgrade.

------
ak217
I feel frustrated too, but I think Ubuntu 14.04 will tip the scales (it ships
with Python 3 by default).

Also, the core devs got at least some things right with Python 3.3 by making
it a lot easier to write code that targets 2.7 and 3.3 at the same time. In
retrospect, that should have been the focus much sooner.

~~~
claystu
As a Linux user, I'd like to believe that Linux distros enjoy this kind of
influence, but I honestly can't see how.

How many people are still on Windows? How many are on OSX? How many are
comfortable in 2.x and couldn't care less about new features?

Python 3.x may be better in some ways, but it just doesn't look better enough.

I wonder how long it will be before the 2.x community goes its own way like
Perl 5.

~~~
dragonwriter
> How many people are still on Windows?

Windows doesn't ship with an OS-default version of Python and doesn't include
OS features that depend on the OS-default version of python, so its not as
influential in that regard. But, in that regard, the inclusion of the
multiple-install-compatible python launcher in the basic Windows install of
Python 3.3 probably improves the Python 3.x story on Windows, since it eases
the multiple install pain and makes it easier to work with Python 3.x while
having some Python 2.x software in use on Windows.

------
PaulHoule
The funny thing is I was getting downvoted by the peanut gallery on proggit
and other sites when I was pointing out, years ago, that there is no such
thing as "Python", but really "Python 2" and "Python 3".

It's nice to see that pythonistas are starting to accept what an outsider saw
give years ago.

Frankly the problem is a culture of overpromising and underdelivering that is
endemic to Python. The situation with threading in PHP and Python is really
the same: "it almost works" but the PHP community is responsible and says you
shouldn't really use threads and the Python community is irresponsible and
says "come in the water is fine".

The developers of languages such as PHP, C# and Java value backwards
compatibility. Certainly things break from release to release, but some effort
is made to minimize the effect, whereas in Python 3 they rewrote important
APIs and broke a lot of stuff that they didn't have to break.

~~~
scardine
Threading in cPython is like recursion, it kind of works but is not the
canonical way to write it.

I dare to say that in Python you should always convert a recursive algorithm
to the iterative form, because cPython lacks tail call optimization common in
functional languages and the default recursion dept is only 999; the same way
you should also look for other patterns related to multitasking if the task is
CPU bound (or look for GIL-free implementation).

I agree with you that these (and other) Python "gotchas" need more visibility;
I don't think the language is broken - one could say the default
implementation is broken, IMHO it is just not optimized for a couple classic
software patterns. Once you start swimming with the current (using alternative
patterns), you probably will find some of the design decisions very pragmatic.

------
antrod
There is no meaningful performance increase to go to a backwards incompatible
version? Three letters: DOA. if not performance then at least we'd need some
crazy new feature like good multi threading or perhaps running on a new
relevant platform (say ios or android). Otherwise we will be 2.X forever.

~~~
ak217
Actually, there are some minor performance increases, but there are tons of
minor improvements, and the new async framework landing in 3.4 is very
exciting.

~~~
tbatterii
> new async framework landing in 3.4 is very exciting

this is the killer feature that would move me to python 3. alas, not released
yet. And I took a rails job :(

------
jrochkind1
Meanwhile, in Railslandia, the annoyance is how much time you have to spend
updating your old apps that rely on ruby versions or other dependencies that
are no longer supported.

I'm annoyed that it's looking like ruby 1.9.3 will be end-of-lifed sometime
this spring, and I'm going to have to go and deal with updating a bunch of
apps to ruby 2.0 or 2.1; it seems like it was just yesterday I had to spend
way too much annoying time updating them all to 1.9.3 in the first place when
1.8.7 was EOL'd.

And don't get me wrong, 1.9.3 is _so_ much better than 1.8; and the update to
2.x will hopefully be not so bad, but it's still time I'm spending on the
treadmill instead of new features.

Is there any path between the continual forced march of updates of ruby, and
the lack of urgency so nobody ever upgrades of python?

------
JesseAldridge
Funnily enough, these days I'm spending most of my time writing Javascript. So
that's like two steps back. But that's ok, because the language is not the
bottleneck in software development. The big time sinks are learning new
concepts and managing inherent logical complexity.

------
mixmastamyk
I was downvoted before for remarking that Py 3 needed a killer feature or two
to drive adoption, similar to this post. Perhaps I was not charitable enough.

I'd personally like to see pypy bundled and a complete package manager
solution, as well as usability features like bpython. I don't think it is
necessary to dump it. It just needs a little excitement.

Still, after many years I am finally planning to move my stuff to Py 3.4 when
it comes out next year. No particular reason, it just feels like it is time.
Shame that it doesn't look like it will get into 14.04.

------
daemonk
Rename it as something else. Call it Cobra or something. Also remove all
backward compatibility features. Maybe by taking away it's association with
python, it will have a better chance.

~~~
pdknsk
If Python 3 is renamed Cobra, I'll switch immediately.

And while doing so I will listen to this track from the Cobra soundtrack.

[http://www.allmusic.com/song/skyline-
mt0010878632](http://www.allmusic.com/song/skyline-mt0010878632)

Preferably to its C64 rendition.

[http://ftp.df.lth.se/pub/media/soasc/soasc_mp3/MUSICIANS/D/D...](http://ftp.df.lth.se/pub/media/soasc/soasc_mp3/MUSICIANS/D/Daglish_Ben/Cobra_T01.sid_MOS6581R4.mp3)

------
erikb
I think it's just starting to roll. Only a month ago I argued in my company's
mailing list, that now is the time to finally start moving to Py3. Py3 is more
stable now, most of the big libraries have finally moved. In a commercial set
up it is just stupid to move forward, when the ecosystem hasn't. But now it
has, so now we start. I think people should just continue to improve in that
direction. Maybe it will take 10 years, not 5. But it's definitely going in
the direction of Py3.

------
Rauchg
I think a really good explanation of why people are not switching was provided
by Ted Dziuba: [http://teddziuba.com/post/26426290981/python-3s-marketing-
pr...](http://teddziuba.com/post/26426290981/python-3s-marketing-problem)

------
hyperpape
This seems like a reasonable perspective, but I wonder how much will change
when Python 3 starts shipping with Linux distributions (and probably OS X
eventually).

It won't change anything for the shop that has a million LOC, but it might
start to budge that 2% number.

~~~
r0muald
GNU/Linux distros have been shipping Python 3 for ages now.

~~~
hyperpape
That was sloppy of me. I meant as the only/default python.

------
mangeletti
Ironically, I just started my _first ever_ (Django) web app that is built for
Python 3 only. I learned Python right after the release of Python 3, and so i
learned everything with Python 3 in mind. For instance, I don't think I've
ever used print as a statement. I even used string.format for heaven's sake,
until I learned that there was little chance of the interpolation syntax going
away.

Annnnyway... I am JUST not writing my first Python 3 application, and I have
just installed (on OS X) Python 3 for the first time since 2009 (only as an
experiment at that point).

Create a virtualenv and tell it to use Python 3 via `-p /path/to/python3`,
update your .gitignore to include __pycache__ directories, don't write any
code that uses features or syntax that was removed in Python 3 (since they
added u'' support to Python 3, most devs I know are already doing this part),
and you're literally off to the races. My app's requirements.txt has
django==1.6.1, pytz==2013.8, South==0.8.4, django-debug-toolbar==1.0 (just
released, btw), and ipython (obviously just for shell support). It works
perfectly, and of course mock is included in Python 3, so you don't need that
anymore. There was one caveat though :( Fabric doesn't work, because Parimiko
is too deep a web to quickly update to run on Python 3.

tl;dr

I think Alex wrote this article too late. I think with Django finally having a
release that fully supports (not experimentally like version 1.5) Python 3, a
lot of libs supporting Python 3, and a lot of updates to Python 3 in the past
year or so, we'll probably see quite a few new apps being built for Python 3
in the next year.

~~~
mangeletti
oops, i meant "just now" rather than "just not", which would basically ruin
the entire context of my comment... what an unfortunate typo :)

------
gizbot
The arrogance burns. It burns.

Python 3.0 was derailed by arrogance that developers _should_ commit to a one-
way transition that would touch every function rather than accept that, in
Python 3.0, 'x = u"Hello"' should have been a valid statement. It didn't help
that it ran slower, added nothing, and broke tools.

Python 3.3 was the first release that had a prayer, but there are mistakes
everywhere. For example, virtualenv was included but broke because pip was
not. Libraries like ftfy are required because the encodings break. Explaining
the oddities of scoping inside generator expressions creates tricky interview
questions. And then, Python 3 didn't fix all the broken.

By broken, I mean actually broken. We know where its broken: lots of standard
libraries like collections.namedtuple which has an argument to print a
generated class. Strange cruft like calendar.weekheader() that only helps one
developer's program. This code is in the standard library. Handy things like
cleaning up Unicode, DSL support, local encodings, security restrictions.
Those you add from other libraries.

Also, where's the love? The courage? I would love to see Python seriously
consider dropping case and underscore sensitivity in order to speed up
developers, an_item = anItem +1 would be a warning. I would like to see
language translation support in the language, great packaging that just works,
incorporation unit tests into the package system, reforming the dunder mess,
anything! Instead I see the mediocrity by arrogance.

Just for fun, they moved the US Pycon conference to Canada. Only little people
have troubles with international travel. Arrogance.

~~~
userbinator
_I would love to see Python seriously consider dropping case and underscore
sensitivity in order to speed up developers_

How? By making it harder to find all occurrences of an identifier? Case
sensitivity is debatable since editors have the option to ignore case during
searches, but ignoring underscores isn't something any text editor I've seen
has as a default search feature.

~~~
dded
And in my world, underscore is more common as a word separator than mixed
case. That is, people use 'foo_bar' instead of 'FooBar' or 'fooBar'. (This is
more often true in C or Verilog than Python, however.)

------
doe88
For all its goodness I think it was a mistake to make syntax changes and other
non-backward compatible changes in Python 3.

My current projects are currently compatible with Python 3 and it's my main
target whenever possible (depending on the dependancies).

But all in all this is one of these little things that make developping in
Python less fun than before. This is not my preferred language anymore.

------
mkolodny
I'd love to use Python 3, but missing library support is definitely the killer
for me. There's a list of py3-compatible/incompatible libraries here:
[http://python3wos.appspot.com/](http://python3wos.appspot.com/).

If we can pick off a few of those top py3-incompatible libraries, I'd be
willing to bet that a shift to py3 would follow. Many of the libraries have
long-standing py3 port branches if you'd like to help the effort. For example:
[https://github.com/boto/boto/tree/py3kport/py3kport](https://github.com/boto/boto/tree/py3kport/py3kport).

As far as I'm concerned, there's really very little in the way of me using
Python 3. But what is in the way matters. Starting a project without being
able to use boto, fabric and gvent would be tough. I like the idea of being
able to import Python 2 libraries until they're finally ported over to Python
3 a lot.

------
cpks
The Python community may take this as a wake-up call to realize Python 3 was
Python's Vista/ME/Windows 8, rolled up into one.

My proposal: Call it a development version, and ask the community to upgrade
when Python 4 fixes GIL, adds support for GPGPU, multicore, adds semantics
useful for going fast, true lambdas, tail recursion, and adds all sorts of
similar pretty things.

Forcing an upgrade down a community's throat worked for Microsoft when they
had a monopoly and could stop releasing security patches for older versions.
And even then not well, and giving huge numbers of botnots.

Anything short of that is likely to fail and just hurt the size of the Python
community. If I'm switching, there's also Ruby and a few other places to go
that aren't Python 3.

I don't like, want, or care about Python 3. It's a regression for me. It's not
a popular view, so I'm not vocal about it, but I don't think I'm in the
minority here.

------
hnriot
Python 3 is a huge distraction. It's hard to get people to move away from
languages like java while there's a fragmented python world. If only we could
just forget py3 the python community would be a better, more newbie friendly
place. Every time I hire someone I have to explain why python 2 and why not
"the latest"

------
dec0dedab0de
This is kind of silly, but the main thing keeping me on Python 2 is the print
statement.

~~~
fdej
Same here! So much more convenient in a quick interactive session.

~~~
ekimekim
When I'm in an interactive session I just leave out the print statement, since
it'll print the repr() of the result anyway. And repr is (generally) what I
want.

------
sergiotapia
Wow, can't believe it's been this long and this is _still_ an issue.

------
koshak
about python 3:

    
    
      $ python
      Python 3.3.3 (default, Nov 26 2013, 13:33:18) 
      [GCC 4.8.2] on linux
      Type "help", "copyright", "credits" or "license" for more information.
      >>> import timeit
      >>> timeit.repeat('for i in range(100): i**2', repeat=3, number=100000)
      [4.451958370991633, 4.446133581004688, 4.4439384159923065]
      >>> timeit.repeat('for i in range(100): pow(i,2)', repeat=3, number=100000)
      [5.343420933000743, 5.341413081012433, 5.3455389970040414]
      >>> timeit.repeat('for i in range(100): i*i', repeat=3, number=100000)
      [0.8348780410015024, 0.8323301089985762, 0.8313860019989079]
    
      $ python2
      Python 2.7.6 (default, Nov 26 2013, 12:52:49) 
      [GCC 4.8.2] on linux2
      Type "help", "copyright", "credits" or "license" for more information.
      >>> import timeit
      >>> timeit.repeat('for i in range(100): i**2', repeat=3, number=100000)
      [0.9710979461669922, 0.9630119800567627, 0.9619340896606445]
      >>> timeit.repeat('for i in range(100): pow(i,2)', repeat=3, number=100000)
      [1.7429649829864502, 1.7306430339813232, 1.729590892791748]
      >>> timeit.repeat('for i in range(100): i*i', repeat=3, number=100000)
      [0.6579899787902832, 0.6526930332183838, 0.6540830135345459] 
    
      $ python -m timeit '"-".join(str(n) for n in range(100))'; python -m timeit '"-".join([str(n) for n in range(100)])'; python -m timeit '"-".join(map(str, range(100)))'
      10000 loops, best of 3: 49.4 usec per loop
      10000 loops, best of 3: 40.6 usec per loop
      10000 loops, best of 3: 32.8 usec per loop
    
      $ python2 -m timeit '"-".join(str(n) for n in range(100))'; python2 -m timeit '"-".join([str(n) for n in range(100)])'; python2 -m timeit '"-".join(map(str, range(100)))' 
      10000 loops, best of 3: 30.2 usec per loop
      10000 loops, best of 3: 25 usec per loop
      10000 loops, best of 3: 19.4 usec per loop
    
      $ uname -rom
      3.12.6-1-ARCH x86_64 GNU/Linux

~~~
exDM69
Your benchmark results could use a little explanation.

I notice that all your examples involve using the range() function, which was
changed from returning a list to a generator. In Python2 the memory usage is
O(n) where as in Python3 it is O(1), albeit a little slower.

The first two cases being compared are 3-4x slower in Python 3 but why? Is it
related to Integer->Float conversion? What has changed from Python 2 to 3
here?

The difference in the rest of the examples is not huge.

In my opinion, changing range, zip, map, etc to be "lazy", ie. return
generators not lists, is one of the best things that happened in Python 3.
What you lose in speed will be gained back in memory use.

These toy example micro benchmarks don't really prove anything, it's not like
the cost of iterating a range of integers would ever be a bottle neck in a
practical application. However, the advantage of O(1) vs. O(n) memory usage is
a major benefit and will make zip, map and other related functions a lot more
useful, especially for large lists.

------
brownbat
As a beginner, not a professional developer, python 3 always made more sense
to me. Print is a function, 1/2 is not 0.

I've heard the counterargument about backwards compatibility.[1] That hasn't
ever been just a 2 vs. 3 thing though. pyOpenSSL works with 32-bit 3.2, but
dies with errors out of the box on Win-64 py 3.3. Last I checked, the PaiMei
debugger works on 2.4, breaks on 2.7.

There are several projects that work with a specific deprecated subversion...
it'd be weird if that were a common argument to keep everyone on 3.2, or 2.4
or something.

[1]
[http://help.codecademy.com/customer/portal/articles/887853-w...](http://help.codecademy.com/customer/portal/articles/887853-why-
do-you-teach-python-2-7-3-)

------
PythonicAlpha
I think, one mistake that was made with Python 3 is, that compatibility had
initially very limited attention. They solved many problems of Python 2, but
left the legacy behind ... and there was the trouble:

* Many libraries where limited to Python 2, because the effort converting them seamed to high

* Because of minor problems (like the infamous u"-stuff), the overhead converting simple Python 2 programs was to high.

Some of the problems where fixed later (e.g. infamous u"\- is now legal in
Python 3 and ignored -- why not before??), but I think that than it also was a
little late ... Python 3 has evolved further and many people just got into the
habit to ignore Python 3.

Not caring about compatibility can be necessary, but also can be a burden
(that hurts a long time)!

------
malkia
Almost all Autodesk products come bundled with 2.x version of python. Could it
be that Python 2.x is the Windows 7 of the Python world :) - just good enough
for everyone.

(I'm not a python user, had to write few items for Maya/MotionBuilder and few
other scripts).

~~~
eks
2.6.4... sigh... I do use Python and Maya/Motionbuilder.

It would be great if Autodesk ever did upgrade python to 3.3, but I suppose A
LOT of stuff would break in the process.

But since A LOT of stuff already breaks from each yearly version it wouldn't
matter much... :P

I would bet they will only upgrade it when many new features in PySide
supports only 3.x and up, or if they ever drop support for 2.6.x.

------
JulianWasTaken
Not that this has ever been a showstopper whenever this comes up, but just to
put some chips on the table, I personally have no interest generally in
CPython development on 3.X, but I would pledge some help wherever I could in a
potential 2.8 release.

------
wiremine
Python 3 is a different language from Python 2. Yes, they are _almost_ the
same language, but they are far enough apart to keep people from making the
switch. It feels closer to Perl 5 => 6 vs. Ruby 1.x => Ruby 2.x.

That's a gross over simplification, but it is closer to the truth than the
Python 3 community likes to think.

I wonder: have there ever been a successful language rewrite, post critical
pass, in the history of computer languages? If so, what lessons can be brought
to the current Python 2/3 situation?

For myself, as a professional Python programmer, I like Python 3 a lot. But
until a critical mass of PyPi moves over, it isn't worth the effort for most
projects.

Edit: fixed a wrong word.

~~~
dded
> have there ever been a successful language rewrite, post critical pass, in
> the history of computer languages?

Does K&R C to C89 count?

> If so, what lessons can be brought to the current Python 2/3 situation?

C89 programs could use K&R libraries [1], and C89 compilers could compile K&R
code.

[1] Well, so could Pascal or Fortran programs for that matter. Where K&R-->C89
fails as an analogy to py2-->py3 may be important aspects of what's so
difficult with py2-->py3. (EDIT: added this footnote.)

~~~
wiremine
> C89 programs could use K&R libraries

That's probably the key. If I could use Py2 libraries as-is in Py3, moving to
Py3 would be a minor issue.

------
3pt14159
If Guido had just left division the way it worked in 2.7 we'd all have moved
by now. Everything else the community is fine with, but it is enough of a
sticking point for some people that they can't be bothered to make the switch.

~~~
ekimekim
I think you'll find alot of developers have very different pain points for the
switch. For you, it's integer division. For me, it's unicode strings. Some
people in this discussion even cite the print function.

Long story short, if you're turning something easy into something hard, don't
expect people to switch.

------
ausjke
For web backend I feel the new PHP and its frameworks are good enough.
JS/HTML5/CSS are doing well for web frontend at least, and they evolve fast.
Java did well on Android and enterprise software stack. There are also
Object-C, .NET for their market segments... Nothing can replace C/C++ for
system programming at this point. Additionally, many 'minor' languages are
here for different goals(Go, Erlang, etc).

Now the question, why do I need Python at all nowadays? I spent two years
trying Python and ended up with PHP/C/C++/JS/Java for nearly all my needs.

------
cjdrake
I develop Python code that helps automate the design of Intel CPUs (&
graphics), and we recently (last week) upgraded to Python 3.3.3. Thankfully, I
am less pessimistic than Alex on the subject.

------
RamiK
Fix the GIL.

Python 3 isn't getting used because it breaks backwards compatibility without
offering many meaningful benefits. Sure, the syntax clean ups and the new
sugar are nice and all. But you don't rewrite a working code base because of
"nice".

So, fix the GIL; Replace the spaces indentations with tabs; Take out the
stupid 79 line limit off PEP8; Even clean up the standard library... After
all, if you don't need to worry about backwards compatibility, then you might
as well re-do it all properly.

~~~
smilliken
PEP8 revised the 79 char recommendation to 99:
[http://www.python.org/dev/peps/pep-0008/#maximum-line-
length](http://www.python.org/dev/peps/pep-0008/#maximum-line-length)

It still doesn't agree with you about spaces vs. tabs though.

------
jrochkind1
I understand there are backwards incompatible changes in python 3.

But how hard is it to write code that works under both python 2 and python 3?
Is this easy, or are the number and nature of changes so hard that this is a
pain? How often do people write code that will work under both?

During the ruby 1.8 to 1.9 switch, it was common for people to write code that
worked under both. How hard this was depended on the code base, but usually
ranged from 'very easy' to 'medium but not that bad.'

You had to avoid the new features in 1.9.3 of course; you had to avoid a few
features in 1.8.7 that had changed in backwards-incompat ways; and, mostly
only around char encoding issues, you had to sometimes put in conditional code
that would only run in 1.9.3. That last one was the most painful one, and
overall it was sometimes a pain, but usually quite do-able, and many people
did it.

Now, the ruby 1.8 to 1.9 migration was quite painful in many ways, but the
fact that so many dependencies worked for a period in both 1.8 and 1.9,
without requiring the developers to maintain two entirely separate
codebases... is part of what made it do-able.

And, later, dependencies eventually dropping 1.8 support, of course, is part
of what forced those downstream to go to 1.9.3. But by the time this happened,
all of your major dependencies were probably available for 1.9.3, you rarely
ran into the problem of "one dependency is only 1.8.7 but another is only
1.9.3", because of that period of many developers releasing gems that worked
under both.

~~~
captainmuon
There were a few breaking changes, like renaming things, and they dropped the
"print" statement. It is possible to write code for both 2 and 3, but you have
to jump through a few hoops, and can't use the nice features of Python 3.

The official way to do it was to write in Python 2, and then use a converter
to generate the Python 3 code (which was backwards IMHO). If the Python
maintainers encouraged writing code that worked on both versions, they could
have done a lot to help so (like providing compatibility modules, or
backports).

But more important than new libraries that work with both versions (or even
with just Python 3) is all the legacy code that doesn't run without heavy
modifications on Python 3. If they had refrained from needless breaking
changes (like removing the `print` statement), and made the braking
improvements opt-out (like renaming str->bytes and unicode->str), it would be
much easier to transition to the newer versions.

------
pixelmonkey
Is there a tool that will take a requirements.txt file and let you know
whether all the packages in that file are already Python 3 compatible (by
looking up corresponding packages on PyPI)?

If not, that tool seems worth writing, and then we can do a poll of some major
production codebases and see whether Python 3 support is actually missing.

As for "Python 2.8": meh. I think we should just support the development of
tulip / asyncio in Python 3.4 (see docs, this is looking awesome already:
[http://docs.python.org/3.4/library/asyncio.html](http://docs.python.org/3.4/library/asyncio.html)),
then use our blog platforms as Pythonistas to promote all the new async
programming you can do using asyncio + Futures + yield from, port over
important async frameworks like Tornado/Twisted, etc.

In that case, Python 3.4 becomes the Python release that gives you all the
power / convenience of Python 2.x with a complete cleanup of callback
spaghetti code as demonstrated in the "hello, world" co-routine example:
[http://docs.python.org/3.4/library/asyncio-
task.html#example...](http://docs.python.org/3.4/library/asyncio-
task.html#example-hello-world-coroutine) \-- I think async programming is
mainstream enough, especially in web/mobile/API applications, that this will
be a compelling draw for people.

I think the only thing GvR and crew got wrong is the timing -- it probably
won't take 5 years from release for everyone to migrate to Python 3, but it
will take more like 8-10. But it'll happen.

------
iandanforth
I'll be honest. I'm waiting until Guido says it's time.

The phrase that I have stored at the moment is "Python 3 is the future of
Python." Fine. Great. But that's not good enough.

This page needs to be updated:
[https://wiki.python.org/moin/Python2orPython3](https://wiki.python.org/moin/Python2orPython3)

It should be shortened to read, in its entirety, "Python 3."

------
dorfsmay
What is really needed is a 3to2.

I have been very impressed with 2to3, the amount of work it does is pretty
impressive. But as somebody who tends and prefers to work in python 3 but
often needs my scripts to run in python 2, I have no choice but write those in
python 2. I can see the same dilemma for somebody who writes an open source
library and hope for as much usage as possible.

~~~
JulianWasTaken
That wouldn't solve the main issue, which is the [non-negative] amount of work
in porting existing Py2 codebases.

Besides, 3to2 (which does exist but isn't maintained) and 2to3 are both bad
ideas. They miss edge cases, even common ones, and they add even more
complexity to the build/test/install process which people already find hard.

~~~
dorfsmay
Sure 2to3 misses a lot of edge cases, but it does make porting from 2 to 3 A
LOT faster, doing all the basic stuff for you.

------
jurassic
From where I sit, it seems like the 2/3 schism is the result of "one and only
one way to do something". While is sounds like a good slogan and I was on
board with this party line for a long time, breaking perfectly good features
in pursuit of a more perfect adherence to "only one way" does nothing except
alienate the community.

------
kngl
Making python 2 a little bit more compatible with python 3 is not the way to
go.

What about make python 3 fully retro-compatible with python 2.7 with the help
of magic imports

    
    
        from __past__ import byte_strings
        from __past__ import except_tuple
    

first this will output warnings, then it will raise RuntimeError.

------
paganel
This feels a lot like the migration from Zope2 to Zope3, which everybody was
saying was going to be painless and wonderful and then Django happened. As a
long-time Python user (and a reluctant former Zope user) I hope things will
not turn out the same this time round.

------
hyp0

      [Python 3 releases live in parallel to Python 2] In retrospect this was a mistake,
      it resulted in a complete lack of urgency for the community to move
    

Adoption comes from solving urgent problems - not from creating them.

------
laureny
To make matters worse, I'm seeing an increasing number of Python programmers
switch to Go and I predict that Go will slowly replace Python 2 over the next
few years.

------
mburst
As sad as it may sound, the most annoying thing about Python 3 for me is this:

print "Hi"

vs

print("hi")

Other than that, as Alex said there isn't much difference between the two.

~~~
mathgenius
I totally agree.

I sat silent at europy in 2006 as guido explained he was breaking the print
statement. At europy in 2007, when he gave the same talk, I boo-ed, loudly. He
said "well no-one complained when I talked about this last year." My bad.

Being able to instantly pepper my code with print statements is how I (and
many others) debug. It really gives me the shits these extra parens.

So I continue to boycott py3.

------
JacobIrwin
I think you are speaking to a large audience with this post. All python devs
are continuously aware of the ongoing avoidance of using newer version. It's a
problem that should be addressed even more directly with us all... what are
the key transitional obstacles to overcome when upgrading from, say, 2.7 to
3.x? etc.

Thanks for shining some light on the issue.

------
buster
Ok, so one thing:

Python3 is just now becoming the default for many Linux distributions. Once
that adoption took place the adoption of Python3 will increase very much. It's
as simple as this. Once this milestone is hit, the remaning incompatbible
libraries will see fixes for python3.

------
jemeshsu
All major libraries/frameworks please drop support for Python 2 by end 2014.

------
SimHacker
This depressing problem requires a crazy solution. Rewrite Python 3 in
JavaScript so it runs on V8, and can interoperate with JS code. ;)

------
hyp0
Reminds me of Perl 6, which was designed not to meet a user need, but to keep
the Perl developers engaged. It has succeeded in this.

------
wyuenho
PHP 4 and PHP 5 weren't compatible either. How come migration was so much more
successful over there than Python 2 to Python 3?

~~~
dscrd
Because python 2 works.

~~~
claystu
I feel like this point can't be overstated.

It's so simple, but so correct.

------
steven_yue
I really can not think of a promising reason to switch from 2.X to 3

Sometimes I feel that Python will end at version 3

------
twsted
A pypy-backed Python 4 (with all the features of 3.4) and everyone will jump.

------
paskakapu
python3 destroyed it's ability work as simple calculator. Try this on python3:

>>> answer = 1 + 1 >>> print answer

~~~
dded
I don't have Python3 handy, but in Python2 I do this:

    
    
      >>> answer = 1 + 1
      >>> answer
      2
    

Doesn't Python3 work the same way?

In any case, my PYTHONSTARTUP has this line:

    
    
      from pprint import pprint as pp
    

and I find pp() very nice for printing various structures.

------
JSno
From the cases I saw(might be biased), a lot of new projects start to use
Python3. These projects don't need to consider backward compatibilities.
Majority of people will use python 3 in python world. Regarding Ruby, it is
more elegant and consistent.And also seems Mats has clearer idea where Ruby
will go. so in a long run. Ruby will catch up python in my own opinion.

------
dschiptsov
The problem is that Linux distros are still use 2.7.x as default interpreter.
As soon as they complete migration to 3.3.x everything will improve, and
maintainers of the packages would be pressed to cope with reality.

At least mod_python already aware of existence of python 3.3.x ,)

------
revskill
I wonder why Django doesn't have the same strength (both technically and
community) as Rails ? I think the philosophy "Everything is an object" makes
sense actually, and in combination with functional programming built-in really
makes Ruby is perfect choice for non-professional programmer (even woman) to
love coding.

~~~
SEMW
> perfect choice for non-professional programmer (even woman)

It's 2013. Could we please leave 'so easy even a _woman_ could use it' levels
of sexism behind us?

(Not to mention - it's a little silly to single out web frameworks as the One
True comparator of two languages. That Rails is more popular than Django does
not necessarily imply that Ruby is a better language than Python, any more
than the fact that SciPy is more popular than SciRuby implies the reverse).

