Python 3 makes it easier to develop high-quality software

http://migrateup.com/main-difference-python-3/

by ColinWright • 11 years ago

237 238 11 years ago

zingermc• 11 years ago

Your title is a little misleading, since you actually discuss three differences.

Just checking - you do understand that the person who submitted the link is not the person who wrote the article, right? Just thought I'd ask, because the wording of your comment seems to think otherwise.

trextrex• 11 years ago

I think the OP means the single main difference is "Python 3 makes it easier to develop high quality software." and gives three examples of this.

badloginagain• 11 years ago

Which still doesn't make much sense. One thesis, "better software", three supporting arguments.

It's ok to be pedantic, but only if you're correct about the thing you're being pedantic about.

jessaustin2• 11 years ago

Nothing about unicode handling?

rspeer4• 11 years ago

People who care about handling Unicode correctly have already made up their mind.

Many people don't, though. Many people run their Python scripts in cmd.exe.

the_mitsuhiko2• 11 years ago

Many people don't, though. Many people run their Python scripts in cmd.exe.

Did you know that cmd.exe supports unicode just fine? It's Python that does not (out of the box). The development version of Click for instance supports input/output in cmd.exe with both 2.x and 3.x.

Unicode is not a feature of Python 3.

the_mitsuhiko2• 11 years ago

Unicode works just fine in 2.x for people that give a shit :)

jessaustin2• 11 years ago

Yes I recall you having written as much, several times! b^)

ptx2• 11 years ago

It's a lot easier to work with in 3.0, though.

For example, xmlrpclib in 2.x will return either str or unicode depending on whether the particular piece of data it's returning happens to contain non-ASCII characters. In 3.x it always returns a unicode string.

Grue32• 11 years ago

I'm sorry, but given how much high quality software is written in Python 2, examples of high quality software written in Python 3 more easily would do a better job proving the central thesis of the article than pointing out design defects of Python 2 fixed in Python 3. Because at the end of the day, there are still plenty of design defects in Python 3 (or any other language) that a coder might trip over. I mean who is to say that new yield functionality of Python 3 wouldn't lead to hard to understand spaghetti code? Or the new way of handling Unicode isn't worse than the old way? Listing concrete projects that benefitted from being written in Python 3 rather than 2 would be much more convincing.

minimaxir• 11 years ago

I'm sorry, but given how much high quality software is written in Python 2

The reason for that isn't "Python 2 is intrinsically better than Python 3," though. It's the sheer inertia of a language whose last minor version (2.7) was released five years ago and the persistent meme that Python 3 is buggy and unusable, despite clear advantages as noted in the article and the added compatibility of popular Python 2 packages in recent years.

As with hardware, Python 2 will only die when the top packages completely drop support for it, and it wouldn't surprise me if that happens sooner than later. (Django, for example, will be dropping Python 2 support in 2017: https://www.djangoproject.com/weblog/2015/jun/25/roadmap/ )

mkohlmyr• 11 years ago

As I understood it he was saying the better way to prove Python 3 is good for creating high quality software might be to look at the high quality software already written in Python 2, rather than pointing out flaws in it - since all programming languages will have flaws (including Python 3)..

legutierr• 11 years ago

Why refer to these as two separate languages? Right now, the vast majority of Python's most popular libraries and packages support both 2.7 and 3.4+ with a single code base. We are a Python shop, and we are doing the same with all our new projects as well. There's a little bit of extra awareness you have to have to do certain things (metaclasses, for instance), but the overhead is no more onerous than, say, following well-defined coding conventions.

Grue32• 11 years ago

The latest Python 2 specification is five years old, but new implementations are still being released (PyPy 4: October 29, 2015). Similarly, the latest Common Lisp specification is from the 80s, but there are still several implementations compatible with modern OS's. As long as the language is useful for somebody, it will be kept alive.

gdulli• 11 years ago

Complaints about a language translate automatically to low-quality software the same way micro-optimizations automatically translate to fast software.

In the real world, software depends significantly more on the properties of a developer or a team. Building software is about people more than it's about tools.

osullivj• 11 years ago

For me it was these two...

1. Calling the next( ) builtin instead of .next( ) method on an interator or generator.

2. .items( ) on a map in 3 is like .iteritems( ) in 2. Which means that nasty short cuts like map.keys( )[0] no longer work.

Oh yeah, and print( ) is a function :)

lqdc137• 11 years ago

I think a bigger issue with keys() is that now the order is non-deterministic. So people may have relied on it not being in any particular order but being the same order. These are the kinds of bugs that are difficult to detect.

dalke3• 11 years ago

I don't understand this comment. The hash method changed under different releases of Python 2.x, enough that was had to change our doctests to ensure a consistent order. So as far as I'm aware, the only guarantee is that calling .keys() and calling .values() will give you the terms in the same order, so long as there hasn't been a modification in the middle.

emodendroket2• 11 years ago

Every programming language, programming language update, and programming tool since the dawn of time claims to make it easier to produce high-quality software.

Amorymeltzer• 11 years ago

Brainfuck

Seriously though, the point is well taken. The right tool for the right job will always apply, and I like to think most developers and programmers acknowledge that there are very few tools that should be used in every opportunity and by every person.

Vendan• 11 years ago

Interestingly Brainfuck has a use, though it is an obscure one. It's proven to be turing complete, and has a rather trivial set of instructions and rules. If you can write an interpreter for it in another language, you prove that language to be turing complete as well.

rch• 11 years ago

This article makes a cogent case for the assertion at least.

parent5446• 11 years ago

The difference being while a lot of people argue against upgrading to Python 3, I've never heard anybody argue against upgrading to PHP 5.

emodendroket2• 11 years ago

