Having demonstrated my confusion about early breaks from loops, I will proceed to demonstrate my confusion about containers.
I have a queue-like class in which I implement __len__ but not __getitem__. Pylint complains:
timeddata.py:79: [R0924(incomplete-protocol), TimedDataQueue] Badly implemented Container, implements __len__ but not __getitem__
I can see where that would be a valid complaint for an array-like container, but not all containers should support indexing even if they have a measurable length. Python sets are one example:
s = set(range(10)) len(s)
10
s[0]
Traceback (most recent call last): File "<stdin>", line 1, in <module> TypeError: 'set' object does not support indexing
Queue-like containers seem similar. While I would allow access to the element at one end or the other (depending if I want queue-like or stack-like behavior), I think it would violate the definition of those types to allow indexing.
Should pylint really be this strict? Or am I expected to implement everything necessary for an array-like containiner and just raise exceptions in those methods the user really shouldn't access?
Thanks,
Skip
Hi Skip,
On 23 septembre 09:07, Skip Montanaro wrote:
Having demonstrated my confusion about early breaks from loops, I will proceed to demonstrate my confusion about containers.
:)
I have a queue-like class in which I implement __len__ but not __getitem__. Pylint complains:
timeddata.py:79: [R0924(incomplete-protocol), TimedDataQueue] Badly implemented Container, implements __len__ but not __getitem__
I can see where that would be a valid complaint for an array-like container, but not all containers should support indexing even if they have a measurable length. Python sets are one example:
s = set(range(10)) len(s)
10
s[0]
Traceback (most recent call last): File "<stdin>", line 1, in <module> TypeError: 'set' object does not support indexing
Queue-like containers seem similar. While I would allow access to the element at one end or the other (depending if I want queue-like or stack-like behavior), I think it would violate the definition of those types to allow indexing.
Should pylint really be this strict? Or am I expected to implement everything necessary for an array-like containiner and just raise exceptions in those methods the user really shouldn't access?
No I'ld say you're right. While it sounded a good idea when proposed, you're not the first one being confused by this message, so I tend to think this check should be either removed or kept for well defined and all-or-nothing protocols (the only one coming to my mind being the context manager __enter__ / __exit__, but there may be others). I would be glad to have others'opinion though.
Should pylint really be this strict? Or am I expected to implement everything necessary for an array-like containiner and just raise exceptions in those methods the user really shouldn't access?
No I'ld say you're right. While it sounded a good idea when proposed, you're not the first one being confused by this message, so I tend to think this check should be either removed or kept for well defined and all-or-nothing protocols (the only one coming to my mind being the context manager __enter__ / __exit__, but there may be others). I would be glad to have others'opinion though.
It occurs to me that the reverse case is likely still correct. That is, if __getitem__ is defined, omitting __len__ should happen only rarely, and probably require an explicit suppression somewhere, probably in the class definition.
Skip
On 23 September 2013 22:14, Skip Montanaro skip@pobox.com wrote:
Should pylint really be this strict? Or am I expected to implement everything necessary for an array-like containiner and just raise exceptions in those methods the user really shouldn't access?
No I'ld say you're right. While it sounded a good idea when proposed,
you're not
the first one being confused by this message, so I tend to think this
check
should be either removed or kept for well defined and all-or-nothing
protocols
(the only one coming to my mind being the context manager __enter__ /
__exit__,
but there may be others). I would be glad to have others'opinion though.
It occurs to me that the reverse case is likely still correct. That is, if __getitem__ is defined, omitting __len__ should happen only rarely, and probably require an explicit suppression somewhere, probably in the class definition.
Several times I've implemented classes with dynamic behaviour in __getitem__, so they have no strict length (beyond "theoretically infinite").
Michael
Skip _______________________________________________ code-quality mailing list code-quality@python.org https://mail.python.org/mailman/listinfo/code-quality
Several times I've implemented classes with dynamic behaviour in __getitem__, so they have no strict length (beyond "theoretically infinite").
Understood, and that's a case where I think you should suppress the warning. I believe the common case is that if you can get a particular item you can count all the items without an infloop or side effects.
Said another way, __getitem__ + __len__ is a much more common pattern than __getitem__ without __len__.
Skip
participants (3)
-
Michael Foord -
Skip Montanaro -
Sylvain Thénault