Hacker Read top | best | new | newcomments | leaders | about | bookmarklet login
Python 3 can revive Python (medium.com) similar stories update story
379 points by coldtea | karma 86593 | avg karma 2.38 2014-05-26 16:54:23 | hide | past | favorite | 242 comments



view as:

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

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.


> There's really not that many magic bullets (other than proper functional programming, maybe, which isn't about to happen in Python).

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.


"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


I found to my surprise that these days Java is as productive as anything else. It's not like the early days anymore; modern Java has generics, reflection, now lambda; there would still be more finger typing than I'd ideally like, but the IDEs are more than good enough to make up for that, to the point that a nontrivial program now usually takes fewer keystrokes to write in Java than almost any other language.

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


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.


Yes, the Go web prototyping story is a bit weak. If you want to do serious development in it I think it's pretty good, because frankly for years our web frameworks in most other languages have been unbelievably contorted around not having something like goroutines in ways that we've stopped even being able to see because they're so darned pervasive, but if you just want to slam a decent site out (and there's nothing wrong with that) there's no great story there right now.

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

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.

I don't know why people are leaving Python for Go when they could be using PyPy or Shedskin. There are plenty of ways to be fast using Python.

Visibility probably. Every whiner blogs "I'm leaving Python for Go" but that was the first time I saw https://code.google.com/p/shedskin/ mentioned.

I think Christian derived people have a tendency to seek solutions as an externality. Rather than focus on the root cause of something and transcend it, we destroy and recreate using a different raw material. Hence leaving Python for X and not realizing that the pattern, leaving <thing> for <replacement>, will continually have one in a cycle of stagnating reconstruction.

If Python is slow, we are using it wrong.


It's easy to lose track of this in the torrent of "PyPy Benchmarks Show It Sped Up 2x!!!!" and "Latest Javascript Engine 50% Faster Than The Last One!!!! OMG!! Node!!!!", but in absolute terms, the dynamic language JITs are still quite slow. It's an urban legend that they are anywhere near compiled performance. Except LuaJIT. "Faster Python" is still slow. Unless you're in a tight loop adding numbers together, but I'm not.

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


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

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)


JITs are/can be faster than static code. They can make dynamic and data dependent optimizations not possible any other way.

I think you're fundamentally confused about how computers work. It is always faster to do things in software than in hardware. Naive optimizations are always faster than data flow analysis from profiling. More layers of indirection make things faster, so the fastest languages put interpreters inside of their interpreters. War is peace. Slavery is freedom. The kids are getting smarter.

Why the heck are you posting stuff on this hell hole? Why am I posting stuff?

Procrastinating writing a JIT? http://dynamorio.org/

other than proper functional programming, maybe, which isn't about to happen in Python

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


> If we could just have tail call optimization, I think we could make the rest work

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)


You only have to write thunk/trampoline utility once, and it is similar to how we do it in clojure.

Tail calls have already been implemented in Python using a similar technique, http://code.activestate.com/recipes/496691/

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


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.


Well the article referred to actual posts by 'people including whole startup teams blogging about switching from python to go' (somewhat paraphrasing), which has indeed occured.

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.


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.


I've never found myself wishing for a better type system, although maybe I've just been steeped in the world of dynamic, strongly typed languages for too long.

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


I never found myself wishing for a better type system, because my idea of "static" typing came from C and Java, where it is mixed up with variable declaration, state, and a bunch of other things it has no right to be associated with. Basically, I was scarred.

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


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.


I would say Go's type system is the least impressive of its features when compared to most other statically typed languages.

but for an interpreted dynamic language, python is particularly slow when compared to other popular ones (for execution time).

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

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.


Don't you think that people should rather consider Julia or even Java instead of Go as Python replacement?

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

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


Here's one particular example of a real company moving a production application from Python to Go:

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


Our team is traditionally a Python team; it's a good fit for the kind of nimble projects we need to take on.

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.


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

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

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

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

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.


`pip freeze`

In my experience, you can bundle the dependancies, and then add the path to your search path.

Not the best approach, but it does work.


If a package doesn't get all its dependencies installed via pip its because of missing information in the package itself. That's neither a flaw of pip or Python but will cause problems for any package manager.

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.


Not necessarily. pip cannot resolve all dependencies. For example, if a package specifies both numpy and pandas as a requirement, installation will fail. This is because pandas in turn requires numpy, and pip does not resolve the dependencies in a single step, you need to install numpy first and then go on with pandas.

In that case, couldn't you just specify Pandas as a dependency and Numpy would automatically be installed?

I think not, I think the problem is that it is a build-time dependency and pip wants to resolve all dependencies before installation begins.

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