I don't know the version but I saw one program written in PHP break because there was a custom function called "goto" and a later version added that as a keyword. But often people don't really have a choice as to whether PHP is upgraded or not since it often runs on shared servers.

CydeWeys5• 11 years ago

And oftentimes it's true. Not sure what point you're trying to make here. The linked article pretty convincingly makes the case for the listed improvements in Python 2 -> 3.

Just because "Use X, it's better" is a frequently made argument doesn't mean it's wrong, especially when X actually is better!

angelbob3• 11 years ago

When saying "the main bottom-line difference between X and Y is that Y is better", you're implying that you'll say something interesting and nuanced and then... not.

I could say "the main difference between Ruby 1.8 and 1.9 is that programs run twice as fast in 1.9" (true, 1.8 is dog-slow.) And that's "Y is better", but it's also fairly specific.

"Python 3.0 makes it easier to produce high-quality software" is annoyingly vague. They seem to mean software that behaves more consistently by reducing the amount of default unpredictability in the language spec -- that's fair and specific. It's also not what the article said, sadly.

njharman3• 11 years ago

That's because people don't generally make shittier things. It happens, rarely, on accident. But by and large (for computer languages) newer == better.

S4M• 11 years ago

That is only true for the languages that manage to gain some momentum. I could probably write a new language, given some time (I am not underestimating that task), but most likely it wouldn't bring anything new so nobody would use it. I'd say that language designers who manage to convince one person to spend the time to learn their languages for a pet project have already done a good job.

yeukhon3• 11 years ago

This is excellent. The first one is totally unknown to me. I wish there is a comprehensive changes between 2.7 and 3.X with code, release notes is okay but falls under different version and hard to grasp at once.

It's really hard to keep up with language changes and implementation changes.

EDIT: I am so surprise at the number of downvotes in this HN thread. I bet there is some haters out there today :-)

maxerickson6• 11 years ago

The first one was a headline change in the Python 3000 release notes:

https://docs.python.org/3.0/whatsnew/3.0.html

The other items in the article are also mentioned there, but not as headline items. The great majority of behavioral changes from 2.7 to 3.x should be listed in that one document, there was a freeze on language changes for several of the 3.x releases.

yeukhon3• 11 years ago

That level of code demonstration from the author is more comprehensive than the documentation in what's news.

A lot of the PEPs are way too verbose for a quick bite. PEP are great for a weekend read, but for a quick summary, OP does a better job.

redsymbol• 11 years ago

Does this serve well enough as a comprehensive diff?

http://migrateup.com/whats-really-new-in-python-3/

(Actually, maybe not, because it doesn't have code examples.)

Alex3917• 11 years ago

Given that even a relatively inexperienced developer can easily port 2,500+ lines of Python 2 to Python 3 per day, there's really very little reason for anyone to still be on Python 2 regardless of the benefits or lack thereof of Python 3. This is especially true if you're not trying to take advantage of all the performance benefits of Python 3 right away, and are content just to wrap iterators in list() or whatever just to get the functionality working the same without much effort.

sago• 11 years ago

It's libraries rather than porting.

Funnily, though, I just thought 'yeah there's that library I use, they never ported that', for one of my codebases. Just looked it up and they now have ported it. So I guess it's time for me to do the same. I wonder what proportion of (actually used) libs are Py 2 only still.

spdionis2• 11 years ago

TensorFlow?

ensignavenger3• 11 years ago

At this point very few 'actually used' (meaning, used by more than a handful of organizations at most) are Py2 only. There are a few still in the process of porting, and a few that will never be ported due to being replaced (but are still somewhat popular for one reason or another.)

For those who don't know: http://python3wos.appspot.com/

yeukhon3• 11 years ago

Most servers are probably still running on Python 2.6 and 2.7.

untothebreach• 11 years ago

Between virtualenvs, containers, or just plain ol' `make altinstall`, there are enough ways to run a python application that _doesn't_ use the system python interpreter that this shouldn't be an issue. Not to mention that most linux distros have packages set up in a way to allow python 2 and python 3 to be installed simultaneously, without interfering with system applications that rely on the version of python that is shipped with the OS.

n0us2• 11 years ago

It's easy to port to python 3 but I think the holdup with some libraries is that they want to support both 2 and 3 with the same library so that devs who cannot upgrade the python on their system don't get left behind. Supporting both at the same time is possible but takes longer in most cases.

greyman• 11 years ago

I picked up Python about 1 year ago as my hobby language, and following the common advice, I started with 3. But I quickly encounter two problems:

1) some libraries I actually wanted to use were still 2

2) When I tried to google a solution for something, more than once I stumbled across a code which just didn't work. Then it occurred to me, that this is because the example is Python 2, while I am on 3.

To sum it up, I later switched to 2, and everything was fine since then. I also asked my friend, who is a professional python programmer, and to this day his company still uses 2 and don't plan to switch.

eeZi10• 11 years ago

1) some libraries I actually wanted to use were still 2

For anyone still in this situation, re-evaluate them - that issue is mostly solved.

Python 2 is deprecated. It's no longer supported after 2020. There's no point in using it for new projects, unless there's a very good reason. You're missing out on lots of incredibly cool features like asyncio and static type checking.

There's even an increasing number of Python 3-only libraries.

tim3332• 11 years ago

I just read the http://lucumr.pocoo.org/2014/5/12/everything-about-unicode/ article referenced elsewhere in this discussion and it illustrates why there is some stuff that is not so easy to port.

twright0• 11 years ago

