<ctismer>
mattip: Yay, sure I will! Thanks a lot 😆
otisolsen70 has quit [Remote host closed the connection]
otisolsen70 has joined #pypy
<ctismer>
mattip: Yes, seems to work. I get now the error `TypeError: can't set attributes on type object 'method_descriptor'`
<ctismer>
mattip: which is probably correct for builtin types?
<ctismer>
mattip: It creates correctly a getset descriptor. Then it breaks because it cannot set the attribute `__signature__` on builtin types (this is in fact new from me). Can I do something about that? Maybe use derived types, or who complains about the `__signature__` name?
<ctismer>
mattip: (probably I can also live without setting the `__signature__` attribute, would be implemented more indirectly if that's the showstopper)
<ctismer>
"can't set attributes on type object '%N'", self)
<ctismer>
raise oefmt(space.w_TypeError,
<ctismer>
if not self.is_heaptype():
<cfbolz>
ctismer: that's important though
<cfbolz>
otherwise you could do list.append = None
<ctismer>
mattip: cfbolz: CPython allows this. What is the problem?
<cfbolz>
ctismer: no?
<cfbolz>
ctismer: can you show some pure python code that does it?
<ctismer>
ccfbolz: of course not! :) But from C it is possible.
<cfbolz>
ctismer: ok, but then we need to understand the rules better
<cfbolz>
when is it ok, when not
<cfbolz>
which C function are you calling to set the attribute?
<ctismer>
cfbolz: in case I do it, it is ok 😂
<cfbolz>
😆
<ctismer>
cfbolz: let me see, it is code from 2017
<cfbolz>
it's a general problem in pypy, our C code is not *special*, the same rules apply as with python code. whereas in CPython the C code can do more
<ctismer>
cfbolz: in a function `add_more_getsets`, I am modifying existent non-heaptypes, adding the `__signature__` attribute. I set simply what I need, see
<ctismer>
...
<ctismer>
int add_more_getsets(PyTypeObject *type, PyGetSetDef *gsp, PyObject **doc_descr)
<ctismer>
return -1;
<ctismer>
if (PyDict_SetItemString(dict, gsp->name, descr) < 0)
<cfbolz>
ctismer: and where is the dict from? the type?
<cfbolz>
ctismer: but that's really unsafe somehow, isn't it? you could use the same approach to change list.append, right?
<ctismer>
cfbolz: I'm not sure if that would work, anyway, because it is a type modification, right?
<cfbolz>
anyway, we need to find out how to fix this
<ctismer>
cfbolz: sure I could, but I just do what I need for the new attribute, nothing bad.
<cfbolz>
yes, sorry, I am just trying to understand the context
<ctismer>
cfbolz: Q: Would it work at all if we fixed this? Because we are modifying a type???
<cfbolz>
ctismer: you don't want to switch to using heaptypes I assume?
<cfbolz>
I don't think it would be a real problem, as long as you do it "early enough", meaning right after the construction of the type
<ctismer>
cfbolz: If not, then I have to re-implement a lot for the signature module. Would be good to know.
<ctismer>
cfbolz: yes! Before `PyType_Ready` is called. But here, I am patching a builtin type, and sure the type is very ready
<cfbolz>
right
<cfbolz>
ok, that's good, then we understand when it's ok ;-)
<ctismer>
cfbolz: So, to be on the right track: Modifying builtin types is a problem, because we don't have a new `PyType_Modified`. With that, and using heaptypes, it would work.
<cfbolz>
ctismer: yes, basically my plan would be to allow such dict modifications before PyType_Ready has been called
<ctismer>
cfbolz: The alternative is to re-implement the whole signature stuff without touching any type. Just use a shadow dict, in case of PyPy.
<cfbolz>
ctismer: I think it's a real bug in pypy, so we should fix it
<cfbolz>
(btw, we don't really need PyType_Modified (it can be a no-op), the dict will inform the type that it was changed)
<ctismer>
cfbolz: Huh? That's new to me! mattip said such a thing would come, because I am modifying types heavily by exchanging the whole dict (`from __feature__ import snake_case`)
<cfbolz>
ah, removing the dict is harder ;-)
<ctismer>
cfbolz: the switching works great, actually, on a per-module basis. But it is not urgent to have it for PyPy.
<cfbolz>
ok
<cfbolz>
anyway, I'll make an issue for the "modifying before pytype_ready"
<ctismer>
cfbolz: what is the plan with "dict informs type"?
<cfbolz>
ctismer: sorry, that was a complete side point. I am just saying that if you have a *heap* type and you modify it somehow from C, you should not have to call PyType_Modified
<cfbolz>
but we should still have the function, even if it does nothing
<ctismer>
cfbolz: I understand. But this is also not implemented, therefore I had to do heavy changes to all variants of `PyType_FromSpec`, to do all changes early. How far is that change?
<cfbolz>
adding PyType_Modified?
<ctismer>
no, the effect of "you should not have to call PyType_Modified"
<cfbolz>
ctismer: that has always been there
<cfbolz>
"always"
<cfbolz>
since like ten years
<cfbolz>
anyway, we can also add it, it's good to have the CPython APIs
<ctismer>
cfbolz: misunderstanding. When PyType_Ready was called, the type is frozen. But if I understand right, the dict can still be changed? That explains something!
<cfbolz>
ctismer: yeah sorry, I think we are talking past each other a bit
<cfbolz>
if you have a non-heap type, you cannot modify it
<cfbolz>
but for heap types, it's safe to modify the dict
<ctismer>
cfbolz: yes, and yes. So I could do my changes if I only use heaptypes. And it works _after_ `PyType_Ready`
<ctismer>
because the dict talks to the type.
<cfbolz>
yes
<cfbolz>
ok, so todo for us is that issue, and maybe adding PyType_Modified
<cfbolz>
ahahaha, I just found a fun way to segfault python
<ctismer>
cfbolz: This crashes PySide, no idea why. Fixed "currently" by temporarily removing the flag because I could not find what's wrong. Now I'm afraid that PyPy does not react on fiddling this flag. Is vectorcall of benefit for PyPy?
<cfbolz>
ctismer: not really no
<ctismer>
cfbolz: but that's already in 3.8, isn't it? I already tried that, works 🖖
<cfbolz>
ctismer: awesome
jacob22_ has quit [Ping timeout: 268 seconds]
Julian has joined #pypy
Julian has quit [Quit: leaving]
otisolsen70_ has joined #pypy
otisolsen70 has quit [Ping timeout: 264 seconds]
otisolsen70_ has quit [Remote host closed the connection]
Atque has quit [Remote host closed the connection]