To expand on my earlier comment about changing the module under test to
make your testing easier, asyncio is one library that has lots of tests of
different combinations of its C and Python implementations being used
together.
As far as I know, it doesn't use import_fresh_module or similar hackery
Maybe an initialization/import side-effect bug which is triggered if the module
is imported twice?
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/pyt
No worries, I actually seem to have solved the immediately pressing
problem that was blocking PEP 615 by doing this:
@functools.lru_cache(1)
def get_modules():
import zoneinfo as c_module
py_module = import_fresh_module("zoneinfo", blocked=["_czoneinfo"])
return py_module, c_module
I
On Wed, May 6, 2020 at 2:34 PM Paul Ganssle wrote:
> I think I tried something similar for tests that involved an environment
> variable and found that it doesn't play nicely with coverage.py at all.
This is a solvable problem:
https://coverage.readthedocs.io/en/coverage-5.1/subprocess.html
But
Have you also considered changes to the modules under test that might make
it easier for both implementations to exist and be tested side-by-side (so
with fewer hacks on the testing side)?
—Chris
On Wed, May 6, 2020 at 2:33 PM Paul Ganssle wrote:
> Thanks for the suggestion.
>
> I think I tried
The subtle issue is of course performance if you get too cozy with this
pattern...
On Wed, May 6, 2020 at 1:59 PM Nathaniel Smith wrote:
> On Wed, May 6, 2020 at 7:52 AM Paul Ganssle wrote:
> >
> > As part of PEP 399, an idiom for testing both C and pure Python versions
> of a library is sugges
Thanks for the suggestion.
I think I tried something similar for tests that involved an environment
variable and found that it doesn't play nicely with coverage.py /at all/.
Also, I will have to solve this problem at some point anyway because the
property tests for the module (not currently inclu
On Wed, May 6, 2020 at 7:52 AM Paul Ganssle wrote:
>
> As part of PEP 399, an idiom for testing both C and pure Python versions of a
> library is suggested making use if import_fresh_module.
>
> Unfortunately, I'm finding that this is not amazingly robust. We have this
> issue: https://bugs.pyth
I'm drowning in work this month, so if you need me to look at something then I
unfortunately need a point-blank link of what you want me to look at with a
targeted question.
As for import_fresh_module() not being robust: of course it isn't because it's
mucking with import stuff in a very non-st
