# Reconciling \`packaging\` module & The Dependency Specifier Spec's non-version to version comparison rules

**URL:** <https://discuss.python.org/t/reconciling-packaging-module-the-dependency-specifier-specs-non-version-to-version-comparison-rules/100287>\
**Category:** Standards\
**Created:** [July 27, 2025, 5:40am UTC](https://discuss.python.org/t/reconciling-packaging-module-the-dependency-specifier-specs-non-version-to-version-comparison-rules/100287 "2025-07-27T05:40:32Z")\
**Posts on this page:** 1\
**Showing post:** 14

<div class="post-metadata">

**Author:** ![henryiii](https://sea2.discourse-cdn.com/flex002/user_avatar/discuss.python.org/henryiii/32/3493_2.png) [@henryiii](https://discuss.python.org/u/henryiii)\
**Post date:** [December 2, 2025, 4:21am UTC](https://discuss.python.org/t/reconciling-packaging-module-the-dependency-specifier-specs-non-version-to-version-comparison-rules/100287/14 "2025-12-02T04:21:41Z")

</div>

Could we at least modify the spec to get rid of the `==` must be typed as a version part for everything except `platform_release`? `platform_release` is nearly useless if all you can do is `==` on it, but there’s no use for any of the other “string” typed values to be viewed as versions, it slows down `packaging` as creating `SpecifierSet`/`Version` is expensive, and it actively breaks things like extras, as `==` requires version comparisons, which breaks extras like `v0`.

Here’s my do-as-little-as-possible proposal:

- Change the spec to state all string values only support string comparisons. No more “convert to version if possible”.
- Make `platform_release` have a new type, `string | Version`, which has the current behavior (just punting the work on fixing this to later, as it’s the hard one) (Note: this is the current behavior of Version, the name just indicates that this might not always be a Version, while the three fields with Version are always supposed to be Versions).

Note that you can’t really use comparisons with `platform_release`, as there is no short-circuit evaluation requirement in the spec, so this will error on platforms that have a non-version-like `platform_release` if you use it, even if you protect it by checking the platform first.\[1\]

Longer term, things that might be useful to improve the situation for `platform_release` could be:

- Add short-circuit evaluation to the spec
- Make the version operators other than `==` and `!=` throw an error if `platform_release` isn’t convertible to a version. This would have to go with the above short-circuiting behavior; it would help reduce silent errors, for example when a “10something” follows a “9something”.
- Maybe find some way to make `platform_release` more usable across platforms (likely a new field that is stripped down in some way to just version-like numbers?)

(PS: to make matters worse, packaging does not follow the spec when it comes to the Python fallback behavior)

The way packaging used to do it (before LooseVersion was removed), and currently (unreleased) does it is comparisons like \< always return False if the value is not a valid Version. Changing the spec to match that is also an option. I can expand on this idea later.

* * *

1. Actually this is changing in the next version of packaging due to fixes in how Specifiers work with legacy versions, but it was true until now.

---

_[View the full topic](https://discuss.python.org/t/reconciling-packaging-module-the-dependency-specifier-specs-non-version-to-version-comparison-rules/100287)._