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

Please make the C extension build optional (e.g. via PURE_PYTHON) #330

Open
mgorny opened this issue Oct 19, 2024 · 11 comments
Open

Please make the C extension build optional (e.g. via PURE_PYTHON) #330

mgorny opened this issue Oct 19, 2024 · 11 comments

Comments

@mgorny
Copy link

mgorny commented Oct 19, 2024

FEATURE REQUEST

Could you consider making the C extension build in setup.py optional, similarly to how the extensions are currently optional in tests? (i.e. if PURE_PYTHON=1, it wouldn't attempt to build them at all)

Our primary use case right now is Python 3.13 freethreading. Since the speedups extension does not support freethreading, importing it effectively reenables GIL for the whole program:

>>> import zope.interface
<frozen importlib._bootstrap>:488: RuntimeWarning: The global interpreter lock (GIL) has been enabled to load module 'zope.interface._zope_interface_coptimizations', which has not declared that it can run safely without the GIL. To override this behavior and keep the GIL disabled (at your own risk), run with PYTHON_GIL=0 or -Xgil=0.

For the time being, we believe that the "lesser evil" would be to install install zope.interface without speedups, and keep GIL disabled for the remainder of the program. The way we see it, it would be done like:

$ PURE_PYTHON=1 pip install zope.interface
@d-maurer
Copy link
Contributor

d-maurer commented Oct 19, 2024 via email

@mgorny
Copy link
Author

mgorny commented Oct 19, 2024

I'm packaging zope.interface for Gentoo. Setting PURE_PYTHON at runtime does not resolve the more general problem that the package currently installs a harmful extension. Similarly, removing it would mean that users unnecessarily burn coal to build it. And the current design would mean we'd have to maintain an intrusive patch forever, vs. having to just control a single envvar.

@d-maurer
Copy link
Contributor

d-maurer commented Oct 19, 2024 via email

@mgorny
Copy link
Author

mgorny commented Oct 19, 2024

Deleting .py files that are merely copied is a minor cost compared to C extensions that are actually compiled, which involve nonzero energy cost.

@d-maurer
Copy link
Contributor

d-maurer commented Oct 19, 2024 via email

@mgorny
Copy link
Author

mgorny commented Oct 19, 2024

Hmm, I suppose that suggestion does make sense. Do you want me to make a patch?

@d-maurer
Copy link
Contributor

d-maurer commented Oct 19, 2024 via email

mgorny added a commit to mgorny/zope.interface that referenced this issue Oct 19, 2024
Do not enable C speedups by default if running Python 3.13+
in freethreading mode (with GIL disabled).  Since the extension
does not support this mode explicitly at the moment, loading it would
cause CPython to reenable GIL with a warning and penalize the whole
environment.

Discussed in issue zopefoundation#330.
mgorny added a commit to mgorny/zope.interface that referenced this issue Oct 19, 2024
Do not enable C speedups by default if running Python 3.13+
in freethreading mode (with GIL disabled).  Since the extension
does not support this mode explicitly at the moment, loading it would
cause CPython to reenable GIL with a warning and penalize the whole
environment.

Discussed in issue zopefoundation#330.
@tseaver
Copy link
Member

tseaver commented Oct 22, 2024

Deleting .py files that are merely copied is a minor cost compared to C extensions that are actually compiled, which involve nonzero energy cost.

We publish wheels with the extension already built, which covers 99.99% of all users of the package. Doing the extra work (if needed) when building for a Linux distribution isn't going to be measurable, compared to the efficiency of actually using the extension.

WRT to the "declaration" that we support free-threading: while there is some work to be done to test / verfiy / declare that the package works under freethreading, we should be pretty close with the refactorings done to support heap-based types and multi-phase initialization.

@mgorny
Copy link
Author

mgorny commented Oct 22, 2024

We publish wheels with the extension already built, which covers 99.99% of all users of the package.

Do you have any honest, unbiased statistics to prove that number? Because 99.99% of the times when people say "99.99%", they're just making that up.

@tseaver
Copy link
Member

tseaver commented Oct 22, 2024

Available download stats for zope.interface here.

  • Downloads for 3.13 and 3.14 (no way to tell FT vs. non-FT) seem to average about 1% of total downloads since the 3.13 release.
  • Those stats don't (any longer?) split out sdist vs. bdist_wheel or other bdist_* formats.

There are essentially three ways folks get zope.interface:

  • Via pip or a derivative: unless the user explicitly prevents it, prefers a binary;
    in many cases, as specified in a requirements.txt file (or similar with tools built atop pip),
    or via a transient dependency.
  • Via zc.buildout (might still prefer source, but I haven't touched it in a while)
  • Via Linux distro packages (already binary)

You'd be hard-pressed to convince me that there are a significant number of pip (and derived tools) users who specify --no-binary for their packages: that makes their builds slower and is wasteful to boot: even if they did, after the first download already have the wheel in their cache if they are doing active development.

@tseaver
Copy link
Member

tseaver commented Oct 22, 2024

See #332 for work needed to support 3.13 FT.

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

No branches or pull requests

3 participants