Short course: the average number of probes needed when searching
small dicts/sets can be reduced, in both successful ("found") and
failing ("not found") cases.
But I'm not going to pursue this. This is a brain dump for someone
who's willing to endure the interminable pain of arguing about
benchm
>
> And what about PEP544 (protocols), which is being drafted? The PEP seems
> to aim for having type objects that represent duck-typing
> protocols/interfaces. Checking whether a protocol is implemented by an
> object or type is clearly a useful thing to do at runtime, but it is not
> really clear
There has been some discussion here and there concerning the differences
between runtime types and static types (mypy etc.). What I write below is
not really an idea or proposal---just a perspective, or a topic that people
may want to discuss. Since the discussion on this is currently very fuzzy
an
On 24 June 2017 at 22:31, Greg Ewing wrote:
> Steven D'Aprano wrote:
>> I think we're over-generalizing this problem. There's two actual issues
>> here, and we shouldn't conflate them as the same problem:
>>
>> (1) People write buggy code based on invalid assumptions of what can and
>> can't raise
Steven D'Aprano wrote:
class X:
def __getitem__(self, n):
if n < 0:
n += len(self)
if not 0 <= n < len(self):
raise IndexError
...
class Y:
def __getitem__(self, n):
self._validate(n)
...
def _validate(self, n):
if n < 0
On Sat, Jun 24, 2017 at 01:02:55PM +1200, Greg Ewing wrote:
> In any case, this doesn't address the issue raised by the OP,
> which in this example is that if the implementation of
> bah.__getitem__ calls something else that raises an IndexError,
> there's no easy way to distinguish that from one
