- stdlib documentation. The docs for the stdlib are incomplete, period. They tend to also be underspecified in terms of semantics. It sucks that I sometimes have to check source code to see exactly what a function or method will do in a certain circumstance.
- Organization of the stdlib. I really don't like how friggin' flat the stdlib's namespace is. I have tried twice now to get it into a nested (but shallow) namespace. But every time you run into the flat camp and the deeply nested camp on top of people bickering over how to separate modules. I am personally burned out on this and won't move forward unless I either get huge backing from python-dev or Guido to give guidance over what he is after because I am not in the mood to fight for this just to have everyone throw out their opinion but not be willing to compromise on anything.
- C API inconsistency. When does a C function return a borrowed reference? When does it not? Should the caller or callee verify arguments are correct? When can a function not have an error return value? What are the rules for -1 being an error compared to 0 or NULL? We need some rules and we need to stick to them! If I know the name of the function I want to use I shouldn't have to look at the docs for stuff like this.
- Complexity of method call resolution. Multiple inheritance, __slots__, descriptors (both data and non-data), super, metaclasses. Python has a rich set of ways for you to muck with what gets called (both at call time and at class creation time). While everything listed has a purpose and is useful, trying to keep it all straight can be hard. And trying to maintain the code that implements all of this is *really* hard.
- How outdated the stdlib is. Names don't follow the style guide. Stuff that has not been touched in years is sitting in there. New ways of doing things have come about. Why the hell do we need all of it? I want a stdlib that is slim, up-to-date, and can move cruft out when a better solution comes along.
- BONUS: Plethora of C functions/macros just for performance reasons. Do you really need macro versions of functions that access an item in a tuple? Or how about a bazillion ways to create a string? The C API needs to go on a diet.
Overlap between Jacob, Titus, and me is interesting. Granted I wrote my list shortly after reading both of theirs, but I doubt my list would change that much. We all didn't like how the stdlib is documented. I would have complained about multi-processing, but since I don't do it that often and I get the perks of the GIL making my life easier I don't find it a flaw in the language.
But what is more interesting is what could be fixed. Pretty much short of the multi-processing/GIL complaint no one is hating on anything that couldn't be fixed with some determination. Trick is finding someone with that determination. =)
And as a bonus, I have the five things I hate about Python that make my life as a core developer a pain but I know won't ever change:
- Refcounting. Some people love the fact that Python cleans up after itself so quickly. That's nice. But getting refcounts right takes a lot of practice. And tracking a reference leak down can be truly painful and requires its own skill set. If we could compartmentalize memory issues more and use something more transparent I would be rather happy as I wouldn't have to deal with memory anymore.
- Use of C. The way we have to fake objects, its lax typing, its crappy library, and huge amount of undefined behaviour makes using C a pain. I personally would rather be using something like C++ (which I hate as a language but realize it can be useful when you code to a *small* subset) or Objective-C where basic object stuff is done for us and stuff like memory management can be made easier (refcounting in C++ is so much easier thanks to RAII). Hell, I would be okay with certain functional languages (Haskell is *not* on that list). But I would not mind having the implementation language do more for us (and no, I am not moving over to PyPy as I like clear delineations between implementation and target languages, which involves a long story as to why I feel that way, and I am willing to work at a low level for overall performance).
- Backwards compatibility. Users love, I hate it. Why? It makes my life hard. I have to worry about whether a change I make will make someone's code no longer work. That can prevent me from doing the better solution. It also leads to outdated APIs that then must be supported along with the more modern one that is better.
- Extensive platform support. I don't care about HP-UX, AIX, or any other random flavour of UNIX. I hate all of the OS-specific macros peppered throughout Python. It is a pain to try to trace code through it and it makes the source a mess.
- The build system. I hate autoconf. I hate makefiles. Our own setup.py is a bloody mess. I don't know how to get off of autoconf to something that runs on almost any platform. I don't even want to attempt to untangle our makefile to move over to cmake or bakefiles or whatever. I am just glad I have never severely broken the build system before.
