cfbolz changed the topic of #pypy to: #pypy PyPy, the flexible snake | IRC logs: and | hacking on TLS is fun, way more fun than arguing over petty shit, turns out
fotis has joined #pypy
fotis has quit [Ping timeout: 260 seconds]
fotis has joined #pypy
fotis has quit [Ping timeout: 264 seconds]
fotis has joined #pypy
fotis has quit [Ping timeout: 260 seconds]
fotis has joined #pypy
fotis has quit [Ping timeout: 245 seconds]
fotis has joined #pypy
fotis has quit [Ping timeout: 260 seconds]
Atque has quit [Quit: ...]
slav0nic has joined #pypy
otisolsen70 has joined #pypy
<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> sorry.
<ctismer> def setdictvalue(self, space, name, w_value):
<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?
<ctismer> cfbolz: yes ` PyObject *dict = type->tp_dict;`
<cfbolz> right
<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"?
<ctismer> cfbolz: thanks!
<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
<cfbolz> cpython
<cfbolz> ctismer: ^^
<cfbolz> pypy works fine
<ctismer> wot?
<ctismer> cfbolz: right! Crazy, crashes also in Py 3.9
<cfbolz> ctismer: it's because with get_referents you can circumvent the cache invalidation by accessing type->tp_dict from pure python
<ctismer> cfbolz: yes, I had my first cache effects in 3.10, but it exists longer, just used less intensively.
<cfbolz> yeah
<cfbolz> will just get worse in the next release ;-)
<ctismer> caching is always a dangerous improvement. The empire will strike back.
<cfbolz> ok, it still segfaults cpython main
amazigh has left #pypy [WeeChat 2.8]
* ctismer thinks that's an area where PyPy shines. When once sth. is right, it is superior to CPython
<cfbolz> yep
<cfbolz> I updated the bytecode set a lot in the 3.9 branch
<cfbolz> the JIT still works
<cfbolz> and I didn't have to touch it at all
<ctismer> yes, an amazing concept
<cfbolz> nice, here's an equivalent issue:
<cfbolz> using __eq__, very sneaky
<cfbolz> and raymond describes the get_referents hack too
<ctismer> wondering about a "won't fix", I thought their "never ever break" attitude was stronger
Atque has joined #pypy
<ctismer> cfbolz: A Q. concerning `Py_TPFLAGS_METHOD_DESCRIPTOR`: I had problems with that flag in CPython 3.9. Will PyPy use that as well?
<cfbolz> ctismer: sorry, I have no clue what that flag does 😕
<cfbolz> (I'm actually not that well versed in the C side of things)
<ctismer> cfbolz: fine, then the chances are good 😀
<cfbolz> Ah, that's vectorcall stuff
<cfbolz> We have it
<cfbolz> Not sure how compatible
<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]
otisolsen70 has joined #pypy
jacob22 has joined #pypy
otisolsen70 has quit [Quit: Leaving]
slav0nic has quit [Ping timeout: 246 seconds]