[Python-ideas] Re: Make list.reverse() more flexible
Indeed, from previous replies, I have already learnt that use-cases are the primary driver here around. In fact that should be the general case. I do admit that my assessment is too abstractive for any feasible considerations. I was looking at it from the algorithmic sense, that if a function is performant then a handful if not many problems, discovered or undiscovered, would have been avoided through efficiency. For a little instance, we have the efficient BWT algorithm, life before it was normal and progressing, but with it data compression improved. It wasn't needed, but with it we improved. This is just the line of thought, hehe. Just for comment, now that you have outlined a more conditioned judgement as to how good an idea is, I would like to say that it does improve performance - maybe a little bit of time, but space is a sure. Does it improve coding, well, if the notations remain the same, then no change, if a different semantic is introduced, then it depends. Useful - ah, relates to above, relates to what many have already from before. The Zen is the wisest: since practicality beats purity, a function is only worth used when its code-friendly and readable, which points out that it heavily depends on the semantics we come up with. I think how useful it is realistically how simple it is to read it and code it. I guess it's just semantics! Thanks for the feedback! ___ 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/BJX77YQ3QJWHN4PFKEATD5MBHCHXWSAL/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Make list.reverse() more flexible
Indeed, making a slice a view does pose painful challenges. For a slice iterator, I wonder if there is an bigger overhead in being an iterator or building an iterator. I wholeheartedly agree that 'adding add-hoc functionality' is slightly toy-ish, but I brought up the idea of 'start' and 'stop' parameters because I believed that mentioning just these two things themselves are humbly adequately below that 'troublesome' or 'complex' line. Yes, Numpy's slice is a view and that is memory efficient. Memory_view, lazy_slice, View_object, and other terms, quite an expansive room of considerations. For discussions-sake, I would like to comment about: '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.'. Indeed, if one puts on a perspective glasses of 'use-cases', it's obvious that there is no urgency, no real-time necessity for that. We can see that there is growing interest, but just my opinion, the more deserving point is that it exhibits intelligence and power. Intelligence because a users gets to choose what to do with that sublist 'before' it takes memory - it's intelligent not to use resources unless explicitly told to, like a generator. Power because if I can 'specify' that section of a list without making a copy, I'm effectively achieving the same thing as many would using for-loop + range() + indices. It has that tiny little conceptual resemblance to how reversed() being much better than for-loop + range() + negative_indices, when iterating backwards. I'm schooled by how there was a history archive on this. Thanks for the links. 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/AJNG4C6QJ372HO3UKVT63HJXAPFKWX6P/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: OT: Make list.reverse() more flexible
Depends on the implementation. If you, instead of swapping pair by pair one by one, rewrite that sequence in the opposite direction and that sequence is longer than 3, it already fits the situation. A block swap algorithm swaps two elements of an array. If out-of-place, you can specify more than 3 items, and you would have been doing that. Thanks. ___ 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/BPF7DCQIRCGP37LIZ3J5S2WC4QEULY3G/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Make list.reverse() more flexible
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/
[Python-ideas] Re: Make list.reverse() more flexible
Indeed, it's not directly related, perhaps misunderstanding, but I'm just drawing the similar idea between the two situations of not taking memory first. If you slice, you make a copy and that takes space. So, the space complexity is no longer O(1). It's just that, not that it has any direct relation to map() function. Perhaps a generator is a better analogy to use in the first place because a generator does not make a whole list first, it does not take up as much space upon creation. Thanks for the feedback. ___ 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/YWAX5T5EUXT4LFOPEQDA5IVSKXHYT3UV/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Make list.reverse() more flexible
Insightful! You mentioned terms like 'memory_view', and 'lazy slice'. You felt the pulse of the situation. But the most elegant thing (I had it a long time ago but you brought it up before, haha) is that you notice the downside of copies - you indicated how a lazy slice is the magic wand that eliminates the problem. I have thought of making slices 'lazy' as a solution which conveniently and smoothly avoids the need for a 'start' and 'stop' parameter, but I could not bring myself to float that idea up here because I already had a hunch that it is, simply said, too much to ask for, too bizarre to talk about. A slice that acts a 'view' rather than a 'copy' shares the same lazy idea as like generators yielding items only when needed and map() returns an 'slim' iterator rather than a 'bulky' list. It's like a slogan that says: 'Do only if necessary'. It gives the flexibility of what to do with the slice, not always taking up memory first. That would be intelligent, in a way. 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/B4ZYSPQNN4S3OJ5YBAUX7D6IW3HZKSX7/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Make list.reverse() more flexible
Indeed, I understand. Thanks for reply. ___ 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/7BV6V22RXD4HPAJAHQWDKWVGWJHUZMRJ/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Make list.reverse() more flexible
I see. You have coined the term exactly, partial-reverse. Nice. You have also put forward a realistic question of 'why do we need'. Well, surely not everyone needs it and definitely it's not urgently needed, but its just the counterintuitive incompleteness such that 'it works for a whole, but not part of it', you see. About the gain, of course it's unlike a monumental speed boost, but its just a little spot that I saw lacking in power. What I had in mind was the algorithmic cost to the program itself, not the cost in developing it. But now that you explained to me, I understand the situation. Thanks for the information. ___ 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/XEVRJMJ7V7MMGIJGH6LKGFZ77DKI2HBI/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Make list.reverse() more flexible
I see. I do agree that my reply brings about that 'verbose repeated' feeling, haha. But for the record, it's not about having something in hand now for the future, but it's more of a paradigmatic approach to the implementation. Python has changed for the better in terms of necessity: - map() returns an iterator instead of a whole list at once - generator yields values only when needed (unlike list comprehension) So I thought, 'Why do we need to make a reversed copy to assign it to the original part, when we can simply reverse the original part itself.' That's the paradigm. Anyway, thanks. ___ 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/NZJ47PKWW7GR37ADVR4U3PIJLAZCYZDB/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Make list.reverse() more flexible
[This is the revised version of the previous reply which contained mistakes] 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 just 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 just 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 the i ssue 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] Re: Make list.reverse() more flexible
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] Make list.reverse() more flexible
Currently, list.reverse() only works for an entire list. If one wants to reverse a section of it 'in-place', one needs to slicing which makes the space complexity no longer O(1). One can also manually make a loop and do the reversal but that is even slower than slicing. List.reverse() does not take any arguments. Wouldn't it be a good if it can take in parameters such as 'start' and 'stop' to enable list.reverse() work even for a section of the list? When no arguments are specified, then it works on the whole list, like usual. ___ 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/SQJE27YTHQC6PBL5RLZY4ULKEYQ32YYX/ Code of Conduct: http://python.org/psf/codeofconduct/
