Dear Python developers,
The help(list) shows in a python console the following documentation
string for the list.sort() method.
sort(self, /, *, key=None, reverse=False)
| Sort the list in ascending order and return None.
|
| The sort is in-place (i.e. the list itself is modified)
[Raymond Bisdorff ]
> ...
> Please notice the following inconsistency in Python3.10.0 and before of
> a sort(reverse=True) result:
>
> >>> L = [(1, 'a'), (2, 'b'), (1, 'c'), (2, 'd'), (3, 'e')]
> >>> L.sort(reverse=True)
> >>> L
> >>> [(3, 'e'), (2, 'd'), (2, 'b'), (1, 'c'), (1, 'a')]
Looks go
On 10/30/21 11:46 AM, Raymond Bisdorff wrote:
Dear Python developers,
The help(list) shows in a python console the following documentation
string for the list.sort() method.
sort(self, /, *, key=None, reverse=False)
| Sort the list in ascending order and return None.
|
| The sort
Hi,
On Sat, 30 Oct 2021 at 16:23, Raymond Bisdorff
wrote:
> >>> L = [(1, 'a'), (2, 'b'), (1, 'c'), (2, 'd'), (3, 'e')]
> >>> L.sort(reverse=True)
> >>> L
> >>> [(3, 'e'), (2, 'd'), (2, 'b'), (1, 'c'), (1, 'a')]
>
> it should be:
>
> >>> L = [(1, 'a'), (2, 'b'), (1, 'c'), (2, 'd'), (3, 'e')
Dear All,
I fully agree with your point. By default, all the components of the
tuple should be used in the comparison.
Yet, I was confused by the following result.
>>> from operator import itemgetter
>>> L = [(1, 'a'), (2, 'b'), (1, 'c'), (2, 'd'), (3, 'e')]
>>> L.sort(key=itemgetter(0), rever
[Raymond Bisdorff ]
> I fully agree with your point. By default, all the components of the
> tuple should be used in the comparison.
>
> Yet, I was confused by the following result.
> >>> from operator import itemgetter
> >>> L = [(1, 'a'), (2, 'b'), (1, 'c'), (2, 'd'), (3, 'e')]
> >>> L.sort(ke
You are re-assigning the list on line 4 here, not displaying it. I get
the answer you expect when using the `itemgetter(0)` key:
IPython 7.28.0, on CPython 3.9.7 (default, Aug 31 2021 13:28:12)
>>> import operator
>>> from operator import itemgetter
>>> L = [(1, 'a'), (2, 'b'), (1, 'c'), (2, 'd'
Dear All,
You are all completely right.
Sorry for the confusion.
Thank you all very much for putting my mind right about this issue.
Best Regards
Raymond Bisdorff
> On 30 Oct 2021, at 19:00, Tim Peters wrote:
>
> [Raymond Bisdorff ]
>> I fully agree with your point. By default, all the com
On 31/10/21 5:47 am, Raymond Bisdorff wrote:
Should the tuples comparison is in this case, I thought, not be solely
based on the first tuple component?
Whether you think it should or shouldn't, the fact is that it's not.
This is documented in Section 5.6 of the Library Reference:
"tuples and l
On Sun, Oct 31, 2021 at 01:32:29PM +1300, Greg Ewing wrote:
> On 31/10/21 5:47 am, Raymond Bisdorff wrote:
> >Should the tuples comparison is in this case, I thought, not be solely
> >based on the first tuple component?
>
> Whether you think it should or shouldn't, the fact is that it's not.
> Th
Greetings list,
I am going to start tinkering with the Python source again (on Linux)
I previously built the source etc using Visual Studio on Windows
Now the EFL ui libs re-ignited my passion for C while playing with
python-efl
And Chris last proposal made me want to re-play with the CPython code
11 matches
Mail list logo
