-
Notifications
You must be signed in to change notification settings - Fork 74
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Implicit version comparison with strings #52
Comments
This kind of thing often breaks transitivity of == and != and generally is a mistake in my experience over just converting the string into the structured type and comparing those. What's the advantage in doing it? |
The advantage of doing it is that versions can be represented in multiple ways, but whenever they are compared to a canonical I see your point about breaking transitivity since it's clearly the case that In any event, I have already implemented subclasses of |
I'm not the maintainer by the way, so my opinion matters very little :), just noting it as a dissent in the event the discussion is useful. |
You make a fair point, but at some point the contents of any variable are only meaningful in context right? If I say For me it boils down to not having to track down every single case in my code where I would have to explicitly convert something to And yes discussion is useful :). I'm not sure if we're getting anywhere in this case, however. |
I was to file a new issue, and smart github suggested me this one! Python's distutils.version supports it (or both left and right comparison), e.g. $> python -c 'from distutils.version import LooseVersion as LV, StrictVersion as SV; print("0.9" < SV("0.10"))'
True so to migrate code which used |
This seems like a cool project and I'd like to include it in a project I'm working on. Is there any chance you'd be willing to support implicit comparison of
Version
andSpec
objects with string types? For example, I'd like the following cases to work:It's less important, but I also think this would be useful with tuples:
It doesn't seem like this would be very difficult or unreasonable to support. I'd be willing to submit a PR myself.
The text was updated successfully, but these errors were encountered: