[issue30772] If I make an attribute "
Nate Soares added the comment: To be clear, the trouble I was trying to point at is that if foo.py didn't have __all__, then it would still have a BB attribute. But if the module is given __all__, the BB is normalized away into a B. This seems like pretty strange/counterintuitive behavior. For instance, I found this bug when I added __all__ to a mathy library, where other modules had previously been happily importing BB and using .BB etc. with no trouble. In other words, I could accept "BB gets normalized to B always", but the current behavior is "modules are allowed to have a BB attribute but only if they don't use __all__, because __all__ requires putting the BB through a process that normalizes it to B, and which otherwise doesn't get run". If this is "working as intended" then w/e, I'll work around it, but I want to make sure that we all understand the inconsistency before letting this bug die in peace :-) On Wed, Jun 28, 2017 at 10:55 AM Brett Cannon <rep...@bugs.python.org> wrote: > > Changes by Brett Cannon <br...@python.org>: > > > -- > resolution: -> not a bug > stage: -> resolved > status: open -> closed > > ___ > Python tracker <rep...@bugs.python.org> > <http://bugs.python.org/issue30772> > ___ > -- title: If I make an attribute "[a unicode version of B]", it gets assigned to "[ascii B]", and so on. -> If I make an attribute " ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue30772> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue30772] If I make an attribute "[a unicode version of B]", it gets assigned to "[ascii B]", and so on.
New submission from Nate Soares: [NOTE: In this comment, I use BB to mean unicode character 0x1D539, b/c the issue tracker won't let me submit a comment with unicode characters in it.] Directory structure: repro/ foo.py test_foo.py Contents of foo.py: BB = 1 __all__ = ['BB'] Contents of test_foo.py: from .foo import * Error message: AttributeError: module 'repro.foo' has no attribute 'BB' If I change foo.py to have `__all__ = ['B']` (note that 'B' is not the same as 'BB'), then everything works "fine", modulo the fact that now foo.B is a thing and foo.BB is not a thing. [Recall that in the above, BB is a placeholder for U+1D539, which the issuetracker prevents me from writing here.] -- components: Unicode messages: 296928 nosy: Nate Soares, ezio.melotti, haypo priority: normal severity: normal status: open title: If I make an attribute "[a unicode version of B]", it gets assigned to "[ascii B]", and so on. versions: Python 3.6 ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue30772> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue29822] inspect.isabstract does not work on abstract base classes during __init_subclass__
Changes by Nate Soares <so8...@gmail.com>: -- pull_requests: +2045 ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue29822> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue29581] __init_subclass__ causes TypeError when used with standard library metaclasses (such as ABCMeta)
Changes by Nate Soares <so8...@gmail.com>: -- pull_requests: +1390 ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue29581> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue29822] inspect.isabstract does not work on abstract base classes during __init_subclass__
Nate Soares added the comment: I didn't know about issue29638, and I'm not sure whether my PR fixes it. Looking at that bug, I don't think that my PR would fix it, because I still trust TPFLAGS_IS_ABSTRACT when __abstractmethods__ exists. That said, I'm not clear on how the cache works, so it's possible that my PR would fix 29638. My issue appears when one uses py3.6's new __init_subclass__ hook with an ABC. __init_subclass__ is run by type.__new__, which means that, as of py3.6, users can (in a natural/reasonable way) inspect ABCMeta classes before ABCMeta.__new__ finishes executing. I didn't see any reasonable way to have ABCMeta.__new__ finish setting up the ABC before calling super().__new__, so I figured the fix should go into inspect.isabstract. But there may be better solutions I just didn't think of. -- ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue29822> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue29822] inspect.isabstract does not work on abstract base classes during __init_subclass__
Changes by Nate Soares <so8...@gmail.com>: -- pull_requests: +556 ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue29822> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue29822] inspect.isabstract does not work on abstract base classes during __init_subclass__
New submission from Nate Soares: Here's an example test that fails: def test_isabstract_during_init_subclass(self): from abc import ABCMeta, abstractmethod isabstract_checks = [] class AbstractChecker(metaclass=ABCMeta): def __init_subclass__(cls): abstract_checks.append(inspect.isabstract(cls)) class AbstractClassExample(AbstractChecker): @abstractmethod def foo(self): pass class ClassExample(AbstractClassExample): def foo(self): pass self.assertEqual(isabstract_checks, [True, False]) To run the test, you'll need to be on a version of python where bpo-29581 is fixed (e.g., a cpython branch with https://github.com/python/cpython/pull/527 merged) in order for __init_subclass__ to work with ABCMeta at all in the first place. I have a simple patch to inspect.isabstract that fixes this, and will make a PR shortly. -- messages: 289682 nosy: So8res priority: normal severity: normal status: open title: inspect.isabstract does not work on abstract base classes during __init_subclass__ versions: Python 3.7 ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue29822> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue29581] __init_subclass__ causes TypeError when used with standard library metaclasses (such as ABCMeta)
New submission from Nate Soares:
I believe I've found a bug (or, at least, critical shortcoming) in the way that
python 3.6's __init_subclass__ interacts with abc.ABCMeta (and, presumably,
most other metaclasses in the standard library). In short, if a class
subclasses both an abstract class and a class-that-uses-__init_subclass__, and
the __init_subclass__ uses keyword arguments, then this will often lead to
TypeErrors (because the metaclass gets confused by the keyword arguments to
__new__ that were meant for __init_subclass__).
Here's an example of the failure. This code:
from abc import ABCMeta
class Initifier:
def __init_subclass__(cls, x=None, **kwargs):
super().__init_subclass__(**kwargs)
print('got x', x)
class Abstracted(metaclass=ABCMeta):
pass
class Thingy(Abstracted, Initifier, x=1):
pass
thingy = Thingy()
raises this TypeError when run:
Traceback (most recent call last):
File "", line 10, in
class Thingy(Abstracted, Initifier, x=1):
TypeError: __new__() got an unexpected keyword argument 'x'
See
http://stackoverflow.com/questions/42281697/typeerror-when-combining-abcmeta-with-init-subclass-in-python-3-6
for further discussion.
--
messages: 287966
nosy: Nate Soares
priority: normal
severity: normal
status: open
title: __init_subclass__ causes TypeError when used with standard library
metaclasses (such as ABCMeta)
type: behavior
versions: Python 3.6
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/issue29581>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
