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

glyph at divmod.com glyph at divmod.com
Thu Jan 31 19:19:01 MST 2008


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.

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.

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 ;-).




More information about the Twisted-Python mailing list