This seems like your mental model assumes relatively small codebases. On a codebase with 1m LOC, your estimation of 2500 lines/day still takes ~400 person-days. That's a big investment to put into something that doesn't present clear benefits. Moreover, converting a huge codebase piecemeal is something of a challenge; I don't know if it's even possible to have python 2 importing python 3 (or vice versa) but assuming your large codebase is relatively interdependent, reorganizing the codebase such that you can split it into modules which can be migrated independently could also be a big undertaking. I would also anticipate that there would be a long tail of fixing bugs caused by incorrect migration (are we code reviewing those 2500 lines/day?) as well as lower productivity as developers get used to the new language.

This is why you frequently hear that large, established codebases that control their environment aren't updating to Python 3. It's pretty easy to move a few thousand lines over but complexity scales non-linearly with the size of the codebase.

anewhnaccount• 11 years ago

And how many subtle bugs will be introduced during porting software for Python 2 to Python 3?

agentultra• 11 years ago

The traps and tricks are well known. With due diligence -- few if any.

lqdc137• 11 years ago

The traps are not always well known (to me).

For example, I just discovered a few days ago while porting a Python2 library that byte concatenation is an O(N^2) procedure in Python3 while it is an O(N) procedure in Python2.

So you have to use bytearrays and really rewrite all the code that deals with bytes. Basically, even if something works, you still have to performance profile.

m0th87• 11 years ago

We ported a major production site from python 2 to 3 a year ago. Exactly one bug has come up - something to do with unicode encoding on a relatively minor part of the site. Thanks to 2to3, the concerns for bugs coming up in porting are way overblown.

brbsix3• 11 years ago

The only insidious issues I've encountered with porting apps have been related to Unicode as well. A lot of old Python 2 code is (what appears to me) very hackish compared to the elegance that is Python 3.

sinxoveretothex• 11 years ago

Slightly tangential, but I wish this blog would date its posts.

Reading "If you're starting a brand-new application today, there are plenty of valid reasons to write it in 2 instead of 3. There will be for a long time." on the same day it was written is not the same as 6 months or a few years down the lines.

I don't actually know when this was written except for the copyright: 2014-2015, so it can't be more than a bit short of 2 years ago.

teraflop• 11 years ago

The Wayback Machine reveals that it was posted sometime after September 2015: http://web.archive.org/web/20150921221742/http://migrateup.c...

seliopou• 11 years ago

I remember seeing a retweet in my stream a couple months ago where somebody made the suggestion of not dating blog posts so as to make them seem less ephemeral. I think the logic went that if the writing isn't tied to a single moment in time, then it'll become timeless.

It's one of the more irrational and idiotic suggestions I've ever come across. One of, if not _the_ most important piece of metadata for anything that has or will ever exist is its creation date. In particular for writing, putting it in a historical context usually makes the piece more powerful and increases your understanding of the subject. If it's bad writing then it's not going to have a chance anyway. Sorry to say but that may be true of the post in question. I was under the impression that due to poor Python 3 adoption, Python 2.7 would continue to be supported.

I second OP, please date your blog posts.

dogecoinbase• 11 years ago

"If you're starting a brand-new application today, there are plenty of valid reasons to write it in 2 instead of 3. There will be for a long time."

This has been true for the last seven years, and I certainly don't see it changing anytime soon.

tibbon• 11 years ago

I still don't understand what happened here historically, was there ever an upgrade path or way to make this a smooth transition? I can't think (surely there is) of another language that had such a hard-breaking version change that still persists 10 years later as a fracture across the community.

maxerickson6• 11 years ago

It hasn't been 10 years. There were known IO performance regressions at the time 3.0 was released, nobody involved in releasing it would have said to use it in production right away. 3.1 was released ~6 years ago:

https://www.python.org/download/releases/3.1/

(Even if the above is deemed BS, the release of 3.0 was 7 years ago)

Many of the 3.0 features can be switched on in 2.7 and there were some attempts to automate as much of the code change as possible (but people ended up preferring to write code that runs on both 2.7 and 3.x, but I suppose that then is not really evidence of a fracture).

saurik• 11 years ago

I remember quite distinctly when the Python 3000 manifesto was released just under ten years ago, in April of 2006. That is when the line in the sand was drawn and the key mistakes were made that caused the "schism" in the community. What the Python community was screaming for was a fix for the GIL and the other performance issues in Python, not minor changes to Unicode handling that were maybe awkward but perfectly possible to get right in Python 2.6.

Google seriously spent tons of effort at the time trying to remove that GIL. They were one of the biggest proponents of Python at the time, and frankly they were part of what made it so successful. With their work on Unladen Swallow not making meaningful progress and the Python core developers concentrating on Python 3000, making it clear that they don't even care, it isn't a wonder that Google was hedging their bets by hiring Rob Pike to work on Go, which many now see as most directly being a competitor to Python, and which has sapped a lot of people who would potentially be Python users.

Meanwhile, the broken release of 3.0 needs to be blamed for part of the problem, not used as a reason to delay the historical date of fracture: a lot of things were broken in 3.0, including some basic things that Python got wrong in Unicode. The performance regressions were not quickly fixed, making people hesitant of the benefits of Python 3, and the Unicode issues (which were not fixed until years later, when they added the round-trip-safe Unicode conversions; but even this is a workaround, as filenames are defined to be strings of bytes by the filesystem) were ironic as the whole point of Python 3 was to somehow be better at dealing with Unicode :/.

And you seem to be forgetting that the real problem was not the features added in 3.0 but the features taken away at the same time that made it impossible to write reasonable code that ran on both 2.7 and 3.0 even for extremely simple cases like "catches an exception". They only just a year or so ago have started to crack their party line of "shut up and upgrade to 3: it is better and you are wrong" and add some backwards compatibility features to 3.x, such as supporting the u prefix (which was the absolute dumbest thing they could have removed).

