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
On 28 Aug, 2010, at 12:29, Martin v. Löwis wrote:
- wide-unicode: this is a tricky one. I'm tempted to say that the
stable ABI should always use a Py_UNICODE that matches the platform's
wchar_t. Alternative proposals are welcome.
Sizeof(wchar_t) is 4 on OSX, but the Apple frameworks use a
On Tue, 31 Aug 2010 11:12:17 +0900
David Cournapeau courn...@gmail.com 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
Ronald Oussoren wrote:
On 28 Aug, 2010, at 12:29, Martin v. Löwis wrote:
- wide-unicode: this is a tricky one. I'm tempted to say that the
stable ABI should always use a Py_UNICODE that matches the platform's
wchar_t. Alternative proposals are welcome.
Sizeof(wchar_t) is 4 on OSX, but
Michael Foord wrote:
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
Hi,
2010/8/31 Antoine Pitrou solip...@pitrou.net:
David Cournapeau courn...@gmail.com wrote:
As far as IO is concerned, FILE* is just a special case of a more
generic issue, though, so maybe this could be a bit reworded. For
example, file descriptor cannot be shared between runtimes either.
So it means that, for example, a FileIO object couldn't be shared
between runtimes either? How about a socket object?
Do you want to forbid FileIO and socket objects as part of the API?
Python objects don't have this concern: all methods of FileIO are implemented
in a single file
M.-A. Lemburg:
Is it possible to have multiple versions of the lib C loaded
on Windows ?
Yes. It is possible not only to mix C runtimes from different
vendors but different variants from a single vendor.
Historically, each vendor has shipped their own C runtime
libraries. This was also
On Aug 31, 2010, at 11:22 AM, M.-A. Lemburg wrote:
BTW: Wasn't one of the main reasons for having versioned .so files
the idea to be able to have UCS2 and UCS4 versions installed
side-by-side ?
Yes. This isn't an issue for PEP 3149 because it adds a flag to the shared
library file name for wide
If you wanted to do something like this in the Python stdlib, you'd
have to monkey-patch (with a proxy/wrapper) all places that can open
or close a filedescriptor -- os.open, os.popen, os.close, file
open/close, socket open/close, and probably a bunch more that I've
forgotten. Also some extension
On Aug 31, 2010, at 10:03 AM, Guido van Rossum wrote:
On Linux you can look somewhere in /proc, but I don't know that it
would help you find where a file was opened.
/dev/fd is actually a somewhat portable way of getting this information. I
don't think it's part of a standard, but on Linux
On 05:22 pm, gl...@twistedmatrix.com wrote:
On Aug 31, 2010, at 10:03 AM, Guido van Rossum wrote:
On Linux you can look somewhere in /proc, but I don't know that it
would help you find where a file was opened.
/dev/fd is actually a somewhat portable way of getting this
information. I don't
On Tue, 2010-08-31 at 17:40 +, exar...@twistedmatrix.com wrote:
On 05:22 pm, gl...@twistedmatrix.com wrote:
On Aug 31, 2010, at 10:03 AM, Guido van Rossum wrote:
On Linux you can look somewhere in /proc, but I don't know that it
would help you find where a file was opened.
/dev/fd is
On Tue, Aug 31, 2010 at 4:54 AM, M.-A. Lemburg m...@egenix.com wrote:
Is it possible to have multiple versions of the lib C loaded
on Windows ?
Yes, and it's a pretty common situation. The fopen() that I call within a
DLL may not be the same fopen() called by another DLL. When writing a
Daniel Stutzbach wrote:
On Tue, Aug 31, 2010 at 4:54 AM, M.-A. Lemburg m...@egenix.com wrote:
Is it possible to have multiple versions of the lib C loaded
on Windows ?
Yes, and it's a pretty common situation. The fopen() that I call within a
DLL may not be the same fopen() called by
Neil Hodgson wrote:
M.-A. Lemburg:
Is it possible to have multiple versions of the lib C loaded
on Windows ?
Yes. It is possible not only to mix C runtimes from different
vendors but different variants from a single vendor.
Historically, each vendor has shipped their own C
Daniel Stutzbach wrote:
Likewise, a FILE * isn't safe to pass around, unless I can guarantee
that the application really is one big happy family compiled against the
same version of the C library.
Given that, it seems to me that it's a mistake for Python
to provide any APIs that take a FILE*
On Wed, Sep 1, 2010 at 7:49 AM, M.-A. Lemburg m...@egenix.com wrote:
Yes, and it's a pretty common situation. The fopen() that I call within a
DLL may not be the same fopen() called by another DLL. When writing a DLL
for Windows, the API must be designed with the assumption that anything
On Tue, Aug 31, 2010 at 2:15 PM, Mark Hammond skippy.hamm...@gmail.com wrote:
It would be interesting to know how, in practice, these FILE pointers come
to life. In my experience they are generally obtained via fopen. If that is
broadly true, then a middle-ground may be for Python to expose
On Wed, 01 Sep 2010 10:23:42 +1200
Greg Ewing greg.ew...@canterbury.ac.nz wrote:
Daniel Stutzbach wrote:
Likewise, a FILE * isn't safe to pass around, unless I can guarantee
that the application really is one big happy family compiled against the
same version of the C library.
Given
M.-A. Lemburg wrote:
But isn't exactly that a major problem for Python ?
An extension written for a different MS CRT version would
not be able to safely free a buffer allocated by the Python
DLL.
Python provides its own set of memory alloc/free functions
to deal with this exact problem. For
On Wed, Sep 1, 2010 at 1:42 AM, Antoine Pitrou solip...@pitrou.net wrote:
What I think would be a mistake would be to define the API in terms of
Windows-specific quirks. All this discussion seems bent on satisfying
the needs of Windows developers at the expense of non-Windows
developers. FILE*
Hello pydev,
This is a meta-question which I hope is appropriate in this list (**).
Recently I've switched to to VIM as my main development platform (in terms
of code editing and navigation). Working on the Python code-base is both a
concrete requirement and a yardstick for me - I want to be as
23 matches
Mail list logo
