[Twisted-Python] Re: [Twisted-commits] r22428 - Deprecation API for functions and methods.

[Jean-Paul Calderone]

On Thu, 31 Jan 2008 17:01:48 -0000, glyph at divmod.com wrote:
>On 04:23 pm, exarkun at divmod.com wrote:
>>Maybe Version shouldn't be responsible for any view at all.  Maybe Version
>>is just a model class, and things that actually know what the view
>>requirements are can implement the view?
>
>I agree insofar as the model is poorly exposed and documented.  The ivars 
>have no documentation, and the only way to get the SVN revision is to call a 
>private method or to mangle strings.
>
>However, some of these "views" should definitely be attached to the class, 
>for convenience and simplicity.  For example, a sensible __repr__ makes 
>debugging and inspecting these things a lot easier.

Having Version.__repr__ is fine.  __repr__ is a thing that Python classes
often have.

>Adding a new module, 
>function, or class which does the string formatting means that users of 
>Version will need to look somewhere else to perform the function they want, 
>and ultimately it doesn't eliminate the confusion - "do I want the 'short 
>dotted' view or the 'includes project but without development version' 
>view?" - unless we also reduce the number of options available.

What I had in mind was more that each application that wants to format
Version in some particular way can do the formatting itself, not that it
would pick an appropriate function from the version_view module and rely
on it to do the formatting.

The complexity of the code we're talking about foisting on an application
is on the order of "%s.%s" % (version.major, version.minor).  Not much of
a burden.  On the other hand, if we really want to make this easy, then
maybe Version should have a `format´ method that just takes a format string
and does the interpolation for you.

Jean-Paul