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.
"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.
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.
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 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.
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)
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.
> 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.
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.
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.
> 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.
>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...
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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...
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.
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.
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.
> 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 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.
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.
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.
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.
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.
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.
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].
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.
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... ;)
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.
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.
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.
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...)
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.
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.
241 comments
[ 2.8 ms ] story [ 261 ms ] threadPeople are leaving Python for Go because people have always left Python for fast compiled languages. Google ditched Python for C++ and Java. Java! I've seen a lot of projects get re-written in Java from Python, but no-one worried then.
Python 3 adds some cool stuff (async, in particular), and fixes some warts. It's a bit rude of them to force people to upgrade, but that will eventually pay off. It will add more things in the future.
The people who start new projects in Python 3 will have some short-term pain, as some libraries take time to port. There will be a long term benefit, though - future libraries will be better for Python 3, and they won't have to port their project.
The only controversial thing was the use of unicode. IMO, Python 3 made the right choice - you should make everything unicode where-ever it's feasible, because it's just a mess otherwise.
We just have to get a bit more daring; check out:
http://research.microsoft.com/pubs/211297/managedtime.pdf
Note the resemblance to Python, it's not an accident.
I think the angst about Go comes from the fact that someone who leaves Python for Java may still come back, because you can develop far more quickly in Python than Java. But someone who leaves Python for Go probably isn't coming back... my experience is that it is slightly slower (10-20%, YMMV but we're certainly not talking integer multiples) to cut out a prototype in Go, but that said prototype runs an order of magnitude faster, can potentially be optimized without much work for another order of magnitude (though ultimately this is more a reflection of Python's slowness than Go's speed), and is then much easier to maintain and extend, even on the timescale of a week or two, to say nothing of larger time scales.
A couple of people elsewhere in the comments here assume that Python must still be much easier to develop for than Go. It really isn't anymore; it turns out the combination of garbage collection and structural-typing-esque interfaces pretty much does anything you might have ever wanted Python to do, and a great deal of the rest of the differences turn out to be far less important in practice than in theory.
I first saw the idea in Joel Spolsky's "How Microsoft Lost the API War" [1], under the heading "Automatic Transmissions Win The Day", that the primary innovation of the 1990s was simply garbage collection instead of memory management. (As he is aware the idea is older than 1990, one presumes he means that it became practical and widespread.) The languages that spread this innovation, the "scripting languages" like Perl and Python and PHP and Javascript, changed a lot of things at once, which as any good scientist knows means it was hard to tell what about those changes actually contributed to the enhanced productivity that they certainly did bring. My experience with Go certainly gives me further belief in Joel's thesis... you read a bullet point listing of the Python features and Go features and it seems obvious that Python is a wildly better language than Go, yet... I've learned after all these years and all the languages I've tried out to ask myself, if the features are so important, why don't I miss them? Because in practice, I don't. Rip closures out of Go, and I'd miss that. Rip out the goroutines and I'd miss not having something like generators or something, indeed, the language would nearly be useless to me. But I certainly don't miss metaclasses or decorators or properties. I will cop to missing pervasive protocols for the built-in types, though; I wish I could get at the [] operator for maps, or implement a truly-transparent slice object. But that's about it.
[1]: http://www.joelonsoftware.com/articles/APIWar.html
Which of course reinforces your main point: nowadays the language differences just aren't that big.
I actually really do miss list comprehensions and properties and pervasive protocols for built-in types and really concise keyword/literal syntax. I don't miss metaclasses, and I only vaguely miss decorators. (Go has struct annotations and compiler-available-as-a-library, which in some ways are better.) Properties in particular are really useful for the evolvability of code; otherwise you have to overdesign up front to avoid a big rewrite as you switch from straight struct fields to accessors.
I'm actually leaning towards Java 8 + Jython 2.7 as I consider what language to write my startup/personal projects in. Jython 2.7 gives me basically all the language features I actually cared about in Python, and it fixes the Unicode mess that necessitated Python 3. It has no GIL and solid multithreading support. The Java layer gives you all the speed of Go and more. And the interface between them lets you seamlessly use Java within your Jython scripts, so you can easily push code down into the Java layer without having to rewrite your whole product.
If Python is slow, we are using it wrong.
Moreover, a plot of their performance over time rather strongly suggests that they've plateaued. Personally, barring any major JIT advances, I'm considering the book closed on the topic of whether JITs can take a dynamic language and make it as fast as C or C++: No.
(Recall that a Java JIT is another issue; it starts with the static typing of Java, and then JITs from there. It has a much larger array of much more powerful guarantees to work with, that the dynamic languages simply don't. Go will be running at straight-up C speeds (which it does not currently) long before Python will.)
It's possible to close more of the speed gap, but these JITs have to be able to:
* identify and use native primitives (avoid overflow and so forth)
* prefer stack allocation over heap (improved escape analysis)
* inline memory allocation and freeing and remove unused codepaths
* optimize across the boundary between implementation language and hosted language (which I believe requires self-hosting)
If we could just have tail call optimization, I think we could make the rest work (well, maybe better lambdas, too).
Manually thunk/trampoline it?
You only have to write thunk/trampoline utility once, and it is similar to how we do it in clojure.Well, people start using it now. I'm teaching Python classes exclusively in Python 3, and do all my personal projects in Python 3 and love it.
I would like to finally have a "stable" Python 3 with forward compatibility. This is important for the future of the language, else no-one would invest in it.
If you think that Python and Go are made for the same tasks then you're really confused.
I try to explain to them that obviously Python developers care about these things, and I show them some of the most common pitfalls. But this isn't the first, or even fifth, thing that you think about when you're coding in Python.
The key thing to remember with dynamic languages, and particularly interpreted dynamic languages, is that they're optimized for programmer speed, not execution speed. And that's fine nowadays, when programmers are expensive and computers are not.
So yeah, maybe Go will run your program 100 times faster. And there are cases when that's important. But in most cases, it's not, and the benefits that you'll get from having a happy, efficient developer will be more than worthwhile.
Having a decent type system and decent concurrency primitives are far more attractive.
But there's no doubt that concurrency is indeed one of Python's weak points, and Go's strong points.
A good type system quietly and with minimal programmer effort encodes and documents your code, helps you find mistakes faster, guides your re-factoring, and gets out of your way when you don't want to deal with it.
It's not Python that's slow, it's CPython. If you use PyPy you get a much faster implementation of Python, not too far from Go speed.
Yes, PyPy is probably faster than CPython. But what then? In most cases, CPython is THE PYTHON. PyPy is still in its early age and has a lot to demonstrate itself as a serious alternative to CPython.
On the other hand, programmer could get out-of-box performance boost from adapting Go without worrying the potential compatibility issues.
PyPy is a very interesting and promising project. I highly respect that. I just don't like the idea of merely using it to dodge the blame of performance slowness, when what people are really talking about is CPython.
A big reason for this is that some prominent members of the Python community left for Go and that Go talks have started appearing at Python conferences.
Well, from TFA: "Again, they’re not many, but they are quite vocal (including whole startup dev teams blogging about switching their codebase), and enough to create a certain buzz (and to surprise Rob Pike, who initially expected people to come to Go from C/C++)".
Data are always hazy in our industry -- who knows what each company/developer uses? But we can gauge interest from the discussion around something. So:
1) Go had several known startups (and established companies) post that they migrated some of their services to it from Python.
2) We have Rob Pike, who wrote a couple of years go he was surprised seeing most in the Go community come from Python, whereas he expected them to come from C/C++.
Now, I don't know what you mean "If you think that Python and Go are made for the same tasks then you're really confused". What's confusing? Sure, Python has some unique niches (like scientific computing), but there's a lot of stuff people use Python that they could (and are) use Go for.
I'm sure you've heard of Twisted. Go solves a similar problem quite nicely. Also: RESTful services. But even more so, people also use Go for glue stuff, including for stuff previously relegated to a scripting language.
It's not that huge numbers are leaving Python for Go. Perhaps not even 1%. But it's a vocal 1%, and it might also be an influential 1%.
Heck, at some point Perl was king of the hill for scripting and web application development. But then 1% went to Python, and 1% went to Ruby. And then they continued going...
https://www.spacemonkey.com/blog/posts/go-space-monkey
We've spent the last few months writing some of our tools in Go. For our purposes, it is slightly slower to develop in, but we have much more faith in its correctness, and deploying the code is a dream. Also, it's much faster than what we've been useful.
We'll still be doing some Python development, but were it up to me I'd be using Go for everything I ever used Python for.
It was all fine once I got it worked out but it would so much nicer to provide a requirements.txt file and have pip figure out the ordering and dependency stuff. That and being able to install binary packages in a simple way from pip would make me much happier with python (no more waiting 10 minutes for numpy or whatever to compile).
As far as actual language features go however, I still find python a joy to work in.
Not the best approach, but it does work.
I find the combination of virtual environments and pip very convenient to work with. When I run into trouble with missing dependencies I often find the project on GitHub and can send a pull request.
Regarding Numpy and the scientific Python stack, check out Anaconda https://store.continuum.io/cshop/anaconda/ it makes managing environments where you need these packages a lot less painful.
See https://github.com/pypa/pip/issues/1386 (oddly, the issue is closed, while the problem is acknowledged).
Ruby installs are especially difficult to manage. Despite the numerous tutorials out there, I still don't know what, if there even is one, the canonically best way to install ruby and necessary gems is. RVM? Install through Brew? Add path to ~/.bashrc?
I say this as someone who likes using command line so much that I've written Caskfiles to automate my deployment to fresh OS X Machines.
Wait, what? On production, install the exact ruby you need from your favorite package manager. On your dev box, install any rubies you need through rbenv [1]. Put all your gem dependencies into a Gemfile [2]. On either end, bundle install [--deployment] and call it a day.
[1]: https://github.com/sstephenson/rbenv
[2]: http://bundler.io/v1.6/gemfile.html
Unfortunately, that's all I've learned from lurking on the mailing list for a couple weeks.
Otherwise you are just asking for nasty surprises when packages upgrade.
If you want to keep up to date with security and bug fixes (but aren't yet ready for the next big feature/backwards incompatible release), you can specify the lines as 'package>=1.1,<1.2' to get 1.1.x fix releases.
`pip list --outdated` is helpful, too.
Basically, when you use >=1.1,<1.2 it will install the best version that matches at the time of first install, and then that version will never be upgraded because it will always satisfy the requirements. So you don't actually get 1.1.x release updates unless you install them manually.
We do, however, use this syntax in development when testing new versions to make sure any subsequent runnings of pip doesn't obliterate the new versions of modules we are testing.
I'd love official pip support for ~1.1 type declarations.
We really need pip wheels or conda to become mainstream. Pip alone doesn't cut it on platforms without compilers (Windows / OSX). Standalone installers are fine, but they don't resolve dependencies and they are only available for Windows.
I totally agree that the installation and deployment story should be a top priority. Once done, it would be another very compelling point on Python 3's feature list.
[1] https://github.com/jordansissel/fpm
BUILD_DIR="/tmp/wheelhouse/$PROJECT" pip wheel --wheel-dir=$BUILD_DIR --find-links=$BUILD_DIR --index=http://$DEVPI_HOST:$DEVPI_PORT/${DEVPI_USER}/${DEVPI_INDEX} --extra-index-url=https://pypi.python.org/simple/ ../$PROJECT
This will try to get packages from your devpi index, but will fall back to pypi if you don't have them.
Then upload this to devpi. It can later be installed by pip with:
pip install --use-wheel --index=http://$DEVPI_HOST:$DEVPI_PORT/${DEVPI_USER}/${DEVPI_INDEX} $PROJECT
This makes deployments super fast because you're deploying pre-built wheels instead of downloading and compiling from pypi. It also gives you resiliance by storing copies of the dependencies you need in devpi, so if they vanish from pypi (or it's unavailable) you can still deploy your software with all the dependencies you developed against.
Any evidence? If it's personal experience, then mine is exactly the opposite.
I don't know if such a thing exists, but maybe a big list of the main changes would help convince people more (type annotations, yield from, the forthcoming @ operator). From what I've seen and read, of course all this is somewhere in the docs and release notes, but I've never seen a clean concise list of the main new features, fixes and reasons why these features are cool.
Specifically, my experience -- teaching Python to dozens of experienced developers every month, for more than four years -- is that people from the C, C++, C#, and Java world and shocked to the core by the ease with which they can do certain things in Python.
Maybe a Ruby or JavaScript developer won't be blown over to the same degree. But there are a heckuva lot of people coming from static, compiled languages who haven't ever seen the power and flexibility of Python before, and love what they see.
It might be surprising to many, but Python feels like C to me. Maybe that's why it's popular as a system language. making people feel at home helps. Another reason of its success might be that it is a simpler C so it got many developers coming from C like languages (Java and PHP among the others). As a rubyist I feel as Guido made all sort of wrong decisions while designing Python but as Matz said "I tried to make Ruby perfect for me, but maybe it's not perfect for you. The perfect language for Guido van Rossum is probably Python." So everybody is happy and I think that the news about the demise of Python are greatly exaggerated. It's here to stay for the good and for the bad.
Sure, people introduced to Python for the first time might find it impressive, but what about people who know Python and also are tempted by Go, Clojure, etc.
I think this will happen eventually, what with some of the recent PEPs; I just wish it could happen faster. Optional typing is the best of both worlds and there is no reason not to have it.
edit: I wanted to respond to this myself, since upon rereading I no longer get the impression the proposed changes need 'break' backwards compatibility per se. For the suggestion on removing the GIL specifically, this would completely necessitate a revolution in the design of python programs such that even if, say, the libraries that had already been ported at the time of 3.2 still work in 3.9, their implementation would be senseless by 3.9 conventions.
Not as nice, but doable.
Seeing how my transition to Py3 got hung up on sending bytes in and out of ZeroMQ sockets, I might stop that now.
Back to the for loop or join the strings as suggested below.
PRINT TO A FILE, OR STDERR print >> sys.stderr, "blah" What are those '>' signs here? Why two? What happens if I use one only?
Compare this to (py3k): print("blablah", file=sys.stderr)
PRINT WITHOUT NEW LINE sys.stdout.write('blah') I can't use print to print?
compare to: print("blah", end="")
DISABLE FLIUSH In python 2 there are 2 or 3 different ways to do that, all more complicated than each other. Compared to:
print("blah", flush=True)
Finally, it's a function, you can do everything you do with a function, use map, return a print from another function, include it in generator expressions etc...
You can. Compare the output from:
With that from:But I can not imagine the languages, which are all this, to spread so nice and readable from command line scripts to scientific computing to big server applications.
Python's use cases will not go anywhere, so don't panic: Python is doing just fine and improving in many areas while holding on to its core values.
On that topic, I'd spend a day writing cobol or C++98 if I could get QML + Python in browsers. Python as a script/python, and QML as a uri schema (ie, http://foobar.com/baconwitch.qml)
My point is: Most successful languages have their point, why you use them. They are successful, because of their focus on not because they try to beat every other language imaginable.
Python's use cases are already pretty diverse. So I have trouble to understand the constant fear Python could miss out on any platform or paradigm.
I really like coding in python, but the weak-sauce lambdas are on of my least favorite things about it. I would like tail call optimization, but living without it doesn't bother me on a daily basis. Lame lambdas do bother me on a daily basis.
Anonymous functions work well (err, passably) in JavaScript and Perl. They don't really work in Python, and of course you'll just run into pain if you try to force them to.
Perhaps also make some noise about this PEP: http://legacy.python.org/dev/peps/pep-0403/
It is a death by multiple paper cuts. Go is just one of the cuts.
Besides Go (and others have mentioned so I am just repeating them). There is Node.js (Javascript), Rust, Dart, Clojure, Julia, C++11, Java (due to Python never making it far on Android). Not one is enough to eat Python's lunch as they say, but they all are taking a little nibble and soon enough Python stays hungry.
Another aspect is that there are multiple forms of deaths. It doesn't have to be an abrupt and dramatic death. But I am afraid it will eventually become like PERL. Still there, still usable, still jobs for it, but not many articles about it. Not much innovation. Not many new developers considering it as an option. It will just be a decline of sorts.
My personal view is also that once someone (or a team) seats down and thinks about cleaning up and doing a re-factoring, of their code, maybe in hopes to move to Python 3, they will be looking at other platforms, and languages as well.
I'd say python took the place that would today be Perl's, were it not for the whole Perl 6 fiasco, and that none of the supposed contenders actually vie for that exact spot,
I used to know a guy who'd freak out about not being able to read Perl. He couldn't write ("speak") it either, so I'm not sure what he was expecting.
I have seen neither evidence that python is "dieing" in any way, nor that people are dropping it because it lacks radical new feature X. Things may be more competitive now but I don't see any stagnation in the community - and that's always been one of python's strongest points.
Yeah. I'm sure there weren't that kind of hard numeric evidence about Perl dying either.
Perhaps, you know, what languages are getting adoption and which might be lossing traction is more of a "sensing the buzz" and following community discussions affair, than some statistic bureau giving hard counts.
>nor that people are dropping it because it lacks radical new feature X
Well, I'd say people EXPLICITLY posting "our team left Python because of it's bad concurrency story and went with Go" is evidence of people "dropping it because it lacks radical new feature X". And we've seen a few of such posts in the past year. Also a couple high profile Python devs migrate to languages such as Go.
Python stable in top 10 in TIOBE index: check Python increasingly popular topic on StackOverflow: check Python jobs in popular demand: check Python community is active and lively: check Python used in large scale deployments: check ... and so on.
I'm not saying they can just rest on their laurels, but to claim python is in crises is just bull. People are well aware of the issues and difficulties of updating to new versions, PEPs are written, improvements discussed, etc - the ability to respond to new challenges is key to the survival of a community, and python has had this built into its development process since forever.
Actually they very much are. Anecdotes such as what we have, real and verifiable posts "our company switched to Go", are very much evidence of people switching to Go. Finding the mangitude of that is up to us -- there are no hard numbers available. But if you care about this, you have to gauge it from what information you have.
Oh, and in certain fields, like what's the next big thing in pop, fashion, etc -- and I'd argue: programming language, you don't have hard data (until it's too late). You have anecdptes and people murmuring stuff here and there, and you have to figure it out yourself.
https://news.ycombinator.com/item?id=7801004
Besides what already was said. It is also important to emphasize that Python 2 is already pretty good. So it is not that Python 3 is bad, it is just that it is very hard to improve on 2.
Ironing out the warts is good, but this was not the right time. This should have happened 7-10 years ago.
Nowadays I can't imagine a lot of people discounting Python because of the print statement, unicode support, division rules, or lack of yield from statement.
It will be performance, concurrency, ability to create web back-ends, installing packages, testing frameworks, IDE support.
Apart from allowing optional type annotation syntax I just don't see Python 3 providing a good enough carrot to force many projects to switch to it.
Imagine you go to a manger and tell him. "Oh this 800K line project we have in Python 2 will be ported to Python 3, can we have 1 month to do that?". Ok then the manager might say "Well we have these features to implement but if you all say so. But what will we gain by it, to offset the time spent (opportunity cost) and risk of breakages". And if the answer if "oh you know print is not a statement anymore, and many dictionary and sequence methods are not iterators not returning values, and this new Twisted-like async library...' Well you can imagine many a manager might just say "well that is just not enough".
If in turn the dev team came back said "Oh yeah they integrated PyPy, STM module, requests module. Static type checking via annotations, 3x speed improvement, no more GIL so can do some CPU intensive work if need to.". I can easily see this proverbial manager OK-ing that.
Just having to use functions to emulate all of these (and many more) is not what functional programming is all about.
Edit: Asked on twitter for any work on this: https://twitter.com/alexchamberlain/status/47126815887225241...
[1]: http://books.google.ro/books?id=fzUCGtyg0MMC&pg=PA437
> So, you'd want people to switch to PyPy, not Python 3.
I personally would want Python to be used more because I like it. But I see how a community has been divided over what I see is an un-necessary backward incompatible change to the language.
To put it another way. I would rather not have backwards compatibility issues and just keep having 2.8, 2.9, 2.10, if all we got was what we got with 3.x
Having to work with 2 bytes languages (CJK typically) without proper Unicode support is much more of a hassle.
Proper unicode support is not even close to being a priority when it comes to dealing with Japanese text. No one would store important Japanese text in unicode. http://en.wikipedia.org/wiki/Han_unification#Unihan_.22abstr...
One size doesn't fit all.
As a unrelated (to Python) example of the encoding nightmare: have you ever tried to import text from CSV files generated on different OS/locales in Excel that don't support Unicode-encoded CSV files? It can be made, sure... but, man, if it can be avoided... ;)
The people I know who use Python, including myself, range from utter beginners to experienced programmers, but are using a relatively small subset of the available libraries, and are just using whichever version we started with. I could translate my code to version 3 in a heartbeat, but have no particular reason to do so. I've translated some of my most important stuff from BASIC to Python after all.
Professional developers will do whatever is right for their projects.
My concern would be for the folks who develop and maintain the libraries -- for whose generosity I'm grateful. If there were some sort of consensus on the direction of Python, I'd hop on the bus just to make life easier for those developers. Their time would be better spent adding useful features or just combing the code for bugs, than coping with multiple Python versions.
Could a single Python interpreter somehow manage a mixture of 2 and 3 code?
You could write code for a subset of 3 that would be fully functional on 2. There are a number of efforts out there to provide the missing compatibility layer that opened a chasm between Python 2 and 3. My contribution is https://github.com/kislyuk/eight.
Depending on what you're doing, writing code that is compatible with even the easiest combination of versions (2.7 and 3.3) can be unreasonably hard, and the officially recommended migration tools suck. IMO this has to do with a few unfortunate design decisions made back in the 2.x days (most egregiously the ascii default encoding and silent Unicode coercion), combined with an unwillingness to admit that 3.0-3.2 were really bad in not providing a migration path and work on a more comprehensive migration strategy and backports library.
:(
I guess I have to roll up my sleeves on that one.
It's a dependency for networkx, to draw diagrams...
I use it every day and even though I love JS (and have been thinking about looking into Go because of all the positive noise) I don't see Python going anywhere for me at least. It is simply too handy and familiar. Maybe it just will be used slightly less by some?
I'd have to see some real stats that Python is dying to believe it.
The idea that errors should pass by default rather than halt by default is just putting more on the programmer to manage. Which I'm almost universally against unless there are significant gains (eg. manual memory management, when appropriate). This guy adds more that I don't care to restate- http://uberpython.wordpress.com/2012/09/23/why-im-not-leavin...
The library scene for Go is also lackluster in comparison to Python, and libraries are what make a language useful. Lack of exceptions kills Go for me, but others are PO'd about lack of generics and some criticize the type system as ignoring the last 20 years of innovation there.
Instead of Go, I'm more excited about Rust as a systems language. Go ultimately is GC'd so it will never be suitable for real-time computing, say writing software for traders or many other use cases. It doesn't so low-level enough to takeover that field (which is why the C/C++ guys aren't coming), and isn't high level enough to really wipe out Python. It's an awkward, yet highly flawed design.
If you're really interested in systems programming, wait for Rust to hit 1.0. I'm more interested in seeing how we can squeeze more performance out of Python with Pyston and PyPy, and if I abandon Python for web development I'll probably be looking at the MEAN stack and biting the bullet on Javascript once ES6 arrives.
Exceptions are arguably one of C++'s largest mistakes, and it requires careful thought to write code in a completely (e.g. strongly) exception-safe way (not to mention it's caused somewhat of a fracture in the C++ community over the years...). Presumably, this is why they don't exist in Go, and it's certainly why they don't exist in Rust.
FWIW, I'm a C++ programmer, and I was a C programmer before that, so my experience with Python is rather limited.
Python remains the language of choice for introducing programming because it is so simple. It isn't fast, and it might not be very well suited for large-scale, long-term use. That's okay.
This appeal to beginners, which the article claims is waning, is the vital force of Python; as long as it is the de facto language for beginners, it will never go the way of Perl.
I always thought of Python as being a great utility programming language. It's not really a specialist, more of a jack of all trades.
For example PHP is all about web development. Ruby is probably most well known for Rails and also widely used for web development. Python is widely used for web development, but that's not necessarily the first thing you think of for Python.
What's going to keep any programming language alive is the libraries that become so well entrenched that a competing library would have a serious uphill battle to even come close to matching functionality. Python has a lot of libraries like this for scientific tools.
I'm always skeptical to hear that a developer has moved from X programming language to Go. I wonder how many of these tales are from developers who are actually referring to what they do in their spare time rather than their day jobs. Go is still early enough that doing the sorts of things which create the most jobs is still more painful than it needs to be (and so you would probably be doing these things in a different ecosystem.) It seems that the real Go job generating stories are from start-ups which have hit some momentum, received funding and are rewriting parts of their stack in Go.
The mass job generators are still at the Rails / Django / PHP / JS levels.
I see what you mean. Also, presumably those that didn't switch, that use and love Python, are not very compelled to write a "We are still staying with Python" blog.
And I think they should. Marketing and perception is important.
I used to stick up for Python 3 on HN and other places but I've given up. I have no interest in converting people going to Go. And no matter what Python (or any other language) does, they are going to lose users to JavaScript.
Also, my experience is that people who feel passionate about Python 2.x will shout down people who are using Python 3 with "nobody uses Python 3." Who has time for that?
When I have seen people talking about sticking with Python 2, its either because A) why bother I don't need to B) a specific library is not Python 3 yet.
If nothing else It'd illustrate clearly either the python 3 folks haven't got a leg to stand on (unable to come up with any tangible real life [reason]) or that there are actually compelling reasons to swap over to python 3; in which case we can point people to those posts in threads like this.
(personally I forayed into 3 but couldn't find any [reason] to stay there; I keep dropping into threads like this hoping to find one...)
http://legacy.python.org/dev/peps/pep-3102/
Like I said, it's a small reason, but it would have made my life much easier today. Enough small reasons add up.
Python is, of course, ubiquitous among startups and west coast tech companies; it is basically Startup Java.
I don't see us stopping using Python any time soon and not just for the legacy factor and cost of switching. It has its place, and Go has its shortcomings, and together they make a nice balance.
BTW we'd also love to move to Python 3 because of Unicode issues, but currently we have so many 3rd party libraries that are Python 2.7 only, that it's not feasible.
Wow... that was 2006. Everything I've read in the PEP and mailing lists seems to imply that the contributors were doing their best to limit the scope of the backwards-incompatible changes to those parts that were deemed absolutely necessary.
The point wasn't to break backwards compatibility to add new, competitive features. It was to make the incremental improvements to the language while strategically correcting some poor, historical decisions. In other words it wasn't a rewrite or a new language.
That there are still prominent, influential Python programmers who are complaining about the bytes object is a shame. However it's a battle that is slowly coming to an end.
The real problem is that the community has been dragging its feet and many frustrated developers are complaining loudly and publicly about it. It's distorting what Python 3 is.