[Twisted-Python] Re: [Twisted-commits] r22428 - Deprecation API for functions and methods.
Jonathan Lange
jml at mumak.net
Thu Jan 31 18:44:36 EST 2008
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
More information about the Twisted-Python
mailing list