Python 3 can revive Python - <AUTHOR> https://medium.com/p/2a7af4788b10 <comment><USER4> That pretty much reiterates my points from last time we discussed (not many hours ago).

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

Besides what already was said. It is also important to emphasize that Python 2 is already pretty good. So it is not that Python 3 is bad, it is just that it is very hard to improve on 2.

Ironing out the warts is good, but this was not the right time. This should have happened 7-10 years ago.

Nowadays I can't imagine a lot of people discounting Python because of the print statement, unicode support, division rules, or lack of yield from statement.

It will be performance, concurrency, ability to create web back-ends, installing packages, testing frameworks, IDE support.

Apart from allowing optional type annotation syntax I just don't see Python 3 providing a good enough carrot to force many projects to switch to it.

Imagine you go to a manger and tell him. "Oh this 800K line project we have in Python 2 will be ported to Python 3, can we have 1 month to do that?". Ok then the manager might say "Well we have these features to implement but if you all say so. But what will we gain by it, to offset the time spent (opportunity cost) and risk of breakages". And if the answer if "oh you know print is not a statement anymore, and many dictionary and sequence methods are not iterators not returning values, and this new Twisted-like async library...' Well you can imagine many a manager might just say "well that is just not enough".

If in turn the dev team came back said "Oh yeah they integrated PyPy, STM module, requests module. Static type checking via annotations, 3x speed improvement, no more GIL so can do some CPU intensive work if need to.". I can easily see this proverbial manager OK-ing that.

<comment><USER5> Exactly. Python and JavaScript is a perfect demonstration of "worse is better". Python 2 is a vastly better language than JS, avoiding nearly all of its design misfeatures and having actually useful built-in types and standard libraries. Yet while Python spent a decade to go from 95 to 99 percent purity, JS took over the world through sheer ubiquity.

<comment><USER6> Javascript won the "language lottery" when it was created for the web browser, how would another language capitalize on that?

<comment><USER7> Exactly. JavaScript has attained ubiquity through convention only. It has nothing to do with its intrinsic qualities or deficiencies. A great many languages are preferable to JavaScript.

</comment></comment></comment></comment><comment><USER8> Python needs to be revived?

I always thought of Python as being a great utility programming language. It's not really a specialist, more of a jack of all trades.

For example PHP is all about web development. Ruby is probably most well known for Rails and also widely used for web development. Python is widely used for web development, but that's not necessarily the first thing you think of for Python.

What's going to keep any programming language alive is the libraries that become so well entrenched that a competing library would have a serious uphill battle to even come close to matching functionality. Python has a lot of libraries like this for scientific tools.

I'm always skeptical to hear that a developer has moved from X programming language to Go. I wonder how many of these tales are from developers who are actually referring to what they do in their spare time rather than their day jobs. Go is still early enough that doing the sorts of things which create the most jobs is still more painful than it needs to be (and so you would probably be doing these things in a different ecosystem.) It seems that the real Go job generating stories are from start-ups which have hit some momentum, received funding and are rewriting parts of their stack in Go.

The mass job generators are still at the Rails / Django / PHP / JS levels.

<comment><USER4> > I'm always skeptical to hear that a developer has moved from X programming > language to Go.

I see what you mean. Also, presumably those that didn't switch, that use and love Python, are not very compelled to write a "We are still staying with Python" blog.

And I think they should. Marketing and perception is important.

<comment><USER9> Spot on. Id love to see a bunch of 'I swapped to python 3 and it was amazing because... [reason]' posts.

If nothing else It'd illustrate clearly either the python 3 folks haven't got a leg to stand on (unable to come up with any tangible real life [reason]) or that there _are_ actually compelling reasons to swap over to python 3; in which case we can point people to those posts in threads like this.

(personally I forayed into 3 but couldn't find any [reason] to stay there; I keep dropping into threads like this hoping to find one...)

<comment><USER10> Here's a small reason I found when refactoring some code today:

[http://legacy.python.org/dev/peps/pep-3102/](http://legacy.python.org/dev/peps/pep-3102/)

Like I said, it's a small reason, but it would have made my life much easier today. Enough small reasons add up.

</comment></comment></comment></comment><comment> peter-row Python 3 isn't really good. It's not really bad, either. There's really not that many magic bullets (other than proper functional programming, maybe, which isn't about to happen in Python).

People are leaving Python for Go because people have _always_ left Python for fast compiled languages. Google ditched Python for C++ and Java. Java! I've seen a lot of projects get re-written in Java from Python, but no-one worried then.

Python 3 adds some cool stuff (async, in particular), and fixes some warts. It's a bit rude of them to force people to upgrade, but that will eventually pay off. It will add more things in the future.

The people who start new projects in Python 3 will have some short-term pain, as some libraries take time to port. There will be a long term benefit, though - future libraries will be better for Python 3, and they won't have to port their project.

The only controversial thing was the use of unicode. IMO, Python 3 made the right choice - you should make everything unicode where-ever it's feasible, because it's just a mess otherwise.

<comment><USER11> "People are leaving Python for Go because people have always left Python for fast compiled languages."

I think the angst about Go comes from the fact that someone who leaves Python for Java may still come back, because you can develop far more quickly in Python than Java. But someone who leaves Python for Go probably isn't coming back... my experience is that it is slightly slower (10-20%, YMMV but we're certainly not talking integer multiples) to cut out a prototype in Go, but that said prototype runs an order of magnitude faster, can potentially be optimized without much work for another order of magnitude (though ultimately this is more a reflection of Python's slowness than Go's speed), and is then much easier to maintain and extend, even on the timescale of a week or two, to say nothing of larger time scales.

A couple of people elsewhere in the comments here assume that Python must still be much easier to develop for than Go. It really isn't anymore; it turns out the combination of garbage collection and structural-typing-esque interfaces pretty much does anything you might have ever wanted Python to do, and a great deal of the rest of the differences turn out to be far less important in practice than in theory.

