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

Inaccessible attribute characters_written on OSError instances #74739

Closed
IgorKozyrenkoikseek mannequin opened this issue Jun 2, 2017 · 6 comments
Closed

Inaccessible attribute characters_written on OSError instances #74739

IgorKozyrenkoikseek mannequin opened this issue Jun 2, 2017 · 6 comments
Labels
stdlib Python modules in the Lib dir type-bug An unexpected behavior, bug, or error

Comments

@IgorKozyrenkoikseek
Copy link
Mannequin

IgorKozyrenkoikseek mannequin commented Jun 2, 2017

BPO 30554
Nosy @bitdancer, @zhangyangyu

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:

assignee = None
closed_at = <Date 2017-06-02.16:44:50.276>
created_at = <Date 2017-06-02.16:01:56.746>
labels = ['invalid', 'type-bug', 'library']
title = 'Inaccessible attribute characters_written on OSError instances'
updated_at = <Date 2017-06-02.20:36:52.607>
user = 'https://bugs.python.org/IgorKozyrenkoikseek'

bugs.python.org fields:

activity = <Date 2017-06-02.20:36:52.607>
actor = 'r.david.murray'
assignee = 'none'
closed = True
closed_date = <Date 2017-06-02.16:44:50.276>
closer = 'xiang.zhang'
components = ['Library (Lib)']
creation = <Date 2017-06-02.16:01:56.746>
creator = 'Igor Kozyrenko (ikseek)'
dependencies = []
files = []
hgrepos = []
issue_num = 30554
keywords = []
message_count = 6.0
messages = ['295030', '295037', '295042', '295043', '295048', '295053']
nosy_count = 3.0
nosy_names = ['r.david.murray', 'xiang.zhang', 'Igor Kozyrenko (ikseek)']
pr_nums = []
priority = 'normal'
resolution = 'not a bug'
stage = 'resolved'
status = 'closed'
superseder = None
type = 'behavior'
url = 'https://bugs.python.org/issue30554'
versions = ['Python 3.6']

@IgorKozyrenkoikseek
Copy link
Mannequin Author

IgorKozyrenkoikseek mannequin commented Jun 2, 2017

If I enumerate attributes on OSError instance with dir
dir(OSError())
I see an 'characters_written' attribute (which is supposed to be defined on BlockingIOError according to docs).
If I try to access it
getattr(OSError(), 'characters_written')
I get an AttributeError

@IgorKozyrenkoikseek IgorKozyrenkoikseek mannequin added stdlib Python modules in the Lib dir type-bug An unexpected behavior, bug, or error labels Jun 2, 2017
@zhangyangyu
Copy link
Member

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

@IgorKozyrenkoikseek
Copy link
Mannequin Author

IgorKozyrenkoikseek mannequin commented Jun 2, 2017

So is it by design?
cgitb library fails to create report if there are links to exceptions based on OSError on the stack because it tries to enumerate all it's attributes.

@bitdancer
Copy link
Member

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 :)

@zhangyangyu
Copy link
Member

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*.

@bitdancer
Copy link
Member

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.

@ezio-melotti ezio-melotti transferred this issue from another repository Apr 10, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
stdlib Python modules in the Lib dir type-bug An unexpected behavior, bug, or error
Projects
None yet
Development

No branches or pull requests

2 participants