Hi,
Is there any kind of internal file descriptor counter that can be
queried to debug issues with leaking resources?
It can be used in tests to check that all tests are finish with 0
opened descriptors.
It will be very useful while porting Python applications from Unix to
Windows. Unix is more to
On 31/08/2010 7:54 AM, Nick Coghlan wrote:
On Tue, Aug 31, 2010 at 12:47 AM, Michael Foord
wrote:
An extension compiled for one version of Python will be linked against the
version of the C runtime used by that version of Python (if it is compiled
with the same version of Visual Studio of cour
On Tue, Aug 31, 2010 at 6:54 AM, Nick Coghlan wrote:
> Hmm... that last point is a bit of any issue actually, since it also
> flows the other way (changes made via the locale module won't be
> visible to any extension modules using a different C runtime). So I
> suspect mixing C runtimes is stil
On Tue, Aug 31, 2010 at 12:47 AM, Michael Foord
wrote:
> An extension compiled for one version of Python will be linked against the
> version of the C runtime used by that version of Python (if it is compiled
> with the same version of Visual Studio of course).
>
> If the extension binary is to re
On Tue, Aug 31, 2010 at 12:30 AM, Barry Warsaw wrote:
> On Aug 30, 2010, at 07:31 AM, Nick Coghlan wrote:
>
>>Since part of the point of PEP 384 is to support multiple versions of the C
>>runtime in a single process
>
> Is it? That's certainly not explicit in the Rationale section of PEP 384.
>
>
With the help of bbreport, I collected these informations:
- 3 tests are freezing randomly : test_bz2, test_codecs and test_tarfile
- it happens on XP-4 and Windows7 builders (branches 2.7 and 3.1
only, trunk is not affected)
- it seems to happen since revisions 84345 and 84346 which fixed issue
Since the recent history of my two Windows buildbots has turned ugly,
I figured I'd mention that they both (XP and Windows 7) have started
generating quite a few GUI C++ RTL runtime pop-up assertions, which
has been throwing a wrench into things until they get manually
cleared. I first noticed the
On Aug 28, 2010, at 12:29 PM, Martin v. Löwis wrote:
>The intention is that there is indeed just one stable ABI, so one
>configuration is the supported one, and that should be the "default"
>build.
>
>As for the specific settings, my analysis would be this:
>- pydebug: not supported by the stable
On Aug 28, 2010, at 01:12 AM, Georg Brandl wrote:
>I don't think I'll want to bother with porting doc fixes to the 2.6
>branch.
Thanks for the feedback everyone. We will not be porting doc fixes to
release26-maint. I would be open to a doc fix that was specifically
addressing a security concern
On 30/08/2010 17:35, Barry Warsaw wrote:
On Aug 30, 2010, at 10:18 PM, Nick Coghlan wrote:
Since the Linkage section of PEP 384 specifically states the
availability of a generic "python3.dll" that dynamically redirects to
the relevant "python3y.dll" to allow an extension module to run
against
On Aug 30, 2010, at 10:18 PM, Nick Coghlan wrote:
>Since the Linkage section of PEP 384 specifically states the
>availability of a generic "python3.dll" that dynamically redirects to
>the relevant "python3y.dll" to allow an extension module to run
>against any 3.2 or later Python version as a goal
On Aug 30, 2010, at 07:31 AM, Nick Coghlan wrote:
>Since part of the point of PEP 384 is to support multiple versions of the C
>runtime in a single process
Is it? That's certainly not explicit in the Rationale section of PEP 384.
It seems to me that the PEP is all about inoculating extension bu
Le lundi 30 août 2010 à 22:18 +1000, Nick Coghlan a écrit :
>
> FILE* is very different from the other things you mention. Function
> call conventions and binary representations are defined in the C
> standard. FILE*, on the other hand, is explicitly called out as an
> opaque reference completely
On Mon, Aug 30, 2010 at 7:43 AM, Antoine Pitrou wrote:
> On Mon, 30 Aug 2010 07:31:34 +1000
> Nick Coghlan wrote:
>> Since part of the point of
>> PEP 384 is to support multiple versions of the C runtime in a single
>> process, [...]
>
> I think that's quite a maximalist goal. The point of PEP 38
14 matches
Mail list logo
