Pathlib, asyncio, unicode default, bundled pip and venv...
I do like the look of Python3. It's looking a lot more interesting, the further along it gets. I still haven't really done anything with it, due to python2 being bundled with our OSX and Linux workstations, which means painless installs. This year, however, I do want to start porting my projects over to Python3 (well, making them run on both, at least...)
NB. And there are more full featured alternatives on CPAN like Path::Class (https://metacpan.org/pod/Path::Class), IO::All (https://metacpan.org/release/IO-All) and Path::Tiny (https://metacpan.org/pod/Path::Tiny).
Rebol has its own file datatype which works seamlessly across platforms - http://www.rebol.com/r3/docs/datatypes/file.html | http://www.rebol.com/docs/core23/rebolcore-12.html
"Note This module has been included in the standard library on a provisional basis. Backwards incompatible changes (up to and including removal of the package) may occur if deemed necessary by the core developers."
pathlib in python3 has ".parent" property that returns parent-directory, and pathlib in master has ".parent(n)" method that returns n levels UP.
That sucks so much.
Python has a relatively large standard library (one of its selling points), and not everything in the standard library can be right the first time. No matter how long a Python release spends in beta, there are probably flaws that will only be discovered when people start using new modules to do their actual jobs (where they won't be using a beta version of Python).
In Python 1 and 2, if a standard library module had a flaw that required a backwards-incompatible change to fix, the flaw would have to remain there. In Python 3 they acknowledge that the first version may require backwards-incompatible changes.
I don't remember the semantics of the reasons it was rejected, but if you search about 'pep' and object paths you ll find more info
I remember VBScript/JScript with FileSystemObject decades ago. It's from COM
or maybe Blum, Floyd, Pratt, Rivest, and Tarjan if you're being fancy, which is 24N comparisons in the worst case (but more than 4N for the average case).
http://hg.python.org/cpython/file/3.4/Lib/statistics.py (line 296)
For lists of size 10M, I got a 7.3x speedup vs using the sorted function, and a 1.6x speedup vs using numpy.median. The sorted function was faster up until lists of size 100, presumably due to lower overhead. (The lazily-sorted list data-structure also keeps track of the pivots resulting from partitions, so that later method calls run faster by exploiting the partially-sorted structure that remains from earlier method calls).
Here's a plot of the time to compute the median for these different algorithms, (taken from a paper I wrote that's under review): http://imgur.com/oX1QLnS
So far I've tried median-of-medians, recursive quickselect, iterative quickselect tracking indices and partitioning in place, and heapq.nlargest. The implementation in Python 3.4.0 is both cleaner/easier to read and faster than anything I can make by an order of magnitude for 10,000 element lists. I'm sure someone else here can do better than me, but (s)he'd have a hard time beating CPython, imo.
The reason it's for non-primitives is because it's optimized for sorting lists where comparison is relatively expensive , such as the dereferencing Python does on every item and Java does for non-primitive items.
Thanks for putting the effort in and testing it! Very interesting results.
FWIW, here is some old timing data on a 2008 era Mac:
* approx timing on my Mac
* n, time in ms
* 10, <1
* 100, <1
* 1000, <1
* 10000, <1
* 100000, 30
* 1000000, 230
* 10000000, 2530
* 100000000, 33000
Note especially the pitfalls highlighted around naive diy solutions (not sure if this is actually taken care of in the module, but I hope so! :-).
Go channels are the only experience I have with concurrent programming, but when I understood them it quickly became second nature to create everything using channels. Can techniques like websockets be used now as cleanly as in Go?
Except then your method shares a namespace with all the other methods defined on the class, which is ugly, and can cause clashes.
This makes a proper P3 Virtualenv into something good (from something barely ok in 3.3 where you need to install setuptools manually in your virtualenv)
virtualenv -p $(which python3) ENV # with virtualenv
mkvirtualenv [-a project path] -p $(which python3) ENVNAME # with virtualenvwrapper
Python 3 comes with pyvenv that's the one that should be used
The good thing about 3.4 is that they finally give a good virtualenv by default and we don't need to install setuptools/pip inside manually
I've seen this rumor that virtualenv "doesn't work" in Python 3. It seems to be propagated by people who make Python 2 virtualenvs and get confused, including a StackOverflow thread full of people basically typing commands at random to try to fix the problem. But pyvenv in 3.3 had much more potential for confusion.
The fact that Python 3.4 bundles pip may finally resolve this confusion, and make pyvenv appropriate to use. But I'm sure virtualenv will keep working fine as well as long as you don't mix up major versions of Python.
Yes, the regular virtualenv may work with Python 3 but it's a small detail in a frustrating setup. When I finally found out how you're supposed to do in > 3.4 it was a relief, still
Just tested 3.4 as it is like in 2.X, so, problem solved and no-one has to worry about this anymore.
That works perfectly if you already have python3 installed.
Added to the stdlib was "ensurepip", which is a simple installer for pip. The ensurepip module includes inside of it a copy of pip that it will install from (in other words, ensurepip doesn't hit the network).
There are various reasons why it does this, part of which is to enable easy upgrades to newer versions of pip both inside of CPython itself, and for the end user to upgrade it locally.
Congrats to the python-core team and thanks to everyone for another great release!
You could do the allocator yourself with a custom allocator easily. Just inspect the object type or object id, and in your meta allocator select the correct allocator.
I'm not sure how that would help you with a CCL style WATCH though...
pdb, with set_trace or conditions on breakpoints could let you WATCH individual objects. Search google for watchpoints.
Speculation: A Python 3.x runtime might be the mystery annoucement promised for the Google Cloud Platform Live event on March 25. Unless it's a Node runtime?
I've written several production apps in it, and the unicode fixes in particular are a much easier, as well as little things like being able to do enums.
Ultimately, they really aren't all that different- I think the differences tend to be overblown somewhat on HN.
If the course/teacher you like only teaches using 2.7, learn that. You can pick up the changes from 2.7->3.4 on your own pretty easily once you know the basic language.
If you for some reason have to work on older version (for example RedHat still uses 2.6) knowing Py3 is not really an issue to program there. Of course few nice features are missing, but people seem to talk as if it is a completely different language for some reason. With Python 3 at least you have a nice more consistent language.
If you were learning Java, would you start with JDK 1.3 or the latest one?
If you're just using it for its own sake, or only for building things locally that either don't need to run anywhere else or only need to run where you have enough control to install your own Python, and you don't and won't need dependencies that aren't currently ported... then definitely start with 3.x. :)
In conclusion, not everyone is in the same boat as you. Try and see beyond your own nose pleas.
There's a very simple solution, for those that can't/won't upgrade: Fork it. Work on OldNewPython 2.8. The core devs of Python want to work on Python 3, so that's where we're headed. There's no need to argue technical merits of Python 2 vs 3, the simple fact is that the development momentum is with Python 3 now.
Open source is a do-ocracy. Bring together your other like minded devs to work on Python 2 and keep on keeping on. We can't expect the core devs to keep maintaining an old version of Python. A lot of them are doing this for fun or as a hobby.
Anyway, there have been bug fixes and there will continue to be security related releases of 2.7 for a while still.
That's totally bonkers.
Actually its not. No one will want to spend time and effort on regression just because the tool maintainers want a print statement to be function and not a statement. Or for a small trivial change.
Anyway when a language doesnt have a strong unit testing culture,that's what happens.
I like both languages actually, and I use python quite a bit, but holy crap has python 3 been a train wreck. C++ moves slowly, but predictably. Python has two active versions: one you're not supposed to use and one you can't.
C++ may have become a bit unwieldy as a result of the combination of this policy and the focus on adding new features, but developers working on existing code bases can continue to develop happily ignoring as much of C++11 as they like without the concern that the plug will be pulled in their platform some time soon. As they decide to adopt the new features, they can, based in the merits of the feature, not because they are forced to by the platform's developers.
There are starting to be some compelling features in py3k, but none of those required the massive language breakage that has happened between Python 2.x and these releases. All of the compelling features could have been added piecemeal through the normal backward-compatible deprecation and release process. And the devs who were so bothered by print and exec being a function, or other stupid things could continue to complain in the mailing list while the rest of us get our work done.
Last month I gave up and reverted the project I'm working on now back to python2 after spending an afternoon looking for unofficial ports of a large library only to find that someone on Github had forked it, done the hard work of fixing 2200 broken bits, and had his pull request ignored without comment for a full year.
I give up.
Apparently it's sort of unmaintained in general, but I was trying to use it for something that I wasn't happy with scikit-learn for, and at the time, I wasn't aware of how long it had been since it had been updated in general.
So in hindsight, it wasn't the best example, but I had already had to deal with tracking down an random person's networkx branch as well, so that was enough to make me finally just fix the few things needed to work in 2.7.
Sometimes you need to use unmaintained or legacy code, and that sucks. But there are lots of programmers who don't have such a burden, and they shouldn't be discouraged from Python 3.
networkx is Python 3 compatible, by the way.
So it is. I'm not sure why I couldn't find that six months ago while I was looking.
Also, I don't mean to imply that people should be discouraged from using Python 3. Like I said, I want to use it myself, and would be if I hadn't ran into problems.
http://radiofreepython.com/episodes/10/ (IIRC this is where I learn this but I'm lazy to listen again to confirm. I recall Barry mentioned some distro that did change /usr/bin/python to 3 and that a lot of stuff broke.)
I stand by Fedora though with a reasonable degree of confidence!
We also depend on Paramiko, which is also red on the WOS.
Twisted is a bit of a bigger matter. A lot of the Python 3 tasks have been closed, but it's a pretty big beast, with lots of corners for bugs to hide in.
See their full plan here: http://twistedmatrix.com/trac/wiki/Plan/Python3
However, we use twisted.spread extensively, and that's not in the list of Python 3 compatible modules, and twisted.web.client and twisted.web.server are only on the "almost" list: http://twistedmatrix.com/trac/browser/trunk/twisted/python/d...
I know from experience that gevent is not in a healthy state of maintenance. There have been some recent commits that indicate it might get better eventually, but I would not design new code to use gevent.
Full python3 plan for twisted here: http://twistedmatrix.com/trac/wiki/Plan/Python3
They really are one of the slowest projects to update.
If there's anyone not using python3 in production now, I'd be wary of that team. Maybe it could be forgiven two years ago, but now... There's just too much to be gained with modern python.
But hey, there's still some organisations using php3 in production!
I'd imagine the majority of teams are using python2 in production. Especially when LTS OSs ship with python 2.7. Things like Anaconda make it a lot easier to install python3 along side of python2.7 and move individual projects to 3.