I first saw the idea in Joel Spolsky's "How Microsoft Lost the API War" [1], under the heading "Automatic Transmissions Win The Day", that the primary innovation of the 1990s was simply garbage collection instead of memory management. (As he is aware the idea is older than 1990, one presumes he means that it became practical and widespread.) The languages that spread this innovation, the "scripting languages" like Perl and Python and PHP and Javascript, changed a lot of things at once, which as any good scientist knows means it was hard to tell _what_ about those changes actually contributed to the enhanced productivity that they certainly did bring. My experience with Go certainly gives me further belief in Joel's thesis... you read a bullet point listing of the Python features and Go features and it seems obvious that Python is a wildly better language than Go, yet... I've learned after all these years and all the languages I've tried out to ask myself, if the features are so important, _why don 't I miss them_? Because in practice, I don't. Rip closures out of Go, and I'd miss that. Rip out the goroutines and I'd miss not having something like generators or something, indeed, the language would nearly be useless to me. But I certainly don't miss metaclasses or decorators or properties. I will cop to missing pervasive protocols for the built-in types, though; I wish I could get at the [] operator for maps, or implement a truly-transparent slice object. But that's about it.

[1]: [http://www.joelonsoftware.com/articles/APIWar.html](http://www.joelonsoftware.com/articles/APIWar.html)

<comment><USER12> My experience was Go was about 2-3x slower (development speed) than Python for prototyping. Web programming, though, which is a particular strength of Python and a particular weakness of Go. YMMV, of course.

I actually really do miss list comprehensions and properties and pervasive protocols for built-in types and really concise keyword/literal syntax. I don't miss metaclasses, and I only vaguely miss decorators. (Go has struct annotations and compiler-available-as-a-library, which in some ways are better.) Properties in particular are really useful for the evolvability of code; otherwise you have to overdesign up front to avoid a big rewrite as you switch from straight struct fields to accessors.

I'm actually leaning towards Java 8 + Jython 2.7 as I consider what language to write my startup/personal projects in. Jython 2.7 gives me basically all the language features I actually cared about in Python, and it fixes the Unicode mess that necessitated Python 3. It has no GIL and solid multithreading support. The Java layer gives you all the speed of Go and more. And the interface between them lets you seamlessly use Java within your Jython scripts, so you can easily push code down into the Java layer without having to rewrite your whole product.

<comment><USER13> What are you considering for a prototyping datastore? Postgres? App Engine?

<comment><USER12> For prototyping I'm actually considering keeping everything in-memory, with hashtables and such (or objects that wrap them). Before you laugh, Hacker News uses this approach and it's gotten well beyond the prototyping stage.

</comment></comment></comment></comment></comment><comment><USER14> One pain point I've really felt recently with Python is in the deploy step. pip installing dependencies with a requirements.txt file seems to be the recommended way, but it's far from easy. Many dependencies (such as PyTables) don't install their own dependencies automatically, so you are left with a fragile one-by-one process for getting library code in place.

It was all fine once I got it worked out but it would so much nicer to provide a requirements.txt file and have pip figure out the ordering and dependency stuff. That and being able to install binary packages in a simple way from pip would make me much happier with python (no more waiting 10 minutes for numpy or whatever to compile).

As far as actual language features go however, I still find python a joy to work in.

<comment><USER15> One of the reasons I've come to do most of my early stage prototyping in node is that managing npm packages has thus proven much easier than finagling with pip or gem.

Ruby installs are especially difficult to manage. Despite the numerous tutorials out there, I still don't know what, if there even is one, the canonically best way to install ruby and necessary gems is. RVM? Install through Brew? Add path to ~/.bashrc?

I say this as someone who likes using command line so much that I've written Caskfiles to automate my deployment to fresh OS X Machines.

<comment><USER16> > _Despite the numerous tutorials out there, I still don 't know what, if > there even is one, the canonically best way to install ruby and necessary > gems is._

Wait, what? On production, install the exact ruby you need from your favorite package manager. On your dev box, install any rubies you need through rbenv [1]. Put all your gem dependencies into a Gemfile [2]. On either end, bundle install [--deployment] and call it a day.

[1]: [https://github.com/sstephenson/rbenv](https://github.com/sstephenson/rbenv)

[2]: [http://bundler.io/v1.6/gemfile.html](http://bundler.io/v1.6/gemfile.html)

</comment></comment></comment><comment><USER17> At this point, I think python 3 just has a severe branding issue. I bet if you took python 3.4, removed the stuff that will egregiously break things (IE, lack of a print statement and new exception syntax), and just called it python 2.8 everyone would be pretty happy with it.

All the same, I'm continuously amazed at the arrogance of the people that maintain the language and set its direction. It's no wonder it's been a colossal failure. You know why I'm not running python 3? Because it doesn't solve a single problem I have. It doesn't solve anyone's problems. It solves imaginary problems, while creating real problems.

<comment><USER18> If it were only syntax, 2to3 would be the answer. Exceptions and Print are not the problem. Migrating unicode-aware code and CPython extensions is a much bigger task, and incidentally, much more useful.

nonlocal, asyncio, unicode, yield from. If you ask me, these four are very compelling reasons to switch to Python 3 and they solve very real problems.

<comment><USER19> There are not so terrible workarounds for all the things you mentioned. While Py3K does them better, they are still not reasons to update. As the article points out, there isn't a compelling reason other than slightly cleaner code. The community agrees as evidenced by the massive push back.

<comment><USER18> There are not so terrible workarounds for things like functions or variables in assembler. While C does them better, they are not reasons to update.

There are not so terrible workarounds for things like closures and memory management in C. While Python does them better, they are not reasons to update.

There will always be neophiles and neophobes...

</comment></comment></comment></comment><comment><USER20> Nailed it. The problem with Python 3 wasn't that it was too radical, it was that it jumped at the chance to introduce backwards-breaking changes for minimal benefit. Trying to convince teams to port code to python3 just because it has better unicode is hardly compelling. They should have taken a few more years and made python 3 a target people were drooling to port for.

Further, the author's priorities seem to line up exactly with my own thoughts on Python's shortcomings. Async, speed, types, stdlib, repl. If they had spent 5 years working on those things they would be done right now, and Python would be one of the most compelling languages out there. Instead, and I hate to say this, Python feels like it is falling off rather quickly. It certainly has a future as a teaching language, and it will survive as linux glue for a long time, but beyond that I think it will be replaced by other up and coming languages with better discipline and design.

</comment><comment><USER21> As much as I wanted to like this article (I remain optimistic about the future of Python as Python 3) wouldn't most of the compelling additional features suggested break backwards compatibility with current versions of Python 3? This strikes me more as a proposal for a Python 4 than a revitalization of Python 3.

edit: I wanted to respond to this myself, since upon rereading I no longer get the impression the proposed changes need 'break' backwards compatibility per se. For the suggestion on removing the GIL specifically, this would completely necessitate a revolution in the design of python programs such that even if, say, the libraries that had already been ported at the time of 3.2 still work in 3.9, their implementation would be senseless by 3.9 conventions.

<comment><USER22> To remove the GIL, you'd need to introduce proper atomicity to all of the standard library, and include concurrency checks for many data structures. And the GIL isn't really the enemy, if you are doing cpu intensive work, you'd use the C interface - which happens to not be affected by the GIL in the first place. This also happens to be how to get "more performance". Unfortunately this means you can't switch to pure JIT, because as PyPY have found out, you need to rewrite parts of the standard library that are written in C (like the crypto libraries).

</comment></comment><comment><USER23> The idea that people move from Python specifically to Go is one of those chestnuts of conventional wisdom that never receives any kind of backing in actual data.

If you think that Python and Go are made for the same tasks then you're really confused.

<comment><USER24> Right. Students in my Python classes (who typically come from static, compiled languages) are always asking me how quickly certain operations execute, or how much memory is used.

I try to explain to them that obviously Python developers care about these things, and I show them some of the most common pitfalls. But this isn't the first, or even fifth, thing that you think about when you're coding in Python.

The key thing to remember with dynamic languages, and particularly interpreted dynamic languages, is that they're optimized for programmer speed, not execution speed. And that's fine nowadays, when programmers are expensive and computers are not.

So yeah, maybe Go will run your program 100 times faster. And there are cases when that's important. But in most cases, it's not, and the benefits that you'll get from having a happy, efficient developer will be more than worthwhile.

<comment><USER25> Speed is low on my list as to why I prefer Go over Python. (In fact, Go isn't necessarily fast. It's just that Python is unnecessarily slow.)

Having a decent type system and decent concurrency primitives are far more attractive.

<comment><USER26> > It's just that Python is unnecessarily slow.

It's not Python that's slow, it's CPython. If you use PyPy you get a much faster implementation of Python, not too far from Go speed.

<comment><USER27> IHMO, PyPy isn't a strong counter-argument for Python's slowness.

Yes, PyPy is probably faster than CPython. But what then? In most cases, CPython is THE PYTHON. PyPy is still in its early age and has a lot to demonstrate itself as a serious alternative to CPython.

On the other hand, programmer could get out-of-box performance boost from adapting Go without worrying the potential compatibility issues.

PyPy is a very interesting and promising project. I highly respect that. I just don't like the idea of merely using it to dodge the blame of performance slowness, when what people are really talking about is CPython.

</comment></comment></comment></comment></comment><comment><USER28> This isn't intended to be obstreperous, but I'm genuinely curious: How many Python developers are in a position to really care about 2 vs 3?

The people I know who use Python, including myself, range from utter beginners to experienced programmers, but are using a relatively small subset of the available libraries, and are just using whichever version we started with. I could translate my code to version 3 in a heartbeat, but have no particular reason to do so. I've translated some of my most important stuff from BASIC to Python after all.

Professional developers will do whatever is right for their projects.

My concern would be for the folks who develop and maintain the libraries -- for whose generosity I'm grateful. If there were some sort of consensus on the direction of Python, I'd hop on the bus just to make life easier for those developers. Their time would be better spent adding useful features or just combing the code for bugs, than coping with multiple Python versions.

Could a single Python interpreter somehow manage a mixture of 2 and 3 code?

<comment><USER29> Most libraries are migrating and honestly I haven't seen that much complaint in places other than ycombinator

<comment><USER30> I need pygraphviz in 3 and it's not.

:(

I guess I have to roll up my sleeves on that one.

It's a dependency for networkx, to draw diagrams...

</comment></comment></comment><comment><USER31> [http://legacy.python.org/dev/peps/pep-3000/](http://legacy.python.org/dev/peps/pep-3000/)

Wow... that was 2006. Everything I've read in the PEP and mailing lists seems to imply that the contributors were doing their best to limit the scope of the backwards-incompatible changes to those parts that were deemed absolutely necessary.

The point wasn't to break backwards compatibility to add new, competitive features. It was to make the incremental improvements to the language while strategically correcting some poor, historical decisions. In other words it wasn't a rewrite or a new language.

That there are still prominent, influential Python programmers who are complaining about the bytes object is a shame. However it's a battle that is slowly coming to an end.

The real problem is that the community has been dragging its feet and many frustrated developers are complaining loudly and publicly about it. It's distorting what Python 3 is.

<comment><USER32> Well, whose problem is it? Most people use Python in order to solve problems they have. If Python 2 solves their problems better than Python 3, they'll use Python 2. (And yes, "solves their problems better" includes "lets them continue to use an already-existing solution that works fine.") If the people developing Python want other people to use Python 3, they need to make it better than other ways of accomplishing the tasks they want to complete -- and that includes being better than Python 2. It's not the responsibility of the community to move to Python 3 for the sake of the Python developers.

<comment><USER23> You have missed that it is much of the community which wants the Python 3 transition to succeed and which is actively working on helping it succeed.

</comment></comment></comment><comment><USER33> Python is not dying and if so, Go would not be the reason why. Sure, Python is not functional, not compiled, not mobile, not Rails and not in the browser.

But I can not imagine the languages, which are all this, to spread so nice and readable from command line scripts to scientific computing to big server applications.

Python's use cases will not go anywhere, so don't panic: Python is doing just fine and improving in many areas while holding on to its core values.

<comment><USER4> > Python is not dying and if so, Go would not be the reason why

It is a death by multiple paper cuts. Go is just one of the cuts.

Besides Go (and others have mentioned so I am just repeating them). There is Node.js (Javascript), Rust, Dart, Clojure, Julia, C++11, Java (due to Python never making it far on Android). Not one is enough to eat Python's lunch as they say, but they all are taking a little nibble and soon enough Python stays hungry.

Another aspect is that there are multiple forms of deaths. It doesn't have to be an abrupt and dramatic death. But I am afraid it will eventually become like PERL. Still there, still usable, still jobs for it, but not many articles about it. Not much innovation. Not many new developers considering it as an option. It will just be a decline of sorts.

My personal view is also that once someone (or a team) seats down and thinks about cleaning up and doing a re-factoring, of their code, maybe in hopes to move to Python 3, they will be looking at other platforms, and languages as well.

<comment><USER34> You could as well say that Ruby is a one trick pony destined to have its lunch eaten by nodejs, or that Go can't stand the competition from Rust as a systems language. It's not easy to predict language evolution, and everything so far points towards python maintaining a healthy evolution rate and a quiet but dedicated user base.

I'd say python took the place that would today be Perl's, were it not for the whole Perl 6 fiasco, and that none of the supposed contenders actually vie for that exact spot,

<comment><USER35> I'd say people took Python over Perl because of readability, not because of the Perl 6 saga.

<comment><USER36> If you take the time to learn the language, it's quite readable.

I used to know a guy who'd freak out about not being able to read Perl. He couldn't write ("speak") it either, so I'm not sure what he was expecting.

<comment><USER37> I've met many developers who had never written Python or spent any time learning it, but still found it very readable.

</comment></comment></comment></comment></comment></comment><comment><USER38> > Newer programmers are not that impressed with either version of Python.

Any evidence? If it's personal experience, then mine is exactly the opposite.

I don't know if such a thing exists, but maybe a big list of the main changes would help convince people more (type annotations, yield from, the forthcoming @ operator). From what I've seen and read, of course all this is somewhere in the docs and release notes, but I've never seen a clean concise list of the main new features, fixes and reasons why these features are cool.

<comment><USER24> I agree; I have found that people are super-impressed with Python.

Specifically, my experience -- teaching Python to dozens of experienced developers every month, for more than four years -- is that people from the C, C++, C#, and Java world and shocked to the core by the ease with which they can do certain things in Python.

Maybe a Ruby or JavaScript developer won't be blown over to the same degree. But there are a heckuva lot of people coming from static, compiled languages who haven't ever seen the power and flexibility of Python before, and love what they see.

<comment><USER39> I agree with you, as a Ruby developer I'm not blown over when I see Python. I shake my head instead and I try to explain why. All those __method__ and all those mandatory (). The : at the end of lines. Can't the parser know when it's over like Ruby does? An else: on a line of itself is a very odd sight. And why must you have built-in functions and methods mixed into the language? Yes len(), I'm looking at you. I won't even enter into the religious war about semantic spaces, because that's a different story.

It might be surprising to many, but Python feels like C to me. Maybe that's why it's popular as a system language. making people feel at home helps. Another reason of its success might be that it is a simpler C so it got many developers coming from C like languages (Java and PHP among the others). As a rubyist I feel as Guido made all sort of wrong decisions while designing Python but as Matz said "I tried to make Ruby perfect for me, but maybe it's not perfect for you. The perfect language for Guido van Rossum is probably Python." So everybody is happy and I think that the news about the demise of Python are greatly exaggerated. It's here to stay for the good and for the bad.

<comment><USER40> That's funny, as a Python person, I think the same thing about the begin and end in Ruby. After awhile, you just get used to whatever language you use most, and those things fade into the background.

</comment></comment></comment></comment><comment><USER41> "Nowadays stuff like proper closures, immutability, a good async story, etc, is considered a necessity by discerning hackers." Python has proper closures; I would hope discerning hackers know the difference between a closure and an anonymous function. asyncio is fantastic.

"Remove the GIL." Do you think no one's thought of that before? Remove it how?

"Make it speedy." As you note, that's what PyPy is doing, but this is a hard problem that doesn't have quite the same glamor as JavaScript, so there aren't multiple giants with deep pockets throwing money at it in a race to the top. Maybe throw some cash PyPy's way.

<comment><USER42> Regarding speed, my thoughts exactly. I'm a Ruby programmer and I see this being thrown as a weak point of Python/Ruby all the time. I remember the days where Javascript and PHP were supposed to be slow. Now that Facebook/Google/Apple/Mozilla have thrown dozens of millions of dollars in across the board optimizations, they aren't so slow anymore. Not C-fast mind you, but (especially for Javascript), definitely not languages you can call slow anymore.

It's really only a problem of investing enough money for JIT and GC technology that would make any language "fast enough" really.

<comment><USER41> Yeah, we need to put our money where our mouth is. Frankly I'm amazed how far PyPy has gotten with the few resources it has. Even their toolchain is amazing; other people are starting to use it to build JITs for other languages.

</comment></comment></comment><comment><USER43> <offtopic>

+1 just for mentioning requests (versus urllib). If someone hasn't tried this library yet, they really should. I replaced tons of libcurl / urllib / ... blocks with simple and legible oneliners. Incredible API!

EDIT: url for those who don't know the library yet: [http://docs.python- requests.org/en/latest/](http://docs.python-requests.org/en/latest/) (I am not affiliated, just really impressed)

</offtopic>

</comment><comment><USER44> When reading both stories, I can't help but think the greatest problem with Python 2/3 is that there are supporters of both and that it splits somehow (not necessarily evenly) the community.

JavaScript, in the meantime, buried its proper version to prevent just that.

[https://developer.mozilla.org/presentations/xtech2006/javasc...](https://developer.mozilla.org/presentations/xtech2006/javascript/) (2006)

</comment><comment><USER45> Python is still, by far, the most friendly language for beginners. The single biggest factor in this is the powerful data structures that Python has, especially lists. As so many others have said, Python is almost "executable pseudocode".

Python remains the language of choice for introducing programming because it is so simple. It isn't fast, and it might not be very well suited for large- scale, long-term use. That's okay.

This appeal to beginners, which the article claims is waning, is the vital force of Python; as long as it is the de facto language for beginners, it will never go the way of Perl.

</comment><comment><USER46> > Add types. Well, opt-in types. That you can use to speed some code up (a la > Cython), or to provide assurances and help type-check (a la Dart). And add > type annotations to everything in the standard library.

I think this will happen eventually, what with some of the recent PEPs; I just wish it could happen faster. Optional typing is the best of both worlds and there is no reason _not_ to have it.

</comment><comment><USER47> The best thing Python has going for it is that it's an exceptionally good learning language. It's very easy to go from zero coding experience at all to making a simple hangman type game, and from there introduce OO concepts and so on.

And if you stick with it, unlike with most 'proper' educational languages, by the end you've learned a language that's _actually useful_ for all kinds of stuff.

I don't think there's any other language out there with such a nice, even learning curve, with that kind of payoff. Javascript is, let's be honest, a bit weird. PHP is enough rope for anyone to hang themselves. Ruby is quick to get started on, but gets conceptually dense pretty quickly. (Sure, we all complain about having to write 'self' everywhere in Python, but compared with the way 'self' dances around in a Ruby class definition, it's much easier to _learn_.)

I note, on topic, that most newer beginner's Python books etc target 3.x nowadays - maybe the RPi generation will force things along. Maybe not.

</comment><comment><USER48> My perspective is as a researcher in academia. From here Python is far from needing to be revived, it is gaining ground. Also, Python 2 is still king and I suspect will remain popular - researchers rarely have the luxury/incentive to go back and improve it to comply with a language update.

A few reasons Python is gaining ground in academia. Firstly, Python is _great_ for teaching undergraduate programming (see [0] for a good perspective), and many institutions are only now catching on and migrating from Matlab. Secondly it is a charitable language allowing scientists to concentrate on their research and not the CS implementation they are using. It is easy to learn, flexible, has lots of scientific libraries, interfaces to fortran/C libs. Julia is supposedly the future with speed being cited as the primary advantage[1], but it far from taking over. From a preliminary investigation into Julia it had less lib support, but most importantly, less inertia. The popularity and relative 'newness' of Python (compared to fortran/C) has meant that docs, blogs, forums, stackoverflow allow anyone to get involved and quickly overcome beginner hurdles and learn best practices. Finding which module interface for a C lib is easy. Comparatively, finding information on Julia's library support is much harder. As to why not use Fortran/C - well, if I need to suddenly share part of my data in JSON, make a plot in matplotlib, or generate a PDF/website for my data all the tools are easily accessible.

Python often gets a bad rap for speed, but this is rarely the problem it is made out to be. Python is best when used as a high level manager sitting on top of low level routines written in C/Cython. Following best practices means I do not a deep understanding of how compilers work to speed up my code, I just need to know how to pass off my data to an existing routine interfacing with LAPACK/BLAS or what have you where some really really smart CS people have already done all the optimisation.

Finally, it has a massive advantage over many other languages: Great documentation and a large community. This gives Python an inertia that the Go and Julia can't achieve yet. Julia, Go, and Closure all have dedicated communities (based on the number of mentions on HN), but the size of the community and their distribution biasing developer interests mean the barrier of entry is higher.

As these languages and their communities mature and grow, Python's advantage might diminish, but then we will just have more tools to choose from, and that would be great.

[0] [http://lorenabarba.com/blog/why-i-push-for- python/](http://lorenabarba.com/blog/why-i-push-for-python/) [1] [http://julialang.org/benchmarks/](http://julialang.org/benchmarks/)

<comment><USER49> I add that Python is excellent at data representation and transformation. You can easily write some test data and just include it in python, then transform it any way you feel you like to get intelligence out of it. With the standard library you can easily load a CSV file you exported form a data-set and then aggregate and evaluate it with only a few lines of code without much language overhead. Schema-less mixed containers, array operations, dictionaries and sets are incredibly powerful and you can nest them anyway you like. Additionally you can also forget about type limits. Work with numbers as big as you like. That's useful for a lot of things.

Go is good at concurrency and speed. It has some very neat features but it's targeted at a different audience. Data transformations in Go are trickier. You have to do a lot of explicit transformation and that's just not as slick as Python. It really shines with concurrent programming, so I you are writing a server backend for your application and have to decide between C++ or Go, you might very well be compelled to go with Go. (C++ also has it's strength and is healthy as ever with the new standards, just more heavyweight).

<comment><USER34> I don't get why is Go defined as a competitor to Python. Go documentation itself places Go in the systems programming language class. The same class as C or Rust. The language advantages are defined by comparison to C. Heck, it starts by stating it _compiles_ quickly.

I know Go is the language of the moment. Fashionable. I assume I take a cautious stance approaching fads, so I may tend to dismiss new stuff rather than all-in adopt every new tool. Having said that, my quick survey of the language features a couple of years ago produced nothing eye catching.

The concept of channels is nice, it lends itself easily to data pipelines and to SIMD parallel programming. It is not a breakthrough, though. SIMD is easily done in many many languages. Other than that, it's pretty down to earth. There's a myriad nice things (first class functions, closures, garbage collection, strong(ish) typing), but nothing ground breaking. There are also some choices that _smell_ , namely the lack of inheritance due to the flat type hierarchy (and the obvious need for a fix), or the inability to overload methods and operators.

All in all, there's not enough in Go to warrant the level of attention the language gets. It's a nice language, it's not groundbreaking.

On the same class, Rust is looking rather nice. The memory management model alone is enough for me to keep an eye on how its ecosystem develops.

<comment><USER50> Go was never a class of C and Rust. Maybe it becomes once, but at the moment I observe it as a kind of server-side Java replacement: by the current design it simply can't be as low level as C and Rust. The main difference with Java is that it compiles to he native code and not bytecode. Still it is dependent on its own special conventions, GC and libraries.

The confusion comes from the announcements of the Go team where they claimed a "systems programming language" where they, it seems, didn't mean "operating systems" but more "some user-space programs on our servers," that is, their in-house user-space "systems." They of course discovered that the only group who saw possible benefits were programmers that would otherwise use languages like Python but liked extra speed and convenience of a compiled language. The other group were those that liked Go's concurrency primitives.

<comment><USER23> > the only group who saw possible benefits were programmers that would > otherwise use languages like Python but liked extra speed and convenience of > a compiled language.

To say "the only group" is far from true. Go has a lot of uptake among people who would otherwise use C++ or Java, for example. And yes, actually there is overlap in the audience of Go and the audiences for C or Rust. Go has its own advantages but really lacks the advantages of a very high-level interpreted language.

<comment><USER50> I agree, "the only" is wrong wording. Luckily there are more sentences in my reply. And actually there are elements of Go that I like. However my impression of the responses of the compiled-language groups were: C: "oh, it's GC, runtime-lib and its calling conventions dependent," C++ "oh it can't make universal containers" and Java "oh it lacks exceptions." Only the Python people were "oh it's much faster than Python and not much harder." And no, I don't think Go needs exceptions.

</comment></comment></comment></comment></comment></comment><comment><USER51> Why doesn't anyone seem to think the full number tower in python 3 is great? It seems to always be left out of discussions like this ... but I think it is a great and very "pythonic" thing to add to the language.

[edit: because the numeric tower wrt integers wasn't new in python3, just other parts of the number hierarchy... see below]

In that light I think unicode also makes more sense: text is text and numbers are numbers. Done. No need to think about it.

Yes, it does break with python2 -- but python2 isn't going anywhere.

As for the GIL -- is it _really_ such a big deal any more? I know that forking processes on Windows used to be hopelessly slow -- maybe it still is? But it's been pretty lightweight on Linux for the longest time -- and as we're getting more and more (logical and physical) cores -- with all the cache-coherency issues that come with it -- isn't multiprocess a pretty sane programming model?

Yes, a solid actor framework would be nice -- but that would also mandate some form of change to python.

If there's something I'd like to see, it's a clean interface between rust and python (rather than having to fall back to c for high performance code).

But I don't understand the people that hold up Go as the terrible threat to python -- sure there are a lot of people that will move from one to the other -- but the languages are so different that the comparison really doesn't make any sense. The one thing they do have in common is a strong vision and focus on simplicity -- but they articulate that vision and focus quite differently.

For those that want "faster" python -- why not use nimrod? If you want something "faster" and "more embeddable" why not use lua? I can't see a good pythonX that is better at either of these two in the areas where they excel. If you want actors, why not use Elexir?

Personally I'd probably enjoy a Smalltalk/Strongtalk that had a slightly more complicated syntax than traditional Smalltalk -- borrowing from python (say indentation for blocks, some way to define infix messages/operations) -- but I'm not under any illusion that such a language would be a _better python_.

<comment> mark-r No matter how fast the OS can spin up another process, you still have to contend with the overhead of Python initialization itself.

And I don't quite understand what you mean by the "full number tower".

<comment><USER51> > No matter how fast the OS can spin up another process, you still have to > contend with the overhead of Python initialization itself.

Good point... but isn't part of that possible to reduce a little when python itself forks? I've not looked at the code, that might very well not be what happens when you use the multiprocess-module?

> And I don't quite understand what you mean by the "full number tower".

I was thinking of: [http://legacy.python.org/dev/peps/pep-3141/](http://legacy.python.org/dev/peps/pep-3141/)

but apparently confused as to what had changed in python3 (mostly the change to division/true division -- which I still think is more pythonic, but less of a change than I thought).

So eg:

        $ python2 -c "print(1/2)"
        0
        $ python3 -c "print(1/2)"
        0.5

But I also thought there might be some differences wrt doing stuff like:

         $ python -c "print(2**10000)"
         19950(...)9376

But there isn't :-)

<comment><USER52> In 2.x, ints and longs are separate types. It's largely transparent though.

</comment></comment></comment></comment><comment><USER53> Breaking backwards compatibility is a sure way to kill off a language / alienate a user base. That's a big reason why c++, Linux, PHP, etc. still exist and are used today.

Python 3 seems hellbent on taking the Perl 6 approach. How's that working out? Languages should evolve, not break off into new species.

<comment><USER41> You're either misunderstanding Python 3 or misunderstanding Perl 6.

Python 3 was a few breaking changes made to Python 2.

Perl 6 was a completely new language, designed from scratch, with little in common with Perl 5 aside from bits of syntax. It still doesn't have a "complete" release, in 14 years. In half that time, we've had a Python 3.0 and four more point releases.

<comment><USER53> Potato, tomato. It broke backwards compatibility.

<comment><USER41> Barely. The subset of code that works in both Python 2.6+ and 3.3+ is orders of magnitude greater than the subset of code that works in both Perl 5 and 6.

</comment></comment></comment></comment><comment><USER54> The biggest problem with python 3 as i see it is that it seems to cause people to air grand opinions unencumbered by any actual data.

I have seen neither evidence that python is "dieing" in any way, nor that people are dropping it because it lacks radical new feature X. Things may be more competitive now but I don't see any stagnation in the community - <USER2> that's always been one of python's strongest points.

<comment><AUTHOR> > _I have seen neither evidence that python is "dieing" in any way_

Yeah. I'm sure there weren't that kind of hard numeric evidence about Perl dying either.

Perhaps, you know, what languages are getting adoption and which might be lossing traction is more of a "sensing the buzz" and following community discussions affair, than some statistic bureau giving hard counts.

> _nor that people are dropping it because it lacks radical new feature X_

Well, I'd say people EXPLICITLY posting "our team left Python because of it's bad concurrency story and went with Go" is evidence of people "dropping it because it lacks radical new feature X". And we've seen a few of such posts in the past year. Also a couple high profile Python devs migrate to languages such as Go.

<comment><USER54> Anecdotes are not evidence. I'm sure that for every post about someone switching to Go from python, you find a post of someone switching to python from something else. Not to mention all the people who are just getting on fine and don't feel the need to tell everyone about it. One blog post does not a trend make. Some things that do make trends:

Python stable in top 10 in TIOBE index: check Python increasingly popular topic on StackOverflow: check Python jobs in popular demand: check Python community is active and lively: check Python used in large scale deployments: check ... and so on.

I'm not saying they can just rest on their laurels, but to claim python is in crises is just bull. People are well aware of the issues and difficulties of updating to new versions, PEPs are written, improvements discussed, etc - <USER3> ability to respond to new challenges is key to the survival of a community, and python has had this built into its development process since forever.

<comment><AUTHOR> > _Anecdotes are not evidence_

Actually they very much are. Anecdotes such as what we have, real and verifiable posts "our company switched to Go", are very much evidence of people switching to Go. Finding the mangitude of that is up to us -- there are no hard numbers available. But if you care about this, you have to gauge it from what information you have.

Oh, and in certain fields, like what's the next big thing in pop, fashion, etc -- and I'd argue: programming language, you don't have hard data (until it's too late). You have anecdptes and people murmuring stuff here and there, and you have to figure it out yourself.

</comment></comment></comment></comment><comment><USER55> Is Python in need of revival? It seems to be doing pretty well. I think it's a great workaday language. It's probably not the Absolute Best at any particular domain but it's easy to learn and use, and it serves fairly capably for sysadmin scripting, web development, scientific computing, etc.

</comment><comment><USER56> Well, Python does have optional type systems. What is missing on that bullet is choosing one, and making the standard library support it.

</comment><comment><USER57> As far as I am concerned, a mere user, hacking python for 'academic research' in multiple aspects of structural biology and bioinformatics, I have yet to see a single practical argument for switching to or even investing time in learning Python 3 'right now'. Maybe in six years it'll be a different story, but from where I stand, python vs python 3 is a remote and ephemeral distinction, created by the grand poobahs, of zero to little significance for me.

Why should I even bother with Python 3?

<comment><USER18> Why did you bother to learn Python 2?

Scientific code typically translates cleanly using 2to3, even. You can get up to speed with all those "terribly complex" changes in Python 3 in about five minutes. Scientific code _in particular_ typically has no advanced unicode handling and no custom CPython extensions, so switching is trivial.

I totally agree with you: Py 2 vs 3 is of very little significance to us scientists. Which is why I use Py3. There's nothing to gain by sticking with Python 2, and almost no effort at all to go Python 3.

<comment><USER57> As an example of why Python 2 is going to be the primary Python for me due to circumstances beyond my control, the following two are examples of open-source "Python" software I (and a _huge_ percentage of the structural biologist community) use for 75%-85% of work:

[http://sourceforge.net/projects/pymol/](http://sourceforge.net/projects/pymol/)

[http://www.phenix-online.org/](http://www.phenix-online.org/)

Both work on Python 2 only! So guess what, I have to write all the extensions and analysis plugins in Python 2 if want them working with those packages.

Want to even _dare_ trying to move those two packages to Python 3? See you in a decade!

</comment></comment></comment><comment><USER58> I pretty much agree with this article.

Anyone who complains about updating their code hasn't done it: upgrading code from Python 2 to Python 3 is dead simple. I've migrated a few large projects manually (not using 2to3 because I wanted to be sure relevant areas of the code were tested). None of these took more than a few hours. Writing code that is compatible with both Python 2 and 3 is a little bit harder, but it's still not prohibitively difficult.

The fact that difficulty of migration is still cited as the main reason for not migrating shows that people simply aren't trying it. So we really have to look at why people aren't trying to migrate. It seems pretty clear to me that people don't see incentives for the change. There's just not enough _different_ about Python 3.

And the author is spot on talking about improving the standard libraries, although I think where they could really get a big win is not necessarily by improving the existing libraries, but by adding new libraries. The thing that got me excited about Python in the first place was the "batteries included" nature of the standard library: so much of what I wanted to do was just an import away. And I'm not the only one who felt that way[1]. But there are tons of holes in the standard library that could be filled with simple wrappers around existing open-source tools or by implementing public standards. Just ones I've run into recently: BSON, AES, RSA. Python supporst SQLite, but what about baking in support for PostgreSQL or MySQL? What about building in a templating engine?

[1] [http://xkcd.com/353/](http://xkcd.com/353/)

</comment><comment><USER59> > It's not like anyone is using Python 3 anyway, so take some chances. Break > things.

Well, people start using it now. I'm teaching Python classes exclusively in Python 3, and do all my personal projects in Python 3 and love it.

I would like to finally have a "stable" Python 3 with forward compatibility. This is important for the future of the language, else no-one would invest in it.

</comment><comment><USER60> A little more than a year ago I had to choose a programming language that I would use to create a platform and I chose Python. It's a mature, evolved language. There's a deep bench of talent that can use it. It's a practical language for someone to learn because of the resources available-- books, blog posts, community forums, IRC, open source. The heavy hitters in Tech seriously use it. Not only do they _seriously_ use it but their teams release their work into the wild if it can benefit more than themselves in the process (Facebook's Tornado, for instance). Aside from commercially supported Python- related open source, there's an abundance of grass-root open source libraries and frameworks that are absolutely phenomenal. Take, for instance, SQL Alchemy or the Pylons projects, such as Pyramid. I attended my first PyCon this year (2014). More than 3000 people, from all over the world, attended the event in Montreal. I got to meet some great people and feel closer to the community. I watched the PSF award Raymond Hettinger for a lifetime of contribution to Python. He received a loud, standing ovation.

All of the things that make Python great didn't happen over night. It can take years before an idea becomes popular among just a few evangelists. Rarely does technology have a chance to transcend before it is replaced by something more powerful, flexible, and fun. Python has brought society-changing, community- supported innovation. It's not a fly-by-night language. So, if you choose to use it, whether as a newbie or by upgrading, you will not fail at your work nor be disappointed as a lone wolf.

Upgrading technical skillsets isn't easy -- I can speak from experience. People get naturally set in their ways, excel at their craft, and take offense to anyone rocking their boat. So, I can empathize with the devout 2.7 users who are unhappy with migrating. Your baby has grown up without you. But, you can trust that the broad Python community has your best interests at heart, and adopt 3.4.

Best of all, if you choose to continue using Python, there is absolutely nothing stopping anyone from working towards core development. Be the change that you wish to see in the world. You don't have to wait for any benevolent dictator to feed you.

</comment><comment><USER61> Is Python really dying? I think the original article proclaiming it's death was written by a MS guy (aren't they coming out with a new version of asp or .net or something?).

I use it every day and even though I love JS (and have been thinking about looking into Go because of all the positive noise) I don't see Python going anywhere for me at least. It is simply too handy and familiar. Maybe it just will be used slightly less by some?

I'd have to see some real stats that Python is dying to believe it.

<comment><USER62> The Go noise got to me too. I worked through a book on it, implementing a project in it, and ended up writing it off. The problem for me was the insane concept they adopted around C-style error codes and abandoning exceptions.

The idea that errors should pass by default rather than halt by default is just putting more on the programmer to manage. Which I'm almost universally against unless there are significant gains (eg. manual memory management, when appropriate). This guy adds more that I don't care to restate- [http://uberpython.wordpress.com/2012/09/23/why-im-not- leavin...](http://uberpython.wordpress.com/2012/09/23/why-im-not-leaving- python-for-go/#comment-1412)

The library scene for Go is also lackluster in comparison to Python, and libraries are what make a language useful. Lack of exceptions kills Go for me, but others are PO'd about lack of generics and some criticize the type system as ignoring the last 20 years of innovation there.

Instead of Go, I'm more excited about Rust as a systems language. Go ultimately is GC'd so it will never be suitable for real-time computing, say writing software for traders or many other use cases. It doesn't so low-level enough to takeover that field (which is why the C/C++ guys aren't coming), and isn't high level enough to really wipe out Python. It's an awkward, yet highly flawed design.

If you're really interested in systems programming, wait for Rust to hit 1.0. I'm more interested in seeing how we can squeeze more performance out of Python with Pyston and PyPy, and if I abandon Python for web development I'll probably be looking at the MEAN stack and biting the bullet on Javascript once ES6 arrives.

<comment><USER63> Well, given that the original target for Go was C/C++ programmers, the stance on error handling makes perfect sense.

Exceptions are arguably one of C++'s largest mistakes, and it requires careful thought to write code in a completely (e.g. strongly) exception-safe way (not to mention it's caused somewhat of a fracture in the C++ community over the years...). Presumably, this is why they don't exist in Go, and it's certainly why they don't exist in Rust.

FWIW, I'm a C++ programmer, and I was a C programmer before that, so my experience with Python is rather limited.

</comment></comment></comment><comment><USER64> I think double the efforts needed to convert all third party modules more than the amount of developing efforts for Python 3.x.

Since, third party libraries are benched more for Python 3.x migration.

Would we have any possible ways as a community to allocate more resources for ONLY the third party libraries re-implementation? Is it possible to start from scratch for 3.x series? otherwise back porting should be made as standard for 2.x

current scenario,

Loving python ~= amount of third party support.

So, 2.x series never dies.

</comment><comment><USER65> I love how you call Julia a wannabe but then go on to list features it has to build up the newer greater Python =P

<comment><AUTHOR> Well, it could have 20 times the features, but since it doesn't have the "crown" (the user count), it's still a wannabe in that regard.

</comment></comment><comment><USER66> To have Python 2 and 3, and then CPython and PyPy and all kind of other similar flavors of the same thing is not really in line with `there should be only one obvious way to do it' don't you think? Do we see something that needs to be fixed in there?

</comment><comment><USER67> If Python needs reviving then Python 3 is the reason.

But I suspect what needs reviving is Python 3. If functioning unicode support isn't getting people to switch, it's got an uphill battle on its hands.

</comment><comment><USER68> Why do people tend to just stick to one tool? I mean i try everything i can and what works works. It´s not actually bad if somethings dying. There are always new/better stuff on the horizon.

<comment><USER69> Training. Not everything is a personal project. If you have to manage a technical team, then you need to standardise on a skillset - whilst we can learn new things and apply them, it isn't feasible to hop around if you are trying to maintain a consistent set of tools and skills within a company.

</comment></comment><comment><USER70> Python doesn't need any reviving. It's a fantastic and very popular language in both web development and scripting. And plenty of jobs exist for it in the market.

</comment><comment><USER27> So how about starting from introducing a reasonable JIT into Python? Does anyone know why BFDL opposes to the idea of having a JIT, like Psyco?

</comment><comment><USER71> Can't disagree much. I think itd be nice if python become all that. easier for programmers to transition to it than to, say, go.

</comment><comment><USER6> Agreed, I would find a python 4 with built in pypi, cython, and bpython analogues compelling.

</comment><comment><USER72> I get way more recruiter spams for Python jobs these days than I did just two years ago.

</comment><comment><USER73> Almost all the things you suggest are breaking changes that would require Python 4.

</comment><comment><USER74> I would love to contribute to make it faster.

</comment><comment><USER75> I only want print as statement again

<comment><USER76> Seriously? The first thing I do when writing python 2 is import the print_function!

<comment><USER77> Out of curiosity: why?

<comment><USER78> I use

        map(print, list_of_tuples)

quite a bit, but that possibly an artifact of my print-based debugging. I can only do this with print as a function rather than a statement, and the single line makes it easy to drop in or comment out as needed.

<comment><USER77> map(print, list_of_tuples) does not work on Python 3 unless you wrap it in list(). In any case it's a anti-idiom because it creates a useless list. Please don't do that.

<comment><USER78> Ah, I can see _now_ that `map` will return a list of Nones, and also that Py3 `map` returns a lazy iterator. Thanks.

Seeing how my transition to Py3 got hung up on sending bytes in and out of ZeroMQ sockets, I might stop that now.

Back to the for loop or join the strings as suggested below.

</comment></comment></comment></comment></comment></comment><comment><USER79> Reminds me of "Waiting for Godot" by Samuel Beckett...

<comment><USER79> You guys really lack a sense of humor and/or easily get offended.

</comment></comment><comment><USER80> Alternatively, all the effort spent reviving Python could be spent making Python go away.

<comment><USER23> If you don't like it, don't whine. Just don't use it.</comment></comment>


Uber CEO hopes to have self-driving cars in service in 18 months - <AUTHOR> https://techcrunch.com/2018/01/23/uber-ceo-hopes-to-have-self-driving-cars-in-service-in-18-months/ <comment><AUTHOR> It looks that Uber just don't want to deal with any legal issue.</comment>