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.

We just have to get a bit more daring; check out:

http://research.microsoft.com/pubs/211297/managedtime.pdf

Note the resemblance to Python, it's not an accident.

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

Which of course reinforces your main point: nowadays the language differences just aren't that big.

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.

If Python is slow, we are using it wrong.

Moreover, a plot of their performance over time rather strongly suggests that they've plateaued. Personally, barring any major JIT advances, I'm considering the book closed on the topic of whether JITs can take a dynamic language and make it as fast as C or C++: No.

(Recall that a Java JIT is another issue; it starts with the static typing of Java, and then JITs from there. It has a much larger array of much more powerful guarantees to work with, that the dynamic languages simply don't. Go will be running at straight-up C speeds (which it does not currently) long before Python will.)

It's possible to close more of the speed gap, but these JITs have to be able to:

* identify and use native primitives (avoid overflow and so forth)

* prefer stack allocation over heap (improved escape analysis)

* inline memory allocation and freeing and remove unused codepaths

* optimize across the boundary between implementation language and hosted language (which I believe requires self-hosting)

If we could just have tail call optimization, I think we could make the rest work (well, maybe better lambdas, too).

Manually thunk/trampoline it?

    class trampoline(object):
        def __init__(self, fn):
            self.fn = fn

        def __call__(self, *args, **kwargs):
            ret = self.fn(*args, **kwargs)
            while isinstance(ret, thunk):
                ret = ret()
            return ret


    class thunk(object):
        def __init__(self, fn, *args, **kwargs):
            self.__dict__.update(fn=fn, args=args, kwargs=kwargs)

        def __call__(self):
            if isinstance(self.fn, trampoline):
                return self.fn.fn(*self.args, **self.kwargs)
            else:
                return self.fn(*self.args, **self.kwargs)


    @trampoline
    def fact(n, accum=1):
        if n <= 1:
            return accum
        else:
            return thunk(fact, n-1, n*accum)

    print fact(1000)


    @trampoline
    def is_even(n):
        if n == 0:
            return True
        else:
            return thunk(is_odd, n - 1)


    @trampoline
    def is_odd(n):
        if n == 0:
            return False
        else:
            return thunk(is_even, n - 1)

    print is_even(1000001)

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.

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

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.

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

But there's no doubt that concurrency is indeed one of Python's weak points, and Go's strong points.

A good type system quietly and with minimal programmer effort encodes and documents your code, helps you find mistakes faster, guides your re-factoring, and gets out of your way when you don't want to deal with it.

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.

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.

A big reason for this is that some prominent members of the Python community left for Go and that Go talks have started appearing at Python conferences.

Well, from TFA: "Again, they’re not many, but they are quite vocal (including whole startup dev teams blogging about switching their codebase), and enough to create a certain buzz (and to surprise Rob Pike, who initially expected people to come to Go from C/C++)".

Data are always hazy in our industry -- who knows what each company/developer uses? But we can gauge interest from the discussion around something. So:

1) Go had several known startups (and established companies) post that they migrated some of their services to it from Python.

2) We have Rob Pike, who wrote a couple of years go he was surprised seeing most in the Go community come from Python, whereas he expected them to come from C/C++.

Now, I don't know what you mean "If you think that Python and Go are made for the same tasks then you're really confused". What's confusing? Sure, Python has some unique niches (like scientific computing), but there's a lot of stuff people use Python that they could (and are) use Go for.

I'm sure you've heard of Twisted. Go solves a similar problem quite nicely. Also: RESTful services. But even more so, people also use Go for glue stuff, including for stuff previously relegated to a scripting language.

It's not that huge numbers are leaving Python for Go. Perhaps not even 1%. But it's a vocal 1%, and it might also be an influential 1%.

Heck, at some point Perl was king of the hill for scripting and web application development. But then 1% went to Python, and 1% went to Ruby. And then they continued going...

https://www.spacemonkey.com/blog/posts/go-space-monkey

We've spent the last few months writing some of our tools in Go. For our purposes, it is slightly slower to develop in, but we have much more faith in its correctness, and deploying the code is a dream. Also, it's much faster than what we've been useful.

