a while ago on this list, we had a bit of discussion about having a sequence view.
It started with my more focused idea for a built in slice iterator, which I wrote up some time ago here: https://github.com/PythonCHB/islice-pep Then an even more expansive idea of a general purpose View was proposed. The conversation eventually petered out. Frankly, I didn't see a lot of use-cases at the time -- but now it seems that we have some more, and some more interest. For my part, I think a general purpose View object is far more compelling than adding add-hoc functionality to various methods. For example, he's the OP's suggestion with view semantics: view(a_list)[a_slice].reverse() Pretty nifty! See the discussion for why adding a method to the Sequence ABC is problematic: it could potentially clash with folks' existing methods for non-built-in sequences -- for instance, numpy arrays already have a .view method, and it has a different meaning (or at least necessarily different semantics). So a "view" builtin and maybe a new dunder may be the way to go. Anyway, perhaps it's time to revive the conversation. Here's the old thread --Please look that over before starting a new discussion! https://mail.python.org/archives/list/python-ideas@python.org/thread/QVTGZD6USSC34D4IJG76UPKZRXBBB4MM/#JCFTPY7U2T3QZGWRG7K4LOJ3XBIYRVZZ -CHB On Sun, Mar 7, 2021 at 5:04 AM Vincent Cheong <vincentcheong6...@gmail.com> wrote: > Interesting. Just to comment, Mr. Mertz is realistic in the algorithmic > sense. Running time is highly affected by various factors. For example, > lets just assume that an insertion sort of O(N^2) time on a quantum > computer is fast enough for all kinds of task in the world. So, naturally, > there should be no problem and we should instead focus on other projects > rather than making an O(N log N) sort for the quantum machine as its > unnecessary. But, you're N^2, it won't change the fact that you're > algorithmically inefficient. You, on the other hand, are realistic in the > developmental sense. Why spend time on this instead of other things, right? > I believe in 'depends-on-situation' and a balance between thinking about > project and about algorithm, because without this project we wouldn't even > be here, likewise without the algorithm we wouldn't reach here. > > This is for discussions-sake and should have no bearing on the main idea. > > Thanks for the input. > _______________________________________________ > 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/4PDBVLJPWU2B4XIGIC7IY4PYMSTTYXOP/ > Code of Conduct: http://python.org/psf/codeofconduct/ > -- Christopher Barker, PhD (Chris) 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/OFXY5HTQH4OGK7I3ZMI6J5JZJMPK52PS/ Code of Conduct: http://python.org/psf/codeofconduct/
