[MERGE] symbol_versioning.deprecation_string

[Martin Pool]

On  6 Sep 2006, Robert Collins <robertc at robertcollins.net> wrote:

> The current symbol version API works this way. 
> Doing what you propose is a larger change, as it requires overhauling
> the symbol versioning API.

That's true.  I was expressing dissatisfaction with the current API, and
therefore the slight negative.  However having looked at the warning
module I see we are kind of stuck with it, so I withdraw the -0.

> They are not raised at all (I am assuming you refer to an exception like
> mechanism). Nor are they reported as objects, rather they are reported
> as a call to 'symbol_versioning.warn(aString, DeprecatedWarning)'. 

(I meant "raise" conceptually, not using the "raise" statement.)

Well, they can be reported as objects, with 

  warn(SomeSpecificDeprecation(more, params))

however unfortunately it looks like the instance isn't exposed to
objects that are trying to filter or report on the output, and is only
used if the warning is turned into an exception, which is a bit
disappointing (and not like logging or exceptions, where the objects are
preserved.)  So apparently we are stuck with doing it just with strings.

> > Factoring out something which returns a nicely formatted name for a
> > callable is fine with me.
> 
> Thats precisely what this helper does. 

No, it also combines it with a particular format template, which is what
I objected to.

-- 
Martin