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
On Mon, Mar 8, 2021 at 1:24 AM Vincent Cheong wrote:
> 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
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
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
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
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
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
06.03.21 09:52, Vincent Cheong пише:
> 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
On Fri, Mar 5, 2021 at 3:23 PM Steven D'Aprano wrote:
> 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
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
On Sat, 6 Mar 2021 at 10:42, Vincent Cheong wrote:
>
> 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
>
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
On Sat, 6 Mar 2021 at 07:52, Vincent Cheong wrote:
>
> 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.
A few points strike me here:
1. The question you asked ("why do we
On Sat, Mar 06, 2021 at 07:46:18AM +, David Mertz wrote:
> 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.
Sorry, are you trying
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()
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
[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
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
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
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
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
21 matches
Mail list logo
