Re: [Python-Dev] Can we make METH_FASTCALL public, from Python 3.7? (ref: PEP 579

[INADA Naoki]

On Thu, Jun 21, 2018 at 2:57 PM Jeroen Demeyer  wrote:

> On 2018-06-20 17:42, INADA Naoki wrote:
> > I don't have any idea about changing METH_FASTCALL more.
> > If Victor and Serhiy think so, and PyPy maintainers like it too, I want
> > to make it public
> > as soon as possible.
>
> There are two different things here:
>
> The first is documenting METH_FASTCALL such that everybody can create
> built-in functions using the METH_FASTCALL signature. I think that the
> API for METH_FASTCALL (without or with METH_KEYWORDS) is fine, so I
> support making it public. This is really just a documentation issue, so
> I see no reason why it couldn't be added to 3.7.0 if we're fast.
>
>
As ​Serhiy noted, argument parsing API (_PyArg_ParseStack) is not public
too.
So METH_FASTCALL is incomplete for pure C extension authors even if it's
documented.

So I don't have strong opinion for documenting it on 3.7.
Consensus about not changing it (without METH_KEYWORDS) on 3.8 seems enough
to me (and Cython).

Then, _PyArg_ParseStack API should be considered first for make it public
on Python 3.8.
(bikeshedding: The name *Stack* feels not good.  It implies Python VM
stack.  But this
API can be used not only with VM stack.)


> The API for calling functions using the FASTCALL convention is more of a
> mess though. There are functions taking keyword arguments as dict and
> functions taking them as tuple. As I mentioned in PEP 580, I'd like to
> merge these and simply allow either a dict or a tuple. Since this would
> require an API change, this won't be for 3.7.0.
>
>
I like proposed API too.  But I think we should focus on METH_FASTCALL
without
METH_KEYWORDS first.  Making _PyObject_FastCall() public is significant
step for 3.8.

Regards,
-- 
INADA Naoki  
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] PEP 579 and PEP 580: refactoring C functions and methods

[Victor Stinner]

https://www.python.org/dev/peps/pep-0580/#the-c-call-protocol

CCALL_VARARGS: cc_func(PyObject *self, PyObject *args)

If we add a new calling convention, I would prefer to reuse the
FASTCALL calling convention to pass arguments: pass a PyObject **args
array with a size (Py_ssize_t nargs) rather than requiring to create a
temporary tuple object to pass positional arguments.

Victor

2018-06-20 10:53 GMT+02:00 Jeroen Demeyer :
> Hello,
>
> Let me present PEP 579 and PEP 580.
>
> PEP 579 is an informational meta-PEP, listing some of the issues with
> functions/methods implemented in C. The idea is to create several PEPs each
> fix some part of the issues mentioned in PEP 579.
>
> PEP 580 is a standards track PEP to introduce a new "C call" protocol, which
> is an important part of PEP 579. In the reference implementation (which is
> work in progress), this protocol will be used by built-in functions and
> methods. However, it should be used by more classes in the future.
>
> You find the texts at
> https://www.python.org/dev/peps/pep-0579
> https://www.python.org/dev/peps/pep-0580
>
>
> Jeroen.
> ___
> Python-Dev mailing list
> Python-Dev@python.org
> https://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe:
> https://mail.python.org/mailman/options/python-dev/vstinner%40redhat.com
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] PEP 579 and PEP 580: refactoring C functions and methods

[Jeroen Demeyer]

On 2018-06-21 11:22, Victor Stinner wrote:

https://www.python.org/dev/peps/pep-0580/#the-c-call-protocol

CCALL_VARARGS: cc_func(PyObject *self, PyObject *args)

If we add a new calling convention


This is not a *new* calling convention, it's the *existing* calling 
convention for METH_VARARGS. Obviously, we need to continue to support that.

___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

[Python-Dev] About [].append == [].append

[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 using "is" and in the latter 
case, it is compared using "==".


I think that comparing using "==" is the right thing to do because "is" 
is really an implementation detail. Consider


>>> (1).bit_length == (1).bit_length
True
>>> (1).bit_length == (1+0).bit_length
False

I guess that's also the reason why CPython internally rarely uses "is" 
for comparisons.


See also:
- https://bugs.python.org/issue1617161
- https://bugs.python.org/issue33925

Any opinions?


Jeroen.
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] About [].append == [].append

