| msg135365 - (view) |
Author: Daniel Holth (dholth) * |
Date: 2011-05-06 20:07 |
| "How much do we care about special method lookup?" Python recently bypasses __getattr__ entirely when looking up context managers. http://mail.python.org/pipermail/python-dev/2009-May/089535.html Could this be the reason that ZODB's transaction module, which attempts to be a context manager by declaring manager = ThreadTransactionManager() __enter__ = manager.get __exit__ = manager.__exit__ Does not work in Python 2.7.1 on Ubuntu 11.04 or RHEL5? Frustratingly, the exception is no more specific than an AttributeError, even though hasattr(transaction, '__exit__')? I would prefer to never get AttributeError: transaction.__exit__ when hasattr(transaction, '__exit__') as I find that to be very confusing. Maybe the interpreter could raise SpecialAttributeError('transaction.__exit__ is not sufficiently special') instead. http://svn.zope.org/repos/main/transaction/trunk/transaction/__init__.py |
|
|
| msg135388 - (view) |
Author: Benjamin Peterson (benjamin.peterson) *  |
Date: 2011-05-06 23:50 |
| Yes, that's why. I suggest you appeal to python-ideas about the new exception. |
|
|
| msg135484 - (view) |
Author: Daniel Holth (dholth) * |
Date: 2011-05-07 17:19 |
| Python should explain AttributeError in the same way when it's raised by the interpreter. The with: statement below should raise the second AttributeError, not the first. import transaction with transaction: pass >>> AttributeError: __exit__ import sys sys.__exit__ >>> AttributeError: 'module' object has no attribute '__exit__' |
|
|
| msg135491 - (view) |
Author: Daniel Holth (dholth) * |
Date: 2011-05-07 17:42 |
| Thank you Benjamin for following up on this issue |
|
|
| msg136640 - (view) |
Author: Éric Araujo (eric.araujo) * |
Date: 2011-05-23 14:09 |
| > hasattr(transaction, '__exit__') http://docs.python.org/dev/reference/datamodel#special-method-names explains that magic methods are looked up on the class, not on the instances. There’s a lot of code out there that erroneously checks for __len__ or __call__ on instances, and this is the second time to my knowledge that a project abused a module-level __enter__ function. |
|
|
| msg354977 - (view) |
Author: Serhiy Storchaka (serhiy.storchaka) * |
Date: 2019-10-19 21:38 |
| Would not be better to change an AttributeError to TypeError? Seems this is the only place in the core when missing special method causes an AttributeError and not TypeError. |
|
|
| msg396148 - (view) |
Author: Irit Katriel (iritkatriel) * |
Date: 2021-06-19 18:58 |
| I've reproduced this on 3.11 (though the AttributeError is now on __enter__ and not __exit__ as was the case in ): >>> import transaction >>> with transaction: pass ... Traceback (most recent call last): File "", line 1, in AttributeError: __enter__ >>> import sys >>> sys.__exit__ Traceback (most recent call last): File "", line 1, in AttributeError: module 'sys' has no attribute '__exit__' >>> |
|
|
| msg396165 - (view) |
Author: Serhiy Storchaka (serhiy.storchaka) * |
Date: 2021-06-20 08:23 |
| PR 26809 makes "with" and "async with" raising TypeError instead of AttributeError for wrong types. |
|
|
| msg396707 - (view) |
Author: Serhiy Storchaka (serhiy.storchaka) * |
Date: 2021-06-29 08:27 |
| New changeset 20a88004bae8ead66a205a125e1fe979376fc3ea by Serhiy Storchaka in branch 'main': bpo-12022: Change error type for bad objects in "with" and "async with" (GH-26809) https://github.com/python/cpython/commit/20a88004bae8ead66a205a125e1fe979376fc3ea |
|
|