WorldMaker• 11 years ago

VB6 versus VB.NET is a worse historic pothole of a version change for arguably the same language.

Ultimately the Python 2 -> 3 transition has been as smooth as developers make it. There are certainly a lot of transition efforts put in place, such as the ability to import from __future__ some of the 3 behaviors and abilities and some automated migration tools. At this point, too, most of the major libraries today support 3 and there's few reasons not to build for 3 and maybe do a few tweaks to also support 2, if you truly have to. (A lot of good 3 code runs on 2 unmodified and just needing the Python equivalent of polyfill libraries and __future__ imports.)

Some of the fracture has been binary ABI compatibility and mini-versions of this struggle can certainly be seen in just about any language with an ecosystem of cross-platform native libraries to support (the brief Node/io.js being an interesting fracture more in that it was resolved so amicably so relatively quickly).

But ultimately it's tough to resolve the psychological and political hurdles: for whatever reason there seem to be "die hard" Python 2 fanatics that hate the direction Python 3 has moved and don't seem interested at all in compromise or transition. It certainly doesn't seem to be as strong as the hate divide between VB6 and VB.NET (which will likely forever be a weird blood feud until VBA and VB6 programmers die of old age), but still haters are gonna hate.

brbsix3• 11 years ago

There is a library (and script) called 2to3 that automates code translation from Python 2 to 3. I wouldn't rely on it for my own projects, but I have seen a number of authors use it successfully (e.g. write their app in Python 2 and tell users it is compatible with automatic translation).

If you're on 2.7.x, you can certainly import in quite of the newer features. There are also some resources for writing 2/3 compatible code, such as the six library and http://python-future.org/. It is no problem for fairly trivial applications, but I don't envy anyone who has to ensure 2/3 compat for a large project.

kansface• 11 years ago

Floobits was forced to write python 6 ... or 2/3 ... for our Sublime Plugin. The python3 experience has been awful enough to completely dissuade me from using python for any other project. Completely breaking backwards compatibility for small features no one cares about was a complete disaster as evidenced by half? of the community still using 2.7.

yellowstuff• 11 years ago

Perl 6 started 15 years ago.

Perl was the workhorse of the early web, when I was a young programmer interested in the web it seemed like the most worthwhile language I could learn. Perl isn't dead but it's lost most of its appeal, and a large part of that is due to the failed development on Perl 6.

crusso• 11 years ago

Yeah, but that's not really the same as what has happened in the Python community where Python 3 has been available for so long but there's still resistance to making the shift.

Perl 6 still isn't available.

mangecoeur3• 11 years ago

The transition has been pretty smooth, but quite slow. Nearly all the major libraries are update - IMHO if a library doesn't support Python 3 these day's it's probably unmaintained and should be avoided. There's plenty of support for transitioning smoothly especially with a handful of changes in 3.2 and 3.3 to make this even easier.

I think there are however a small number of very vocal people who didn't like the change, and their posts tend to linger...

pornel• 11 years ago

This is sad and frustrating. The article is trying to convince people to upgrade to a 7-year-old version of Python! And everyone is still skeptical about it, thinking it's too new, too risky, unproven, and libraries aren't ready yet.

Python 3 adoption takes longer than entire NodeJS lifetime. In the same timeframe PHP introduced and EOLed 5.3 (edit: and there were 4 years between release of 5.0 and EOL of 4.x, which involved backwards-incompatible refactoring of OO semantics).

GFK_of_xmaspast• 11 years ago

I don't have any compelling reason to move off of python 2.7, and for my use cases the positives are outweighed by the negatives (in particular getting used to needless changes).

upofadown3• 11 years ago

You missed a whole subclass of people. Those that don't like Python3. Personally I believe Python3 took a wrong turn with the approach of converting everything to UTF-32 and making a big deal about the philosophical difference between "strings" and "bytes". I very much suspect the future will be something like how Julia deals with the issue, where UTF-8 can be just left as UTF-8.

maxerickson6• 11 years ago

Recent versions only convert to UTF-32 when a wide character is present (they also use 2 byte characters when that is sufficient):

https://docs.python.org/3.3/whatsnew/3.3.html#pep-393-flexib...

Glancing at Julia, I'm not sure "invalid character index" is really a great thing to have to handle when dealing with text. It does seem that systems for dealing with text will eventually offer various apis beyond just a somewhat disfunctional character api (which I think is a fair description of str in Python 3).

mangecoeur3• 11 years ago

Apparently you don't deal with much non-ascii data if you don't like python3's string handling. It's literally the reason I first upgraded, because reading in simple text data on Python2 can break completely. Seeing as literally no language on earth can be written entirely in ascii characters (since even English text can contain words with accents or old fashioned things like the long s ſ) this is a pretty big issue.

Yes it is possibly to laboriously add code to check and encode/decode text, that might sometime be text and sometimes binary pretending to be text pretending to be binary. But why go through that pain when you could just use Python3 where things are clear and generally actually work.

Avernar9• 11 years ago

I agree. Everything is so much simpler when you use UTF-8 everywhere. Being effectively forced to use the ASCII/UCS2/UCS4 unicode type in Python3 is the only thing that has kept me from switching to it.

shubhamjain• 11 years ago

I don't believe its the same. Code from old version of PHP could still be expected to run the same in the newer version except for "deprecation" warnings maybe. Probably, a reason why it is not easy for PHP devs to fix all typecasting quirks their language has.

Python 3, on other hand, has tried to fix many design decisions and hence requires some transition effort. The effort is many folds more with so much software already written in Python 2 and large codebases. I am not surprised the adoption is slow.

frik• 11 years ago

