Hi, > What we probabl need is a new hook, "pytest_enter_pdb" maybe, which > pytest-timeout can implement to switch off timeout handling. > pytest would call this hook in the "pdb.set_trace()" interception > code around _pytest/pdb.py:34.
I like this idea, seems simple enough to implement. :) Cheers, On Sun, Sep 14, 2014 at 12:00 PM, holger krekel <hol...@merlinux.eu> wrote: > Hi Wolfgang, Bruno, > > On Sat, Sep 13, 2014 at 15:53 -0300, Bruno Oliveira wrote: > > Hi, > > > > > 1. Am I missing something or does pytest indeed completely seal off its > > internals? > > > > Not really, you can access _pytest module directly: > > >>> import _pytest.pdb > > >>> _pytest.pdb.pytestPDB > > <class _pytest.pdb.pytestPDB at 0x026F0500> > > Right, pytest's functionality is implemented in core builtin > plugins living at _pytest/*.py (except for core.py which is the plugin > mechanism itself). Core and 3rd party plugins expose functions/objects > to be exposed at "pytest.*" via the pytest_namespace hook. This > approach has advantages but also disadvantages in that it's not easy to > just read the source and discover how pytest startup actually happens. > > > > 2. Am I approaching this wrong? How else could I go about achieving my > > goal of disabling the timeout? > > > > Personally I would try to implement this in pytest-timeout instead, > > possibly by adding a `disable_all_timeouts()` API function would be > called > > automatically when `pdb.set_trace()` is called. This also leaves room for > > other code to disable timeout handling if needed. > > What we probabl need is a new hook, "pytest_enter_pdb" maybe, which > pytest-timeout can implement to switch off timeout handling. > pytest would call this hook in the "pdb.set_trace()" interception > code around _pytest/pdb.py:34. > > best, > holger >
_______________________________________________ Pytest-dev mailing list Pytest-dev@python.org https://mail.python.org/mailman/listinfo/pytest-dev
