[issue46376] PyMapping_Check returns 1 for list
Ben Avrahami added the comment: IMHO, I don't think any alternative to aviramha's solution addresses the issue, And I don't think the need is niche enough to be ignored. PyType_HasFeature excludes strings, bytes, and other esoteric types. PyMapping_Check includes mappings like dict and MappingProxyType. PySequence_Check includes non-dict mappings like MappingProxyType. The only possible solutions right now are: a. Import the "collections.abc.Sequence" class into C and run "PyObject_IsInstance" on it. This would be the correct solution, but it would be slower than aviramha's propsal. b. Perform's aviramha's proposal manually: first check the "Py_TPFLAGS_SEQUENCE" feature flag, and fallback for instance checking strings, bytecodes, and other esoteric types individually. This would be correct and fast, but is cumbersome to perform, and users are bound to forget some types. A question as simple as "would isinstance(X, ) returns true?" should be easier to answer for low-level developer, one only needs to look at the finagling numpy, among others, has to perform to parse a sequence (the relevant function in numpy is called "PyArray_FromAny"). A simple implementation of a new function for non-CPython alternatives will be to do implement solution a: import "collections.abc.Sequence", and check for instance. For CPYTHON, this can be optimized by implementing solution b. There is already a precedence for ABI functions that only exist because its trivial implementation can be optimized with CPython specific behaviour. I don't understand the reluctance to add this one. -- nosy: +avrahami.ben ___ Python tracker <https://bugs.python.org/issue46376> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue44695] asdict use deep copy to dataclass instances
Change by Ben Avrahami : -- nosy: +avrahami.ben ___ Python tracker <https://bugs.python.org/issue44695> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue36517] typing.NamedTuple does not support mixins
Ben Avrahami added the comment: The patch PR blocks out a useful idiom: generic Nametuple >>> class LLNode(NamedTuple, Generic[T]): ... value :T ... next: Optional[LLNode[T]] I put forward that, at the least, NamedTuple should accept do-nothing bases like Generic. -- nosy: +avrahami.ben ___ Python tracker <https://bugs.python.org/issue36517> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue42088] types.SimpleNamespace.__repr__ documentation inconsistency
New submission from Ben Avrahami : According to the documentation for types.SimpleNamespace, `repr(SimpleNamespace())` should return `"SimpleNamespace()"`, but in actuality returns `"namespace()"`. This is because SimpleNamespace is an alias for the C implemented type `_PyNamespaceObject`. Interestingly, `_PyNamespaceObject` names itself `"types.SimpleNamespace"`. This has the obvious issue of the documentation being wrong, but also the (perhaps less interesting issue) of `eval(repr(SimpleNamespace))` resulting in a NameError. I propose that `_PyNamespaceObject`'s __repr__ method be changed to return `"SimpleNamespace()"`. This would require only the change of a constant in one line (currently this is line 75 on namespaceobject.c). A smaller fix would be to change the documentation to correctly reflect this behavior. -- components: Library (Lib) messages: 379010 nosy: avrahami.ben priority: normal severity: normal status: open title: types.SimpleNamespace.__repr__ documentation inconsistency versions: Python 3.10 ___ Python tracker <https://bugs.python.org/issue42088> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue41905] add update_abstractmethods function to update an ABC's abstract methods
Ben Avrahami added the comment: > Adding a function to recalculate will require everyone to use it I'd argue that this is akin to `functools.update_wrapper`. It too is a function that must be called in virtually every function decorator (the only function decorators that don't/needn't call it are the built-in method decorators and, appropriately enough, @abstractmethod), and if not called, certain functionality won't work. > and worse, know that it even exists I think that knowing about such a function is a fair requirement. Mixin tools already has nuances and edge cases, such that it should only be done (and especially distributed) by advanced users. Furthermore, not all class mixin tools have/need to be ABC-aware. Just as `total_ordering` is ABC-agnostic (indeed, it is also subclass-agnostic), any other mixin tool can decide that implementing abstract classes is simply not a use case for them. The upshot of the `update_abstractmethods` implementation is that, as long as their implementation isn't afraid to override methods that are already defined (like attrs does), the function can be slotted above ABC-agnostic wrappers and it suddenly becomes ABC-aware. -- ___ Python tracker <https://bugs.python.org/issue41905> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue41905] add update_abstractmethods function to update an ABC's abstract methods
Ben Avrahami added the comment: Implementing this behavior automatically would be more complicated since you would also have to take subclasses into account. Current implementation enforces that the class is unused (as much as can be reasonably done) when its abstraction status is re-calculated, such checks cannot be done in an automatic implementation. The question becomes whether or not we think its reasonable that an abstract class would change its abstraction status throughout its lifetime. I'd argue "not implicitly". -- ___ Python tracker <https://bugs.python.org/issue41905> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue41905] add update_abstractmethods function to update an ABC's abstract methods
Ben Avrahami added the comment: > Maybe you misunderstand what I tried to say? Possibly, right now, total_ordering avoids overriding any method that is declared, either in the class or its superclasses (except for object), regardless of whether or not it is abstract. For it to be ABC-aware, it would need the ability to override abstract methods defined in superclasses, so we need to check whether an exisitng method is abstract. Additionally we want to not override abstract methods defined in the subject class, so we also need to check whether the method is defined in the class __dict__ (that's the extra logic I was referring to). An argument could be made that total_ordering should override any method not defined in the subject class, abstract or no (implementing this logic would also speed up total_ordering, but that's beside the point). Is this what you meant? -- ___ Python tracker <https://bugs.python.org/issue41905> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue41905] add update_abstractmethods function to update an ABC's abstract methods
Ben Avrahami added the comment: > I would prefer the isinstance(cls, ABCMeta) check to be inside that helper I had a little debate about this in my mind, I'll change it. > it's totally clear to me what @total_ordering should do -- it should define > __le__, __gt__ and __ge__ in terms of __lt__, and leave __lt__ alone, for > some subclass to implement. Implementing this logic would require more than two lines. I will add it to the PR. -- ___ Python tracker <https://bugs.python.org/issue41905> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue41905] add update_abstractmethods function to update an ABC's abstract methods
Ben Avrahami added the comment: This is a behavior that the PR changes. total_ordering should be able to override/implement abstract methods (in my opinion). If this ends up a strickling point then we can exclude total_ordering from this issue. Regardless, I think that this behavior is extremely unintuitive. -- ___ Python tracker <https://bugs.python.org/issue41905> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue41905] add update_abstractmethods function to update an ABC's abstract methods
Ben Avrahami added the comment: Good points all, that I will try to address one by one: Firstly, this function is by no means mandatory for "post-creation mixins". Such tools can still be used without calling it (and remain ABC unaware), with absolutely no change in functionality. Indeed, the function itself can be used as a decorator for just such cases, where a tool is ABC unaware (either from deciding that ABC aren't a use case for them, or from simply not considering that possibility), but the user wants to also subclass an ABC. The problem is that, right now, post-creation tools simply can't be ABC aware. The thought that few tools are ABC aware is not, I think, a good reason to neglect tools that would like to be. Just as dispatch and type-routing tools might not be ABC aware to use `abc.get_cache_token()`, but it is still added for tools that want to be ABC aware and sidestep this confusing behavior. As for not occurring in practice: a simple github search reveals many instances of comparison operators being abstract, and while likely few of them likely use dataclasses, that is a possibility that I believe should be addressed (of course, we could decide that this is desired behavior, and scrap this whole issue). Finally, total_ordering: I originally added it to the issue because it was the other decorator mixin in the standard library, after I rand into this behavior using dataclasses. If total_ordering proves to be a barrier, we can remove it from the PR (and perhaps re-introduce it later if that is deemed necessary). I will only remark that I find total_ordering used in many hand-rolled classes where users would sacrifice some performance for cleaner code and an assertion that total order is enforced. Sorry for the scroll and thanks for the scrutiny :-) -- ___ Python tracker <https://bugs.python.org/issue41905> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue41905] add update_abstractmethods function to update an ABC's abstract methods
Ben Avrahami added the comment: for the functionality to work, `total_ordering` needs to change to also override abstract methods. I believe this is an OK change since total_ordering implicitly dictates that the comparison methods are interchangable. Thus, implementing some comparison operators, but leaving others unchanged is undesired behaviour. -- ___ Python tracker <https://bugs.python.org/issue41905> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue41905] add update_abstractmethods function to update an ABC's abstract methods
New submission from Ben Avrahami : python-ideas discussion: https://mail.python.org/archives/list/python-id...@python.org/thread/6BNJ3YSEBPHEPGXSAZGBW3TJ64ZGZIHE/ In order to allow "decorator mixins" (most notably dataclass and total_ordering) to implement ABCs, new functionality is needed. I propose a new python function in `abc.py` called `update_abstractmethods`. The function will accept a class and, if the class is an instance of ABCMeta, will update the class's `__abstractmethods__` attribute to not include implemented attributes, and to include new abstractmethods (proposed implementation in thread). Both dataclass and total_ordering will be modified to call this function on the subject class before returning it, and 3rd-party libraries which implement mixin decorators (like attrs) will be to do the same. Also, the function can be used as a decorator individually, this is especially useful in cases where 3rd party decorators do not call the function. -- components: Library (Lib) messages: 377769 nosy: avrahami.ben priority: normal severity: normal status: open title: add update_abstractmethods function to update an ABC's abstract methods type: enhancement versions: Python 3.10 ___ Python tracker <https://bugs.python.org/issue41905> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
