On Tue, Jul 28, 2020 at 10:26 PM Stephen J. Turnbull < turnbull.stephen...@u.tsukuba.ac.jp> wrote:
> Christopher Barker writes: > > from itertools import islice > > > > smaller_dict = dict(islice(large_dict.items(), 0, 255)) > > > > which works, and isn't doing any unnecessary copying, but it's pretty > > darn ugly, as far as I'm concerned. > > In your application, I think that's just pretty, myself. well, beauty is in the eye of the beholder, of course. But really, you think it's pretty to import itertools, then make a function call, for what's very much a slicing operation? Python has been shifting away from a sequence-focused to an iteration focused approach for a while -- and while I do see the benefits, I also see the drawbacks. And it seems to be coupled with what might be called a shift to a functional style This reminds me a bit of a thread on this list a couple years(?) back, about a built in "group by" operation. It petered out, but one point of disagreement was whether folks wanted an API that was more "functional", e.g. map-like, or comprehension based. Comprehensions are functional, and at least generator comprehensions (expressions) are all about iterables, but there is a different style as to whether you are more using expressions or passing functions around. I personally far prefer the comprehension style, but was surprised by how many folks prefered the "functional" style. This is not exactly the same, but it "feels" the similar to me -- I really prefer things like expressions and slice notation to a pile of nested function calls. Think about it -- if Python had started out being built around iterables, and itertools had been there from the beginning, would Sequences simply be iterables that happened to have a length? And would people be expressing that: itertools.islice(a_list, 0, 100, 2) was a pretty way to get a portion of a list -- why would we want "slicing" notation at all? That's being dramatic, but to bring this back around, the original title of this thread is:"Access (ordered) dict by ..." The point being that dicts are now ordered, so maybe it makes sense to add some operations that make it natural and easy to work with them in an ordered way -- you know, like slicing :-) I don't expect this to be accepted, folks didn't seem to like the idea much, and it's not a very big deal, as we've seen this is only the second use case anyone has come up with (the other being selecting a random item out of a dict). But it did strike me when I had the use-case. And I'm well aware of islice, and yet it still took me a LOT longer to write that code than it would have to do a slice :-) that's missing is slice notation. But that's probably not hard to > implement in terms of the islice function, just completely redundant. > I don't follow here -- the slice notation is very important here -- I'm not sure what you mean by "implement in terms of the islice function", but that does bring up another point: islice does not provide a way to do the equivalent of negative indexes -- because it's designed to work with iterables that don't have a length. But if you ARE using it on a Sequence -- that's a missing feature. -CHB -- Christopher Barker, PhD Python Language Consulting - Teaching - Scientific Software Development - Desktop GUI and Web Development - wxPython, numpy, scipy, Cython
_______________________________________________ Python-ideas mailing list -- python-ideas@python.org To unsubscribe send an email to python-ideas-le...@python.org https://mail.python.org/mailman3/lists/python-ideas.python.org/ Message archived at https://mail.python.org/archives/list/python-ideas@python.org/message/KAFHZT3A2UJVYPKJ5Y6Y7HAYFJZVMEO4/ Code of Conduct: http://python.org/psf/codeofconduct/
