
Python 3 can revive Python - coldtea
https://medium.com/p/2a7af4788b10
======
rdtsc
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.

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

~~~
mixmastamyk
Javascript won the "language lottery" when it was created for the web browser,
how would another language capitalize on that?

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

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

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

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

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

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

~~~
jerf
"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)

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

~~~
nswanberg
What are you considering for a prototyping datastore? Postgres? App Engine?

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

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

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

~~~
pak
> _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)

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

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

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

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

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

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

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

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

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

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

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

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

------
analog31
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?

~~~
msl09
Most libraries are migrating and honestly I haven't seen that much complaint
in places other than ycombinator

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

------
agentultra
[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.

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

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

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

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

~~~
sergiosgc
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,

~~~
mkesper
I'd say people took Python over Perl because of readability, not because of
the Perl 6 saga.

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

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

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

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

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

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

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

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

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

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

------
hbbio
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)

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

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

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

------
neumann
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/)

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

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

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

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

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

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

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

~~~
e12e
> 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 :-)

~~~
maxerickson
In 2.x, ints and longs are separate types. It's largely transparent though.

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

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

~~~
laichzeit0
Potato, tomato. It broke backwards compatibility.

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

------
mangecoeur
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 - and
that's always been one of python's strongest points.

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

~~~
mangecoeur
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 - the
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.

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

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

------
marcosdumay
Well, Python does have optional type systems. What is missing on that bullet
is choosing one, and making the standard library support it.

------
shiven
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?

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

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

------
kerkeslager
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/)

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

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

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

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

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

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

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

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

------
contulluipeste
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?

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

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

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

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

------
mimighost
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?

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

------
mixmastamyk
Agreed, I would find a python 4 with built in pypi, cython, and bpython
analogues compelling.

------
pyfish
I get way more recruiter spams for Python jobs these days than I did just two
years ago.

------
nightcracker
Almost all the things you suggest are breaking changes that would require
Python 4.

------
ulam2
I would love to contribute to make it faster.

------
dvl
I only want print as statement again

~~~
dorfsmay
Seriously? The first thing I do when writing python 2 is import the
print_function!

~~~
the_mitsuhiko
Out of curiosity: why?

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

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

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

------
kolev
Reminds me of "Waiting for Godot" by Samuel Beckett...

~~~
kolev
You guys really lack a sense of humor and/or easily get offended.

------
eudox
Alternatively, all the effort spent reviving Python could be spent making
Python go away.

~~~
pekk
If you don't like it, don't whine. Just don't use it.

