jessenoller.com

Yeah, I haven’t posted in awhile - since pycon I’ve been sick off an on, working my butt off at the place which allows me to purchase ice cream for my kid, and so on. Busy busy. Not to mention, I’ve been suffering a slight case of burnout - long story.

That all being said, I think it was last week when I twittered a minor philosophical point which was picked up and ran with by pydanny. The little point I made was something like:

I don’t think it’s unreasonable to be able to name at least 5 things you don’t like/would change about something you love. Implementation details are fair game too

Now, before I delve into my personal list, I want to provide some context to this comment. It actually has some history, and it’s not an original thought - I think Titus Brown started a meme around this last year. In his case, it was purely based around python.

• Titus’ Post
• Daniel’s Post
• Brett’s Post
• Jacob’s Post

In my case, I’ve long maintained that if you can not name things you would change, irk you or generally dislike about something (not just a language) you supposedly love, whether it be a tool, a language, an OS, etc - then it shows you have a certain lack of self-awareness or pragmatism (there is another word I’m grasping for here, but it escapes me).

Historically, I’ll ask this in interview situations whether I’m speaking with someone who is a test engineer (name and explain 5 things you love/hate about automated testing?) a programmer (name and explain 5 things you love/hate about language $FOO) - generally speaking, this is great discussion fodder, and allows you to probe the thought process of the candidate.

For example, if someone says “I hate Python’s whitespace” and they’re interviewing for a Python coding position, I think it fair game to dig into that a bit and see if its rational, and ultimately ask the question: If you hate something so fundamental, why do you use it/why do you want to program in it for the foreseeable future?

In any case, I promised a few people I’d give them the shortlist of nits (I don’t hate these things, I simply dislike them) I have with Python. It’s important to remember that:

