On Sun, May 10, 2020 at 12:48 PM Andrew Barnert <abarn...@yahoo.com> wrote:
> Is there any way you can fix the reply quoting on your mail client, or > manually work around it? > I'm trying -- sorry I've missed a few. It seems more and more "modern" email clients make "interspersed" posting really hard. But I hate bottom posting maybe even more than top posting :-( (gmail seems to have magically gotten worse in this regard recently) > If you don’t keep views around, because you’re only using them for more efficient one-shot iteration, you might never think about that, but then you’ll never notice it to be surprised by it. The dynamic behavior of dict views presumably hasn’t ever surprised you in the 12 years it’s worked that way. True -- though I the dict views aren't mappings themselves, and thus *maybe* less useful, but certainly less tempting to use where you might have otherwise used the original dict or a copy. But sure -- if you have to go out of your way to get it, then you should know what the implications are. > And you probably don't want to lock the "host" anyway -- that could be >> very confusing if the view is kept all be somewhere far from the code >> trying to change the sequence. >> > > Yes. I think memoryview’s locking behavior is a special case, not > something we’d want to emulate here. I’m guessing many people just never > use memoryview at all, but when you do, you’re generally thinking about raw > buffers rather than abstract behavior. (It’s right there in the name…) And > when you need something more featureful than an invisible hard lock on the > host, it’s time for numpy. :) > Yeah, memoryviews are a pretty special case, I don't think they are really intended to be used much in "user code" rather than libraries with pretty special cases. The docs explain it reasonably well. See > https://docs.python.org/3/glossary.html#term-dictionary-view for the > basic idea, https://docs.python.org/3/library/stdtypes.html#dict-views for > the details on the concrete types, and I think the relevant ABCs and data > model entries are linked from there. I was surprised to see that there are ABCs for the Mapping Views as well -- that does make it clear. The point of collections.abc.Set, and ABCs jn general, and the whole > concept of protocols, is that the set protocol can be implemented by > different concrete types—set, frozenset, dict_keys, third-party types like > sortedcontainers.SortedSet or pyobjc.Foundation.NSSet, etc.—that are > generally completely unrelated to each other, and implemented in different > ways—a > That I knew -- what surprised me was that the "standard" set methods aren't part of the ABC. It's also interesting to note (from another part of this thread) that slicing isn't part of the Sequence ABC, or any? "official" protocol? I do see this, though not entirely sure what to make of it: https://docs.python.org/3/c-api/sequence.html?highlight=sequence Anyway, a Sequence view is simpler, because it could probably simply be an immutable sequence -- not much need for contemplating every bit of the API. It’s really the same thing, it’s just the Sequence protocol rather than the Set protocol. Well, dict_keys is a set, and dict_items is *sometimes* a set, and dict_values is not a set (but is a Sized Collection). If anything, it’s _less_ simple, because for sequences you have to decide > whether indexing should work with negative indices, extended slices, etc., > which the protocol is silent about. But the answer there is pretty > easy—unless there’s a good reason not to support those things, you want to > support them. > Agreed -- Protocol or not, the point would be for a sequence_view to be as must like the built in sequences as possible. And as far as my motivation for all this goes -- getting that nifty slicing behavior is the main point! > (The only open question is when you’re designing a sequence that you > expect to be subclassed, but I don’t think we’re designing for subclassing > here.) > nope. I do see a possible objection here though. Making a small view of a large sequence would keep that sequence alive, which could be a memory issue. Which is one reason why slices don't do that by default. > But I don’t think it’s a problem for offering an alternative that people have to explicitly ask for. Probably not. > Also, notice that this is true for all of the existing views, and none of them try to be un-featureful to avoid it. But there is no full featured mapping-view that otherwise acts much like a mapping. in theory, there *could* be -- if there was some nice way to specify a subset of a mapping without copying the whole thing -- I can't think of one at the moment. But having a view that really does act like the original Ihtink makes ir more tempting to use more broadly. But again, you will have had to ask for it. And it could simply be a buyer beware issue. But the more featureful you make a view, the more likely it is that they will get used and passed around and kept alive without the programmer realizing the implications of that. > I think it is worth mentioning in the docs. Absolutely. Feel free to borrow whatever you want (and discard whatever you don’t want) > from the slices repo I posted. (It’s MIT-licensed, but I can relicense it > to remove the copyright notice if you want.) > great, thanks! > I think the biggest question is actually the API. Making this a function > (or a class that most people think of as a function, like most of > itertools) is easy, but as soon as you say it should be a method or > property of sequences, that’s trickier. You can add it to all the builtin > sequence types, but should other sequences in the stdlib have it? Should > Sequence provide it as a mixin? Should it be part of the sequence protocol, > and therefore checked by Sequence as an ABC (even though that could be a > breaking change)? > Here is where I think you (Andrew) and I (Chris B.) differ in our goals. My goal here is to have an easily accessible way to use the slice syntax to get an iterable that does not make a copy. While we're at it, getting a sequence view that can provide an iterator, and all sorts of other nifty features, is great. But making it a callable in itertools (or any other module) wouldn't accomplish that goal. Hmm, but maybe not that bad: for i in itertools.seq_view(a_list)[::2]: ... I still think I prefer this though: for i in a_list.view[::2]: ... So to all those questions: I say "yes" except maybe: "checked by Sequence as an ABC (even though that could be a breaking change)" -- because, well, breaking changes are "Not good". I wonder if there is a way to make something standard, but not quite break things -- hmm. For instance: It seems to be possible to have Sequence provide it as a mixin, but not have it checked by Sequence as an ABC? For instance, I note that the Mapping ABC has .keys, .items, .values, and there are ABCs for MappingViews, but I can't see if it's defined anywhere that the Mapping methods have to produce View objects. Maybe the only way to do this in a non-breaking way is to Add a new ViewableSequence ABC. Is there precedence here? Have any of the (Major) ABCs grown new features since they were introduced? I also can't find mixins that provide features that aren't part of the standard protocols -- but I haven't looked very hard, either. >> People know they’re lazy, they know iterators are lazy, so they think they’re a kind of iterator, and the docs don’t ever make it clear why that’s wrong. Right -- I think a lot of the confusion around the vocabulary is that people think of "iterators" as being "lazy", and the term gets used a lot when laziness is really the key point. (a lot of confusion like that around "generator" as well). Heck, I got it wrong just then, when I was trying to be careful. -Chris -- 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/PG2GXA6V4BW62HDZIZXQAOBKIHXB73PE/ Code of Conduct: http://python.org/psf/codeofconduct/
