> The 'message' attribute itself is deprecated
> as it didn't exist prior to being introduced in 2.5.

That seems to me to be the wrong way to phrase it, and indeed that kind
of phrasing implies the current bug.  For example, it leads to the
incorrect statement that "The 'message' attribute ... didn't exist prior
to being introduced in 2.5."  But looking at the docutils and Twisted
code bases, to take two examples, tells us that it **did** exist: a slew
of instances had this attribute.  The correct statement, that
BaseException did not initialize a `message` attribute, is an entirely
different matter.

Imo, deprecating setting and accessing an **instance attribute** is just
flat out wrong and grossly violates inheritability promises.  As we have
seen.

I think (?) that what was desired to be deprecated is the combination of

- setting a message attribute via BaseException.__init__, AND
- accessing an instances message attribute that was set *this way*

But in fact the setting cannot really be deprecated because it is
implicit: it is something currently done by BaseException, not by the
user.  So I think (?) the best we can do is look at whether the user
initializes BaseException (**not** the derived classes) with a single
argument, which is a nonempty string, and then tries to access this as a
`message` attribute.  Which is why I originally proposed setting a flag
when BaseException.__init__ is called and conditioning the deprecation
warning on this flag.  (E.g., the flag could be set if and only if the
user calls BaseException.__init__(instance, string).)

In any case, I think Jean-Paul is asking exactly the right question
(i.e., just what exactly is being deprecated?).  A more careful answer
will hopefully lead to less buggy DeprecationWarning.