[Python-ideas] discontinue iterable strings

Michael Selik michael.selik at gmail.com
Sun Aug 21 02:56:11 EDT 2016


On Sun, Aug 21, 2016 at 2:53 AM Michael Selik <michael.selik at gmail.com>
wrote:

> On Sun, Aug 21, 2016 at 2:46 AM eryk sun <eryksun at gmail.com> wrote:
>
>> On Sun, Aug 21, 2016 at 6:34 AM, Michael Selik <michael.selik at gmail.com>
>> wrote:
>> > The detection of not hashable via __hash__ set to None was necessary,
>> but
>> > not desirable. Better to have never defined the method/attribute in the
>> > first place. Since __iter__ isn't present on ``object``, we're free to
>> use
>> > the better technique of not defining __iter__ rather than defining it as
>> > None, NotImplemented, etc. This is superior, because we don't want
>> __iter__
>> > to show up in a dir(), help(), or other tools.
>>
>> The point is to be able to define __getitem__ without falling back on
>> the sequence iterator.
>>
>> I wasn't aware of the recent commit that allows anti-registration of
>> __iter__. This is perfect:
>>
>>     >>> class C:
>>     ...     __iter__ = None
>>     ...     def __getitem__(self, index): return 42
>>     ...
>>    >>> iter(C())
>>     Traceback (most recent call last):
>>       File "<stdin>", line 1, in <module>
>>     TypeError: 'C' object is not iterable
>>     >>> isinstance(C(), collections.abc.Iterable)
>>     False
>>
>
> For that to make sense, Iterable should be a parent of C, or C should be a
> subclass of something registered as an Iterable. Otherwise it'd be creating
> a general recommendation to say ``__iter__ = None`` on every non-Iterable
> class, which would be silly.
>

I see your point for avoiding iterability when having __getitem__, but I
hope that's seen as an anti-pattern that reduces flexibility.

And I should learn to stop hitting the send button halfway through my email.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-ideas/attachments/20160821/ee1addef/attachment.html>


More information about the Python-ideas mailing list