Oh, I just remember this old issue which is somehow similar:
http://bugs.python.org/issue11995
"test_pydoc loads all Python modules"
Running test_pydoc in a subprocess would work around this issue.
Arfrever wrote a patch, I didn't read it (sorry!).
Victor
___
On Mon, Dec 31, 2012 at 7:30 PM, Gregory P. Smith wrote:
>
> On Sun, Dec 30, 2012 at 6:48 AM, R. David Murray wrote:
>
>> On Mon, 31 Dec 2012 00:38:47 +1000, Nick Coghlan
>> wrote:
>> > On Mon, Dec 31, 2012 at 12:19 AM, Eli Bendersky
>> wrote:
>> > > On Sun, Dec 30, 2012 at 5:54 AM, Stefan Krah
On Sun, Dec 30, 2012 at 6:48 AM, R. David Murray wrote:
> On Mon, 31 Dec 2012 00:38:47 +1000, Nick Coghlan
> wrote:
> > On Mon, Dec 31, 2012 at 12:19 AM, Eli Bendersky
> wrote:
> > > On Sun, Dec 30, 2012 at 5:54 AM, Stefan Krah
> wrote:
> > >>
> > >> Eli Bendersky wrote:
> > >> > Yes, this is
On Sun, Dec 30, 2012 at 5:33 AM, Eli Bendersky wrote:
>
>
> On Sat, Dec 29, 2012 at 5:34 PM, Nick Coghlan wrote:
>
>> On Sun, Dec 30, 2012 at 10:46 AM, Benjamin Peterson
>> wrote:
>> > 2012/12/29 Eli Bendersky :
>> >> Hi,
>> >>
>> >> This came up while investigating some test-order-dependency fa
On 30/12/2012 9:52pm, Antoine Pitrou wrote:
If you have an object with a __del__ method as a module global, the
cyclic gc will refuse to consider the module globals at all (which
means it will affect unrelated objects).
So, yes, I think the shutdown purge is still necessary. Perhaps there
are wa
On Mon, Dec 31, 2012 at 1:45 AM, Arfrever Frehtes Taifersar Arahesis <
arfrever@gmail.com> wrote:
> 2012-12-30 15:48:30 R. David Murray napisał(a):
> > On Mon, 31 Dec 2012 00:38:47 +1000, Nick Coghlan
> wrote:
> > > However, specifically spinning out the "import the world" tests like
> > > te
2012-12-30 15:48:30 R. David Murray napisał(a):
> On Mon, 31 Dec 2012 00:38:47 +1000, Nick Coghlan wrote:
> > However, specifically spinning out the "import the world" tests like
> > test_pydoc and test___all__ to a separate process might be worth the
> > effort.
>
> Adding something to regertest
On Mon, 31 Dec 2012 10:25:25 +1300
Greg Ewing wrote:
> Richard Oudkerk wrote:
> > Personally I would like to get rid of the "purge globals" behaviour for
> > modules deleted before shutdown has started: if someone manipulates
> > sys.modules then they can just call gc.collect() if they want to
Richard Oudkerk wrote:
Personally I would like to get rid of the "purge globals" behaviour for
modules deleted before shutdown has started: if someone manipulates
sys.modules then they can just call gc.collect() if they want to
promptly get rid of orphaned reference cycles.
Now that we have c
On Mon, 31 Dec 2012 00:38:47 +1000, Nick Coghlan wrote:
> On Mon, Dec 31, 2012 at 12:19 AM, Eli Bendersky wrote:
> > On Sun, Dec 30, 2012 at 5:54 AM, Stefan Krah wrote:
> >>
> >> Eli Bendersky wrote:
> >> > Yes, this is the solution currently used in test_xml_etree. However,
> >> > once
> >> >
On Mon, Dec 31, 2012 at 12:19 AM, Eli Bendersky wrote:
>
>
>
> On Sun, Dec 30, 2012 at 5:54 AM, Stefan Krah wrote:
>>
>> Eli Bendersky wrote:
>> > Yes, this is the solution currently used in test_xml_etree. However,
>> > once
>> > pickling tests are added things stop working. Pickle uses __impor
Eli Bendersky wrote:
> Yes, this seems to have done the trick. Thanks for the suggestion.
>
> I'm still curious about the test-in-clean-env question though.
I think that in general we do want to check unexpected interactions between
tests, that's also why the test order is randomized.
Here's an
On Sun, Dec 30, 2012 at 5:54 AM, Stefan Krah wrote:
> Eli Bendersky wrote:
> > Yes, this is the solution currently used in test_xml_etree. However, once
> > pickling tests are added things stop working. Pickle uses __import__ to
> import
> > the module a class belongs to, bypassing all such tric
On Sun, Dec 30, 2012 at 6:06 AM, Eli Bendersky wrote:
>
>
>
> On Sun, Dec 30, 2012 at 5:54 AM, Stefan Krah wrote:
>
>> Eli Bendersky wrote:
>> > Yes, this is the solution currently used in test_xml_etree. However,
>> once
>> > pickling tests are added things stop working. Pickle uses __import__
On Sun, Dec 30, 2012 at 5:54 AM, Stefan Krah wrote:
> Eli Bendersky wrote:
> > Yes, this is the solution currently used in test_xml_etree. However, once
> > pickling tests are added things stop working. Pickle uses __import__ to
> import
> > the module a class belongs to, bypassing all such tric
Eli Bendersky wrote:
> Yes, this is the solution currently used in test_xml_etree. However, once
> pickling tests are added things stop working. Pickle uses __import__ to import
> the module a class belongs to, bypassing all such trickery. So if test___all__
> got _elementtree into sys.modules, pi
On Sat, Dec 29, 2012 at 5:34 PM, Nick Coghlan wrote:
> On Sun, Dec 30, 2012 at 10:46 AM, Benjamin Peterson
> wrote:
> > 2012/12/29 Eli Bendersky :
> >> Hi,
> >>
> >> This came up while investigating some test-order-dependency failures in
> >> issue 16076.
> >>
> >> test___all__ goes over modules
On 30/12/2012 12:31am, Eli Bendersky wrote:
Would it make sense to save the sys.modules state and restore it in
test___all__ so that sys.modules isn't affected by this test?
Deleting module objects can cause problems because the destructor
replaces values in the globals dict by None. If anyth
On Sun, Dec 30, 2012 at 10:46 AM, Benjamin Peterson wrote:
> 2012/12/29 Eli Bendersky :
>> Hi,
>>
>> This came up while investigating some test-order-dependency failures in
>> issue 16076.
>>
>> test___all__ goes over modules that have `__all__` in them and does 'from
>> import *' on them. This l
On Sat, Dec 29, 2012 at 4:46 PM, Benjamin Peterson wrote:
> 2012/12/29 Eli Bendersky :
> > Hi,
> >
> > This came up while investigating some test-order-dependency failures in
> > issue 16076.
> >
> > test___all__ goes over modules that have `__all__` in them and does 'from
> > import *' on them.
See (unfinished but trivial enough) http://bugs.python.org/issue14715
for proposed way to modules/importsystem cleanup
On Sun, Dec 30, 2012 at 2:31 AM, Eli Bendersky wrote:
> Hi,
>
> This came up while investigating some test-order-dependency failures in
> issue 16076.
>
> test___all__ goes over
2012/12/29 Eli Bendersky :
> Hi,
>
> This came up while investigating some test-order-dependency failures in
> issue 16076.
>
> test___all__ goes over modules that have `__all__` in them and does 'from
> import *' on them. This leaves a lot of modules in sys.modules,
> which may interfere with som
Hi,
This came up while investigating some test-order-dependency failures in
issue 16076.
test___all__ goes over modules that have `__all__` in them and does 'from
import *' on them. This leaves a lot of modules in sys.modules,
which may interfere with some tests that do fancy things with sys,mod
23 matches
Mail list logo
