On 04/26/18 09:32, Thomas Wouters wrote:
Thanks for working on this, Marcel (and Petr). This looks like an
ambitious intern project :) Couple of questions and comments in-line.
Indeed, but also a multi-year one. Sometimes it seems like Python is
moving too fast under us!
Specifically, PEP
On 2018-04-26 16:37, Nick Coghlan wrote:
PEP 487 refers to this as the "owner" of a descriptor
That's just copied from the Python docs:
https://docs.python.org/3.8/reference/datamodel.html#object.__get__
Anyway, I never liked the name "owner" there, "cls" would have been much
clearer.
For
On 26 April 2018 at 04:46, Jeroen Demeyer wrote:
> On 2018-04-25 20:33, Petr Viktorin wrote:
>>
>> Perhaps "m_objclass" could point to the module in this case
>
>
> That was exactly my idea also today. Instead of treating m_objclass as the
> defining class, we should generalize it to be the "paren
Thanks for working on this, Marcel (and Petr). This looks like an ambitious
intern project :) Couple of questions and comments in-line.
On Mon, Apr 23, 2018 at 12:36 PM, Marcel Plch
wrote:
> Hello,
> I am an intern at Red Hat mentored by Petr Viktorin. As a part of my
> internship, I learned the
- In Python code, __objclass__ should be the defining class, not the module.
Indeed. My idea would be to add an accessor __parent__ returning the
m_parent field (whatever it is) and then implement __objclass__ as
something like:
@property
def __objclass__(self):
parent = getattr(self, "_
On 04/25/18 14:46, Jeroen Demeyer wrote:
On 2018-04-25 20:33, Petr Viktorin wrote:
Perhaps "m_objclass" could point to the module in this case
That was exactly my idea also today. Instead of treating m_objclass as
the defining class, we should generalize it to be the "parent" of the
function
On 2018-04-25 20:33, Petr Viktorin wrote:
Perhaps "m_objclass" could point to the module in this case
That was exactly my idea also today. Instead of treating m_objclass as
the defining class, we should generalize it to be the "parent" of the
function: either the class or the module.
__
On 04/24/18 13:12, Jeroen Demeyer wrote:
On 2018-04-24 16:34, Jeroen Demeyer wrote:
On the other hand, if you are passing the function object, then you can
get __self__ from it (unless it's an unbound method: in that case
__self__ is NULL and self is really args[0]). So there wouldn't be a
need
On 2018-04-24 16:34, Jeroen Demeyer wrote:
On the other hand, if you are passing the function object, then you can
get __self__ from it (unless it's an unbound method: in that case
__self__ is NULL and self is really args[0]). So there wouldn't be a
need for passing "self". I'm not saying that th
If PEP 575's new call doesn't have any surprising restrictions,
I think that completely dropping METH_METHOD would be the
best way of resolving this.
I suggest we push PEP 575 first and if it gets accepted, I will rebase
PEP 573 to these changes.
On Tue, Apr 24, 2018 at 4:34 PM, Jeroen Demeyer wr
On 2018-04-24 14:53, Nick Coghlan wrote:
In PEP 575, I'm already proposing a flag (METH_ARG0_FUNCTION) to pass the
function *instead* of self. Unless PEP 573 is rejected, maybe that should
change to passing the function *in addition* to self.
That would definitely be an elegant way of addressin
On 24 April 2018 at 18:17, Jeroen Demeyer wrote:
> In PEP 573, instead of passing the defining class to the C function, why not
> pass the function object itself? That is far more general: once you have the
> function object, you can still access the defining class using your
> PyCMethod_CLASS. It
In PEP 573, instead of passing the defining class to the C function, why
not pass the function object itself? That is far more general: once you
have the function object, you can still access the defining class using
your PyCMethod_CLASS. It's also more future-proof: if we ever decide to
add ev
On 04/23/18 14:04, Jeroen Demeyer wrote:
Hello,
I just saw this PEP. There is a bit of overlap between PEP 573 and PEP
575 since these both change the calling convention for built-in methods.
In particular, PEP 575 also proposes to add a "defining class" member
(for different reasons). In PEP
Hello,
I just saw this PEP. There is a bit of overlap between PEP 573 and PEP
575 since these both change the calling convention for built-in methods.
In particular, PEP 575 also proposes to add a "defining class" member
(for different reasons). In PEP 575, this is added to the PyCFunction
st
Hello,
I am an intern at Red Hat mentored by Petr Viktorin. As a part of my
internship, I learned the CPython internals and how to contribute
to the CPython interpreter.
As a result, I have prepared PEP 573, which solves some problems
that PEP 489 (Multi-phase extension module initialization) has
16 matches
Mail list logo
