From the Sphinx documentation:

returns, return: Description of the return value.
rtype: Return type. Creates a link if possible.

You might also benefit from:

raises, raise, except, exception: That (and when) a specific exception is raised.

So, as one example:

def get_previous_release(release_id):
    """ 
    Holt Vorgängeritem eines Items mit der ID release_id

    :param release_id: ID des items für das Release
    :type release_id: int
    :returns: appropriate release object
    :rtype: AlphaRelease, BetaRelease, or VRelease
    :raises ValueError: if release_id not an int
    :raises LookupError: if given release_id not found
    :raises TypeError: if id doesn't reference release
    """
    ... # your code here

Unfortunately there is not a strict or canonical choice in the Sphinx grammar and vocabulary for multiple return types. Often one would state a super-type of all the types that might be returned, if one existed (GenericRelease e.g.). But Python is just now, in its mid- to late-Python 3 era, defining a richer type notation. The typing module defines an evolving new grammar for such types independent of the old Sphinx definitions. If you wished to use this emerging standard, you might try something like:

:rtype: Union[AlphaRelease, BetaRelease, VRelease]

Writing good documentation is an art unto itself. Repeating yourself (e.g., repeating the variable name without underscores) is valueless; e.g., ++i; // increment i. If you're just repeating variable names without underscores, then you're not adding to anyone's understanding of the code.

I think it's always important to document what exceptions your methods throw. Return values aren't always as obvious as the original programmer thinks they are, so that's usually useful to document as well. (Again, if your method is get_foo(), saying "returns a foo" doesn't add anything.)

One thing to point out about that mypy example, the authors are using type hints which replaces a lot of what would be included in a docstring:

def warn(self, msg: str, context: Context, file: Optional[str] = None,
             origin: Optional[Context] = None)

Just from this, I know exactly what this method expects. Without it:

def warn(self, msg, context, file = None, origin = None)

I know a lot less.

First, here's the PEP on docstring conventions on Python (so 'Gets stuff given some parameters.' goes on the line above and there's a blank line after the docstring :D).

In my mind, the docstring for get should be specifically about get, so if it takes no arguments and returns nothing then there will be no 'Arguments' or 'Returns' section in the docstring. If this is the case, and there are arguments to pass in to MyHandler which affect the function of get, then this information should be put in the class docstring like so:

class MyHandler(tornado.web.RequestHandler):
    '''Handle the internet.

    MyHandler(some_param, other_param).get():
        Get the internet and handle it.

        Args:
            some_param: data about x sent by the client.
            other_param: data about y sent by the client.

    MyHandler().get():
        Get the internet and mishandle it.

    Never mishandle the internet.
    '''

    def get(self):
        '''Gets stuff given some parameters.

        Returns:
            HTTP 200 if everything's OK.
            HTTP 404 if other_param can't be found.
            HTTP 500 if some_param results in a database error.
        '''

        x = ...

There are also cases where you wouldn't want docstrings: if the parent class already has a sufficient docstring for the get (this doesn't seem to be the case for RequestHandler).