[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
On Sat, Mar 6, 2021 at 7:07 AM David Mertz wrote: > 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 > 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. > > The key thing is that it's very, very unlikely "research area of sorting algorithms" is going to beat Timsort. But maybe it is. Or maybe it is for some specialized kind of data collections that tend to come with some characteristic ascending or descending runs. Even assuming that is true, and some new algorithm is good for a specific case, it's not going to be especially fast once implemented in Python, even with the hypothetical "in-place reverse of a slice". Maybe it would be faster in C or another low-level language, but not on top of the Python interpreter. So this "research" is inherently doomed to fail UNLESS, you do the research not by actual raw timings, but rather in the sensible way of profiling the specific number of operations in an abstracted way. For that, existing "reversal of slice" techniques are perfectly fine to profile algorithms, but with things like internal counters of operations, not as actual machine timings. I was, however, a little curious, so timed a few related things: >>> a = list(range(1_000_000)) >>> %timeit a.reverse() 450 µs ± 16 µs per loop (mean ± std. dev. of 7 runs, 1000 loops each) >>> %timeit list(reversed(a)) 7.38 ms ± 149 µs per loop (mean ± std. dev. of 7 runs, 100 loops each) >>> %timeit a[:] = a[-1:0:-1] 14.1 ms ± 230 µs per loop (mean ± std. dev. of 7 runs, 100 loops each) >>> %timeit a[500_000:550_000] = a[550_000-1:500_000-1:-1] 240 µs ± 1.77 µs per loop (mean ± std. dev. of 7 runs, 1000 loops each) So indeed, list(reversed()) is more than 15x slower than list.reverse(). And assigning from a reverse slice is slower still by about 2x. However, assuming you only want to reverse a moderate amount in the middle of a large list, the time remains pretty moderate. In my example, 1/2 the time of reversing the entire list. Other than subclassing list per se, you could also write a Cython or C extension that merely provided extra operations on actual lists. Maybe call it `listtools` in the spirit of `itertools` and `functools`. Some external function like `reverse_middle(a, 500_000, 550_000)` isn't a terrible thing to experiment with. And in concept, that could be as fast as is theoretically possible. ___ 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/2XEG3YIPKSARXBH3ZIVZJGYKWI6QEDYD/ 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
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 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 >
[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] Re: Make list.reverse() more flexible
On Fri, Mar 05, 2021 at 04:27:27PM -, Vincent Cheong wrote: > 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). The space complexity of a list is not constant, O(1). The lists [] and [1]*10 do not take the same amount of space. I think that, perhaps, you are trying to say that reversing a list requires no additional storage and can be done in place. But having said that, I think that giving `list.reverse()` optional start and end parameters would probably be a simple and easy change to make, and would be backwards compatible. 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. 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.) 1. What are you doing that you need to reverse just a section of the list? 2. Is the performance (time or space) of this task so critical that you can't just use slicing? mylist[start:end] = mylist[end-1:start-1:-1] Some additional questions: - Do we extend this feature to the `reversed()` built-in? - What about sorting? -- Steve ___ 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/G7UYGVXJQV23L7IKJUQMJJB63OMXDBG5/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Add an __exclude_all__ complement to __all__
On Sat, Mar 6, 2021 at 9:47 AM Ethan Furman wrote: > > On 3/5/21 12:41 PM, Caleb Donovick wrote: > > > > > __all__ = (Class.__name__, func.__name__, ...) > > > > > > So I have to put it at the end of the module. I do this because if I > > > change the class or function name and I forget to change it in > > > __all__, I get an exception. > > > > I certainly will not claim to be the arbitrator of good and bad practices > > but that seems reasonable enough. > > > > It is worth pointing out that it's pretty easy to unit test `__all__` > > > > ``` > > # module/__init__.py > > __all__ = 'Foo', 'Bar' > > > > class Foo: pass > > ``` > > > > ``` > > # tests/test_imports.py > > def test_star(): > ># will raise `AttributeError: module 'module' has not attribute > > 'Bar'` > >from module import * > > ``` > > > > > from .a import * > > > from .b import * > > > > > __all__ = a.__all__ + b.__all__ > > > > Assuming you mean: > > ``` > > from . import a > > from . import b > > from .a import * > > from .b import * > > __all__ = a.__all__ + b.__all__ > > ``` > > Actually, Marko's version works, and is the same style used by asyncio. > Apparently, > >from .a import * > > also adds `a` to the module's namespace. > My guess is that that works only because the module is a package? ChrisA ___ 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/L5C4IES5MZMOPG6RUIHKZ4VLHEIMJAB4/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Add an __exclude_all__ complement to __all__
On 3/5/21 12:41 PM, Caleb Donovick wrote: > __all__ = (Class.__name__, func.__name__, ...) > > So I have to put it at the end of the module. I do this because if I > change the class or function name and I forget to change it in > __all__, I get an exception. I certainly will not claim to be the arbitrator of good and bad practices but that seems reasonable enough. It is worth pointing out that it's pretty easy to unit test `__all__` ``` # module/__init__.py __all__ = 'Foo', 'Bar' class Foo: pass ``` ``` # tests/test_imports.py def test_star(): # will raise `AttributeError: module 'module' has not attribute 'Bar'` from module import * ``` > from .a import * > from .b import * > __all__ = a.__all__ + b.__all__ Assuming you mean: ``` from . import a from . import b from .a import * from .b import * __all__ = a.__all__ + b.__all__ ``` Actually, Marko's version works, and is the same style used by asyncio. Apparently, from .a import * also adds `a` to the module's namespace. -- ~Ethan~ ___ 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/XIWHAUXPEO6U2ZYNUFGHQDQEROUDVWRK/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Add an __exclude_all__ complement to __all__
> __all__ = (Class.__name__, func.__name__, ...)
>
> So I have to put it at the end of the module. I do this because if I
> change the class or function name and I forget to change it in
> __all__, I get an exception.
I certainly will not claim to be the arbitrator of good and bad practices
but that seems reasonable enough.
It is worth pointing out that it's pretty easy to unit test `__all__`
```
# module/__init__.py
__all__ = 'Foo', 'Bar'
class Foo: pass
```
```
# tests/test_imports.py
def test_star():
# will raise `AttributeError: module 'module' has not attribute 'Bar'`
from module import *
```
> from .a import *
> from .b import *
> __all__ = a.__all__ + b.__all__
Assuming you mean:
```
from . import a
from . import b
from .a import *
from .b import *
__all__ = a.__all__ + b.__all__
```
It is fairly unnecessary if you aren't adding more names. but definitely
isn't harmful.
On Fri, Mar 5, 2021 at 12:11 PM Marco Sulla
wrote:
> On Wed, 3 Mar 2021 at 23:59, Brendan Barnwell
> wrote:
> > But usually you want to define it at the beginning as a sort of
> > documentation aid ("this is the public API").
>
> This is a little off-topic, but I'm curious, since usually, for public
> functions and classes, I do
>
> __all__ = (Class.__name__, func.__name__, ...)
>
> So I have to put it at the end of the module. I do this because if I
> change the class or function name and I forget to change it in
> __all__, I get an exception.
>
> Furthermore, if there's a module composed by submodules, I usually do
>
> from .a import *
> from .b import *
>
> __all__ = a.__all__ + b.__all__
>
> In your opinion, these are good or bad practices?
> ___
> 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/AZLCRXYWZUS63RDSAUEQ52SGRXGKY3KE/
> 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/QNSBH5DEG74AU6QC472HRQMWPNYMJY3W/
Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Add an __exclude_all__ complement to __all__
On Wed, 3 Mar 2021 at 23:59, Brendan Barnwell wrote:
> But usually you want to define it at the beginning as a sort of
> documentation aid ("this is the public API").
This is a little off-topic, but I'm curious, since usually, for public
functions and classes, I do
__all__ = (Class.__name__, func.__name__, ...)
So I have to put it at the end of the module. I do this because if I
change the class or function name and I forget to change it in
__all__, I get an exception.
Furthermore, if there's a module composed by submodules, I usually do
from .a import *
from .b import *
__all__ = a.__all__ + b.__all__
In your opinion, these are good or bad practices?
___
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/AZLCRXYWZUS63RDSAUEQ52SGRXGKY3KE/
Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Make list.reverse() more flexible
On 2021-03-05 at 16:27:27 -, Vincent Cheong wrote: > 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. Try this: def slice_reverse(the_list, start, stop): the_list[start:stop] = the_list[stop - 1, start - 1, -1] I'll defer on whether or not this deserves a place in the standard library; the older I get, the more I prefer building new data than mutating existing data. ___ 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/DWV7DH3H7MIWQXMI2A5C5GAW4CYLSNDI/ Code of Conduct: http://python.org/psf/codeofconduct/
[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/
