On May 13, 2020, at 20:32, Christopher Barker <pythonchb@gmail.com> wrote:
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.
You’re right. Looking at the dict and similar docs, what they mostly do is to talk about”the key view”, and sometimes even “the key view type”, etc., in plain English, while being careful not to say anything that implies it has any particular name or identity. (In particular, “key view type” obviously can’t be the name of an actual type, because it has a space in it.)
Anyway, if the proposal gets far enough to need docstrings and documentation, I guess you can worry about getting it right then, but until then you don’t have to be that careful; as long as we all know that list_view isn’t meant to name a specific type (and to be guaranteed distinct from tuple_view), I think we’ll all be fine.
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.
That’s a good point. Does a sequence slice view (or a more general sequence view?) need an ABC beyond just being a Sequence?
I wasn’t expecting that to be needed, but now that you bring it up… if there’s, say, a public attribute/property or method to get the underlying object, presumably it should be the same name on all such views, and maybe that’s something you’d want to be documented, and maybe even testable, by an ABC after all.
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 :-)
It’s actually a bit surprising what tuple and list share under the covers in CPython, even at the public C API level.
> 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?
Exactly. The same as these:
>>> s = ''.join(random.choices(string.ascii_lowercase, k=10))
>>> s[:] is s
True
>>> str.__new__(s) is s
True
>>> copy.copy(s) is s
True
>>> t = tuple(s)
>>> t[:] is t
True
etc.
But all of those are just allowed, and implemented that way by CPython, not guaranteed by the language. So maybe the same should be true here. You can implement .view as just self, but if other implementations want to do something different they can, as long as it meets the same documented behavior (which could just be something like “view-slicing a view slice has the same effect as slicing a view slice” or something?).