I see, thanks for pointing to that issue. The other issue referred https://github.com/pypa/pip/issues/988 is still open, so I guess they work on sorting this out.

At my company we build with Jenkins, tarball it and deploy from that. I haven't had experience another way but I think it ends up being more efficient and less error-prone than doing actual pip installs during deployment.

That's basically what the company I used to work for did as well with our large python application. Build using a build script, pulling in dependencies from local build server, test, package up the result and deploy. Pip was used for pulling in libraries to the build machine and never used during deployment.

(dormant) PyTables developer here, we do have a requirements.txt file but I understand our setup.py needs an update. Please open an issue on github and tell us about your experience and how we can improve it.

I will soon, thanks!

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.


> 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

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


I install rvm on my production boxes as explained at https://rvm.io/ then I put .ruby-version and .ruby-gemset files in the application directory to select the interpreter and the gemset (I might need to have different applications running - especially on staging machines). Finally I use bundle and a Gemfile. It's pretty easy. You got another answer suggesting rbenv which is also fine.

There is work going on in the python packaging SIG to make installing better. One of the big additions for pip is the ability to install pre-built wheels for those "hard to build" packages. There is also work happening on a new package metadata standard.

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


You should avoid using normal requirements.txt files in production. If you want to use pip, it's better to "pip freeze" your test environment, and use that requirements file to specify the production environment.

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


Or just specify versions in your requirements.txt file to begin with.

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.


Just a note so people don't get confused, while specifying packages with >=1.1,<1.2 seems to be similar to the tilde in npm, in practice it isn't.

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.


Long compile times can be fixed with pre-compiled wheels, http://wheel.readthedocs.org/en/latest/ I shaved off 4 minutes of our build time of numpy/pandas with it.

I recently tried to deploy a desktop app written in Python. It was a nightmare. I recently taught scientific Python to prospective switchers. The installation step was a nightmare.

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.


wheels are pretty mainstream and are getting better fast. Forking the package management ecosystem again, just after we got over the last round of headaches there, is only going to make things worse

