Name the Python extension after what it contains - #21813
Closed
shoumikhin wants to merge 1 commit into
Closed
Conversation
shoumikhin
requested review from
JacobSzwejbka,
kirklandsign and
larryliu0820
as code owners
August 13, 2026 15:06
🔗 Helpful Links🧪 See artifacts and rendered test results at hud.pytorch.org/pr/pytorch/executorch/21813
Note: Links to docs will display an error until the docs builds have been completed. ❌ 19 New Failures, 295 Pending, 4 Unclassified FailuresAs of commit 66557e0 with merge base e265ea6 ( NEW FAILURES - The following jobs have failed:
UNCLASSIFIED FAILURES - DrCI could not classify the following jobs because the workflow did not run on the merge base. The failures may be pre-existing on trunk or introduced by this PR:
This comment was automatically generated by Dr. CI and updates every 15 minutes. |
meta-cla
Bot
added
the
CLA Signed
|
|
shoumikhin
changed the base branch from
gh/shoumikhin/105/head
to
gh/shoumikhin/106/head
August 13, 2026 15:11
The compiled Python extension in the wheel was called `_portable_lib`. That name is misleading in two ways. "Portable" is the name of a kernel set in this project, the portable kernels, and this file does not contain them: it holds the Python bindings for the runtime. "Lib" says nothing, since every shared object is a library. Someone looking for the portable kernels finds the Python bindings instead, and someone looking for the bindings has no reason to open a file named after kernels. Rename it to `_C`, which is the usual name for a package's compiled C extension and what PyTorch calls the same thing (`torch/_C.cpython-*.so`). The package path already says `pybindings`, as in `executorch.extension.pybindings`, so a name like `_pybindings` would repeat itself while `_C` reads as "this package's C extension". Nothing user facing changes. Applications import the public wrapper: ```python from executorch.extension.pybindings import portable_lib ``` That wrapper re-exports everything from the compiled module and keeps its name, so existing code continues to work. Only the private module behind it is renamed, and it was already documented as experimental and subject to change. Test plan: Built a wheel and confirmed the shipped file is named for the new module: ``` extension/pybindings/_C.cpython-312-x86_64-linux-gnu.so ``` Installed that wheel into a fresh environment and checked both the public wrapper and the private module load, then exported and ran a model through the Python bindings: ``` public wrapper works: True module name : executorch.extension.pybindings._C exported symbols : 22 ``` Also grepped the tree to confirm no build file, test, or comment still names the old module.
shoumikhin
force-pushed
the
gh/shoumikhin/106/head
branch
from
August 13, 2026 15:17
e0f495d to
cbb1f34
Compare
shoumikhin
force-pushed
the
gh/shoumikhin/107/head
branch
from
August 13, 2026 15:17
264ee87 to
66557e0
Compare
Contributor
Author
|
Superseded by #21816, which carries the same change and is managed as part of the stack. Closing this duplicate. |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
The compiled Python extension in the wheel was called
_portable_lib. That nameis misleading in two ways. "Portable" is the name of a kernel set in this project,
the portable kernels, and this file does not contain them: it holds the Python
bindings for the runtime. "Lib" says nothing, since every shared object is a
library. Someone looking for the portable kernels finds the Python bindings
instead, and someone looking for the bindings has no reason to open a file named
after kernels.
Rename it to
_C, which is the usual name for a package's compiled C extensionand what PyTorch calls the same thing (
torch/_C.cpython-*.so). The package pathalready says
pybindings, as inexecutorch.extension.pybindings, so a name like_pybindingswould repeat itself while_Creads as "this package's Cextension".
Nothing user facing changes. Applications import the public wrapper:
That wrapper re-exports everything from the compiled module and keeps its name, so
existing code continues to work. Only the private module behind it is renamed, and
it was already documented as experimental and subject to change.
Test plan:
Built a wheel and confirmed the shipped file is named for the new module:
Installed that wheel into a fresh environment and checked both the public wrapper
and the private module load, then exported and ran a model through the Python
bindings:
Also grepped the tree to confirm no build file, test, or comment still names the
old module.