We'll still be doing some Python development, but were it up to me I'd be using Go for everything I ever used Python for.

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.

Not the best approach, but it does work.

I find the combination of virtual environments and pip very convenient to work with. When I run into trouble with missing dependencies I often find the project on GitHub and can send a pull request.

Regarding Numpy and the scientific Python stack, check out Anaconda https://store.continuum.io/cshop/anaconda/ it makes managing environments where you need these packages a lot less painful.

See https://github.com/pypa/pip/issues/1386 (oddly, the issue is closed, while the problem is acknowledged).

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.

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

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

Unfortunately, that's all I've learned from lurking on the mailing list for a couple weeks.

Otherwise you are just asking for nasty surprises when packages upgrade.

If you want to keep up to date with security and bug fixes (but aren't yet ready for the next big feature/backwards incompatible release), you can specify the lines as 'package>=1.1,<1.2' to get 1.1.x fix releases.

`pip list --outdated` is helpful, too.

Basically, when you use >=1.1,<1.2 it will install the best version that matches at the time of first install, and then that version will never be upgraded because it will always satisfy the requirements. So you don't actually get 1.1.x release updates unless you install them manually.

We do, however, use this syntax in development when testing new versions to make sure any subsequent runnings of pip doesn't obliterate the new versions of modules we are testing.

I'd love official pip support for ~1.1 type declarations.

We really need pip wheels or conda to become mainstream. Pip alone doesn't cut it on platforms without compilers (Windows / OSX). Standalone installers are fine, but they don't resolve dependencies and they are only available for Windows.

I totally agree that the installation and deployment story should be a top priority. Once done, it would be another very compelling point on Python 3's feature list.

[1] https://github.com/jordansissel/fpm

BUILD_DIR="/tmp/wheelhouse/$PROJECT" pip wheel --wheel-dir=$BUILD_DIR --find-links=$BUILD_DIR --index=http://$DEVPI_HOST:$DEVPI_PORT/${DEVPI_USER}/${DEVPI_INDEX} --extra-index-url=https://pypi.python.org/simple/ ../$PROJECT

This will try to get packages from your devpi index, but will fall back to pypi if you don't have them.

Then upload this to devpi. It can later be installed by pip with:

pip install --use-wheel --index=http://$DEVPI_HOST:$DEVPI_PORT/${DEVPI_USER}/${DEVPI_INDEX} $PROJECT

This makes deployments super fast because you're deploying pre-built wheels instead of downloading and compiling from pypi. It also gives you resiliance by storing copies of the dependencies you need in devpi, so if they vanish from pypi (or it's unavailable) you can still deploy your software with all the dependencies you developed against.

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.

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.

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.

Sure, people introduced to Python for the first time might find it impressive, but what about people who know Python and also are tempted by Go, Clojure, etc.

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.

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.

    map(print, list_of_tuples)

Not as nice, but doable.

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.

    >>> from pprint import pprint; pprint(list_of_tuples)

PRINT TO A FILE, OR STDERR print >> sys.stderr, "blah" What are those '>' signs here? Why two? What happens if I use one only?

Compare this to (py3k): print("blablah", file=sys.stderr)

PRINT WITHOUT NEW LINE sys.stdout.write('blah') I can't use print to print?

compare to: print("blah", end="")

DISABLE FLIUSH In python 2 there are 2 or 3 different ways to do that, all more complicated than each other. Compared to:

print("blah", flush=True)

Finally, it's a function, you can do everything you do with a function, use map, return a print from another function, include it in generator expressions etc...

You can. Compare the output from:

  print "foo"
  print "bar"

  print "foo", 
  print "bar"

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.

On that topic, I'd spend a day writing cobol or C++98 if I could get QML + Python in browsers. Python as a script/python, and QML as a uri schema (ie, http://foobar.com/baconwitch.qml)

My point is: Most successful languages have their point, why you use them. They are successful, because of their focus on not because they try to beat every other language imaginable.