There were plans for a never released PHP6. Even some books were published for PHP6, it was meant to be the big unicode release. Most of its feature made it to the 5.4 version. In the end, it seems that it was the better decision to introduce new features in a smoother way. PHP hasn't suffered the problems that exists with Python 2 to 3. Although, there was the PHP4 to 5 transition that broke the older object oriented implemention - though most never used OO in PHP4 as it was known to be slow - so it wasn't a problem for the community.

strictnein• 11 years ago

Speaking of Node, it still requires Python 2.7, right? Or at least node-gyp does: https://github.com/nodejs/node-gyp

gsnedders• 11 years ago

gyp itself still relies on Python 2 (and, to my knowledge, Google has mostly moved on gyp, so they're unlikely to do anything large to it).

eeZi10• 11 years ago

Python 2 devs are also missing out on the amazing ecosystem developing around the new async features.

There are asyncio ports of many popular and less popular libraries, and it even has a nicer syntax than NodeJS.

msellout• 11 years ago

I think we're going to see the switch occur quickly now. This year I've seen several large enterprise projects using Python 3. Also, the release of v3.5 brings useful features that will not be backported as 2.8.

njharman3• 11 years ago

I think there is way less "anti" python 3 attitude than there appears. A few haters, a few blog spam/click baiters, a few people who never even looked at python3. Vast majority of people using Python3 (me included), just use it. It's not a big deal. No reason to toot my horn over it.

There is lots of FUD from early 3.0-3 days. Python 3.5 is solid and well supported by 3rd party libs check this out

https://caniusepython3.com/

Python3 has been adopted, now. It just isn't newsworthy so we don't hear about it.

vegabook3• 11 years ago

This is true and incomplete at the same time.

It's true that 3 is happily happening for many people, effectively and without fuss.

But it's incomplete to pretend the schism is not an issue; not to try to understand the pro-2.x points which many reasonable users have.

Its a huge issue, even now, and to pretend it's not there is to do BOTH pythons a disservice because it will simply serve to feed the disagreement, to the detriment of both flavours of the language.

The Python 3 project needs to understand where it went wrong, acknowledge it, 'better language' arguments (true-ish but largely ineffective) notwithstanding, and try to bridge the community.

Yes the 3 segment reasonably wishes all this would just go away so we can all focus on moving python forward, but it's not going away. It must be adressed without yet another post about 3 being better, which simply makes 2.7 people feel like second class citizens. They've heard all the arguments before.

Animats• 11 years ago

No, it hasn't, based on download stats of packages. Guido found this out the hard way when he went to work for Dropbox. They run mostly Python 2.7 code, and now he has to maintain it.

Also, PyPy is 2.7 compatible, although there's a 3.x beta.

fredrik-j• 11 years ago

While CPython 3.x is rock solid and shipped years ago - no argument there - both Pypy and Jython still lacks stable Python 3.x releases. That's a major migration pain point.

It is hard trying to introduce Python 3 at a place that has systems that depend on both Cpython and Jython. Jumping between python 2 and 3 between projects is quite taxing mentally. And staying on python 2 only leaves me with a sense of lingering doom to say nothing of having to endure all the idiosyncrasies of python 2.x. I really enjoy the few moments when I can use Python 3.

It is perhaps easy to consider the 2 vs 3 debate over and done with for people who can just disregard Pypy and Jython entirely in their environment. I probably would think so myself had I not been so unfortunate to be the unwilling maintainer of solutions dependent on Jython right now.

Semiapies• 11 years ago

I'm not sure how to even read this, after I give it the requirements file for my last Flask project. It says six projects block transition for me, then offers me a goofy badge saying 4 blockers. Over on the right, the top thirteen of the projects in my file are black and not given as links.

(However, it is clear that going to Python 3 would not work.)

incepted• 11 years ago

It's unproven because nobody uses it and nobody uses it because it's unproven.

rdtsc3• 11 years ago

And everyone is still skeptical about it,

They are not skeptical. Nobody thinks "yeah if I just wait long enough, Python 3 will go away and 2.8 will come out".

They just don't see an incentive to update. Simple as that. It is basic economics of time and money.

Python 2 wasn't terrible and Python 3 isn't dramatically better. Unicode and other stuff in Python 3 is nice. Is it nice enough to start digging into stable, working, money making code just to say "Yay, Python 3"? I think the development community has spoken by how it was handled. It's gonna happen but it will happen at a very slow pace.

Imagine this alternative scenario -- "Python 3 brings 3x speed improvement + removed GIL". Ok, I bet you, there would have been a much faster adoption because now there is a greater incentive to justify it. People would think "Yeah, I'll destabilize my code a bit but I gain performance, I can do that".

Someone in a sibling comment suggested "They should have just stopped updating security patches for 2.7, that would have forced them to use 3.0". That's ok if Python holds a monopoly on development languages. But it doesn't. As soon as that happens developers will not just look at updating to Python 3, they'll start looking at other ecosystems: Go, Elixir, Java, Clojure, Scala, NodeJS etc.

mangeletti2• 11 years ago

I could not agree more.

To add to this; if it included even a 2x speed up / memory reduction, I think 90% of everyone would have switched by now, and you know what else? Go probably wouldn't exist.

s73v3r• 11 years ago

I would say that actual, continued support is an incentive to update.

jrumbut2• 11 years ago

I think the energy spent supporting Python 2 and the inability to really unify and focus the community on Python 3 is preventing or delaying that kind of dramatic improvement.

If people would rather move to another ecosystem rather than update their code that's fine. The Python community doesn't get paid a nickel every time the interpreter runs, (at least slightly) engaged users are what move Python forward.

k_sze• 11 years ago

I would argue that removing the GIL would scare the shit out of developers and slow adoption instead of hasten it. A lot of accidentally thread-safe code would suddenly become thread-unsafe.

falcolas4• 11 years ago

I've said it before, I'll say it again. When all of the major Linux platforms provide the same pre-built Python 3 packages for the packages I use, I'll make the migration. Until then, it's just easier to stay on Python 2.

Yes, I could build the packages/wheels myself. Yes, I could install a compiler on the target machine and let the binaries build from scratch. I won't, however, since it's a lot of time for remarkably little benefit. Python 2 is still well supported, and is a great language to program in.

Yes, Python 3 has cleaned up some of the rough edges of Python 2; but the improvements are still not significant enough to offset the cost of porting libraries and building packages.

maweki• 11 years ago

but for node we expect everyone to install/build from source an not use the supplied packages because they are ancient, in comparison.

Which distribution doesn't ship python3.3?

falcolas4• 11 years ago

Most ship python 3.3, but most of the libraries which the distro provides pre-compiled are not Python 3.

e.g.

python-mysql python-django python-keyczar python-pyhsm

but for node we expect everyone to install/build from source an not use the supplied packages

This is not necessarily an improvement in the state of packaging. Verifying that unsigned source code has not been changed is a hard problem (which NPM has not yet solved). Installing compilation tools and extensive header files on a production machine opens up a new class of security vulnerabilities on that machine (whether a VM, container, or bare metal).

mcguire• 11 years ago

"Yes, I could install a compiler on the target machine and let the binaries build from scratch."

Are we talking about the same Python?

falcolas4• 11 years ago

Yes -- specifically packages with c shared libraries. The kind you get when installing bcrypt, python-mysql, or any number of libraries with optimized binaries.

collyw• 11 years ago

Don't you use a virtualenv? There are benefits beyond having up to date packages and its not especially complicated (I am guessing it would take an hour or two to learn).

falcolas4• 11 years ago

Yes, I know about virtualenv. I also know it still requires either having pre-compiled wheels, or a compiler on the frontend. Same problem, a bit better isolated from system packages.

Ologn• 11 years ago

I alternate between 2 and 3 depending on the system, but I am like you as well - me using 2 has nothing to do with philosophical differences and all of that, it has to do with my Linux distribution having more python2 packages than python3 packages.

mixmastamyk2• 11 years ago

install a compiler on the target

One solution, build on your dev machine and produce distro packages instead.

klunger• 11 years ago

It doesn't help that Mac books come with 2.7 installed. For someone starting out (Python is often used as a teaching language in CS101-esque classes), figuring out how to get one's machine to use 3 might seem really difficult/impossible.

sigzero2• 11 years ago

Almost everyone will say "Use homebrew". I don't think it will that difficult.

tim3332• 11 years ago

Yeah brew install python3 seems to work. You then just type python to run 2 and python3 to run 3. The compsci course I did was in Python 2.

thrownaway24243• 11 years ago

Py3 is a completely different language that happens to share the same name as Py2. If you want to talk about typed comparisons you might as well mention C++ and Java and Go and Rust, because you might just as easily move from Py2 to any of them, as from Py2 to Py3.

eeZi10• 11 years ago

Not true. Not only can most of the code be used verbatim, but the libraries and APIs are still the same - which would constitute most of the porting effort to another language.

A Python 2 dev can learn Python 3 in a day.

arbitrage• 11 years ago

It's the kind that easily sneaks its way past the most vigilant unit tests

If your unit tests are the most vigilant, you'll test the output of that function for just such a comparison.

avoutthere• 11 years ago

Python 3 makes it easier to develop high quality software

That is, unless said software needs to include a popular library that has not been ported.

eeZi10• 11 years ago

There aren't many unported popular libraries left. Actually, the only one I remember off-hand is Twisted, and they're working on it.

njharman3• 11 years ago

Circa 2010 is calling and wants its FUD back.

dagw• 11 years ago

Popular libraries aren't the problem. The big problem is unpopular and obscure libraries.

snake_plissken• 11 years ago

On a tangential note, no pun intended, I am a little confused. Why would you ever want compare in the manner of "TrickyAngle(6) < TrickyAngle(5)"? I can understand something like "trickyAngle_A.degrees < trickAngle_b.degrees" but when comparing instances of a class like that, when would one ever be...greater than the other?

angelbob3• 11 years ago

Often, an instance of a class represents a mathematical entity (vector, matrix, imaginary number, mathematical set, et al) where less than might be a fundamentally reasonable operation, especially in some specific context.

His example is using it as an angle, where comparing two of them is conceptually pretty sensible.

If you pretend it's a structure, sure, you'll need to extract primitive data types out of it before doing anything with it. But if you want it to behave as a higher-level abstraction, reimplementing less-than (say, for comparing the vector magnitude) at every call site isn't great.

philh• 11 years ago

(This is completely beside the point.)

comparing two of them is conceptually pretty sensible.

Well, there are a bunch of sensible ways to do it, depending what the angle represents. You might not want to privilege any of them over the others directly in the class.

Is it a point on the unit circle? It doesn't make much sense to compare (sqrt(2), sqrt(2)) to (-1, 0).

Is it an angular distance to travel from point A to point B? Then you want 355 and -5 to both be less than 10.

Is it an amount that a screw has to be rotated? Then you can't take mods, so 720 > 360 > 0.

Do you have a robot that can only turn anticlockwise? Then maybe 5 < -10 < 355. This is the comparison implied by the implementation in TFA (self.degrees = degrees % 360), but it's pretty obscure.

exogen• 11 years ago

1. Encapsulation (arguably the whole purpose of creating such a class in the first place).

2. Would you think it's reasonable for a class to implement equality ==, so it can tell you if it's equal to another instance of the same class? Then why not ordering?

3. Take Python's set type as a useful example. A < B tells you whether A is a subset of B, A | B returns the union, etc. All very handy.

cballard• 11 years ago

I disagree with 3, a subset is not "less than" the superset. Sets are equatable, but they're not comparable. A named function or a different operator would be preferable.

yarrel2• 11 years ago

Is it "people use Python 2"?

brianmcconnell• 11 years ago

Dealing with Unicode in Python 2.x is a _nightmare_. So if you need to go beyond ASCII, Python 3 is a huge improvement. On the downside, if you want to use tools like App Engine, you're still stuck with 2.7 for now, but hopefully that will change.

yarrel2• 11 years ago

Python 2's handling of Unicode basically isn't. That's as much the fault of third party libraries as the core language, but it is a real and constant time suck.

I'm sure I hit Unicode problems in Python 3 a few years ago as well, but if current versions are better that would be a sufficient reason for switching.

Avernar9• 11 years ago

I've had no issues whatsoever dealing with unicode in Python2. Just wondering what you found to be a nightmare?

nnq• 11 years ago

The whole 2 vs. 3 debate would simply have not existed if the Python core devs would have simply refused to backport tweaks and fixes from 3 to 2 and would have forcefully deprecated 2.x immediately after releasing 3.0, even if it was inferior to 2.x at first release.

Guido should have used his power to force the move forward down people's throats, because that's the responsibility of a BDFL. The D is there for a reason, and its exactly in this cases that the power of the Dictator role should have been used.

Communities rarely move forward on their own if left to decide democratically: they need o be forced or tricked into moving forward by individuals with vision!

...heck, I'm even starting to like the nodejs folks for their "shove the future down people's throats" attitude :)

fuhrysteve• 11 years ago

I think it would have been more prudent to have implemented an iterative approach:

Python 2.8: - boring easy to fix changes like division, print function, exception handling syntax, removal of iteritems() / etc

Python 2.9 - library reorganization (urllib2 & urllib, etc)

Python 3.0 - unicode stuff

Most organizations that have been lingering at 2.7 for 5+yrs would have long since migrated to 2.9, and would thus be half way to 3.x in terms of backwards compatibility.

Now instead, everyone has to introduce the better part of a decade's worth of backwards compatibility changes at once, or be left in the dust. Hardly a fair choice.

maxerickson6• 11 years ago

Some of your Python 2.8 exists as from __future__ imports added to various 2.x releases.

https://docs.python.org/2/library/__future__.html

(in versions where the new behavior is the default, the import does nothing and is not an error)

collinmanderson4• 11 years ago

I agree. Spreading it over multiple releases would have been better.

rasz_pl• 11 years ago

Majority of people dont care about new shiny, they care about things that broke or changed. Probably 90% of them started complaining because print statement is a function :).

