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

Accept any non-string iterable for distutils.Extension's sources #311

Open
wants to merge 4 commits into
base: main
Choose a base branch
from

Conversation

agriyakhetarpal
Copy link

Description

This PR continues what was discussed in python/typeshed#12958 (comment) on allowing a loosened check for the source files for a distutils Extension instance.

Previously: just lists were accepted; now: any non-string iterable is accepted (tuples, sets, other iterators, etc.). I plan to update python/typeshed in accordance with this change.

Additional context

xref: python/mypy#18107, python/typeshed#12958

@agriyakhetarpal
Copy link
Author

I have a bunch of failing tests, linter errors, and several warnings from VS Code extensions locally; I hope the CI will be cleaner in its output. :)

.gitignore Outdated Show resolved Hide resolved
Comment on lines 110 to 126
raise AssertionError("'name' must be a string") # noqa: TRY004
if not (
isinstance(sources, list)
and all(isinstance(v, (str, os.PathLike)) for v in sources)
):

# we handle the string case first; though strings are iterable, we disallow them
if isinstance(sources, str):
raise AssertionError( # noqa: TRY004
"'sources' must be an iterable of strings or PathLike objects, not a string"
)

# mow we check if it's iterable and contains valid types
try:
sources = list(sources) # convert to list for consistency
if not all(isinstance(v, (str, os.PathLike)) for v in sources):
raise AssertionError(
"All elements in 'sources' must be strings or PathLike objects"
)
except TypeError:
raise AssertionError(
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Question for the distutils maintainers: I can't help but feel that AssertionError is misused here, shouldn't these all be TypeError ? (it's noqa'd but not explained)

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I have the same suggestion! :)

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Peeking at the history, these used to be actual assert statements (7d70ca7), so my guess is that the AssertionErrors were kept for backwards compatibility with code that might try to catch these errors.

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Additionally, what I infer from the commit message is that that they were added because in-line assert statements are completely removed from the bytecode if used with -O

distutils/extension.py Outdated Show resolved Hide resolved
distutils/extension.py Outdated Show resolved Hide resolved
Co-authored-by: Avasam <[email protected]>
@Avasam
Copy link
Contributor

Avasam commented Nov 6, 2024

To expand on the additional context: This allows typing the sources parameter in a way that avoids type invariance issues.
This indirectly relates to pypa/setuptools#2345 and pypa/setuptools#4689

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

Successfully merging this pull request may close these issues.

3 participants