Shared publicly  - 
Hmm, popping this up when I hit publish in Blogger is kinda cheating, Google...
Richard Jones's profile photoJeroen Ruigrok van der Werven's profile photoNick Coghlan's profile photoDavid Kutcher's profile photo
Nice article Nick, and in general I agree with the points you are making. However, when it comes to properly using threading, low-level socket networking, and bit-fiddling, I find Python to be subpar. Granted, my low-level systems development might be less charming than whatever goes on on the web side of things, but I actually had to revert to Java to solve in a few weeks what I had not been able to implement in Python in months before. I consider the community's attitude to "use Twisted" a metaphorical hammer that's being used for too many different shaped nails.
I wouldn't use Python for anything especially low-level either, especially bit-twiddling: that's what C is for, as far as I'm concerned.
That's the most straightforward answer anyone has given me on this topic so far. Much appreciated for that clarity.
The language is sane (syntax). Binding with C for low level bit twiddling is shifting but working (cf bitarray on pypi). Some communities are sane (flask, scipy).  Stdlib is quite sane (except urllib/2). However, the packaging filed is sprouting software solutions that at my opinion do not address any actual problems. Packaging is the only black spot of python I am aware of, however it is a huge one. 
I've written a few networking systems for telcos which admittedly don't have a horrendously high throughput requirement but on the other hand I much preferred writing the bit twiddling code to pack/unpack SMS PDUs in Python than I would've in C. Maybe it's just been too long since I've done hardcore C but I didn't find the Python code that onerous. Also, being able to use a Python long int to pack 7-bit SMS message septets was really nice, elegant option that C doesn't offer...

Also, great post Nick! :-)
Julien, software packaging and redistribution being awful isn't a problem unique to Python - it's pretty much awful everywhere, even if you opt into one of the platform specific distribution solutions.

We at least have a reasonably usable solution in distribute and pip (with the older setuptools and easy_install also being usable if you don't mind the lack on an uninstall option), and work is ongoing to better separate the build and install steps so that it is easier to build things once and then redistribute them directly or via PyPI.
Richard, yeah, I've done a lot of bitbashing directly in Python, too (testing a serial communications link for bit errors and tracing the origins of any that do occur - difflib is awesome). So I guess my view is really that "Python is generally fine for bit twiddling, but if it ever gets annoying, I'm happy to just drop down to the C layer to solve whatever problem I am having".
+Nick Coghlan yes, packaging is awfully complicated at language and OS levels, I know. (I made debian packages in my youth).

I am just a little bit concerned that we throw piles of code to try to solve the problem, whereas we have no clear goals.
I do advocate that we should first think of what we desire to achieve in terms of functions and maybe give up to the OS some parts of the packaging (especially when it involves C/fortran/C++ extensions).

I as a python developer would first like to have something that can compare to CPAN: one link to the source, Missing In Action procedures,  getting rid of unmaintained packages, documentation, ticketing, matrix testing to know where the package *actually works* ...

I think not having test made before installation is below actual packaging standard in all languages (even PHP), if tests were made I would like an automated trace (opt in way) coming back for troubleshooting.

But I am helpless. These require more than code; it requires strong will, server, decisions at the platform level, time and way more than 1 coder alone piling more approximate solution.
Julien, catalog-sig is the place to ask those kinds of questions, although PyPI has an open API precisely so that anyone is free to implement their own PyPI competitor that has stricter quality control or other features (see, for example,

We're currently in the process of trying to split the build step more cleanly from the install step. Once that's done, then it becomes more feasible to introduce a test hook that can be invoked without installation.
Add a comment...