[Antoine Pitrou]

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 former case, __self__ is compared using "is" and in the latter 
> case, it is compared using "==".
> 
> I think that comparing using "==" is the right thing to do because "is" 
> is really an implementation detail.

Probably... though comparing bound methods doesn't sound terribly
useful, so I'm not sure how much of an issue this is in practice.

Regards

Antoine.


___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] About [].append == [].append

[Ivan Pozdeev via Python-Dev]

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 
the minds of the .__eq__ designers, and Python Zen advises "In the face 
of ambiguity, refuse the temptation to guess." -- which is what you're 
suggesting.



On 21.06.2018 14:25, 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 former case, __self__ is compared using "is" and in the latter 
case, it is compared using "==".


I think that comparing using "==" is the right thing to do because 
"is" is really an implementation detail. Consider


>>> (1).bit_length == (1).bit_length
True
>>> (1).bit_length == (1+0).bit_length
False

I guess that's also the reason why CPython internally rarely uses "is" 
for comparisons.


See also:
- https://bugs.python.org/issue1617161
- https://bugs.python.org/issue33925

Any opinions?


Jeroen.
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/vano%40mail.mipt.ru


--
Regards,
Ivan

___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] About [].append == [].append

[Jeroen Demeyer]

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 instances.


It's a valid question to ask even if it doesn't solve an actual problem.
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] About [].append == [].append

[Antoine Pitrou]

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 change the 
> implementation of comparisons of builtin_function_or_method instances.

I think it's ok.

Regards

Antoine.


___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] About [].append == [].append

[Steven D'Aprano]

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 functions and methods.

https://www.python.org/dev/peps/pep-0579/

https://www.python.org/dev/peps/pep-0580/


> 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_?

That's a red-herring, because CPython already defines an unambiguous 
notion of method equality. The problem is that the notion depends on 
whether the method is written in Python or not, and that seems like a 
needless difference.


> The result that you're seeing is a consequence of that same dichotomy in 
> the minds of the .__eq__ designers, and Python Zen advises "In the face 
> of ambiguity, refuse the temptation to guess." -- which is what you're 
> suggesting.

How do you come to that conclusion? If "refuse the temptation to guess" 
applied here, we couldn't do this:

py> "".upper == "".upper
True

(by your reasoning, it should raise an exception).

Note the contrast in treatment of strings with:

py> [].append == [].append
False

(The reason is that "" is cached and reused, and the empty string is 
not.)


> On 21.06.2018 14:25, Jeroen Demeyer wrote:
[...]

> >I think that comparing using "==" is the right thing to do because 
> >"is" is really an implementation detail.

+1


-- 
Steve
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] About [].append == [].append

[INADA Naoki]

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 using "is" and in the latter
> case, it is compared using "==".
>
> I think that comparing using "==" is the right thing to do because "is"
> is really an implementation detail.


I think "is" is correct because "bound to which object" is essential for
bound (instance) methods.


Consider
>
>  >>> (1).bit_length == (1).bit_length
> True
>  >>> (1).bit_length == (1+0).bit_length
> False
>

I'm OK for this difference.
This comparison is what people shouldn't do, like 'id(1) == id(1+0)'


> I guess that's also the reason why CPython internally rarely uses "is"
> for comparisons.
>
> See also:
> - https://bugs.python.org/issue1617161
> - https://bugs.python.org/issue33925
>
> Any opinions?
>

I think changing this may break some tricky code.
Is it really worth enough to change?


>
>
> Jeroen.
> ___
> Python-Dev mailing list
> Python-Dev@python.org
> https://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe:
> https://mail.python.org/mailman/options/python-dev/songofacandy%40gmail.com
>
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

[Python-Dev] 2018 Python Language Summit coverage, last part

[Jake Edge]

Hola python-dev,

Here are the last three sessions from the Python Language Summit that I
wrote up.  Unfortunately, I did not write up the Lightning Talks, which
were numerous and interesting, mostly because of time pressure. As
usual, I am posting SubscriberLinks for articles that are still behind
the paywall.  LWN subscribers can always see our content right away; one
week after they are published in a weekly edition, they become freely
available for everyone. SubscriberLinks are a way around the paywall.
Please feel free to share the SubscriberLinks I am posting here.

