On May 15, 2020, at 18:21, Christopher Barker <python...@gmail.com> wrote:
>
> Hmm, more thought needed.
Speaking of “more thought needed”, I took a first pass over cleaning up my
quick&dirty slice view class and adding the slicer class, and found some
bikesheddable options. I think in most cases the best answer is obvious, but
I’ve been wrong before. :)
Assume s and t are Sequences of the same type, u is a Sequence or a different
type, and vs, vt, and vu are view slices on those sequences. Also assume that
we called the view slicer type vslice, and the view slice type SliceView,
although obviously those are up for bikeshedding.
When s==t is allowed, is vs==vt? What about vs==t? Same for <, etc.? I think
yes, yes, yes.
When s is hashable, is vs hashable? If so, is it the same hash an equivalent
copy-slice would have? The answer to == constrains the answer here, of course.
I think they can just not be hashable, but it’s a bit weird to have an
immutable builtin sequence that isn’t. (Maybe hash could be left out but then
added in a future version if there’s a need?)
When s+t is allowed, is vs+t? vs+vt? (Similarly when s+u is allowed, but that
usually isn’t.) vs*3? I think all yes, but I’m not sure. (Imagine you create a
million view slices but filter them down to just 2, and then concatenate those
two. That makes sense, I think.)
Should there be a way to ask vs for the corresponding regular copy slice? Like
vslice(s)[10:].strictify() == s[10:]? I’m not sure what it’s good for, but
either __hash__ or __add__ seems to imply a private method for this, and then I
can’t see any reason to prevent people from calling it. (Except that I can’t
think of a good name.)
Should the underlying sequence be a public attribute? It seems easy and
harmless and potentially useful, and memoryview has .obj (although dict views
don’t have a public reference to the dict).
What about the original slice object? This seems less useful, since you don’t
pass around slice objects that often. And we may not actually be storing it.
(The simplest solution is to store slice.indices(len(seq)) instead of slice.)
So I think no.
If s isn’t a Sequence, should vslice(s) be a TypeError. I think we want the C
API sequence check, but not the full ABC check.
What does vslice(s)[1] do? I think TyoeError('not a slice').
Does the vslice type need any other methods besides __new__ and __getitem__? I
don’t think so. The only use for vslice(s) besides slicing it is stashing it to
be sliced later, just like the only use for a method besides calling it is
stashing it to be called later. But it should have the sequence as a public
attribute for debugging/introspection, just like methods make their self and
function attributes public.
Is the SliceView type public? (Only in types?) Or is “what the vslice slicer
factory creates” an implementation detail, like list_iter. I think the latter.
What’s the repr for a SliceView? Something like vslice([1, 2, 10, 20])[::2]
seems most useful, since that’s the way you construct it, even if it is a bit
unusual. Although a tiny slice of a giant sequence would then have a giant repr.
What’s the str? I think same as the repr, but will people expect a view of a
list/tuple/etc. to look “nice” like list/tuple/etc. do?
Does vs[:] return self? (And, presumably, vs[0:len(s)+100] and so on.) I think
so, but that doesn’t need to be guaranteed (just like tuple, range, etc.).
If vs is an instance of a subclass of SliceView, is vs[10:20] a SliceView, or
an instance of the subclass? I think the base class, just like tuple, etc.
_______________________________________________
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/X45QVVPMB5JOQDKI7OEV4JAQ7WMA4XHO/
Code of Conduct: http://python.org/psf/codeofconduct/
