Use prettier for markdown formatting

Changelog.md

@@ -20,7 +20,7 @@ The crate has been completely rewritten by [burntsushi](https://github.com/Burnt
 
 * Faster version parsing.
 * Faster version comparisons.
-* `Version` field accessors are now methods. 
+* `Version` field accessors are now methods.
 * `Version` is an [`Arc`](https://doc.rust-lang.org/std/sync/struct.Arc.html) of its internal representation, so cloning
   is cheap.
 * The internal representation of a version is split into a full representation and an optimized small variant that can
@@ -30,8 +30,8 @@ The crate has been completely rewritten by [burntsushi](https://github.com/Burnt
 
 ## 0.4
 
-* segments are now `u64` instead of `usize`. This ensures consistency between platforms and `u64` are required
-  when timestamps are used as patch versions (e.g., `20230628214621`, the ISO 8601 "basic format")
+* segments are now `u64` instead of `usize`. This ensures consistency between platforms and `u64` are required when
+  timestamps are used as patch versions (e.g., `20230628214621`, the ISO 8601 "basic format")
 * Faster version comparison
 * Added `VersionSpecifier::equals_version` constructor for `==<version>`
 * Added `VersionSpecifier::any_prerelease`: Whether the version marker includes a prerelease
@@ -88,6 +88,6 @@ The crate has been completely rewritten by [burntsushi](https://github.com/Burnt
 
 ## 0.2.0
 
-* Added `VersionSpecifiers`, a thin wrapper around `Vec<VersionSpecifier>` with a serde
-  implementation. `VersionSpecifiers::from_str` is now preferred over `parse_version_specifiers`.
+* Added `VersionSpecifiers`, a thin wrapper around `Vec<VersionSpecifier>` with a serde implementation.
+  `VersionSpecifiers::from_str` is now preferred over `parse_version_specifiers`.
 * Reexport rust function for python module

Readme.md

@@ -4,7 +4,8 @@
 [![PyPI](https://img.shields.io/pypi/v/pep440_rs.svg?logo=python&style=flat-square)](https://pypi.org/project/pep440_rs)
 
 A library for python version numbers and specifiers, implementing
-[PEP 440](https://peps.python.org/pep-0440). See [Reimplementing PEP 440](https://cohost.org/konstin/post/514863-reimplementing-pep-4) for some background.
+[PEP 440](https://peps.python.org/pep-0440).
+See [Reimplementing PEP 440](https://cohost.org/konstin/post/514863-reimplementing-pep-4) for some background.
 
 Higher level bindings to the requirements syntax are available in [pep508_rs](https://github.com/konstin/pep508_rs).
 
@@ -36,21 +37,17 @@ assert Version("2.0") in VersionSpecifier("==2")
 
 PEP 440 has a lot of unintuitive features, including:
 
-* An epoch that you can prefix the version which, e.g. `1!1.2.3`. Lower epoch always means lower
-  version (`1.0 <=2!0.1`)
+* An epoch that you can prefix the version which, e.g. `1!1.2.3`. Lower epoch always means lower version (`1.0 <=2!0.1`)
 * post versions, which can be attached to both stable releases and prereleases
-* dev versions, which can be attached to sbpth table releases and prereleases. When attached to a
-  prerelease the dev version is ordered just below the normal prerelease, however when attached
-  to a stable version, the dev version is sorted before a prereleases
-* prerelease handling is a mess: "Pre-releases of any kind, including developmental releases,
-  are implicitly excluded from all version specifiers, unless they are already present on the
-  system, explicitly requested by the user, or if the only available version that satisfies
-  the version specifier is a pre-release.". This means that we can't say whether a specifier
-  matches without also looking at the environment
+* dev versions, which can be attached to sbpth table releases and prereleases. When attached to a prerelease the dev
+  version is ordered just below the normal prerelease, however when attached to a stable version, the dev version is
+  sorted before a prereleases
+* prerelease handling is a mess: "Pre-releases of any kind, including developmental releases, are implicitly excluded
+  from all version specifiers, unless they are already present on the system, explicitly requested by the user, or if
+  the only available version that satisfies the version specifier is a pre-release.". This means that we can't say
+  whether a specifier matches without also looking at the environment
 * prelease vs. prerelease incl. dev is fuzzy
-* local versions on top of all the others, which are added with a + and have implicitly typed
-  string and number segments
+* local versions on top of all the others, which are added with a + and have implicitly typed string and number segments
 * no semver-caret (`^`), but a pseudo-semver tilde (`~=`)
-* ordering contradicts matching: We have e.g. `1.0+local > 1.0` when sorting,
-  but `==1.0` matches `1.0+local`. While the ordering of versions itself is a total order
-  the version matching needs to catch all sorts of special cases
+* ordering contradicts matching: We have e.g. `1.0+local > 1.0` when sorting, but `==1.0` matches `1.0+local`. While the
+  ordering of versions itself is a total order the version matching needs to catch all sorts of special cases

python/Readme.md

@@ -18,25 +18,22 @@ assert not VersionSpecifier(">=1.1").contains(Version("1.1a1"))
 assert Version("2.0") in VersionSpecifier("==2")
 ```
 
-Unlike [pypa/packaging](https://github.com/pypa/packaging), this library always matches preleases. To only match final releases, filter with `.any_prelease()` beforehand.
+Unlike [pypa/packaging](https://github.com/pypa/packaging), this library always matches preleases. To only match final
+releases, filter with `.any_prelease()` beforehand.
 
 PEP 440 has a lot of unintuitive features, including:
 
-* An epoch that you can prefix the version which, e.g. `1!1.2.3`. Lower epoch always means lower
-  version (`1.0 <=2!0.1`)
+* An epoch that you can prefix the version which, e.g. `1!1.2.3`. Lower epoch always means lower version (`1.0 <=2!0.1`)
 * post versions, which can be attached to both stable releases and prereleases
-* dev versions, which can be attached to sbpth table releases and prereleases. When attached to a
-  prerelease the dev version is ordered just below the normal prerelease, however when attached
-  to a stable version, the dev version is sorted before a prereleases
-* prerelease handling is a mess: "Pre-releases of any kind, including developmental releases,
-  are implicitly excluded from all version specifiers, unless they are already present on the
-  system, explicitly requested by the user, or if the only available version that satisfies
-  the version specifier is a pre-release.". This means that we can't say whether a specifier
-  matches without also looking at the environment
+* dev versions, which can be attached to sbpth table releases and prereleases. When attached to a prerelease the dev
+  version is ordered just below the normal prerelease, however when attached to a stable version, the dev version is
+  sorted before a prereleases
+* prerelease handling is a mess: "Pre-releases of any kind, including developmental releases, are implicitly excluded
+  from all version specifiers, unless they are already present on the system, explicitly requested by the user, or if
+  the only available version that satisfies the version specifier is a pre-release.". This means that we can't say
+  whether a specifier matches without also looking at the environment
 * prelease vs. prerelease incl. dev is fuzzy
-* local versions on top of all the others, which are added with a + and have implicitly typed
-  string and number segments
+* local versions on top of all the others, which are added with a + and have implicitly typed string and number segments
 * no semver-caret (`^`), but a pseudo-semver tilde (`~=`)
-* ordering contradicts matching: We have e.g. `1.0+local > 1.0` when sorting,
-  but `==1.0` matches `1.0+local`. While the ordering of versions itself is a total order
-  the version matching needs to catch all sorts of special cases
+* ordering contradicts matching: We have e.g. `1.0+local > 1.0` when sorting, but `==1.0` matches `1.0+local`. While the
+  ordering of versions itself is a total order the version matching needs to catch all sorts of special cases