Python 3 in 2016
hynek.me
hynek.me
So the question for me, for new projects is: why choose Python 3 (over all the other non python options) at all? Not what's better about Python 3 than Python 2, but what's better about Python 3 than those other choices. These other choices all have certain areas where they have great strengths. What is Python 3's strength when compared to these other languages? It's a mutable, imperative, single CPU bound language that can't target the browser and is extremely difficult to distribute and deploy. Or have these issues been fixed?
I don't mean to troll any Python fanboys. I use Python 2 every single day at work and I'm very happy with it. But what does Python 3 offer that other new languages don't? Because when you are starting a new project you can choose anything. Why should I choose Python 3 for my new projects?
We package virtualenvs using fpm, others use Docker. But Go just spits out a single binary you can scp anywhere (the build process OTOH is more painful IMHO).
That’s why I’m highly curious about https://us.pycon.org/2016/schedule/presentation/2122/ .
I spent a few days going back and forth - comparing the performance, design time, etc of both - and in the end I'm just using Qt's JS JIT for dynamic list comprehensions and other things C++ is bad at. In the end, the fact that distributing on everything but Linux would have been reduced to having to bundle CPython in was just a deal breaker.
Linux isn't really bad for deployment, though. You can use the SUSE OBS to build packages for all the major platforms besides Arch, and since my main desktop is Arch, I'm building my software with PKGBUILD's from the get-go.
Fully cross-platform.. easy to distribute. Quite nice all around.
sudo pip install [package/repo]The python users I've encountered fall generally into two camps:
1) The engineer/scientist/researcher/hacker type that has python installed on their snowflake machine, and has a whole bunch of packages installed to make their flavor of snowcones. These users just want python to work, find joy in the syntax, and in general get their work done.
2) the developer that is trying to deploy the same thing to many machines. This is a pain. Often you end up with users from camp 1 trying to do this and you end up with a global python install with batteries and the kitchen sink included that is a dependency for a whole bunch of "server" apps. you update a package (because "my special snowcone needs it") and you break something else that you didn't know to test. This is a nightmare. With pip and venv it is easier to manage this, but I still see that relocatable venv is "experimental" when you read the help. IMHO, the python 3 community needs to make it very, very easy to distribute and deploy my special snowcone maker and all its dependencies to a system without python already installed, and not stomp on anybody elses snowcone maker in the process.
What it offers for me truly is the batteries included and easy, memorable and predictable syntax. (Probably due to experience).
Sure, Go is easier to deploy, Erlang and by extension Elixir are easier to scale.
But python does align very well with my personal though process. I don't think parallel and I don't have race conditions in my mind. If I want to quickly write something that will perform decently, I choose python, because the time I save by not having to learn a new language could be days or perhaps even weeks. I guess it boils down to this: with my current experience, I'm more then 10 times as productive in python as I would be in any other language.
Sure, it would be neat if I had as much experience in Erlang as I have in python, but that will take years, and at the end of the day, I'd rather finish my project this year with python, then next year with any other language.
Go's lack of a package manager making deployment more painful is the thing that made me come back to python.
(Does go statically link the libc, too? If so, you should be rebuilding all your go applications right now, after the glibc issues reported on Tuesday…)
TBH, that's the most rational reason ever for choosing any language. Anything else is much less important.
But, yes, for me the experience is the opposite, Python flies in the face of my thought process in every single aspect of it. I find it limiting, inflexible and dominating. Which means, everyone think differently, and there is no single language that suits all possible combinations of problem domains and thinking styles.
Python finally has module packaging down fairly well (Go still drives me crazy even with the latest vending approach--cannot wait for a major build to break because the module creator switched hosting services).
Python is pretty pleasant to debug. The ability to set breakpoints and then poke around and/or modify values saves me hundreds of hours a year.
Building executables can still be a bit problematic (one reason we used Go for a few projects -- they really have this down). However, latest pyInstaller has been working smoothly on Windows and Linux.
Python is quick enough -- and we know how to scale websites with WSGI and stand-alone apps with asyncio (or Twisted). Rarely does the need for that last ounce of speed outweigh the ability to quickly create and modify apps.
Elixir, of all the new languages, intrigues me the most; not just for the language but being built on top of Erlang's OTP platform. They also seem to be doing a decent job on the packaging and distribution front.
I posted about it:
What language has decorators, generators, comprehensions, modules, but isn't Python?
http://fourlightyears.blogspot.com.au/2015/08/what-language-...
And the worst thing is, Node/v8's JIT would kill Python in performance for a;; the kind of things people write Python scripts for, even if it run all synchronous.
It would be nice if callbacks/promises/async-await were only optional and for network/web things, not for everything.
Well, yeah, I'm sure ES2105 is cool, but most of us don't have the choice of using languages from the next century.
> What language has decorators, generators, comprehensions, modules, but isn't Python?
In the transpilers era, Javascript will never be so bad that choosing another dynamic language is a clear win. I'd go back to Python and Django for a CRUD app, but since Javascript is easier to write in a functional style than Python, I've actually started to prefer it as a first choice.
As for Py3, the standard libs are very clean and streamlined, (e.g. io). Oddly enough, the point that I love about Py3 is its handling of unicode vs bytes (which most people find it difficult for some reason).
I'm not sure what you mean by "can't target the browser"? I don't find distributing/deploying python to be difficult or even involved at all. I do get annoyed at the single CPU bound limitation.
If I had to summarize why I'd pick Py3 for new projects, I'd say because it thrives in being minimalist and I hate clutter.
Picking the best tool for the job often gets in the way of actually getting things done. Python is the true swiss army knife of today's programming languages.
Not advocating for Perl, just on behalf of Perl lovers like my office mate
EDIT Added another "most" to make it clear that not everyone can write readable python.
For companies, there are more factors to consider, eg. finding devs at a correct price, getting existing workforce to work on a new tech, size of standard/open source library, getting help and bugfixes from community instead of hacking on your own, risk of language/tech losing steam, etc. That's why several comparatively "boring" languages still thrive.
My issue is I always see Python as the Second Best choice for what I am doing. There is always a better tool for the job. The one thing going for Python is that it is such a generalist BUT when doing work I prefer the Right Tool for the Job approach. I seriously can't think of a job that Python does best.
For me personally it is the best choice for non-throwaway shell scripting once the scripts becomes more complex and/or long lived than a sequence of shell commands.
Python is part of the base install of just about every mainstream Linux distro, so in that regard its only real competitor is Perl.
Python in science is kinda like the One Ring the Binds them - it is the glue that holds together the HPC code at CERN, ESA, NASA, and more, it crunches climate models and delivers your daily weather forcasts. Some really great projects like Cython, Theano, and Numba boost the performance of numeric code to native speeds with a fraction of the hassle of hand-written C. Mountains of machine learning research is done in Python, as well as statistics and analytics. And of course Numpy remains the de-facto standard of N-dimensional array libraries - if you look at numeric computing libraries in many other languages they will be framed as "Numpy-for-X".
While Numpy/Scipy is great with a capital G, it seems the underlying infrastructure is flaky.
I'm talking about the messy process of building and installing it. And it seems everything is held with duct-tape
Also it seems that "inside Scipy' it is a different world, and that to really "talk to the outside world" there seems to be a data-translation step needed.
If you're using Python for scientific computing, you can use the Anaconda distribution of Python, it makes it painless to work with those packages.
> "Also it seems that "inside Scipy' it is a different world, and that to really "talk to the outside world" there seems to be a data-translation step needed."
Python has excellent ORMs, I'm not sure what you're getting at.
That and Cristoph Gohlke[0]'s repository of pre-compiled modules. That guy saved me more than once. Should I ever meet him, I'll sure buy him a beer!
Most any significant scientific package I've ever had to build (which is quite a few) had a complex build system that felt like it was built on top of shaky glass pillars. It's just the nature of what's involved and it's a fundamentally hard problem; it's difficult to replace those libraries because the extreme amount of verification/validation and optimization that have gone into something like LAPACK makes it economically undesirable.
I'd say also that this is part of the appeal of NumPy and SciPy, which is they glue together a huge number of tools that are otherwise disjoint. You don't have to worry (most of the time) about matrix ordering, calling conventions, those mysterious "workspace" variables in LAPACK etc.
% pip install numpy
For more (e.g., other OS'es, build-from-source), see:
My C code was very complicated in order to be fast. Lots of pointer swapping, bit-shifting, etc.
The code was about 4% faster in C, which was more lines of code, much harder to read (and write), compiled with every imaginable flag that could offer a speedup. Switching operating systems, this code was about 8% faster in C on Linux than Python in Windows 10. C in Linux would take about 9.5 days to complete, Python in Windows 10 would be about 10.5 days.
In addition, Python has the "pickle" module so that I can easily make the algorithm save state to pause and restore it any time I want. What's more, I can probably use mmap to share memory easily without making copies and switch to multiprocessing for an even greater speedup (my first attempt using Pool was a little slower despite using 3 cores, but that's the slowest way to multithread).
Plus, with each variable being ~10Mb, I was concerned about memory copying (I studied mechanical engineering, I missed a lot of this stuff in school), and with C I could make memory copying vs passing pointers explicit. All of that was unnecessary.
It was another reinforcement of the idea: "Build it first, then optimize".
If you like Go, try Nim - it's like Go but without all the dogma. I wrote a blog post about my little Nim project: https://klibert.pl/output/slock_in_nim.html
> Why should I choose Python 3 for my new projects?
You shouldn't unless it fits all the constraints of your new project. Choosing a language is not, for the most part, a technical decision: sure there are language features and implementation features (those are separate matters!), but in the end it comes down to external factors: your experience with a particular paradigm, your taste in syntax, skills of potential collaborators and so on.
One thing of note, though: there is no rule saying that you can't use more than one language for your project. On the contrary, you can mix-and-match languages with relative ease nowadays (see https://klibert.pl/output/python_interop.html) and, in my experience, it works rather well. For example, in one of my projects I need to scrape a bunch of websites for data and then process this data. I wrote scraper in Elixir, which made dealing with network errors and parallelizing requests a breeze, and used Python with Pandas for the analysis part. It was a very pleasant experience: neither Python nor Elixir were up to the task on their own, but they worked very well together. It's even easier when you use a JVM, .NET or JavaScript-based languages.
And it does the job.
Productivity, productivity, productivity.
Yes, there are faster, safer, and more modern languages out there. However Python for me still hits nails the hell out of getting stuff done, really really quickly. That applies both to the language itself, and from the standpoint of having such an extensive and mature ecosystem of packages to choose from.
Mastering Python-foo is still on my todo list, though. As a Ruby user, I've noticed that Python scripts are much more straight forward and maintable. I still write my scripts in Ruby though because nobody seems to mind. This is perhaps because I try my best write good comments. In general, Ruby is better as Perl replacement than a Python substitute. In fact, one of my coworkers who is an oldschool perl scripters was sold on Ruby over Perl just by reviewing one of my scripts. I think the issue is people don't think of Ruby outside of Rails, where it's basically a readable purely object oriented Perl.
As an aside, I think there is a bigger overall problem of using scripting languages for application development. I wouldn't use Python, Ruby, or Perl for anything that was more than, say, 500 lines. I almost cried when I tried to read the code for homebrew. Not that it's bad code (it's quite good actually), it's just way too much duck typing for me. I could never keep all that type information in my head. I prefer to pass that cognitive load to the compiler.
https://migrateup.com/main-difference-python-3/
Perhaps if python3 annoys you more than makes you say, "Hey, this prevents lots of latent bugs I might have easily shipped to production before, cool!", then you need to learn python a bit better and re-evaluate what is annoying about it.
What I was trying to say is that the portability of python3 is bad enough that it effects non-python programmers.
For example, sometimes I want to try a new vim plugin that's written in python. I install it, and it doesn't work. Great. Then I find out it's because OS X's python can't interpret it. So I install python3 (which has a different executable name, also annoying). All good, right? Wrong. Vim needs to be compiled with python3 support because the python extension is exclusive to python. Now I have to recompile macvim with
brew install macvim --with-python3 && brew install python3
It doesn't ruin my whole day or anything, but it's a bit irritating to have to manage several versions of an interpreter for a language I'm not even using that language in production. It doesn't help that I use several machines and VMs.
So yeah, I know exactly what is annoying about it.
I suppose you should first figure out the domain, then figure out the language support and ecosystem around that domain and then pick one. That is, if you are implementing something practical whose aim is to provide value outside of personal learning.
For example, several constraints still lead to a situation where C++ is a prime choice unless one is mostly interestes in hacking in a new domain and not finishing a project.
Note! I'm not dissing trying out languages for the joy of it!
Personally, I would pick Python for experimenting with syntax transforms, data mining and such. And as a basis for any offline tool that needs to chug bits from one place to another. Also, the numerical use cases listed elsewhere.
Basically, for anything that does not need a GUI.
Ubuntu is actively working on the transition but the current LTS release (ie the one companies/enterprise will use) is still locked onto python2.
The same can likely be said for other flavors of *nix.
From a user's perspective, python3 has been ready for 'prime time' for a while. From an OS, systems, enterprise perspective python3 still is still a ways out.
If you maintain many FOSS libs like I do, together with tox it's priceless.
What if I want to distribute a package to an audience that doesn't have a strong Python background.
What would otherwise be a simple 'pip install' just turned into a complex multi-step process to install a new version, update PATH, and use virtualenv to avoid conflicts with the default install used internally by the OS.
These all seem like 'simple' fixes to a regular Python user but they set a huge barrier-of-entry for others.
'Just use [insert python specific fix]' is a UX failure for a language that emphasizes usability.
To reiterate. Python3 is ready for regular python users/devs. Not so much for the rest who consume python applications.
We're mostly seeing the same thing, but there is a few libraries where we maintain forks, because the original author didn't test Python 3 support, but just claimed that it would work. However all but one of these libraries are by commercial companies an solely for integrating their service. For the third one the original author seems to have evaporated (I believe one of my colleague are planning a fork with some of the other users of the library).
Last year though I tried again and there were absolutely no problems. It's more natural, all non-dead libraries seem to support it, and in any case I was already using "from future import" for a while.
That said, I don't really intend to port old stuff from 2.7 if I can avoid it, so I expect that 2 and 3 will coexist for a while even within the same firm
I'm calling this as bullshit.
How much of these downloads are computers auto updating their configurations?
How, exactly, do these stats reflect the number of people developing current projects with Python 3?
The number of legacy projects written in Python 2 will be vastly higher than the number of Python3 projects currently in development. Maybe that's what is being updated.
When a statistician does an analysis of what these numbers really mean I will believe them but until then the numbers mean precisely nothing. Or more accurately, they seem to mean exactly what the Python 2 diehards want them to believe.
My assertion is that Python 3 is very actively and healthy and the PyPi stats are just lies, damn lies and statistics.
There's no gloom around Python 3. Lots of people support it. The highest ever upvoted post on Reddit/r/Python was a post asking to remove training material that asserts that Python 3 is irrelevant. https://www.reddit.com/r/Python/top/ There must be alot of people who feel positively about Python 3 to vote it up that high, presumably at the same time that the Python 2 diehards are voting the post down.
The appropriate message regarding the PyPi stats is not to give gentle credence to them but to condemn them as a completely irrelevant measure of the success or otherwise of Python 3.
However in the last couple of years I have dropped Python in favor of Groovy in part because I know the JVM and its plethora of libraries so well. Groovy is a highly underrated language. Really my only complaint is the startup time is not nearly as fast as Python but it does seem faster than say Clojure scripts. Also one of the things that I have to say I sort of think Java got right is that it has always been backward compatible (I know this was sort of impossible with Python given its not really a byte code language). That is I really don't have to worry if I write Groovy in a pre Java 5 (ie without generics) where as with Python I wasn't sure if I should write new scripts in 3 or 2.
The other annoying thing albeit far less than Ruby is dependencies with Python. Groovy has a complete bad ass way of just declaring dependencies in a script (@Grab) and they will automatically be downloaded. I have yet to see a scripting language that does this (ie dependency install on demand).
BTW since apparently any time I mention Java-like-tech on any HN post I seem to get downvoted... I really really love Python. This was not to denigrate Python or that Groovy is better than Python.
Groovy has many incompatible changes between versions, esp from 1.8 to 2.0 but also 1.7 to 1.8, 1.6 to 1.7, etc. Many sites provide Groovy 1.8 as the default because no-one there wants to bother with upgrading.
I am also not as Groovy as I could be (ie write like its Java at times) so maybe thats why I haven't ran into issues.
Example: Ubuntu 14.04 (and later versions) come with Python 3.4, but pyvenv is unavailable (just try searching ubuntu 14.04 pyvenv to get an idea).
This bug from 2014 is still relevant, although at least the "python3.4-venv" package is available to patch it enough to get going. https://bugs.launchpad.net/ubuntu/+source/python3.4/+bug/129...
The %-formatting (printf style) for bytes is a big deal (introduced in 3.5). Putting a 'u' prefix in front of text strings and 'b' in front of byte strings will not go a long way in making things work.
For my code base, I'm mostly worried about division being different, which will introduce silent errors when integer types break down (or up?) into floats.
The last piece that needs to change, to complete the transition, is the majority of OS makers to bundle python3 by default.
RedHat needed it too and forked the project: https://pypi.python.org/pypi/pyldap
- not large syntax
- expressive overloaded keywords (in)
- slice syntax that is easy on mind and eyes
- nice set of builtin structure: lists, sets, dicts
- with literals for all of them [], {}, {:}
- lambda, generators, context
(cute yet general way to ensure releasing resources, files, connections..)
ps: I don't like it's oop syntax sometimes
That said, I never learned so much about one language than by learning another one. All paradigms have at least one gem to discover.
It will continue to be a massive, unavoidable language, but something of the magic of when I first learned it, has been snuffed out.
My own Python bubble is more like what you described (although the mood is improving IMHO) but talking to newcomers is eye opening.
It's hard to find people blogging about it, not sure why? It seems like a great combination.
http://blog.gmludo.eu/2015/02/macro-benchmark-with-django-fl...
I've got a list of Django youtube vids queued up on my plex server right now. But I was thinking yesterday (while in the shower of course), perl has perl6 (which may or may not take off). But what does the future of python have?
Python 4,5,6? Any real innovative changes or just more of kicking the can down the road (such as perl5)?
There are not too many perl companies that have been founded in the last 10 years. And I am finding more and more that companies that are older than 10 years old and are using perl, that this usually means they haven't changed a dang thing in their architecture or web dev process since 1998.
Which means I get to deal with CGI spaghetti, 6+ second page load times (so count ajax anything out), and the world's worse use of javascript. I've had good experiences with newer perl companies with short contract work, but these older ones are killing me and I'm pretty bummed about it as you can tell. I've worked hard to learn best practices and modern web dev styles, none of which I can use at the older places.
The main roadblock in upgrades is unicode text vs bytes handling.
Python2 was lax about using bytes for text. You could do unicode and bytes properly if you really tried hard enough, but it took a conscious effort. So most people just used bytes for text, and hoped for the best (if the data is ASCII or UTF-8, it will work most of the time).
Python3 is strict about the text vs bytes separation. Patching this into a program afterwards is a lot of work.
But if your Python2 program already does unicode carefully in Python2 (unicode type internally everywhere, from __future__ import unicode_literals, explicit encode/decode when talking to external APIs), then you are 90% done with the upgrade to Python3.
What python really needs in 4 is better unified package management and distribution support. They have a lot to learn from the Javascript and Ruby evosystems.
Such as?
I really hope I'm not going to start needing 1,200 dependencies to build a simple app like I would in node.
Per-project configurations to map things like external dependencies and project info. Setup.py + MANIFEST is not the answer.
Better suport of versioned deps so multiple versions of the same dep 'just works' when its neessary.
Better package publishing for library maintainers. Have you ever published a pckage to PYPI? It's a huge pain.
Support for Markdown-based documentation on PYPI. ReStructuredText is cool and all but MD os the defacto standard
Standard support for direct install from GitHub without weird hacks.
Pick one unified standard and deprecate the rest. The current 3, distutils, distutils2 and setup.py all suck.
Write some halfway decent docs on how to publish packages. I spend more time on Stack Overflow that the python docs every time I publish a package.
Dependencies are used so heavily in the JS/Ruby ecosystem because it's extremely easy to publish a package and the package manager 'just works'.
* Setup.py/MANIFEST.in seems like a pretty clear answer to me.
* I've worked with python for about 10 years and only once have I come across two packages that required conflicting versions that I wanted to deploy in the same environment.
* Yes, I do it pretty frequently.
* "MD os the defacto standard" Huh? According to whom? ReST is fine.
* "Standard support for direct install from GitHub without weird hacks." - stick "git+https://github.com/yourname/yourpackage" in your requirements.txt and off you go.
* Yeah, they should really standardize on pip, but this is relatively minor.
* Use one of the templates.
* Yes, I hear somebody even published a package that checked if a number was negative. And it had a bug.
If it doesn't, it shouldn't be 4.
Breaking changes to the language syntax/semantics.
I'd expect breaking changes to apply to core APIs and/or to external tooling as both could probably use some revision now that the fundamental issues with the language (ex utf8 support) are mostly fixed.
>Scala, Haskell, Clojure, Erlang (or Elixir) or Go. And there's also the less popular ones like Haxe and Dart
Are you kidding me? Did you just list the languages you see threads on HN about? Scala and Go I could maybe understand if you needed the performance but the rest of the choices are just bad. Especially if you are trying to start a business instead of a functional programming bootcamp.
Also there is nothing inherently more difficult about deploying and distributing python compared to any of the languages you chose.
We detached this subthread from https://news.ycombinator.com/item?id=11124822 and marked it off-topic.
The developers have dug themselves into this mess with frivolous differences ("print" a function, wanting to remove the "%" string operator, etc.), instead of spending the years on more productive features, now is the chance to dig themselves out again.
It's a beautiful language, too bad the development choices were a bit sketchy.
Python 4 will just be the next release after Python 3.9.
We'll see what it does to Python's popularity.
Really? Why even change the major version then, when there are no breaking changes?
Given that many Python programmers seem to be traumatized by the last major version switch, why even bother?
Or is this just for setting up Python 5 can have breaking changes if the switch to 4 is painless?
Python releases don't follow semver. If Linus can bump the kernel to 4.0 because he felt like it so can Python.
"Can" is not "should": I mean, Python can go from 3.x to Python 2020, go with year numbers for a while, then have Python XP, then go Python 7, Python 8, Python 8.1, and then skip to Python 10. But there's no good reason to do that.
The problem isn't just breaking compatibility, it's performance. There have been a number of experiments with removing the GIL going back (I think) to python 1.4. However every attempt has led to significant performance degradation in some part of the language.
That's a bold statement. Can you elaborate on what those reasons are?
1. The Python language itself doesn't lend itself to being JIT compiled - it's too dynamic.
2. cPython is the reference implementation. It's source should be as simple as possible.
3. Only a subset of Python programs would benefit, and the rest would be slower/more memory hungry
and finally,
4. If you want/need a JIT then use PyPy, in all it's glory with all its upsides and downsides.
PyPy is a big project with a lot of very very very smart people working on it. They've done an excellent job at JITting Python (and creating an impressive interpreter framework) but even they couldn't make a JIT that is anywhere near suitable for inclusion in cPython. A bunch of cPython hackers on python-dev have no chance.
tldr: Want a JIT? Use PyPy.
1. This was also said about JS before people just went ahead and wrote JITs for it. Are you sure what they're saying isn't "we can't make a JIT for python" rather than "nobody can make one"? Because that's how it turned out with JS.
2. If given the choice, do you think the community would turn down a JIT to avoid making the reference implementation more complex? To whose benefit is that requirement? I've never heard people complain about other languages that they didn't have an easy-to-read reference implementation.
3. I've not heard this reported as a problem in practice for languages that have a JIT. It's usually toy programs where the JIT overhead is significant and they're so small and short-running that neither slowdown or extra memory is usually an issue.
4. Not everything that runs on cPython runs on PyPy so that's not a choice I'm necessarily able to make.
I'm not saying there aren't reasons to not have a JIT in cPython. But it's a choice not a natural law. And it's not ridiculous to suggest that they could make a different choice if they wanted, as JS eventually did.
2. It would make the reference implementation insanely more complex, to the point where it is no longer a reference implementation but a JIT implementation of Python. That's not cPython's role. For whos benefit is the requirement of a JIT? My apps run fine without them, and I don't need the memory bloat or startup cost associated with a JIT. If the community really wants another JIT they could fork cPython, find a room full of JIT experts and re-do all of the work PyPy has done, with all of the tradeoffs and problems they encountered. Nice idea.
3. "so small and short-running that neither slowdown or extra memory is usually an issue." - this is exactly the situation where a JIT adds a lot of overhead and becomes an issue.
4. So you want the best of both worlds, with no clear idea as to what magical person can make this happen (or even how) and you won't be happy until you can have your cake and eat it?
It's not that the Python developers preventing discussion, it's just this discussion is always fruitless, has been had many times before and the people invoking the discussion often blame the cPython developers for their response. Nobody wins, it's a waste of time.
Remove the "maintaining compatibility for C-based extensions" requirement, and you get, well, PyPy. And you also get a community split that makes 2/3 look trivial. Vast swathes of core Python code and libraries are really not "Python", but Python C-based bindings to custom code or C libraries.
or spend some time helping with Pyjion to add a C API to CPython for plugging in a JIT of your choice
Guido could do that if he decided that Python 4 would be based on PyPy (AFAIK, many people thought Python 3 would be based on PyPy too). Compatibility isn't 100% but if it was the main platform I'm sure it'd improve even faster.
This might turn out to be quite difficult for non-trivial Python applications.
STM is exciting but I think it's important to keep in mind that it's an experiment that while promising might still fail in practice.
What difference does that make. STM will still enable the removal of the GIL. If an applications is coded that doesn't work with PyPy, that's a separate matter.
I remain skeptical that STM is a good fit for this problem, as I was when I first heard about this, and after their work, alas, I have to say I see little evidence to make me change my mind on that. STM is something that probably needs to be baked in from day one, possibly all the way into the language itself, not put on the side of a complicated secondary implementation of Python.
From the page... "THIS PAGE IS OLD, THE REST IS ABOUT STMGC-C7 WHEREAS THE CURRENT DEVELOPMENT WORK IS DONE ON STMGC-C8"
This page is probably a better starting point for the current PyPy STM work:
Part of the problem is that they're trying to wedge into a really tight window; for all its flaws, the GIL is not all that expensive (relative to how slow Python in general is, anyhow), and trying to do it on PyPy makes their window even smaller. It's a really hard thing to hit, and I'll believe it when I see it. I'm not saying it's impossible. Just, I'll believe it when I see it, and I don't recommend a high degree of confidence that it will occur. Nor do I recommend that you use it as part of your advocacy... it's nowhere near solid enough to be making promises about it to people outside the community.
You may be interested in this...
"Leysin Winter Sprint (20-27th February 2016)"
"STM (Software Transaction Memory), notably: try to come up with benchmarks, and measure them carefully in order to test and improve the conflict reporting tools, and more generally to figure out how practical it is in large projects to avoid conflicts"
http://morepypy.blogspot.co.uk/2016/01/leysin-winter-sprint-...
> "Nor do I recommend that you use it as part of your advocacy."
I'm an advocate for F#, but I'll encourage the progress of any open source language, strong competition is good for the field as a whole. The question isn't 'Why can't Python be fast?' but rather 'How fast can Python be?', the difference is a difference in attitude.
AFAIK, many people thought Python 3 would be based on PyPy too
Don't think so. Some people hoped that Python 3 might be based on Unladen Swallow, which was a different Python JIT that Guido was working on while at Google, but that project never really got off the ground and Google seemed to lose interest in it.
With the proviso that a lot can change in two years, here's a relevant comment from the Dropbox Pyston announcement [1]:
"Guido's advice has been extremely helpful, but so far we haven't been able to get any code from him"
[1]: https://blogs.dropbox.com/tech/2014/04/introducing-pyston-an...
If you see only print, you are missing the point.
But good news, there are many projects working to improve the perfs and/or bypass the GIL this year.
The top thing, sometimes the only thing, that makes my scripts written for 2 not work in 3 is the change to print. Adding a print function is fine, I'm all on board with that; removing the statement though seems like pain for no reason. Bringing that up is not missing the point, it's hitting the nail right on the head.