On Wed, May 13, 2020 at 7:50 PM Andrew Barnert <abarn...@yahoo.com> wrote:
> On May 13, 2020, at 12:40, Christopher Barker <python...@gmail.com> wrote: > > I hope you don’t mind, but I’m going to take your reply out of order to > get the most important stuff first, in case anyone else is still reading. :) > And I'm going to keep this reply to one topic ... > Back to the Sequence View idea, I need to write this up properly, but I'm >> thinking something like: > > > Can we just say that it returns an immutable sequence that blah blah, > without defining or naming the type of that sequence? > > Sure -- but it ends up getting a lot more wordy if you dont' have a name for a thing. Python doesn’t define the types of most things you never construct directly. > No, but there are ABCs so that might e the way to talk about this. (Sometimes there is a public name for it buried away in the types module, > but it’s not mentioned anywhere else.) Even the dict view objects, which > need a whole docs section to describe them, never say what type they are. > fair enough. > And nobody even notices that list and tuple use the same type for their > __iter__ in some Python implementations but not others. > I sure haven't noticed that :-) > Similarly, I think dict.__iter__() used to return a different type from > dict.keys().__iter__() in CPython but now they share a type, and that > didn’t break any backward compatibility guarantees. > > And it seems there’s no reason you couldn’t use the same generic sequence > view type on all sequences, > Indeed, I was thinking that would be the way to prototype it anyway -- but yes, of course you would want to be able to write custom, optimized versions on some cases. Anyway -- yes, of course, this should all be Duck Typed / Protocol / API based, not any particular type. It's just hard to tak about that way -- kind of like the awkward "file-like object". > > slicing a list view returns ???? I'm not sure what here -- it should > probably be a copy, so a new list_view object refgerenceing the same list? > That will need to be thought out carefully) > > Good question. I suppose there are three choices: (1) a list (or, in > general, whatever the original object returns from slicing), (2) a new view > of the same list, or (3) a view of the view of the list. > > I think I agree with you here that (2) is the best option. In other words, > lst.view[2::2][1::3] gives you the exact same thing as lst.view[4::6]. > > At first that sounds weird because if you can inspect the attributes of > the view object, there’s way to see that you did a [1::3] anywhere. > > But that’s exactly the same thing that happens with, e.g,, > range(100)[2::2][1::3]. You just get range(4, 100, 6), and there’s no way > to see that you did a [1::3] anywhere. > I have NEVER thought to slice a range -- but it is kind of cool. > calling.view on a list_view is another trick -- does it reference the host view? or go straight back to the original sequence? > I think it’s the same answer again. In fact, I think .view on any slice view should just return self. Hmm -- this makes me nervous, but as long as its immutable, why not? Think about it: whether you decided that lst.view[2::2][1::3] gives > lst.view[4::6] or a nested view-of-a-view-of-a-list, it would be confusing > if lst.view[2::2].view[1::3] gave you the other one, and what other options > would make sense? And, unless there’s some other behavior besides slicing > on view properties, if self.view slices the same as self, it might as well > just be self. > exactly. > iter(a_list_view) returns a list_viewiterator. > > > Here, it seems even more useful to leave the type unspecified. For list > (and tuple) in CPython, > I agree -- I was using that name for convenience of talking about it, but that probably simply adds more confusion. > ... That all seems like quality-of-implementation stuff that should be > left open to whatever turns out to be best. > Exactly. See another reply for the " stuff that probably nobody else cares about: " -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/UCOPXXVRSOM7WSK2JRMPCYHR6XSXNQFC/ Code of Conduct: http://python.org/psf/codeofconduct/
