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

[Jonathan Lange]

On Feb 1, 2008 3:23 AM, Jean-Paul Calderone <exarkun at divmod.com> wrote:
> On Thu, 31 Jan 2008 16:11:10 -0000, glyph at divmod.com wrote:
> >On 02:45 pm, exarkun at divmod.com wrote:
> >>What's the right way to get a string describing a Version now?  It's an
> >>even
> >>harder decision to make than it was before.  Is it:
> >>
> >>  * str(Version(...))
> >>  * repr(Version(...))
> >>  * Version(...).base()
> >>  * Version(...).short()
> >>  * getVersionString(Version(...))
> >>
> >>Can we do something to make this better?
> >
> >This collection is super ad-hoc.  Let me try to express some of the
> >requirements that lead to the current confusion:
> >
> >  * [snip - special-case view requirement]
> >  * [snip - another special-case view requirement]
> >  * [snip - another special-case view requirement]
> >  * [snip - another special-case view requirement]
> >
> >Was getVersionString added because the other string representations weren't
> >"friendly" enough?  I guess the 'rUnknown' makes them look a little gnarly,
> >but I'd actually like to see the SVN revision in the cases where it's
> >present; the right thing to do to make it friendly would be to fix the
> >entries-file parser.
> >
> >Also, in any case, it should really be a method.  There's no reason to have
> >a free function defined right after a class whose only argument is a single
> >instance of that class :).
> >
>
> 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?
>

That was my thinking. Originally, getVersionString was in
t.p.deprecate, but I moved it on reviewer suggestion.

jml