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 ef
On Wed, Sep 1, 2010 at 1:42 AM, Antoine Pitrou 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*" is a perfectl
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 e
On Wed, 01 Sep 2010 10:23:42 +1200
Greg Ewing 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 that, it seems to
On Tue, Aug 31, 2010 at 2:15 PM, Mark Hammond 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 something
> like Py_fope
On Wed, Sep 1, 2010 at 7:49 AM, M.-A. Lemburg 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
>> returned b
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*
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 ow
Daniel Stutzbach wrote:
> On Tue, Aug 31, 2010 at 4:54 AM, M.-A. Lemburg 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
On Tue, Aug 31, 2010 at 4:54 AM, M.-A. Lemburg 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 DLL
for Windows
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.
> >
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'
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 Lin
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 m
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 wi
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
> > 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 fil
Hi,
2010/8/31 Antoine Pitrou :
> David Cournapeau 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.
>
> Er, really?
Yes, on Windows
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 allo
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 o
On Tue, 31 Aug 2010 11:12:17 +0900
David Cournapeau 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 r
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 us
22 matches
Mail list logo
