Python 3.3.5 has been released
docs.python.org
docs.python.org
Sorry, but my recent experience has not matched yours, so the fact that this particular project had no library compatibility issues does not mean they no longer exist.
I'm glad you found a project you can use it on. That just doesn't mean much to those of us who are still hitting the same familiar issues with it.
Also, here's a great tool that checks if you can use Python 3: https://caniusepython3.com/ .
Then the ones left behind can be adapted, tested, or alternatives found, and the whole ecosystem can move on.
If we keep using Python 2 to be safe nothing will change.
Using Django and Python 3 and so far it's been a breeze, with minor bumps.
Yes.
> which is the default "python" in most (all?) Linux distributions
Most distributions ship both 2.x and 3.x at the same time. Ubuntu ported most (all?) of its tools to 3.x already.
> is it safe to write for python3 now?
What do you mean by safe? It's been stable for a long time now. As long as you verify all your dependencies work, you should be fine. The only annoying thing you may run into is a situation where only one of the versions is provided: for example if you want to drive ufw (3.x only) from salt (2.x only), you'll have to resort to some kind of IPC instead.
There was a poll about the current state a month or two ago on HN.
Before you start writing in Python 3, make sure your dependencies will run on Python 3.
Mercurial is an application you use to version control your source. I'm not sure I understand why any python developer would care if Mercurial was written in python 2 as long as it worked. Maybe if someone was writing a Mercurial plugin or patching Mercurial they would care.
Hopefully these start disappearing, as Ubuntu and Arch have already moved to 3.x.
Luckily, a Twisted Reactor can be built on top of asyncio, and this will likely happen as people port more parts of Twisted to Python 3 (it's a long-running project with fairly little interest from developers willing to put work into it).
Alternatively, people could start to build new libraries that implement all the abstractions and protocol implementations that Twisted has to offer. I think it'd be preferred that even if each abstraction/protocol were a separate repo and installable package, they'd all be under the same "banner", so that everything interoperates correctly and using the same set of abstractions.
And you did say that some people - people who write plugins or develop Mercurial for living - do care later in your sentence. That's some developers. And the parent was asking whether Python 3 was safe to use. It's nice to know that some major Python projects are not ready for Python 3.
The problem is rarely the major libraries, it's that one obscure minor library that almost no one (except you in your Very Import Application) uses.
Google code shows download counts so you can get an idea of popularity of each release for Windows developers:
https://code.google.com/p/apsw/downloads/list?can=1&q=&colsp...
I've since moved the project to github which doesn't show the download counts for releases.
I think I'll wait for 3.4 to land in a few days and from then on use py3 instead of 2.7 :)
Quite a few others like Gevent and supervisor, for example, have py3k ports nearly done, and mostly await merging.
edit: changed grammar for clarity
Your average interactive webapp is reasonably query-heavy, some of which is alleviated by reasonable caching.
The performance of the connector comes into play when someone hits an uncached page which requires tens of queries. This matters the most when it drastically affects load time. It's really a shitty experience when a user comes to a page, waits more than a second for the page to load. I do find, though, that a large portion of my query overhead comes from round trip time to the db server, and not intermediate processing.
So I figure for low to medium traffic sites with reasonable caching (and cache priming when needed), this probably won't be a bit hit, like you say.
There is of course the interesting benefit that if you're using a JIT implementation like pypy, then everything within a pure python db adapter is up for auto-optimization. This is interesting because it could effectively provide something close to application-specific hand optimization of the connector, which tends to be a pain in the ass that not many people would bother with.
I will try to be a good boy and use it going forward (I already find it more useful for CSV and other file I/O type tasks thanks to the unicode support, but am reliant on mysql for some routine drudgery as well).
If you want performance, Python 2 and PyPy is what you're looking for.
I'm sure PyPy will eventually get there, but in the meantime, projects are still happening, so what's available now (or what's so close that it's considered complete and in testing) is a lot more interesting and useful.
PyPy3 has a beta release.
This would be like "If you want Earth without the pollution and are willing to move, then we've terraformed Mars already; we just need some fuel for the rocket to get you there."
As for making Python 3 the default if you type "python", this is unlikely to happen, for compatibility reasons: http://legacy.python.org/dev/peps/pep-0394/