As several person mentioned already, wheels (http://wheel.readthedocs.org/en/latest/) make deploying much easier (and faster), not needing to get anything from pypi.

There's nothing like a good old deb (or rpm) package. Learn fpm[1] and bundle your dependencies instead of hoping that they get there.

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


Check out devpi (http://doc.devpi.net/latest/). We build our projects as wheels with pip using devpi as a custom index, i.e.:

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.


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


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.


This was my initial reaction after coming from Java, generators, list comprehensions, insanely easy iteration, Python makes a lot of things extremely easy that would take 10+ lines in another language.

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.


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.

I'm still running into php programmers who are just now switching to python/django. They follow the work, and there are a growing number of sites that are now django and need to be worked on.

I think the idea is "newer programmers" as newer hackers (e.g the HN crowd etc), not "newbies".

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.


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


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.


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

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.

I only want print as statement again

I thought `repr backticks` were convenient, but alas "there is only one way to do it".

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

Out of curiosity: why?

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.

Print '\n'.join(str(x) for x in list_of_tuples)

Not as nice, but doable.


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.

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.


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

I can never remember the python 2 quirky, inconsistent syntax, I always have to look it up.

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


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

You can. Compare the output from:

  print "foo"
  print "bar"
With that from:

  print "foo", 
  print "bar"

Not at all, I can live without it, was only less thing to type when debugging.

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.


You can write pretty functional python, though. There are python compilers like Nuitka (I'm sure there is an llvm frontend somewhere...), mobile is kind of a pickle, yeah, I'd say Django is pretty rails but I always use bottle because I've never needed the kitchen sink before, and the reason its not in the browser is not pythons fault.

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)


You can use Ruby outside Rails, too, or Java outside of enterpricy applications. Last time i checked (few years ago) you could even use PHP for GTK desktop apps. You can write laggy mobile apps in pretty much every major language.

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.


The main problem with functional programming in python is the bizarre neutered version of its lambdas. It really limits the expressiveness of using anonymous functions in python, as compared to, say, JavaScript. It's by far my biggest complaint with what is otherwise one of my favorite languages.

Since you can define a function inside a function, why does it matter that it isn't anonymous?

Having done a lot of python and JavaScript, all I can say is it does matter. It is an extra redirect as you try to find out what is happening as part of a callback (repeated over and over). It is also additional cognitive load as you now need to mentally parse the function's name (which you don't actually care about) and the function's purpose. Finally, it is more time consuming.

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.


Is tail optimization a language or an implementation issue? Couldn't that be implemented in the compiler without changing the language?

Don't try to fake anonymous functions in Python. Use its strengths: decorators, generators, etc.

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/


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


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,


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

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.


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

I think many programmers (myself included), use more than one language at the same time. At the moment I use VB, python, flex and java, for different environments and different problems within those environments. If I want to quickly do something, for instance manipulating a CSV file, Python is my goto tool. And this is the reason Python will be popular for many because it can do certain things very fast and with minimum of fuss. Therefore I think Python will be around for awhile.

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.


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


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.


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


That pretty much reiterates my points from last time we discussed (not many hours ago).

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.


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.

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

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.

Given that the functional programming story in JavaScript is much more developed, "vastly better language" may be true as long as you only consider the object-oriented side of it.

How is it "much more developed", without providing generators, coroutines, or comprehensions?

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


ECMAScript 6 has generators, and they are already available in Node.js.

Javascript seems to go the opposite way of python: instead of ironing the warts out, it adds them. The DOM-API is nonsensical and ugly? Why not add language features so we can implement it in pure JS? Sounds like a great idea.

How does that relate to ES6 generators?

While I agree mostly with your point, I think the DOM example isn't going to work. The DOM is a spec and doesn't really have anything to do with JavaScript.

The DOM API has nothing to do with JS.

So we need to get Python embedded into a couple of major browsers?

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


There used to be something for Internet Explorer 4 and above. All you had to do was to set the language attribute of the <script> tag to Python. See "Python Programming On Win32: Help for Windows Programmers", page 437 [1].

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


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

I think you missed my point. I presented a hypothetical situation where in an alternative reality Python 3 happened to instead integrate something like PyPy in it (or say have any other mind blowing features of that caliber).

> 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


I can tell that proper Unicode support is a reason to discounting a language/library if you're not a native English speaker and/or writing programs that have to be localized.

Python was created by a non-native English speaker.

Well, he's Dutch, his language uses an alphabet meaning that even with all the accents it's still a one byte language.

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


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


This makes me wonder about Ruby, whose creator is Japanese and Japanese is certainly not a language whose characters can be expressed in a single byte. Is Ruby better than Python for complex encodings? If so has it always been this way, or did Matz just deal with it in the early days?

Yes, Ruby has long had decent (i.e. comparable to Python 3) encoding support. But in the early days not much was made of this, perhaps because Rails was the driving force behind Ruby adoption in the west and Rails' encoding support was much worse than what Ruby could do.

I know that. I'm Italian, and Western European Languages can be expressed on a 1-byte character type. I also understand that the performance gain of 1 byte char was significant. But now is 2014 and not to have to wrestle with encodings definitely worth the performance and (somewhat) complexity hit.

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


I did this recently. I can't remember the details but it was absolutely insane.

Before Unicode existed

And Python3 was also endorsed by the same person, so?

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.

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.

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?


If python 3 hadnt chosen to swap all its internals for unicode this miiiight have been plausible; but as it stands the bizaar 'python X' language subset that runs on both is about as good as it gets unfortunately.

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


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

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


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.


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

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.


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.


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.


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.


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


I'm using Python 3.4. All the libraries I need are available, including the world's best database library, SQLAlchemy. It's a more pleasant experience than Python 2.x. And I have the peace of mind knowing that I'm not stuck on a legacy, deprecated platform.

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?


I thought I was alone. I also stopped trying to convert people to Python 3. It is a much better language. By this point, it should be obvious. After taking it for a test lap, and after cursing at forgetting parenthesis on print for the hundredth time, you get it. Anyone who uses python and, by this time, hasn't taken python 3 for a test run isn't worth my advocacy time.

I don't think it's a question of test runs. For most of us, it's a question of waiting for various libraries to be ported.

How do you know what "most of us" think?

speaks to people, reads forums, participates in conversations like this....

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.


Selective hearing has not provided the other side of the story. Because it's not true at all that everyone or even a clear majority agrees with the viewpoint you've expressed

The porting is not that hard. Almost every library which isn't ported at this point is probably legacy, depreciated for something significantly better, or abandoned.

You say it is a much better language. I see very little difference between the two.. With the exception of exceptions, and print I think all the changes must be to language features I don't know about / use.

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


Here's a small reason I found when refactoring some code today:

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.


I had some bug in a Django library, that went away by using Python 3. Can’t remember what it was exactly, but it was related to Unicode support.

We see Golang in production in our practice pretty regularly. Not many shops use it exclusively, but it pops up in backend systems. You're right that there are things Python does that are painful in Golang (SQL databases are a good example), but the things Golang does better than Python/Ruby, it does way, way better than Python/Ruby.

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


We switched some of our services from Python to Go and are very happy. To be more precise - we chose Go over Python for new projects that would have been developed in Python a year ago; we didn't rewrite anything from scratch in Go - though we'll probably do it for a couple of services.

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.


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.


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.

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.

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

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?

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.


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.


Those 4 things are really just nice-to-have features though. I can work around all of those with minimal effort (asyncio and unicode), or it just doesn't come up much (yield from and nonlocal)

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

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


Unicode support in Python 2 is broken. That is not a imaginary problem for me. Unicode in Python 3 is much cleaner and robust.

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


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


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.


The people who call Go a systems programming language are fundamentally misguided. It is an applications programming language under any reasonable definition.

You know that "the people who call Go a systems programming language" are its authors, do you not?

You know that they retracted that line from the Go introduction text on the webpage, don't you?

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


http://golang.org/doc/faq#What_is_the_purpose_of_the_project

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


Yes, but they are also the ones being surprised that Go is cannibalizing Python, not C or C++.

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.


They actually dropped the "systems" bit on the home page because people told them it wasn't a systems language.

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


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.


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


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.

> I don't get why is Go defined as a competitor to Python.

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.


I think D will grow in that server space.

> I add that Python is excellent at data representation and transformation

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


I see what you did there :-)

