Inaccessible attribute characters_written on OSError instances

[IgorKozyrenkoikseek]

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]

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

[zhangyangyu]

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]

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]

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]

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]

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.