On Nov 20, 3:09 pm, Terry Reedy <tjre...@udel.edu> wrote: > Use standard subscripting with slices, and only that, to both get and set.
i did this for __delitem__ too, so you can do e.g. del m[:'abc']. > In fact, to emphasize the symmetry of the bijective map, consider > disallowing m[key] as ambiguous and require m[key:] my initial feeling is that i'd prefer to be able to say m[key], the defense being that it's not ambiguous if it's documented, and users who don't like it don't have to use it, while users who do like it won't be alienated. but i am definitely still open to this. > Note that m[slice(1,2,3):] passes slice(slice(1, 2, 3), None, None), so > this approach does not even prevent using slices as keys/values. except slices aren't hashable.</nitpick> but props for even thinking of that! > In __setitem__, m[a:b] which passes slice(a,b,None) would have to be an > error. In __getitem__, it could either be a error or return True/False > depending on whether the pair is in the map. i went with raising an error for __getitem__(slice(a,b,None)). returning True/False for this usage based on whether a -> b is in the bijection is an interesting idea, but i feel like it complicates things for no good reason: if that's what you wanted to know you'd just ask whether m[a] == b. > But this depends on whether __contains__ only tests keys or is modified to > test pairs. i have __contains__ only testing keys, and similarly [i for i in bijection] only gives you the keys, again on the theory that deviating too much from the dict api increases the learning (adoption) curve, so i think we should only do it if it buys us a tremendous usability win. thanks again for your insightful input, i'm pretty psyched about how this is coming along! any further feedback is always welcome. josh -- http://mail.python.org/mailman/listinfo/python-list