Python's use cases are already pretty diverse. So I have trouble to understand the constant fear Python could miss out on any platform or paradigm.

I really like coding in python, but the weak-sauce lambdas are on of my least favorite things about it. I would like tail call optimization, but living without it doesn't bother me on a daily basis. Lame lambdas do bother me on a daily basis.

Anonymous functions work well (err, passably) in JavaScript and Perl. They don't really work in Python, and of course you'll just run into pain if you try to force them to.

Perhaps also make some noise about this PEP: http://legacy.python.org/dev/peps/pep-0403/

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.

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,

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.

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.

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.

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.

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.

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.

Just having to use functions to emulate all of these (and many more) is not what functional programming is all about.

Edit: Asked on twitter for any work on this: https://twitter.com/alexchamberlain/status/47126815887225241...

[1]: http://books.google.ro/books?id=fzUCGtyg0MMC&pg=PA437

> So, you'd want people to switch to PyPy, not Python 3.

I personally would want Python to be used more because I like it. But I see how a community has been divided over what I see is an un-necessary backward incompatible change to the language.

To put it another way. I would rather not have backwards compatibility issues and just keep having 2.8, 2.9, 2.10, if all we got was what we got with 3.x

Having to work with 2 bytes languages (CJK typically) without proper Unicode support is much more of a hassle.

Proper unicode support is not even close to being a priority when it comes to dealing with Japanese text. No one would store important Japanese text in unicode. http://en.wikipedia.org/wiki/Han_unification#Unihan_.22abstr...

One size doesn't fit all.

As a unrelated (to Python) example of the encoding nightmare: have you ever tried to import text from CSV files generated on different OS/locales in Excel that don't support Unicode-encoded CSV files? It can be made, sure... but, man, if it can be avoided... ;)

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?

You could write code for a subset of 3 that would be fully functional on 2. There are a number of efforts out there to provide the missing compatibility layer that opened a chasm between Python 2 and 3. My contribution is https://github.com/kislyuk/eight.

Depending on what you're doing, writing code that is compatible with even the easiest combination of versions (2.7 and 3.3) can be unreasonably hard, and the officially recommended migration tools suck. IMO this has to do with a few unfortunate design decisions made back in the 2.x days (most egregiously the ascii default encoding and silent Unicode coercion), combined with an unwillingness to admit that 3.0-3.2 were really bad in not providing a migration path and work on a more comprehensive migration strategy and backports library.

:(

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

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

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.

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

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.

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.

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.

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.

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.

I used to stick up for Python 3 on HN and other places but I've given up. I have no interest in converting people going to Go. And no matter what Python (or any other language) does, they are going to lose users to JavaScript.

Also, my experience is that people who feel passionate about Python 2.x will shout down people who are using Python 3 with "nobody uses Python 3." Who has time for that?

When I have seen people talking about sticking with Python 2, its either because A) why bother I don't need to B) a specific library is not Python 3 yet.

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

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.

Python is, of course, ubiquitous among startups and west coast tech companies; it is basically Startup Java.

I don't see us stopping using Python any time soon and not just for the legacy factor and cost of switching. It has its place, and Go has its shortcomings, and together they make a nice balance.

BTW we'd also love to move to Python 3 because of Unicode issues, but currently we have so many 3rd party libraries that are Python 2.7 only, that it's not feasible.

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.

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.

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.

To me, a compelling feature is a pypy like jit, or fixing the Gil, or lamdas that don't suck. For things like that, I'm willing to break the ecosystem. But for sorta better Unicode? Ha!

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

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/ [1] http://julialang.org/benchmarks/

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

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.

And of course, them being Go's authors and them being wrong on characterizing it, is in no way contradictory.

« No major systems language has emerged in over a decade, but over that time the computing landscape has changed tremendously.

(...)

We believe it's worth trying again with a new language, a concurrent, garbage-collected language with fast compilation. Regarding the points above [cut on edit]:

* It is possible to compile a large Go program in a few seconds on a single computer.

* Go provides a model for software construction that makes dependency analysis easy and avoids much of the overhead of C-style include files and libraries.