The starting point is here: https://lwn.net/Articles/754152/  That is
an overview article with links to the individual articles.  Here are
the articles since my post on Monday (which is here:
https://lwn.net/ml/python-dev/20180618112251.5f936617%40gallinule/ )

PEP 572 and decision-making in Python
https://lwn.net/SubscriberLink/757713/2118c7722d957926/

Getting along in the Python community
https://lwn.net/SubscriberLink/757714/8dadb362ff7d5673/

Mentoring and diversity for Python
https://lwn.net/SubscriberLink/757715/d6cf8c9f72e4bdd8/

enjoy!

jake

-- 
Jake Edge - LWN - j...@lwn.net - https://lwn.net
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

[Python-Dev] PySequence_Check but no __len__

[Christian Tismer]

Hi friends,

there is a case in the Python API where I am not sure what to do:

If an object defines __getitem__() only but no __len__(),
then PySequence_Check() already is true and does not care.

So if I define no __len__, it simply fails. Is this intended?

I was mislead and thought this was the unlimited case, but
it seems still to be true that sequences are always finite.

Can someone please enlighten me?
-- 
Christian Tismer-Sperling:^)   tis...@stackless.com
Software Consulting  : http://www.stackless.com/
Karl-Liebknecht-Str. 121 : http://pyside.org
14482 Potsdam: GPG key -> 0xE7301150FB7BEE0E
phone +49 173 24 18 776  fax +49 (30) 700143-0023



signature.asc
Description: OpenPGP digital signature
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] About [].append == [].append

[Ivan Pozdeev via Python-Dev]

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 implementation
details of the CPython builtin functions and methods.


I see.

`pythonobject.c:method_richcompare' compares .im_func and .im_self . 
Bound builtin methods should do the same, obviously -- preferrably, even 
use the same code.




https://www.python.org/dev/peps/pep-0579/

https://www.python.org/dev/peps/pep-0580/



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_?

That's a red-herring, because CPython already defines an unambiguous
notion of method equality. The problem is that the notion depends on
whether the method is written in Python or not, and that seems like a
needless difference.



The result that you're seeing is a consequence of that same dichotomy in
the minds of the .__eq__ designers, and Python Zen advises "In the face
of ambiguity, refuse the temptation to guess." -- which is what you're
suggesting.

How do you come to that conclusion? If "refuse the temptation to guess"
applied here, we couldn't do this:

py> "".upper == "".upper
True

(by your reasoning, it should raise an exception).

Note the contrast in treatment of strings with:

py> [].append == [].append
False

(The reason is that "" is cached and reused, and the empty string is
not.)



On 21.06.2018 14:25, Jeroen Demeyer wrote:

[...]


I think that comparing using "==" is the right thing to do because
"is" is really an implementation detail.

+1




--
Regards,
Ivan

___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] 2018 Python Language Summit coverage, last part

[Antoine Pitrou]

Hi Jake,

On Thu, 21 Jun 2018 09:18:30 -0600
Jake Edge  wrote:
> 
> The starting point is here: https://lwn.net/Articles/754152/  That is
> an overview article with links to the individual articles.  Here are
> the articles since my post on Monday (which is here:
> https://lwn.net/ml/python-dev/20180618112251.5f936617%40gallinule/ )
> 
> PEP 572 and decision-making in Python
> https://lwn.net/SubscriberLink/757713/2118c7722d957926/

This is an excellent writeup, thank you.  The discussion seems to have
been constructive, too.

I would just like to approve the following points:

> Part of the problem is that there is no real way to measure the
> effectiveness of new language features. 

Indeed.  But, for a syntax addition such as PEP 572, I think it would be
a good idea to ask their opinion to teaching/education specialists.

As far as I'm concerned, if teachers and/or education specialists were
to say PEP 572 is not a problem, my position would shift from negative
towards neutral.

> Van Rossum wondered if the opposition only got heated up after
> he got involved; people may not have taken it seriously earlier because
> they thought he would not go for it. 

That's very true.  For me, at the start, the assignment operator
proposal was one of those many python-ideas threads about new syntax
that never get any wide approval, so I didn't bother about it.

Regards

Antoine.


___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] PySequence_Check but no __len__

[Brett Cannon]

Sorry, I don't quite follow.

On Thu, 21 Jun 2018 at 08:50 Christian Tismer  wrote:

> Hi friends,
>
> there is a case in the Python API where I am not sure what to do:
>
> If an object defines __getitem__() only but no __len__(),
> then PySequence_Check() already is true and does not care.
>

Which matches
https://docs.python.org/3/c-api/sequence.html#c.PySequence_Check .

>From Objects/abstract.c:

int
PySequence_Check(PyObject *s)
{
if (PyDict_Check(s))
return 0;
return s != NULL && s->ob_type->tp_as_sequence &&
s->ob_type->tp_as_sequence->sq_item != NULL;
}



>
> So if I define no __len__, it simply fails. Is this intended?
>

What is "it" in this case that is failing? It isn't PySequence_Check() so
I'm not sure what the issue is.

-Brett


>
> I was mislead and thought this was the unlimited case, but
> it seems still to be true that sequences are always finite.
>
> Can someone please enlighten me?
> --
> Christian Tismer-Sperling:^)   tis...@stackless.com
> Software Consulting  : http://www.stackless.com/
> Karl-Liebknecht-Str. 121 : http://pyside.org
> 14482 Potsdam: GPG key -> 0xE7301150FB7BEE0E
> phone +49 173 24 18 776 <+49%20173%202418776>  fax +49 (30) 700143-0023
> <+49%2030%207001430023>
>
> ___
> Python-Dev mailing list
> Python-Dev@python.org
> https://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe:
> https://mail.python.org/mailman/options/python-dev/brett%40python.org
>
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] About [].append == [].append

[Serhiy Storchaka]

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 because they 
have different side effect.


The use case for using "is" for __self__ is described by the OP of 
issue1617161. I don't know use cases for using "==".


There is a related problem of hashing. Currently
bound methods are not hashable if __self__ is not hashable. This makes 
impossible using them as dict keys.


___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] About [].append == [].append

[Guido van Rossum]

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 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 because they
> have different side effect.
>
> The use case for using "is" for __self__ is described by the OP of
> issue1617161. I don't know use cases for using "==".
>
> There is a related problem of hashing. Currently
> bound methods are not hashable if __self__ is not hashable. This makes
> impossible using them as dict keys.
>
> ___
> Python-Dev mailing list
> Python-Dev@python.org
> https://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe:
> https://mail.python.org/mailman/options/python-dev/guido%40python.org
>
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] About [].append == [].append

[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, methods rather shouldn't have a rich comparison logic at 
all -- at the very least, until we have a realistic use case and can 
flesh out the requirements for it.


In my previous message, I meant that if they do have that logic, the 
right way is what `method_richcompare' does. And that was apparently 
what the method's author (that you might be familiar with) was thinking 
in 
https://github.com/python/cpython/commit/47b9ff6ba11fab4c90556357c437cb4feec1e853 
-- and even then and there, they were hesitant about the feature's 
usefulness.


