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
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.
>
Whic
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/2
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
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
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 behi
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 "=="
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.
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 th
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
20 matches
Mail list logo