* Go's type system has no hierarchy, so no time is spent defining the relationships between types. Also, although Go has static types the language attempts to make types feel lighter weight than in typical OO languages.

* Go is fully garbage-collected and provides fundamental support for concurrent execution and communication.

* By its design, Go proposes an approach for the construction of system software on multicore machines. »

It is still at the forefront of the language presentation.

They are smart guys, so I can only conclude that "systems programming" means something different to them than it does to many other systems programmers.

To me, "no imposed GC" is a non-negotiable element of being a systems programming language. So I am far more drawn to Rust than Go.

"Systems" in Rob/Ken's time was services/servers - what we call applications these days.

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.

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.

To me the area where Go excels the most, and where I feel most strongly compelled to use it, is in tooling apps that you expect your users to install on their machines and run from a command line. This has been an area where python and ruby have been pretty common, but they're both a complete pain in the ass to use that way (setting up virtualenv, setting up rvm, pip problems, gem/bundler problems, etc).

For eg. we use vagrant and fabric at my work for server management (vagrant+fabric for dev environments, fabric alone for production servers). One's written in ruby and the other is written in python, and we have to spend a non-trivial amount of time managing their dependencies so they continue to install correctly. If they were go apps we'd just build and install binaries.

This is the area where I think Go is taking up python users, personally.

Indeed! It's a very practical extraction and reporting language.

Your approach to concurrency matters even more than the tool you use, and python is a great tool for network services. It's my preferred tool actually.

Maybe it's time to start porting twisted to go.

Coincidentally, Redhat's python tools are one of the major reasons for continuing support of Python 2.

If the next Mac OS X release has python 3... then we things will change really quickly.

Apple has no interest to migrate their Python configuration scripts to Python 3. I use Python 3 for my side projects, so I compile it myself or install it with Brew on OS X, but I suspect most users will use what comes with the OS (which is 2.7.x). One can hope ...

In conclusion, on the Linux land we'll see in about 4 years, for OS X ... maybe this summer or sometime in the future. In any case, I see no massive Python 3 adoption in the near future.

It is not really important if it is the default python or not. Python 3 is no less available than ruby or nodejs or any of the other contenders presented in this thread.

Ubuntu not only includes python3 in the base repos, I'm pretty sure its on the CD and used by some core packages now -- the conversion project that is ongoing but not yet complete is to completely eliminate python2 from the base install, which is not yet complete.

I think you are confusing several different things:

1) "switching to Python 3" -- if by this you mean making /usr/bin/python point to python 3, that will never happen on Ubuntu (and probably most other distros that aren't Arch.) They've stated that even when everything that relies on python is moved to python 3, they will follow PEP-349 and keep python 3 at /usr/bin/python3. /usr/bin/python will only exist when python2 is installed and will always be python 2.

2) "removing Python 2" -- obviously, they won't retroactively do this to an existing LTS release. It'll probably be first done in a regular release between now and the next LTS release (it was targetted for this LTS release, but not everything was ported, so currently both python 2 and python 3 are used.)

3) Making Python 3 a "first class citizen in the Ubuntu world" -- it already is.

This is about consistency given that major versions aren't intended to be backward compatible so scripts either fail or find a compatible python when using a shebang, not about what is "default".

edit: markdown... oh, nevermind.

I was looking at making a restore from backup script today (tomorrow I will likely implement it). I have been using Python and Django for the last three years almost exclusively. Perl just felt like would more natural fit for the job (with the exception of messing about with dates part).

I want to iterate how important these two factors are.

Python is a joy to get started with because the documentation is very easy to understand, very well organized (search results are almost always relevant), and it includes lots of examples.

The large community takes care of what the documentation lacks. Stack Overflow is loaded with Python knowledge, something I realized I took for granted now that I'm learning Ruby.

Why should I even bother with Python 3?

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.

There is a lot more useful code and libraries out there for python 2.

http://sourceforge.net/projects/pymol/

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!

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

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.

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

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

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/

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

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

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

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

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.

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.

+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/ (I am not affiliated, just really impressed)

</offtopic>

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

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

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.

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.