On Wed, May 13, 2020 at 7:50 PM Andrew Barnert <abarnert@yahoo.com> wrote:
On May 13, 2020, at 12:40, Christopher Barker <pythonchb@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