[Twisted-Python] Re: [Twisted-commits] r22428 - Deprecation API for functions and methods.
jml at mumak.net
Thu Jan 31 23:34:16 EST 2008
On Feb 1, 2008 1:19 PM, <glyph at divmod.com> wrote:
> On 31 Jan, 11:44 pm, jml at mumak.net wrote:
> >>Maybe Version shouldn't be responsible for any view at all. Maybe
> >>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.
> I'd really prefer it if we had a canonical string representation for
> versions which t.p.deprecate would use as well as anything else which
> needs to report information about a version to developers. The
> (existing?) str() ought to be acceptable for that. That way when you
> saw a string in a certain format you could immediately identify it as a
> precise statement about a current or future Twisted package version.
Having a canonical representation doesn't exclude having multiple
Looking at how these are actually used:
- str() is used only for copyright (and tests)
- short is used for __init__.py
- base is used for short, in _release._changeVersionInFile (don't know
why base rather than everyone else, actually) and dist.py
- repr is only used generically.
- getVersionString is used only by deprecate.
In summary, sometimes we want the project name, sometimes we want the
svn revno. This is perhaps better achieved by having a single function
/ method that takes a couple of params.
Personally, I think that having a project name in Version is silly.
> I was sort of hoping that we might have Version-alike objects at some
> point which could know about different versioning schemes, and ways of
> comparing different revision control systems (although I guess dealing
> with comparing arbitrary bzr revisions in one tiny little object might
> be too much to ask...). This is one reason I don't want to separate the
> view out too much; inspecting the model directly binds any potential
> view very tightly to the x.y.z versioning scheme.
For the purposes of this discussion, that is a massive, massive YAGNI.
> But, this is somewhat obviously a bike shed, so I am not going to
> agitate terribly hard for this. It's not like I use Twisted primarily
> for dealing with my obscurely formatted package version strings ;-).
Right. I propose we do nothing.
More information about the Twisted-Python