Python 3 insistence on unicode hurts my brain. I had a 'pleasure' of writing Python 3 script manipulating data produced by Python 2 (custom pickle). Ended up reimplementing whole Python 2 pickle library by hand, because apparently no one imagined a use case involving reading raw bytes into a buffer.

DasIch3• 11 years ago

The problem is really that Python 3 isn't new and shiny. It's an attempt to improve some downsides of Python 2 and some parts did actually get better but many parts didn't although they easily could have been improved, some parts even got worse.

Python 3 provides no real benefit to an experienced Python developer. So considering all the things you could possibly do, switching to Python 3 is not switchting to a new and shiny thing, it's just a bad decision.

If you really want to switch to something new and shiny, there are now many more interesting language options. Modern Javascript has copied so much from Python, you can feel very much at home there. If you care about concurrency, you have Go. If you care about concurrency and care about using a language that's well designed or just want performance, there is Rust.

lqdc137• 11 years ago

async lib is really really nice. You can easily issue async requests now. Also, a bunch of useful utilities were improved like shutil.

vegabook3• 11 years ago

My problem with this post is not its factual accuracy. It's factually accurate, downright impressive.

My problem is with its premise. That premise is that Python 2.7 people need to be somehow educated. To be shown some kind of light. It's the same premise that the project leaders have been going on about for 7 years. "Can't you see how much better this is?". Worse: "are you 2.7 people stupid, or what?".

