Skip to content
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

Open
drdavella opened this issue Jul 26, 2017 · 5 comments
Open

Implicit version comparison with strings #52

drdavella opened this issue Jul 26, 2017 · 5 comments
Labels

Comments

@drdavella
Copy link

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 and Spec objects with string types? For example, I'd like the following cases to work:

import semantic_version as sv
assert sv.Version('1.0.0') == '1.0.0'

spec = sv.Spec('>=2.0.0')
assert spec.match('2.1.0')

It's less important, but I also think this would be useful with tuples:

assert sv.Version('1.0.0') == (1,0,0)

It doesn't seem like this would be very difficult or unreasonable to support. I'd be willing to submit a PR myself.

@Julian
Copy link

Julian commented Jan 19, 2018

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?

@drdavella
Copy link
Author

The advantage of doing it is that versions can be represented in multiple ways, but whenever they are compared to a canonical Version or Spec, the comparison will make sense. It also conforms with Python's philosophy of duck typing, where in this case if it looks like a Version/Spec and acts like a Version/Spec, then we can treat it as such.

I see your point about breaking transitivity since it's clearly the case that '1.0.0' != (1,0,0). However, the semantics of comparing to a known Version or Spec seem to be clear enough that it shouldn't matter in this case.

In any event, I have already implemented subclasses of Version and Spec in my own code base, so it's not a big deal if you don't want to support it here. However, if you want to accept it upstream, I'm happy to help.

@Julian
Copy link

Julian commented Jan 19, 2018

1.0.0 is not a version :), it's a string that happens to look like a version, and might be a version, but you don't know if it is or not without out of band info. As a facetious example, what happens if my name is 1.0.0 and you compare me with ==?

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.

@drdavella
Copy link
Author

You make a fair point, but at some point the contents of any variable are only meaningful in context right? If I say a = 5 and b = 5, is comparison of a == b meaningful and/or useful to me or not? Maybe a represents length and b represents dollars. On the other hand, if I choose to compare Version('1.0.0') == '1.0.0', then I have already declared that the results of this comparison are meaningful to me.

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 Version in order to be able to perform a meaningful and obvious comparison. But this is a problem I have already solved in my own code.

And yes discussion is useful :). I'm not sure if we're getting anywhere in this case, however.

@yarikoptic
Copy link

I was to file a new issue, and smart github suggested me this one!
Here is my arguments for support of comparisons against strings:

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 distutils.version classes to use proper semantic versioning via this package would require explicit casting into target class at the point of comparison, which would require more code refactoring. Moreover it might make it harder in some use cases to use generic code, such as some_version_instance < '1.0.0' where some_version_instance could be either semantic_version.Version or distutils.version.StrictVersion instance depending on logic somewhere else in the code on what kind of versioning scheme is used.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

4 participants