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
Inaccessible attribute characters_written on OSError instances #74739
Comments
If I enumerate attributes on OSError instance with dir |
Actually the docs says "This attribute is available when using the buffered I/O classes from the io module", which means it's not always available since it depends on an inner field set or not. It's just like Python code: >>> class CW:
... def __get__(self, obj, objtype):
... if obj._written:
... return obj._written
... else:
... raise AttributeError("characters_written")
... def __set__(self, obj, val):
... obj._written = val
...
>>> class MyOSError:
... characters_written = CW()
... def __init__(self):
... self._written = False
...
>>> dir(MyOSError())
['__class__', '__delattr__', '__dict__', '__dir__', '__doc__', '__eq__', '__format__', '__ge__', '__getattribute__', '__gt__', '__hash__', '__init__', '__init_subclass__', '__le__', '__lt__', '__module__', '__ne__', '__new__', '__reduce__', '__reduce_ex__', '__repr__', '__setattr__', '__sizeof__', '__str__', '__subclasshook__', '__weakref__', '_written', 'characters_written']
>>> MyOSError().characters_written
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
File "<stdin>", line 6, in __get__
AttributeError: characters_written |
So is it by design? |
That's actually a very good question. hasattr returns False, but is it supposed to be an invariant that if dir returns a string hasattr should return True and getattr should not return AttributeError? (Well, it might raise AttributeError from inside the attribute, but the attribute itself should be "real".) Or to put it the other way, if hasattr returns False, should it be an invariant that dir does not list that attribute name? This may be a question for python-dev, and the answer may well be that we do *not* want to suggest that such an invariant should be expected. (We of course don't enforce such things, but we do make them hold true in the stdlib if we establish them). However, it is certainly a surprising behavior, and Python *generally* tries to avoid such surprises. This may have already been discussed and decided at some previous point, so someone should do some docs and archive searching about it first :) |
Looking at the code and doc it seems it's by design. But it's good or not remains in question. The related discussion about the more general problem behind this issue is https://groups.google.com/d/msg/python-ideas/Kou5cYGjGQ8/oXEixwgiDwAJ. There is a workaround and a proposed general resolution. But it's hard for me now to treat the current OSError behaviour as a *bug*. |
Thank you for linking to that Xiang. I had a vague memory of that discussion but couldn't find it. No, there is no bug here, but there is a question of whether or not there *should* be a bug here (that is, is there a design bug) and if so how/where to fix it :) This issue isn't the place to have that discussion. |
Note: these values reflect the state of the issue at the time it was migrated and might not reflect the current state.
Show more details
GitHub fields:
bugs.python.org fields:
The text was updated successfully, but these errors were encountered: