This sounds like a very verbose repeated statement that "there may be a use in the future." That's definitely not going to get a feature, no matter how many times repeated.
If this is something you actually need, write a subclass of list in Cython or C, and add that capability. I cannot think of a time I would have used it in the last 23 years, but maybe someone would. Put it on PyPI and explain why it helps something. On Sat, Mar 6, 2021, 1:42 AM Vincent Cheong <vincentcheong6...@gmail.com> wrote: > Sorry for not explaining the background of my idea. I'm involved in the > research area of sorting algorithms. Reversals are part of sorting and > correct me if wrong, `list.reverse()` is the fastest method to reverse an > entire list, which is also in-place. Yet, it doesn't work for a subsection > of it. If not mistaken, the easiest way is to reassign that subsection with > a reversed slicing, One, it is not as fast anymore. Two, by time > complexity, the algorithm is no longer in-place because of the slicing. > Thus, this is the entire story. > > > I think that, perhaps, you are trying to say that reversing a list > requires no additional storage and can be done in place. > > >>> Yes! This is what I meant. > > > > To balance those costs, we require something more than "Wouldn't it be > good...?", we require an actual, real life use-case for > the feature. (And even then, it's not a guarantee that we will accept the > proposed feature.) > > >>> I try not to enter into details and technicalities. I try to help by > proposing ideas, abstract thoughts, and visions. Anyways, there are many > things we do that involve reversals and subsection reversals - it's not an > uncommon thing to do. Thus, it will help. It's better to shape this > perspective: with the proposed idea, Python gains more power, and along the > way, when the time comes we need it, we already have it. For the short term > or time being, normal reversal tasks would be the first to benefit. > > > But even easy changes have some cost: the work has to be done, tests > written and run, documentation updated, and that adds one more thing for > people to learn. > >>>This is my assessment: list.reverse() lacks functionality because it > only works for whole lists. Once any intention goes out of the radius of > the stated purpose, it becomes completely unusable. So we should agree that > it lacks functionality and versatility. This is unworthy and Python should > be more powerful than this. Noticing that it takes no arguments, it has > room for improvement where we can conveniently add 'start' and 'end' > parameters. Those mentioned costs I believe are part of daily development > hassles, but I would like to comment more on the 'adds one more thing for > people to learn'. Assuming that we do add the two parameters, I would > foresee as just an 'upgraded version' of the function and the changes are > as simple as 'Now, list.reverse() can take in two arguments which allows us > to reverse a specific range in the list, not the complete list.' Therefore, > it will not pose a heavy stuff for learning. It should be a situation where > people will be like, for experienced, 'Oh > , now list.reverse() works on a specific range instead of the entire > list', and for newcomers, 'Oh, list.reverse() can work on specific ranges > too.' > > > >Some additional questions: > > Do we extend this feature to the reversed() built-in? > > What about sorting? > > >>> Interesting. The second one is mainly my lack of explanation which I > have cleared at the top. For the first one, I have not given much thought > about it since it performs quite differently, hence a quite different > territory, but it is interesting to explore. It returns an iterator for any > given sequence, if I'm not mistaken. Reversed is used when we need to do > something more to each item, in the opposite direction. It's usually used > in a loop, list comprehension, etc. It can also be used to make a reversed > list by putting it into the list constructor but then you have slicing more > suitably for that. Back to the first functionality, we would usually > traverse an entire list, and if one needs to traverse only a section of it, > we would be passing in a slice (which already creates a copy of it, correct > me if wrong). So, issues still tend to revolve around slicing and its > copy-making behavior. I understand that we are encouraged to avoid mutating > existing data, but that also brings in t > he issue of necessity - must we always make a copy of something? There > are quite a number of things we do which traverse sections of lists, so by > adding the two arguments, we are giving reversed() an in-place capability. > On one hand, this allows us to save memory for larger and larger lists. On > the other hand, it seems unnecessary because we can also use range() and > indices within reversed() to traverse a section, but then that would be > unclean as compared to having simply declare a 'start' and 'stop'. Here in > reversed(), the proposal may not have much of a position of strength for > consideration, compared to list.reverse(), but it is worth weighing how > simpler, cleaner or better iterators are having 'start' and 'stop' > arguments. You have extra flexibility but is it worth it; that would be > better answered with more assessments by a wider range of audience. > _______________________________________________ > 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/NAH2RRPDQ3F3AO3UBJEL3BTSDAQ3CQXO/ > Code of Conduct: http://python.org/psf/codeofconduct/ >
_______________________________________________ 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/H7TN4ZQF5VGDPYAPGMWSTD2VMJT4I6Z4/ Code of Conduct: http://python.org/psf/codeofconduct/