It hasn't worked.

Why hasn't it worked? Not because 2.x people are slow or uninformed. They're very well informed. They assess the merits and downsides. They've had 7 years!

The reason is a combination of inertia, but also, many people actually think that in many ways, 3.x is a regression. If you don't need Unicode, Unicode is a huge pain in the xxxx. I was just having to mess with "b"s everywhere today on strings over msgpack to a non-pythonic endpoint. Lazy ranges (can also be) a huge pain in the bt. So I must move to 3.5. For what? Type annotations? Asyncio? I've been using (the highly impressive) Tornado for 3 years on 2.7.

Now google brings out the brand new TensorFlow. On 2.7. "But porting to 3 is their #1 priority" I'm told. Okay cool. You wait. I won't.

So the advances of 3 meet the regressions of 3. Even if you believe the net is positive in 3's favour, that net is not nearly enough to persuade people with actual lives outside of computer science, to port years of code, and more importantly, to port their brains to work with the new dispensation. Python is a language for people who want to get things done. 2.7 gets things done. Zero problems. For many people, that's the killer feature.

pbreit• 11 years ago

Question is: could they have fixed these problems without breaking everything else?

webmaven• 11 years ago

TL/DR: No. Many, many of the changes are backward incompatible with the existing Python 2 syntax and APIs.

Any changes that could be made in some compatible way have largely been backported to the Python 2.x versions (the latest stable version of which is Python 2.7.10) that have been released more-or-less in parallel with the 3.x line (search for 'backport'): https://hg.python.org/cpython/raw-file/15c95b7d81dc/Misc/NEW...

