cfbolz changed the topic of #pypy to: PyPy, the flexible snake (IRC logs: https://quodlibet.duckdns.org/irc/pypy/latest.log.html#irc-end ) | use cffi for calling C | if a pep adds a mere 25-30 [C-API] functions or so, it's a drop in the ocean (cough) - Armin
<arigo>
re cross-posting between pypy-dev and python-ideas: I'll just drop mails that pypy-dev blocks by being sent from non-subscribed people (likely to python-ideas)
<mattip>
will the person who posts get a notice they must subscribe?
<arigo>
yes
<arigo>
the hope is that they'll notice they are also sending to pypy-dev by mistake, and stop doing that
<rjarry>
however, the way cffi extensions are structured seems not to cut it with pylint
<rjarry>
since we need to do:
<rjarry>
from <compiled_cffi_extension> import lib
<rjarry>
and then, lib.<exported_c_symbol>
<rjarry>
pylint complains: Instance of 'module' has no '<exported_c_symbol>' member [no-member]
rubdos has quit [Client Quit]
<mattip>
rjarry: what version of cffi are you using? I think lib.__all__ has <exported_c_symbol>, no?
<rjarry>
mattip: I use cffi-1.14.0 and pylint-2.4.4
<rjarry>
the latest versions I guess
<rjarry>
I did not check lib.__all__
<rjarry>
yes, lib.__all__ has all symbol names
rubdos has joined #pypy
<mattip>
so this seems like a pylint bug
<rjarry>
yeah, I was hoping there was a hidden workaround
<mattip>
there is some tag you can put on pylint false positives
<mattip>
# pylint: disable=no-member
<mattip>
on the offending line
<rjarry>
I know, but I would like it very much for pylint to actually detect errors, if I put pylint: disable=no-memeber on all lines that fail, there is no point in running pylint
<cfbolz>
arigo: do you have an opinion on whether we should forbid this?
<arigo>
wat
<cfbolz>
:-)
<cfbolz>
changing the __code__ is forbidden too, so I think it would make sense
<arigo>
yes, agreed
<cfbolz>
ok, will do it
<arigo>
but then it's also about the other attributes too:
<cfbolz>
sure
<arigo>
__closure__
<arigo>
__dict__?
<arigo>
__globals__
<cfbolz>
I think those are less severe, since they don't affect behaviour
<cfbolz>
but yes, agreed
<arigo>
well, __closure__ would, but I suspect it's never used for builtins
<cfbolz>
(ah, maybe they *do* affect behaviour, for @builtiny ed app-level builtins!)
<cfbolz>
arigo: another quick question, do you have an idea how we should deal with the fact that the sre bytecodes change quite a bit in 3.7, given that the sre engine is in rlib? :-(
<cfbolz>
I'm planning to try to fix sre for 3.7, but don't know to deal with that fact
<mattip>
cfbolz: time for some software engineering: either rewrite the entire thing as a separate module, factor out the common parts, or something in between