Line length adjustments

Author: zklaus

peps/pep-0790.rst

@@ -13,9 +13,9 @@ Python-Version: 3.14
 Post-History: <REQUIRED: dates, in dd-mmm-yyyy format, and corresponding links to PEP discussion threads>
 
 ..
-    If adopted, the contents of this pep should be integrated into the canonical
-    documentation in the Python Packaging User Guide and the following
-    directive should be added here:
+    If adopted, the contents of this pep should be integrated into the
+    canonical documentation in the Python Packaging User Guide and the
+    following directive should be added here:
     .. canonical-pypa-spec:: :ref:`packaging:dependency-specifiers`
 
 Abstract
@@ -41,15 +41,15 @@ evolved and new features warrant their own environment markers.
 
 The primary motivation for extending the allowed set of environment markers now
 is free-threaded CPython [#python-free-threading]_ emerging. Currently there is
-no way to distinguish between a GIL-enabled and a free-threaded CPython interpreter
-with an environment marker. This leads to real world issues for the adoption of
-free-threading and its incremental rollout. When a Python package is being made
-compatible with free-threaded CPython, it also needs all its build and runtime
-dependencies to be compatible. Capturing the first version of a dependency that
-is compatible precisely in metadata is currently not possible, and increasing
-the minimum version of a dependency also for the GIL-enabled build is usually
-undesirable since it unnecessarily limits compatibility between packages.
-
+no way to distinguish between a GIL-enabled and a free-threaded CPython
+interpreter with an environment marker. This leads to real world issues for the
+adoption of free-threading and its incremental rollout. When a Python package
+is being made compatible with free-threaded CPython, it also needs all its
+build and runtime dependencies to be compatible. Capturing the first version of
+a dependency that is compatible precisely in metadata is currently not
+possible, and increasing the minimum version of a dependency also for the
+GIL-enabled build is usually undesirable since it unnecessarily limits
+compatibility between packages.
 
 Some concrete examples of such issues have been discussed in the `Environment
 marker for free-threading`_ Discourse thread:
@@ -62,35 +62,36 @@ marker for free-threading`_ Discourse thread:
   Python`_).
 - CFFI has no support for free-threading yet, and `Armin Rigo, one of the
   maintainers, has stated
-  <https://github.com/python-cffi/cffi/pull/143#issuecomment-2580781899>`__ that
-  it may be a good idea to fork ``cffi``, implement support for free-threading, and
-  only come back to the CFFI project with a single large PR that adds support
-  after the functionality "is reasonably well-tested (either as tests or,
-  better in this case, tested by being in use in various other projects)".
-  There are a lot of projects that depend on ``cffi``. They are likely fine to
-  start depending on a fork for free-threading only, however depending on a
-  fork for >=3.13 or for all Python versions seems like a much larger ask, and
-  more disruptive for distribution packagers.
+  <https://github.com/python-cffi/cffi/pull/143#issuecomment-2580781899>`__
+  that it may be a good idea to fork ``cffi``, implement support for
+  free-threading, and only come back to the CFFI project with a single large PR
+  that adds support after the functionality "is reasonably well-tested (either
+  as tests or, better in this case, tested by being in use in various other
+  projects)". There are a lot of projects that depend on ``cffi``. They are
+  likely fine to start depending on a fork for free-threading only, however
+  depending on a fork for >=3.13 or for all Python versions seems like a much
+  larger ask, and more disruptive for distribution packagers.
 
 While these concrete examples may be addressed later this year by Cython and
 CFFI making compatible releases, the same issue is going to repeat further up
 the stack. The free-threading rollout is expected to take several years, and an
 environment marker for free-threading will make that rollout significantly less
 bumpy.
 
-Another important ABI feature that is not yet covered by environment markers is the bitness
-of the interpreter. In most cases, the ``sys_platform`` or ``platform_system``
-markers are enough, because there's only a single bitness in use per platform.
-This is not the case on Windows however: both 32-bit and 64-bit Python interpreters
-are widely used on x86-64 Windows. Not being able to distinguish between the
-two may be relevant for packages that provide C extensions. For example, SciPy
-does not provide ``win32`` wheels (it isn't able to due to the lack of a suitable
-32-bit compiler toolchain with Fortran support). Those wheels lacking can be
-awkward especially for projects where SciPy is an optional dependency only. In
-that case, it would be useful to be able to specify that SciPy is required
-*unless* the interpreter is a 32-bit one on Windows (c.f. `Require SciPy Unless
-on 32-bit win32`_) - it avoids users who install such packages to get failed
-from-source installs because of the missing wheels.
+Another important ABI feature that is not yet covered by environment markers is
+the bitness of the interpreter. In most cases, the ``sys_platform`` or
+``platform_system`` markers are enough, because there's only a single bitness
+in use per platform. This is not the case on Windows however: both 32-bit and
+64-bit Python interpreters are widely used on x86-64 Windows. Not being able to
+distinguish between the two may be relevant for packages that provide C
+extensions. For example, SciPy does not provide ``win32`` wheels (it isn't able
+to due to the lack of a suitable 32-bit compiler toolchain with Fortran
+support). Those wheels lacking can be awkward especially for projects where
+SciPy is an optional dependency only. In that case, it would be useful to be
+able to specify that SciPy is required *unless* the interpreter is a 32-bit one
+on Windows (c.f. `Require SciPy Unless on 32-bit win32`_) - it avoids users who
+install such packages to get failed from-source installs because of the missing
+wheels.
 
 
 Rationale