But Serhiy has just disproven that that is the right way which looks 
like the final nail into its coffin.


On Thu, Jun 21, 2018, 12:55 Serhiy Storchaka > wrote:


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 because
they
have different side effect.

The use case for using "is" for __self__ is described by the OP of
issue1617161. I don't know use cases for using "==".

There is a related problem of hashing. Currently
bound methods are not hashable if __self__ is not hashable. This
makes
impossible using them as dict keys.

___
Python-Dev mailing list
Python-Dev@python.org 
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
https://mail.python.org/mailman/options/python-dev/guido%40python.org



___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/vano%40mail.mipt.ru


--
Regards,
Ivan

___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] About [].append == [].append

[Nathaniel Smith]

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 implementation detail.
>
> In this light, methods rather shouldn't have a rich comparison logic at all
> -- at the very least, until we have a realistic use case and can flesh out
> the requirements for it.

== and hashing for methods can be quite useful for things like cache
keys. (E.g., a dict mapping callable+args -> result.) I'm sure people
are using it. So I think simply removing it would be pretty
disruptive.

I can't think of any cases where == and hashing are useful for methods
on *mutable objects*, which is that case where it matters whether the
'self' comparison uses == or 'is', but the method object doesn't know
whether 'self' is mutable, so it has to either work in general or not
work in general.

-n

-- 
Nathaniel J. Smith -- https://vorpus.org
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] About [].append == [].append

[Serhiy Storchaka]

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, methods rather shouldn't have a rich comparison logic at 
all


This would be so if you get the same method object when resolve an 
attribute. But a.f is not a.f. Every time a new method object is 
created. If we want a.f == a.f, we need to implement a rich comparison 
logic.


-- at the very least, until we have a realistic use case and can 
flesh out the requirements for it.


There are realistic use cases. You will get a number of failures in the 
Python tests if make method objects incomparable.


___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com