antocuni changed the topic of #pypy to: PyPy, the flexible snake (IRC logs: https://botbot.me/freenode/pypy/ ) | use cffi for calling C | "PyPy: the Gradual Reduction of Magic (tm)"
bogner has quit [Read error: Connection reset by peer]
jcea has joined #pypy
dddddd has quit [Quit: Hasta otra..]
iko has quit [Ping timeout: 276 seconds]
iko has joined #pypy
<kenaan>
fijal unicode-utf8 8c2d7104d91e /rpython/: use iterator and add some more obscure iterface for it
antocuni has quit [Ping timeout: 260 seconds]
jcea has quit [Quit: jcea]
ssbr has quit [Ping timeout: 255 seconds]
Jellyg00se has joined #pypy
<Jellyg00se>
Hi, I keep reading mixed (old) articles, and can't really find a straight answer to: Are most modules supported in pypy? Is there a listing of which ones are and aren't? and are there any scenarios where I shouldn't use pypy in particular?
<simpson>
Jellyg00se: I would say that a lot of existing Python code is PyPy-compatible, although usually by accident. Most of the CPython stdlib is available. PyPy should only be avoided if its footprint is too large for your platform; when that happens, you may need microPython.
<simpson>
There is a page with a straight answer, but the problem is that the question you probably want to ask is "Does my codebase work with PyPy?" and the answer is "Set up a PyPy virtualenv and run your codebase's tests."
<simpson>
And the *goal* is that if you write pure CPython-compatible Python then you usually will be fine on PyPy.
<Jellyg00se>
simpson, thanks for your reply that's really good news, also quite confusing why it isn't the standard :P
<arigato>
also, simpson's answer seems to imply that CPython C extension modules don't work, but a lot of them do nowadays
realitix has joined #pypy
<Jellyg00se>
simpson, I'm still new to python, but we're developing a Django application which uses a lot of loops etc.. and so it might be reasonable to give pypy a chance for sped
<simpson>
Oh, sorry, yes, I didn't mean to imply any such thing. Many chunks of CPython-compatible C do work on PyPy, including the ones that you'd expect in the stdlib.
<arigato>
and yes, django is known to work
<simpson>
Jellyg00se: PyPy is not standard (IMO, arigato probably has other thoughts) mostly because of feelings, politics, and factually-incorrect memes within the larger Python galaxy. I would not worry too much about it; you already did the hard part of discovering that PyPy exists and trying it out. That's more than most folks do!
<Jellyg00se>
simpson, Always politics! Be open minded ;) Thanks a lot for the info guys, appreciated
<Jellyg00se>
simpson, regarding the footprint, do you mean the size of the compiled python script (as I said I'm new to python) is quite large?
<fijal>
Jellyg00se: memory consumption of pypy binary
<fijal>
Jellyg00se: anyway, seriously, try and see
<fijal>
asking questions usually gets you scary answers that might or might not be related, it's much better to check
<Jellyg00se>
fijal, just wanted to know what to look for :)
<fijal>
yes, so a) check if it works
<fijal>
b) make sure there is enough requests for pypy to warm up
<fijal>
and c) look if the memory consumption is ok
<fijal>
a) is almost always true
<fijal>
these days
<realitix>
Hi arigato ! I'm trying to do esoteric stuff with cffi ^^. I have a CompiledFFI (abi mode) and I try to inject it in a dependant module with ffi.include but I got an error because I should use a FFI, not a CompiledFFI. Is it possible to inject a CompiledFFI (ABI mode) into a FFI (API mode) ?
oberstet has joined #pypy
<kenaan>
fijal unicode-utf8 2d147c5dd32c /TODO: add one item
tayfun has quit [Remote host closed the connection]
<Jellyg00se>
This is a bit of a weird question apologies in advance. I'm not used to defining self within the method parameters for every method, but does this mean that you could replace self with super().__init__() and force it to call the base class if you wanted?
<fijal>
Jellyg00se: yes you can, but yes wrong channel :)
<fijal>
arigato: I'm good at whacking?
<fijal>
(nothing more you can do at 40degrees)
<kenaan>
fijal unicode-utf8 8d468e08f3fe /: whack a few more places, handle surrogates correctly
<fijal>
arigato: maaaybe we should review all the places that call check_utf8 to see if we can call the faster version
Jellyg00se has quit [Quit: Leaving]
<fijal>
arigato: feel like trying to do splitlines?
<fijal>
I've been trying for half an hour and failing
dcrosta has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
dcrosta has joined #pypy
pulkitg has quit [Ping timeout: 276 seconds]
zmt00 has joined #pypy
dcrosta has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
<realitix>
arigato, fijal: I got this message: cffi.error.VerificationError: not implemented yet: ffi.include() of a Python-based ffi inside a C-based ffi
<realitix>
Is it a lot of work?
<realitix>
to know if I can do it ?
<arigato>
right, I didn't exactly remember the rules
<arigato>
sorry about that
<arigato>
I don't remember right now, but it's probably that some rules about some things (struct definitions?) are not exactly the same
<realitix>
ok arigato, I will have a look tomorrow because I have to go now. Bonne soirée!
<arigato>
it must be something like: after ffi.include() inside a C-based ffibuilder, it might emit C code that uses the 'struct'
<arigato>
even if they come from the included ffibuilder
<arigato>
but doing so doesn't really make sense if the included ffibuilder is ABI-based (i.e. Python-based)
<realitix>
that's my case
dcrosta has joined #pypy
<arigato>
you can't have C code that uses 'struct foo' if 'struct foo' was originally supposed to not come from C at all
<arigato>
so the whole thing is again a bit of a mess to implement: maybe we have to require that in this C file the original ABI-based declarations are really available to C (and should match exactly)