IMO this is a purism that have little, if any place in language restrictions.
I see that not allowing. "run once" iterables could indeed void attempts to write
"deliberatly non cooperative code" - but can it even be reliably detected? 

The other changes seem just to break backwards compatibility for little or no gain at all. 



On Fri, Mar 18, 2022 at 6:57 AM Ronald Oussoren via Python-Dev <python-dev@python.org> wrote:


On 18 Mar 2022, at 10:29, 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.

Pydoc supports __slots__ that is a dict, and will use the values in the dict als documentation for the slots.   I’ve also seen code using ``__slots__ =  “field1 field2”.split()``. I don’t particularly like this code pattern, but your proposal would break this.

Also note that __slots__ only has a side effect during class definition, changing it afterwards is possible but has no effect (“class Foo: pass; Foo.__slots__ = 42”). This surprised my recently and I have no idea if this feature is ever used.

Ronald


—

Twitter / micro.blog: @ronaldoussoren

_______________________________________________
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/YQUWR7CYKNM65HR5FZQ3BANR5SNNK6N6/
Code of Conduct: http://python.org/psf/codeofconduct/