"why is python documentation so bad" Really? Did not see that one coming
1. Google "Python os.unlink".
2. First link is https://docs.python.org/2/library/os.html which starts at the very top of the documentation for the os module.
3. CTRL + f/Command + f for "os.unlink".
4. The first result on the page is right around https://docs.python.org/2/library/os.html#os.mkfifo.
5. Click on os.unlink words because it's an actual link.
That last bit is very important. Every bit of documentation typically has a link from any module/object/method to its canonical documentation location. Contrast this with Django REST Framework, which does not do this and their docs are basically unusable because of this.
I agree that this could be shortened somehow to Google "Python os.unlink" and the first result being https://docs.python.org/2/library/os.html#os.unlink but it's such a minor flaw compared to everything else I've ever seen in terms of searching for docs that I am willing to live with it.
Contrast this with PHP's docs. Here, it's great: just go to http://php.net/YOUR-FUNCTION and you'll get the docs. For example: http://php.net/implode. What I don't like about these docs is that they often lie to your face. As in, they are just plain inaccurate and the way you find this out is by having your production code blow up. That right there is actual bad documentation.
I dunno, but google manages to do it pretty well. Like for your example, I might search for "python delete file" since I don't remember unlink. Ignoring the stackoverflow results, the first doc result is the right one, but I'll have a hell of a time finding it on that page. Looking at the next result tutorialspoint, the page itself is exactly what I was looking for. Tutorialspoint is quite excellent in this regard and I've started going there first.
https://www.google.com/search?q=python+unittest&ie=utf-8&oe=...
First link is correct, and so is the snippet in the search result. When you click on the link, it should have taken you to:
https://docs.python.org/2/library/unittest.html#setupclass-a...
which is the anchor / title closest to the snippet found, as opposed to the main page:
I think that even in an example like the one you cite, this has some relevance. When the quoted context was larger, it seemed to me easier to find it -- scanning visually -- within the target page.
Of course, there is also the matter that with Google's loosened matching and/or increased page dynamism, results these days pertain less often to what I'm interested in. Not all that infrequently, I'll click through on a promising result, to find little or no hint of the context that Google quoted.
TL;DR: More anecdotal grumbling about the decreasing usefulness of Google search results.
is probably the first thing that pops up when you search of python and tutorial, yet it reads like it is adressed at people that are looking for a way to augment their unix shell. This is not very helpful to most people. Thankfully, there are many alternatives, however it is bad that this is the first thing that pops up.
I am confused by the why is "X so slow" argument. Conceptually and practically, Python might be slower than native C code, but the tradeof lies in the relationship between runtime and "design"-time. It is a little slower, but it is faster to learn, read and write. Demands for "more performance" should be driven by actual numbers: How many people should your webservice serve in a second, minute? So far python has been fast enough for anything I wanted to do. For everything else there is numpy/scipy - fortran for the win!
I've actually found myself doing quite a bit of code reading for Django. As much as the team tries, there is quite a bit of undocumented magic that can really trip you up if you are not doing exactly the right things. For example, don't create a source-tree/project/__init__.py file (sibling to your settings.py) that does any type of imports.
You're definitely right about the C# docs, though. I always feel totally lost looking through those, especially since I'm not much of a C# dev to begin with.
As noted elsewhere, there can be a lot of Ctrl/Command-f'ing to find what you want. That, and sometimes I just want an example of what I have to think is the most common case for a function. Instead I often get examples of esoteric cases that I'll likely never do. I mean, it's nice that those capabilities are there and that they're documented, but I just want to (made-up example) search for a simple ASCII substring, not a UTF-8 substring in a Unicode string using a regex all fourteen optional parameters.
That said, I wouldn't go so far as to say that the docs are bad, but they could certainly be better.