1. I contribute work to python-core (see the multiprocessing module)
2. I program in Python daily for work, and in my free time too.
3. I participate (when I’m not on a self imposed exile) on the mailing lists and discussions (see Python-dev, etc.
4. I too, am a strong believer in “put up or shut up”

Now, part of me is sad that I have to preface me being critical with a disclaimer like the above; but alas - some people, especially those on the internet, thrive on controversy and fail to read more than 5 or 6 words before posting some half-witted response, or worse yet, someone skims to the gripes I have, finds one they want to take me to task about and says “SUBMIT A PATCH !!!11″.

I do contribute back, so you can avoid telling me to submit a patch, ok?

That all being said, here’s my list:

1. Concurrency: This is actually a love/hate topic for me. Obviously, I’m the maintainer of the multiprocessing module, which sidesteps the GIL, but the GIL is still an irritant for me (given I do write a lot of threaded code). A lot of people are very familiar with the fact I am a proponent of threads and processes/IPC, as both serve different (yet overlapping) purposes. There is room for both. Hopefully unladen-swallow will be able to get rid of the GIL, and then we can all move on with our lives: So long as in killing it, we don’t hose the ecosystem of C extensions.
   • Additionally, I would love to see a decent coroutine implementation included in the standard library, once PEP 380 is done and in the bag, if you need justification, see David Beazley’s coroutine talk. Again, while people might disagree with this, saying that coroutines/processes/threads all “do the same thing” and would violate “TIOWTDI” (There’s Only One Way To Do It) I would strongly disagree with them. In the case of concurrency, different solutions fit different problems. We do not have a grand unified theory of concurrency within python.
   • Also in the concurrency vein, I would like to see a cross language messaging/serialization system/format eventually come in. Right now, we have pickle; most recently, JSON - and JSON might be the final answer in this regard, but something akin to protocol buffers has also piqued my interest. Given we have JSON, I’m not terribly hot on this one.
   • Finally, I’d like to see more of the java.util.concurrent abstractions migrated in. I mean, using python threads isn’t hard, seriously, but more/better abstractions make things nicer for everyone.

2. The Standard Library: This, again, is a love/hate thing - I love the standard library, and I will gladly argue with anyone who suggests getting rid of it. However, that said - I would like to see the entire thing get a much better documentation treatment, the docs while good, could be 1000x better, more clear/etc. I would also make every single module in there PEP 8 compliant. I know that sounds like a style-nazi thing, but if that’s the style we’re to use, I think the first thing to adhere to that is the standard lib.
   • It’s also disorganized. While flat is better than nested, I’m sorry - but I think making it deeper and putting all the things like one another into the same namespaces does make sense.
   • I would also break out the stdlib from core. This idea was discussed at the python language summit, and I think almost everyone there was in agreement. The idea would be to separate out the stdlib into it’s own path inside the repo, and other python implementations (such as Jython/etc) could use that copy as their copy of the stdlib modules. Anything which was CPython specific (such as multiprocessing) would stay with core/be marked as CPython only.
   • Taking this concept of breaking out the standard library a little further: I would begin to evolve it a little more quickly. There’s a strong difference between changes to the language, and changes to the standard library. In the case of the former; it should evolve slowly, and carefully. In the case of the latter (the stdlib) I think it could - and possibly should, evolve more quickly. By evolve, I mean “get cleaned up, have things removed/added” more quickly. I do not, however, mean with less thought. There’s obviously a lot of “buts” and other concerns with this idea, but it’s just a thought. I think compartmentalizing this into python-core and python-stdlib meshes with how a lot of people think about things.

3. The Docs: I touched on this in the stdlib one, but the standard library documentation, as well as rich examples for a lot of the core features are lacking. Many of them focus on syntax and not necessarily on use. For example, I would gladly integrate all of Doug Hellmann’s Python Module of the Week posts into the standard library documentation tomorrow, and wholesale if I could - his examples are much more rich than those we find in the current docs.
   Many people, including myself, have been working on making these better - in my case, I need to overhaul the multiprocessing docs when I have a chance.
   • Don’t get me wrong - I actually appreciate the docs we have, they keep me sane, but they can be better, more clear and in some cases, more practical. One or two examples for usage just doesn’t cut it.

   • update see: http://tosh.pl/gminick/gsoc/sphinx/

   

4. Packaging: Ahhhhh! I’m not going to go too deep into this rabbit hole, especially given I know Tarek is hacking away at making python packaging a much better animal, but the entire setuptools/eggs/distutils/etc pile is well, frustrating. I just want a clean, standard way of packaging my packages, built into core, that doesn’t force me into install into the global site-packages directory. Also, uninstall, dammit. I know setuptools and easy_install and eggs were designed to scratch an itch: and I do use easy_install, but the entire pile of things need to be made into a standard, implemented in core and we need to move on.
   • However, as I pointed out during the language summit - I don’t think something like easy_install belongs in core, instead I think core should make what easy_install does (to a certain extent) easier and standard, so people can use whatever tools/scripts/etc they want. One ring to bind them!

5. Linting: Ok, face it, if you’re on a big enough team, you need to have a pre commit hook for your VCS that lints the code, and yacks if it doesn’t conform. I would love for one to be built into the stdlib, but something like pylint is too big, pychecker is too simple, and I haven’t used pyflakes recently enough to comment. There was a thread on python-ideas about this recently - and maybe Jeremy Hylton is right, and it doesn’t belong in core, but if that’s the case, we need to pick one to “endorse” on the python doc website. Maybe in a “getting started with developing python” document, which is linked in size 30 font, and links to a linter, maybe the pep8.py and reindent.py scripts, etc. It should be painfully obvious where to get and how to use these tools. Yeah, I know “waaaaah why didn’t they link to mine” - well, because we liked this one over here more. QQ.
   • As it stands, I can not count the number of times I’ve been asked about linters and style checkers for python code. Maybe we make three packages: python-core, python-stdlib and python-tools.

6. Optional Static Typing: This one doesn’t make me feel like I’ll make any friends, but I would love to have pre-runtime, static typing as an option to python - maybe as a –anal-types flag. Guido has discussed (part 2) the difficulties of this before, so I don’t think this will ever come (the closest we get to “type safety” is function annotations, which make me feel funny in sensitive places). The biggest reason I have for static typing of any flavor, is that I would prefer to have the ability to catch some errors prior to runtime. That’s all. On a big enough team, all hacking on the same (massive) python code base, I’ve found you do want the ability to turn something like this on - it helps you with a (small) class of very annoying bugs.
   • I do love me the dynamic/late typing system of python, and I use it to my advantage as much as possible. So, I wouldn’t trade the dynamism of Python for static types, it’s just an nit I have. Of course, maybe something like interfaces (as Jacob points out in his list) might solve some of the issues I have (mainly bad people doing silly things). The rest of the stuff is why I write unit tests and actually run the damned code.
   • Yes, I know the drawbacks of something like this; I also don’t have some sort of magic solution to be able to wave a wand and do this. Nor do I have a concrete proposal, otherwise you’d see an email on python-dev. Other people much smarter than me have pointed out the sheer enormity and numerous drawbacks to something like this. No, I don’t expect magic fairy dusty to suddenly appear and just “make this work”.

7. Standard Library Part II: Yeah, you might notice a lot of my gripes are around the stdlib - but in particular, I want to point out the state of XML handling in the standard library is about as clear as wearing glasses made of meat. Additionally, the httplib/urllib/urllib2 thing? Yeah. No.
   • While I’m harping on this stuff, get rid of the commands module, anything that is not in subprocess should be put there. Since I mentioned subprocess, needs more documentation also, non blocking asynchronous input/output/handling of subprocess data should be easy, and built in. There’s a GSoC project around this spinning up, so we’ll see.

That all being said, would I trade python for something else? Not right now. Most of my nits are exactly that: nits, and most of all, they’re not impossible to change or resolve (given enough time, and resources).

I can make a similar list for OS/X, Linux and other things I use day in and day out - hell, I can make one for myself (ask my wife about me griping about me sometime). I can probably make a list like this for every single thing I’ve written, tools, scripts, apps, etc.

Like I said, being aware of, and trying to overcome your own shortcomings is how we all improve. In the case of a language, you can’t just keep adding things into a standard library and call it “better” - you have to take a constant look at what you’ve done to date with a critical eye, and ask yourself “what can we do better”.