When it comes to Unix glue jobs, it's certainly no Perl.

Shame it doesn't have regex syntax built in...

Go has pretty neat semantics for channels and goroutines, but it presumes you want threads and blocking IO. Or in other words, "hey kid here's some rope"

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.


The question is: is the Python community OK with it becoming a niche language for scientific computing, or do we want to to keep being used as a general purpose language?

Python is also the modern sysadmin's Perl. This is a huge niche, to the point of not being a niche at all. Just take a look at the number of system tools used in a Redhat install that use python.

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


The next RHEL is going python 3 though I think? Fedora has done nicely over the last couple of years packaging everything for python 3 as well. A dozen or so packages left to do, but they are going well. Ubuntu, Debian, and Gnome have also been pushing to get to a python 3 use by the base system in the last releases... and are almost there as well. This of course has meant a lot more packages have been ported upstream in the last few months.

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


No major Linux distribution uses Python 3 as the default Python today. All of them use Python 2. Yes, they have a half backed Python 3 alternative for "almost" all packages ... We can discuss more in 4 years when the next Ubuntu LTS will be released.

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.


I use Debian, and python 3 is one "apt-get install python3" away. Ubuntu probably includes the same packages in its repos. SuSE and Fedora are in the same boat (python3 in repos). Arch and Gentoo obviously package python 3. Redhat really is the black sheep here. There is no reason for the assertion that no major distro has more than a half baked python 3 alternative.

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 probably includes the same packages in its repos.

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.


Do you really think Ubuntu will destabilize their current LTS release by switching to Python3 and removing Python2 ? I don't know what Canonical will do for the next LTS release, but for the near future (read like 4 years) Python3 will not be a first class citizen in the Ubuntu world.

> Do you really think Ubuntu will destabilize their current LTS release by switching to Python3 and removing Python2 ?

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.


Actually it is important which one is the default, most users will use what comes with the base install and this will slow the Python3 adoption at least for a few years.

This is not correct. Arch Linux now uses Python 3 by default. (https://wiki.archlinux.org/index.php/python)

I was talking about major Linux distributions like in the first 3 or 4 (I don't want to dismiss Arch, but this more of an expert distribution than a major/popular one). Obviously, there are a lot of Linux distributions today, however most people will use some flavour of Debian, Ubuntu or RedHat.

I think a number of distros include python3 by default, but -- per python's own standards (adopted as a result of disruption caused by Arch having python3 as /usr/bin/python -- it isn't linked to /usr/bin/python but to /usr/bin/python3; /usr/bin/python is (except on Arch) always python2. That's not a matter of which is "default python" (e.g., even if, as Ubuntu plans to, python3 is the only python installed (not merely "the default python"), it will only be /usr/bin/python3, not /usr/bin/python.)

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


Also, Ansible: https://github.com/ansible/ansible

edit: markdown... oh, nevermind.


Is it?

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


> it has a massive advantage over many other languages: Great documentation and a large community

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.


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?


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.


> There's nothing to gain by sticking with Python 2

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


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://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!


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

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.

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.


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.


Potato, tomato. It broke backwards compatibility.

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.

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.


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


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

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

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

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.

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

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


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.


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.


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

</offtopic>


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


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.


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.

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.


I would love to contribute to make it faster.

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.


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.


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?

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

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.

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/


Legal | privacy