On 10 Aug 2013 21:06, "Eli Bendersky" wrote:
>
> n Sat, Aug 10, 2013 at 5:47 PM, Nick Coghlan wrote:
>>
>> In a similar vein, Antoine recently noted that the fact the per-module
state isn't a real PyObject creates a variety of interesting lifecycle
management challenges.
>>
>> I'm not seeing an e
On Sat, 10 Aug 2013 18:06:02 -0700
Eli Bendersky wrote:
> This solution has problems. For example, in the case of ET it would
> preclude testing what happens when pyexpat is disabled (remember we were
> discussing this...). This is because there would be no real way to create
> new instances of su
On Sat, 10 Aug 2013 21:40:46 -0400
Terry Reedy wrote:
>
> This run recorded here shows a green test (it appears to have timed out)
> http://buildbot.python.org/all/builders/x86%20Windows7%203.x/builds/7017
> but the corresponding log for this Windows bot
> http://buildbot.python.org/all/builders/
Hi Eli,
On Sat, 10 Aug 2013 17:12:53 -0700
Eli Bendersky wrote:
>
> Note how doing some sys.modules acrobatics and re-importing suddenly
> changes the internal state of a previously imported module. This happens
> because:
>
> 1. The first import of 'csv' (which then imports `_csv) creates
> m
On Sun, 11 Aug 2013 12:33:16 +0200
Antoine Pitrou wrote:
> So, the PEP 3121 "module state" pointer (the optional opaque void*
> thing) should only be used to hold non-PyObjects. PyObjects should go
> to the module dict, like they do in normal Python modules. Now, the
> reason our PEP 3121 extens
On 11 August 2013 06:33, Antoine Pitrou wrote:
> So code can be written like:
>
> PyObject *dialects = PyState_GetModuleAttr(
> &_csvmodule, "dialects", &PyDict_Type);
> if (dialects == NULL)
> return NULL;
This sounds like a good near term solution to me.
Longer term, I think th
On Sun, 11 Aug 2013 07:04:40 -0400
Nick Coghlan wrote:
> On 11 August 2013 06:33, Antoine Pitrou wrote:
> > So code can be written like:
> >
> > PyObject *dialects = PyState_GetModuleAttr(
> > &_csvmodule, "dialects", &PyDict_Type);
> > if (dialects == NULL)
> > return NULL;
>
>
Antoine Pitrou, 11.08.2013 12:33:
> On Sat, 10 Aug 2013 17:12:53 -0700 Eli Bendersky wrote:
>> Note how doing some sys.modules acrobatics and re-importing suddenly
>> changes the internal state of a previously imported module. This happens
>> because:
>>
>> 1. The first import of 'csv' (which then
Antoine Pitrou, 11.08.2013 13:48:
> On Sun, 11 Aug 2013 07:04:40 -0400 Nick Coghlan wrote:
>> On 11 August 2013 06:33, Antoine Pitrou wrote:
>>> So code can be written like:
>>>
>>> PyObject *dialects = PyState_GetModuleAttr(
>>> &_csvmodule, "dialects", &PyDict_Type);
>>> if (dialects ==
On 11/08/2013 11:00am, Antoine Pitrou wrote:
You've got the answer at the bottom:
"program finished with exit code 0"
So for some reason, the test suite crashed, but with a successful exit
code. Buildbot thinks it ran fine.
Was the test terminated because it took too long?
TerminateProces
On Sun, 11 Aug 2013 14:16:10 +0200
Stefan Behnel wrote:
>
> > We
> > just need to devise a convenience API for that (perhaps by allowing to
> > create both the subclass *and* instantiate it in a single call).
>
> Right. This conflicts somewhat with the simplified module creation. If the
> module
http://stackoverflow.com/questions/2061735/42-passed-to-terminateprocess-sometimes-getexitcodeprocess-returns-0
--
Richard
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.py
Antoine Pitrou, 11.08.2013 14:32:
> On Sun, 11 Aug 2013 14:16:10 +0200 Stefan Behnel wrote:
>>> We
>>> just need to devise a convenience API for that (perhaps by allowing to
>>> create both the subclass *and* instantiate it in a single call).
>>
>> Right. This conflicts somewhat with the simplified
Stefan Behnel, 11.08.2013 14:48:
> Antoine Pitrou, 11.08.2013 14:32:
>> On Sun, 11 Aug 2013 14:16:10 +0200 Stefan Behnel wrote:
We
just need to devise a convenience API for that (perhaps by allowing to
create both the subclass *and* instantiate it in a single call).
>>>
>>> Right. Th
Stefan Behnel, 11.08.2013 14:53:
> Stefan Behnel, 11.08.2013 14:48:
>> Antoine Pitrou, 11.08.2013 14:32:
>>> On Sun, 11 Aug 2013 14:16:10 +0200 Stefan Behnel wrote:
> We
> just need to devise a convenience API for that (perhaps by allowing to
> create both the subclass *and* instantiate
On Sun, Aug 11, 2013 at 2:58 AM, Antoine Pitrou wrote:
> On Sat, 10 Aug 2013 18:06:02 -0700
> Eli Bendersky wrote:
> > This solution has problems. For example, in the case of ET it would
> > preclude testing what happens when pyexpat is disabled (remember we were
> > discussing this...). This is
On 11 Aug 2013 09:02, "Stefan Behnel" wrote:
>
> Stefan Behnel, 11.08.2013 14:53:
> > Stefan Behnel, 11.08.2013 14:48:
> >> Antoine Pitrou, 11.08.2013 14:32:
> >>> On Sun, 11 Aug 2013 14:16:10 +0200 Stefan Behnel wrote:
> > We
> > just need to devise a convenience API for that (perhaps by
On Sun, Aug 11, 2013 at 3:33 AM, Antoine Pitrou wrote:
>
> Hi Eli,
>
> On Sat, 10 Aug 2013 17:12:53 -0700
> Eli Bendersky wrote:
> >
> > Note how doing some sys.modules acrobatics and re-importing suddenly
> > changes the internal state of a previously imported module. This happens
> > because:
On Sun, 11 Aug 2013 06:26:55 -0700
Eli Bendersky wrote:
> On Sun, Aug 11, 2013 at 3:33 AM, Antoine Pitrou wrote:
>
> >
> > Hi Eli,
> >
> > On Sat, 10 Aug 2013 17:12:53 -0700
> > Eli Bendersky wrote:
> > >
> > > Note how doing some sys.modules acrobatics and re-importing suddenly
> > > changes t
Nick Coghlan, 11.08.2013 15:19:
> On 11 Aug 2013 09:02, "Stefan Behnel" wrote:
>>> BTW, this already suggests a simple module initialisation interface. The
>>> extension module would expose a function that returns a module type, and
>>> the loader/importer would then simply instantiate that. Nothin
On Sun, Aug 11, 2013 at 6:40 AM, Antoine Pitrou wrote:
> On Sun, 11 Aug 2013 06:26:55 -0700
> Eli Bendersky wrote:
> > On Sun, Aug 11, 2013 at 3:33 AM, Antoine Pitrou
> wrote:
> >
> > >
> > > Hi Eli,
> > >
> > > On Sat, 10 Aug 2013 17:12:53 -0700
> > > Eli Bendersky wrote:
> > > >
> > > > Note
On Sun, 11 Aug 2013 08:49:56 -0700
Eli Bendersky wrote:
> On Sun, Aug 11, 2013 at 6:40 AM, Antoine Pitrou wrote:
>
> > On Sun, 11 Aug 2013 06:26:55 -0700
> > Eli Bendersky wrote:
> > > On Sun, Aug 11, 2013 at 3:33 AM, Antoine Pitrou
> > wrote:
> > >
> > > >
> > > > Hi Eli,
> > > >
> > > > On
On Sun, Aug 11, 2013 at 8:56 AM, Antoine Pitrou wrote:
> On Sun, 11 Aug 2013 08:49:56 -0700
> Eli Bendersky wrote:
>
> > On Sun, Aug 11, 2013 at 6:40 AM, Antoine Pitrou
> wrote:
> >
> > > On Sun, 11 Aug 2013 06:26:55 -0700
> > > Eli Bendersky wrote:
> > > > On Sun, Aug 11, 2013 at 3:33 AM, Ant
On Sun, Aug 11, 2013 at 6:52 AM, Stefan Behnel wrote:
> Nick Coghlan, 11.08.2013 15:19:
> > On 11 Aug 2013 09:02, "Stefan Behnel" wrote:
> >>> BTW, this already suggests a simple module initialisation interface.
> The
> >>> extension module would expose a function that returns a module type,
> an
Eli Bendersky, 11.08.2013 19:43:
> Out of curiosity - can we list actual use cases for this new design? The
> previous thread, admittedly, deals with an isoteric corner-cases that comes
> up in overly-clever tests. If we plan to serious consider these changes -
> and this appears to be worth a PEP
Some tests uses the following idiom:
def test_main():
try:
test.support.run_unittest(...)
finally:
test.support.reap_children()
Other tests uses the following idiom:
def test_main():
key = test.support.threading_setup()
try:
test.support.run_unittest(...)
Richard Oudkerk writes:
> On 11/08/2013 11:00am, Antoine Pitrou wrote:
>> You've got the answer at the bottom:
>>
>>"program finished with exit code 0"
>>
>> So for some reason, the test suite crashed, but with a successful exit
>> code. Buildbot thinks it ran fine.
>
> Was the test terminate
2013/8/11 David Bolen :
>> Was the test terminated because it took too long?
>
> Yes, it looks like it.
>
> This test (and one on the XP-4 buildbot in the same time frame) was
> terminated by an external watchdog script that kills python_d
> processes that have been running for more than 2 hours.
On 11 Aug 2013 09:55, "Stefan Behnel" wrote:
>
> Nick Coghlan, 11.08.2013 15:19:
> > On 11 Aug 2013 09:02, "Stefan Behnel" wrote:
> >>> BTW, this already suggests a simple module initialisation interface.
The
> >>> extension module would expose a function that returns a module type,
and
> >>> the
Hi,
I fixed various bugs in the implementation of the (new) PEP 446:
http://hg.python.org/features/pep-446
At revision da685bd67524, the full test suite pass on:
- Fedora 18 (Linux 3.9), x86_64
- FreeBSD 9.1, x86_64
- Windows 7 SP1, x86_64
- OpenIndiana (close to Solaris 11), x86_64
Some tests
2013/8/12 Victor Stinner :
> I fixed various bugs in the implementation of the (new) PEP 446:
> http://hg.python.org/features/pep-446
>
> At revision da685bd67524, the full test suite pass on: (...)
I also checked the usage of atomic flags. There was a minor bug on
Linux, it is now fixed (remove a
Nick Coghlan, 12.08.2013 00:41:
> On 11 Aug 2013 09:55, "Stefan Behnel" wrote:
> this already suggests a simple module initialisation interface.
> The
> extension module would expose a function that returns a module type,
> and
> the loader/importer would then simply instantiate
32 matches
Mail list logo
