I propose to restrict the type of __slots__.
-1 for adding a restriction. This breaks code for no good reason. This API has been around for a very long time. I've seen lists, tuples, dicts, single strings, and occasionally something more exotic. Why wreck stable code? Also, the inspect module will detect whether __slots__ is a dictionary and will use it to display docstrings. In the database world, data dictionaries have proven value, so it would be a bummer to kill off this functionality which is used in much the same way as docstrings for properties. It is still rarely used, but I'm hoping it will catch on (just like people are slowly growing more aware that they can add docstringa to fields in named tuples). Raymond On Fri, Mar 18, 2022 at 4:33 AM Serhiy Storchaka <storchaka@gmail.com> wrote:
Currently __slots__ can be either string or an iterable of strings.
1. If it is a string, it is a name of a single slot. Third-party code which iterates __slots__ will be confused.
2. If it is an iterable, it should emit names of slots. Note that non-reiterable iterators are accepted too, but it causes weird bugs if __slots__ is iterated more than once. For example it breaks default pickling and copying.
I propose to restrict the type of __slots__. Require it always been a tuple of strings. Most __slots__ in real code are tuples. It is rarely we need only single slot and set __slots__ as a string.
It will break some code (there are 2 occurrences in the stdlib an 1 in scripts), but that code can be easily fixed.
_______________________________________________ Python-Dev mailing list -- python-dev@python.org To unsubscribe send an email to python-dev-leave@python.org https://mail.python.org/mailman3/lists/python-dev.python.org/ Message archived at https://mail.python.org/archives/list/python-dev@python.org/message/E32BRLAW... Code of Conduct: http://python.org/psf/codeofconduct/