[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