Enough such has been done that you can write Python code that runs in recent versions of both Python 2 and Python 3 (which is very important for 3rd-party library maintainers that want/need to support both it in a single codebase), but to do that you will be forgoing most of the productivity and 'niceness' benefits of the sort that are described in the OP.

collinmanderson4• 11 years ago

I think 3.x could have kept easily kept backwards compatibility aliases for unicode(), long(), xrange(), iterkeys(), itervalues(), iteritems(). It seems to me keeping those would have certainly have been a huge help when upgrading.

Basically, I think a lot of the shims in the six library could have been included in 2.6, 2.7 and 3.x.

Also, I think it would have been wise to spread the breaking changes over many releases, not saving them all for one massive breakage. That way you can deal with only a few subtle bugs and breakages at a time.

pbhowmic2• 11 years ago

Library compatibility is definitely an issue. You still have some very influential libraries that are not Python 3.x compatible. But an oft underestimated issue is the number of Py3 improvements that have been backported to Py2. For example absolute imports. That has made the case for moving to Py3 harder.

takeda8• 11 years ago

Argh, I don't like this argument.

There's really barely anything that is python2 specific, most of the things that weren't ported is no longer being maintained.

I think the main reason you should start moving to python3 is that it will be discontinued. Python 2.6 was EOL in 2013, 2.7 they've been more generous and you have 4 more years, originally it supposed to be 2015.

There's no good reason to stick with 2.7, if you have some legacy apps there's nothing preventing you from having Py2 and Py3 installed side by side.

If you need to write libraries that share code, it's much easier to write the code in Py3 and then make it backwards compatible with use of from __future__ ... imports and six module.

I feel like people who still complaining about the difficulties did not actually tried Python 3. Py3 is much more enjoyable language to write in.

pbhowmic2• 11 years ago

TensorFlow is just the latest library that is Py2 only. App Engine is Py2 only. The bigger issue is the 2 biggest weakness with Py2 that were not addressed in Py3 (CPython version at least) - GIL & JIT. JIT is addressed more or less by PyPy but it is Py2.7-compatible, not Py3 compatible. Addressing this in the standard CPython implementation can make for a very compelling case for move to Py3. Otherwise, it does not buy you much.

stevecalifornia• 11 years ago

When I went to learn Python I was immediately faced with a choice that would have profound effects on my future success: Python 2 or Python 3.

Both sides are extremely persuasive and thus I felt that no matter what choice I made it was the wrong one and would haunt me down the line.

So I just stuck with a different modern language that has wide acceptance and isn't battling with itself.

aoro• 11 years ago

So, what did you choose?

markdown• 11 years ago

PHP.

adrianlmm2• 11 years ago

The same thing hapenned to me in 2011, so I ended learning Ruby, no regrets.

takeda8• 11 years ago

Which is quite ironic, because (at least from my experience) Ruby constantly breaks backward compatibility.

RussianCow• 11 years ago

Both sides are extremely persuasive and thus I felt that no matter what choice I made it was the wrong one and would haunt me down the line.

It really isn't that big or hard of a decision. For the vast majority of projects, the choice doesn't matter, so I'd default to Python 3 at this point. Really, the only reason to choose Python 2 for a new project is compatibility with libraries you need[0], but the list of Py3-incompatible libraries is constantly getting smaller and smaller.

That said, if you already have a lot of Python 2 code written, there probably isn't any point to upgrading--the benefits are marginal at best, and it can be a lot of work to migrate a large code base.

[0]: Here's a pretty good reference for Python 3 support in popular libraries: http://py3readiness.org/

lyschoening• 11 years ago

Python 3 is so far ahead now as a language that it surprises me anyone would even consider it for a new project. Among other things, Python 3.4 and 3.5 have added support for coroutines that provide a whole new level of utility to the language. Meanwhile, Python 2.7 is a study in limitations to anyone who has followed up on Python 3.x developments.

EvanPlaice• 11 years ago

Python 3 is great, but that doesn't matter.

The ecosystem is rotting for 2 reasons.

First, there's no easy way for library developers to maintain a codebase that supports both 2/3 development in parallel. Yes, it's easy to use a 2to3/3to2 tool but unlike transpilers in Javascript the output code may still require fine-tuning after the tranform.

This could be solved by adding preprocessor support to python (ie for conditional loading of code) but GvR is adamantly against this approach use to the way many devs write unmaintainable code in c via the preprocessor.

I actually published an OSS project called pypreprocessor that was supposed to solve this issue. It works to add preprocessor conditionals to code but won't work with both 2/3 code in the same file because there's no hook to inline code before lexer runs and throws syntax errors.

Second, package management in python still sucks. Do you use distutils, distutils2, setup.py, etc? There's no single standardized approach that everybody agrees on and each tool follows a unique approach or needs to be supported because of legacy code.

Unlike the Ruby, Javascript ecosystem where package management and publishing is relatively straightforward/easy, it's an absolute PITA to publish packages to PYPI.

Back in 2011, the answer was. Just wait 5 years for everybody to adapt their libraries to support Python 3. 5 years later, nothing has changed. The existing libraries don't want to piss off users by dropping Python2 support and maintaining two separate branches of the code in parallel sucks. So, since most everybody that uses python in production still relies on Python2, Python2 is still the default.

The library ecosystem makes the platform. The tooling sucks so library devs don't want to make the switch.

Until there is a major cultural shift python devs have 2 options. Use a better version of the language without the support of a mature library ecosystem, or use an outdated version of the language with a rich ecosystem.

Python 3 makes it easier to develop high-quality software

Related Stories