And I wish I knew what those were.

I don’t understand the request.

The obvious example is that the tutorial makes no mention of calling 'super' in __init__.  I'm also aware that there are issues of pickleability that arise if you do things one way, but do not arise if you do things another way.  But I don't know the details, and I'd like to see the tutorial show an example of the *best* way to write a user defined exception so that they behave like the built in Python exceptions.

This seems more like a Stack Overflow question or fodder for a blog post.  

When such best practices become well known and agreed upon, they can be added toa HOWTO document.  The tutorial is problematic because beginners start there and sprinkling the nuances of super() throughout the tutorial will only get in the way of the main learning points for a given section.

OK, let's move this, then.  I asked the question because I'd like to know what the best practice is for exceptions in the stdlib.  This is an area in which we have made quite a bit of progress recently (ie: the work done on exceptions for Python3, and PEP 3151), but I think there is still a lack of documentation (and possibly consensus?) on best practices for the stdlib.

I agree with Raymond that this, especially super() is not tutorial material. I agree with David that we need something somewhere else. Just today a commit was pushed about IOException subclasses causing problems because they have an __init__ but don't call super(). (Something like that.) I had no idea about this issue.

The stdlib has things like "class ModException(Exception): pass". Is that okay because it does *not* have __init__ override?

I'm not sure this belongs to the devguide.
Ideally the best way to do it should be documented in the docs.
This doesn't necessary mean it should be in the tutorial, but if the way documented in the tutorial is "wrong", I'd rather tell users "this is the right way, do like this and don't worry about the details right now (but follow this link if you want to know more)" than "use this wrongish way that is simple but will break as soon as you start doing something more complex".

I think the Library Manual's chapter 5 on exceptions, currently called Built-in Exceptions, would be a good place for a section on subclassing exceptions.

I'm removing the "devguide" component and update the title accordingly.