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

Jonathan Lange 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
> >>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.
> 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 mailing list