-
-
Notifications
You must be signed in to change notification settings - Fork 32k
reprlib (used by pytest) infers builtin types based on class __name__
#113570
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
Comments
This is what I'm using as a workaround for pytest, in my conftest.py file: import reprlib
import pytest
import my_own_library
@pytest.fixture(scope="session", autouse=True)
def _patch_reprlib():
if not hasattr(reprlib.Repr, "repr1_original"):
def repr1(self, x, level):
if isinstance(x, ragged.array):
return self.repr_instance(x, level)
return self.repr1_original(x, level)
reprlib.Repr.repr1_original = reprlib.Repr.repr1
reprlib.Repr.repr1 = repr1 |
georgepittock
added a commit
to georgepittock/cpython
that referenced
this issue
Jan 3, 2024
georgepittock
added a commit
to georgepittock/cpython
that referenced
this issue
Jan 3, 2024
georgepittock
added a commit
to georgepittock/cpython
that referenced
this issue
Oct 17, 2024
georgepittock
added a commit
to georgepittock/cpython
that referenced
this issue
Oct 17, 2024
serhiy-storchaka
pushed a commit
that referenced
this issue
Oct 17, 2024
miss-islington
pushed a commit
to miss-islington/cpython
that referenced
this issue
Oct 17, 2024
…dowed builtins (pythonGH-113577) (cherry picked from commit 04d6dd2) Co-authored-by: George Pittock <[email protected]>
miss-islington
pushed a commit
to miss-islington/cpython
that referenced
this issue
Oct 17, 2024
…dowed builtins (pythonGH-113577) (cherry picked from commit 04d6dd2) Co-authored-by: George Pittock <[email protected]>
serhiy-storchaka
pushed a commit
that referenced
this issue
Oct 17, 2024
…adowed builtins (GH-113577) (GH-125655) (cherry picked from commit 04d6dd2) Co-authored-by: George Pittock <[email protected]>
serhiy-storchaka
pushed a commit
that referenced
this issue
Oct 17, 2024
…adowed builtins (GH-113577) (GH-125654) (cherry picked from commit 04d6dd2) Co-authored-by: George Pittock <[email protected]>
ebonnal
pushed a commit
to ebonnal/cpython
that referenced
this issue
Jan 12, 2025
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Uh oh!
There was an error while loading. Please reload this page.
Bug report
Bug description:
Code like the following:
raises
because reprlib uses
type(x).__name__
to infer thatx
has typearray.array
, rather than my user-defined class:cpython/Lib/reprlib.py
Lines 62 to 70 in cf34b77
Perhaps there's good reason to check the
__name__
string instead ofisinstance(x, array.array)
, to avoid unnecessarily importing thearray
module for start-up time or for minimizing clutter in thesys.modules
. However, this test should check both the__name__
string and the__module__
string.This affects any user-defined classes with the following names:
Some of these, admittedly, would be bad names for user-defined classes, but others are more reasonable, such as
array
anddeque
.1Since these methods are publicly available on class
reprlib.Repr
, the method names can't change, but the lookup could be replaced using a dict likeI encountered this in pytest. My error output contained
or
for reasons that had nothing to do with the actual error, and the
array.__repr__
code itself is error-free. (pytest overrides reprlib to provide a SafeRepr.)Thanks!
CPython versions tested on:
3.10
Operating systems tested on:
Linux
Linked PRs
Footnotes
In my case, I want the
ragged
library to provide aragged.array
because it reads like English that way. I also don't want to change the__name__
of my class to differ from its actual name. In particular, the Array API specification uses "array
" as a type name. ↩The text was updated successfully, but these errors were encountered: