Let's make it so.
On Sat, Jun 23, 2018, 08:53 Terry Reedy wrote:
> On 6/23/2018 4:54 AM, Serhiy Storchaka wrote:
> > 23.06.18 10:27, Jeroen Demeyer пише:
> >> On 2018-06-23 03:50, Steven D'Aprano wrote:
> >>> I think it is more important that builtin methods and Python methods
> >>> behave the s
On 6/23/2018 4:54 AM, Serhiy Storchaka wrote:
23.06.18 10:27, Jeroen Demeyer пише:
On 2018-06-23 03:50, Steven D'Aprano wrote:
I think it is more important that builtin methods and Python methods
behave the same.
+1
This inconsistency is the *real* problem here. It's one little extra
compli
Hi,
On 23 June 2018 at 10:54, Serhiy Storchaka wrote:
> +1 too. But I think the right solution should be opposite: reverting
> issue1350060 changes and making all methods equality be based on the
> identity of __self__.
The arguments in this thread are the kind of discussion I was looking
for wh
23.06.18 10:27, Jeroen Demeyer пише:
On 2018-06-23 03:50, Steven D'Aprano wrote:
I think it is more important that builtin methods and Python methods
behave the same.
+1
This inconsistency is the *real* problem here. It's one little extra
complication to merging those classes (which was prop
On 2018-06-23 03:50, Steven D'Aprano wrote:
I think it is more important that builtin methods and Python methods
behave the same.
+1
This inconsistency is the *real* problem here. It's one little extra
complication to merging those classes (which was proposed in PEP 575,
576 and 579).
_
23.06.18 05:21, Guido van Rossum пише:
A bound method is a fairly complicated object, and for builtin bound
methods, the == comparison has the following definition:
- if the `__self__` objects are not the same object, return False
- otherwise, return True iff it's the same method (i.e. the same
On Fri, Jun 22, 2018 at 6:52 PM Steven D'Aprano wrote:
> On Fri, Jun 22, 2018 at 11:44:07AM -0700, Guido van Rossum wrote:
> [...]
> > > I know why it happens -- at the REPL, the interpreter uses the same
> > > object for both 17.1 instances when they're part of the same statement,
> > > but not
On Fri, Jun 22, 2018 at 11:44:07AM -0700, Guido van Rossum wrote:
[...]
> > I know why it happens -- at the REPL, the interpreter uses the same
> > object for both 17.1 instances when they're part of the same statement,
> > but not when they're on separate lines. I just don't know whether this
> >
On Fri, Jun 22, 2018 at 9:43 AM Steven D'Aprano wrote:
> On Fri, Jun 22, 2018 at 08:13:44AM -0700, Guido van Rossum wrote:
>
> > Honestly it looks to me like the status quo is perfect.
>
> Does this example work for you?
>
> py> (17.1).hex == (17.1).hex
> True
>
> But:
>
> py> a = 17.1
> py> b =
On 22.06.2018 19:41, Steven D'Aprano wrote:
On Fri, Jun 22, 2018 at 08:13:44AM -0700, Guido van Rossum wrote:
Honestly it looks to me like the status quo is perfect.
Does this example work for you?
py> (17.1).hex == (17.1).hex
True
But:
py> a = 17.1
py> b = 17.1
py> a.hex == b.hex
False
I
On Fri, Jun 22, 2018 at 08:13:44AM -0700, Guido van Rossum wrote:
> Honestly it looks to me like the status quo is perfect.
Does this example work for you?
py> (17.1).hex == (17.1).hex
True
But:
py> a = 17.1
py> b = 17.1
py> a.hex == b.hex
False
I know why it happens -- at the REPL, the inter
Honestly it looks to me like the status quo is perfect.
>>> a = []
>>> a.append is a.append
False
>>> a.append == a.append
True
>>> b = []
>>> a.append == b.append
False
>>>
On Thu, Jun 21, 2018 at 10:02 PM Serhiy Storchaka
wrote:
> 22.06.18 00:04, Ivan Pozdeev via Python-Dev пише:
> > On 21.
22.06.18 00:04, Ivan Pozdeev via Python-Dev пише:
On 21.06.2018 23:40, Guido van Rossum wrote:
I'm with Serhiy here, for mutable values I don't think the methods
should compare equal, even when the values do. For immutables I don't
care either way, it's an implementation detail.
In this light
On Thu, Jun 21, 2018 at 2:04 PM, Ivan Pozdeev via Python-Dev
wrote:
> On 21.06.2018 23:40, Guido van Rossum wrote:
>
> > I'm with Serhiy here, for mutable values I don't think the methods should
> > compare equal, even when the values do. For immutables I don't care either
> > way, it's an impleme
On 21.06.2018 23:40, Guido van Rossum wrote:
I'm with Serhiy here, for mutable values I don't think the methods
should compare equal, even when the values do. For immutables I don't
care either way, it's an implementation detail.
In this light, methods rather shouldn't have a rich comparison l
I'm with Serhiy here, for mutable values I don't think the methods should
compare equal, even when the values do. For immutables I don't care either
way, it's an implementation detail.
On Thu, Jun 21, 2018, 12:55 Serhiy Storchaka wrote:
> 21.06.18 14:25, Jeroen Demeyer пише:
> > Currently, we ha
21.06.18 14:25, Jeroen Demeyer пише:
Currently, we have:
>>> [].append == [].append
False
However, with a Python class:
>>> class List(list):
def append(self, x): super().append(x)
>>> List().append == List().append
True
I think this is a bug. These bound methods can't be equal b
On 21.06.2018 16:39, Steven D'Aprano wrote:
On Thu, Jun 21, 2018 at 02:33:27PM +0300, Ivan Pozdeev via Python-Dev wrote:
First, tell us what problem you're solving.
You might not be aware of the context of Jereon's question. He is the
author of PEP 579 and 580, so I expect he's looking into im
2018年6月21日(木) 20:27 Jeroen Demeyer :
> Currently, we have:
>
> >>> [].append == [].append
> False
>
> However, with a Python class:
>
> >>> class List(list):
> ... def append(self, x): super().append(x)
> >>> List().append == List().append
> True
>
> In the former case, __self__ is compared
On Thu, Jun 21, 2018 at 02:33:27PM +0300, Ivan Pozdeev via Python-Dev wrote:
> First, tell us what problem you're solving.
You might not be aware of the context of Jereon's question. He is the
author of PEP 579 and 580, so I expect he's looking into implementation
details of the CPython builtin
On Thu, 21 Jun 2018 13:53:53 +0200
Jeroen Demeyer wrote:
> On 2018-06-21 13:33, Ivan Pozdeev via Python-Dev wrote:
> > First, tell us what problem you're solving.
>
> There is no specific problem I want to solve here. I just noticed an
> inconsistency and I wondered if it would be OK to chang
On 2018-06-21 13:33, Ivan Pozdeev via Python-Dev wrote:
First, tell us what problem you're solving.
There is no specific problem I want to solve here. I just noticed an
inconsistency and I wondered if it would be OK to change the
implementation of comparisons of builtin_function_or_method ins
First, tell us what problem you're solving.
Strictly speaking, bound methods don't have an unambiguous notion of
equality:
are they equal if they do the same thing, or of they do they same thing
_on the same object_?
The result that you're seeing is a consequence of that same dichotomy in
On Thu, 21 Jun 2018 13:25:19 +0200
Jeroen Demeyer wrote:
> Currently, we have:
>
> >>> [].append == [].append
> False
>
> However, with a Python class:
>
> >>> class List(list):
> ... def append(self, x): super().append(x)
> >>> List().append == List().append
> True
>
> In the for
Currently, we have:
>>> [].append == [].append
False
However, with a Python class:
>>> class List(list):
... def append(self, x): super().append(x)
>>> List().append == List().append
True
In the former case, __self__ is compared using "is" and in the latter
case, it is compared using "=="
25 matches
Mail list logo
