> That said, looking at the PEP, I was wondering whether fields such as
> ob_type, ob_refcnt, ob_size have to be directly accessible, rather than
> through a macro-turned-into-a-function such as Py_REFCNT().
That they are macros still is primarily for performance reasons. For
ob_type, that may be
On Sun, 12 Sep 2010 19:38:33 +0200
"Martin v. Löwis" wrote:
> > On http://bugs.python.org/issue9778 you elaborated on what the PEP would
> > entail in its current state:
> >
> > “No, vice versa. The PEP promises that the ABI won't change until
> > Python 4. For any change that might break the ABI
> On http://bugs.python.org/issue9778 you elaborated on what the PEP would
> entail in its current state:
>
> “No, vice versa. The PEP promises that the ABI won't change until
> Python 4. For any change that might break the ABI, either a
> backwards-compatible solution needs to be found, or the ch
Am 07.09.2010 19:48, schrieb M.-A. Lemburg:
> "Martin v. Löwis" wrote:
>>
>>> This sounds like the issues such a mix can cause are mostly
>>> theoretical and don't really bother much in practice, so
>>> PEP 384 on Windows does have a chance :-)
>>
>> Actually, the CRT issues (FILE* in particular) h
On Wed, Sep 8, 2010 at 7:59 PM, Nick Coghlan wrote:
> On Wed, Sep 8, 2010 at 6:34 PM, David Cournapeau wrote:
>> In other words, the problem mainly arises when you need to integrate
>> libraries which you can not recompile with the compiler used by
>> python, because the code is not visual-studio
On Wed, Sep 8, 2010 at 6:34 PM, David Cournapeau wrote:
> In other words, the problem mainly arises when you need to integrate
> libraries which you can not recompile with the compiler used by
> python, because the code is not visual-studio compatible, or because
> the library is only available in
On Wed, Sep 8, 2010 at 5:19 PM, Nick Coghlan wrote:
> On Wed, Sep 8, 2010 at 8:34 AM, David Cournapeau wrote:
>> I would turn the question around: what are the cases where you manage
>> to mix CRT and not getting any issues ? This has never worked in my
>> own experience in the context of python
On Wed, Sep 8, 2010 at 8:34 AM, David Cournapeau wrote:
> I would turn the question around: what are the cases where you manage
> to mix CRT and not getting any issues ? This has never worked in my
> own experience in the context of python extensions,
I've done it quite a bit over the years with
On Wed, Sep 8, 2010 at 2:48 AM, M.-A. Lemburg wrote:
> "Martin v. Löwis" wrote:
>>
>>> This sounds like the issues such a mix can cause are mostly
>>> theoretical and don't really bother much in practice, so
>>> PEP 384 on Windows does have a chance :-)
>>
>> Actually, the CRT issues (FILE* in par
"Martin v. Löwis" wrote:
>
>> This sounds like the issues such a mix can cause are mostly
>> theoretical and don't really bother much in practice, so
>> PEP 384 on Windows does have a chance :-)
>
> Actually, the CRT issues (FILE* in particular) have been
> causing real crashes for many years, fo
Hello Martin,
On Sat, 28 Aug 2010 12:04:10 +0200
"Martin v. Löwis" wrote:
> I have now started an initial patch for PEP 384, in the pep-0384 branch.
[...]
On http://bugs.python.org/issue9778 you elaborated on what the PEP would
entail in its current state:
“No, vice versa. The PEP promises tha
On Sat, 04 Sep 2010 15:13:55 +0200
"Martin v. Löwis" wrote:
> > Please consider this: even without relying on PEP 384, using FILE*
> > is /already/ dangerous; because you might compile an extension with a
> > different compiler version than Python was compiled with.
>
> It's only dangerous *if*
> Please consider this: even without relying on PEP 384, using FILE*
> is /already/ dangerous; because you might compile an extension with a
> different compiler version than Python was compiled with.
It's only dangerous *if* you compile with a different compiler.
That's why we take serious precau
> 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 perfectly standard C feature (and a
> widely-used one at that).
> This sounds like the issues such a mix can cause are mostly
> theoretical and don't really bother much in practice, so
> PEP 384 on Windows does have a chance :-)
Actually, the CRT issues (FILE* in particular) have been
causing real crashes for many years, for many people.
Regards,
Martin
> It would be interesting to know how, in practice, these FILE pointers
> come to life. In my experience they are generally obtained via fopen.
I think that experience can't be generalized. I personally guess that
in most cases, the FILE* being passed across CRT boundaries is stdout.
> If that i
On Fri, Sep 3, 2010 at 12:44 PM, Greg Ewing wrote:
> On 02/09/10 09:04, Nick Coghlan wrote:
>
>> I think it would be better if everything dealing with FILE* was a
>> macro rather than a function, yes.
>
> How would that help?
Macros (and, as Antoine pointed out, inline functions) will never
cross
On 02/09/10 09:04, Nick Coghlan wrote:
I think it would be better if everything dealing with FILE* was a
macro rather than a function, yes.
How would that help?
--
Greg
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman
On Wed, Sep 1, 2010 at 10:54 PM, Antoine Pitrou wrote:
> Please consider this: even without relying on PEP 384, using FILE*
> is /already/ dangerous; because you might compile an extension with a
> different compiler version than Python was compiled with. So, if we were
> following you, we should
On Thu, Sep 2, 2010 at 7:19 AM, Antoine Pitrou wrote:
> Maybe I've missed your answer, but what would prevent the "inline"
> solution from working?
Only PEP 7 (since standard support for inline is a C99 feature)
On the other hand, if gcc (including cygwin/mingw) and MSVC support it
(even with no
On Thu, 2 Sep 2010 07:04:31 +1000
Nick Coghlan wrote:
> On Wed, Sep 1, 2010 at 10:54 PM, Antoine Pitrou wrote:
> > Please consider this: even without relying on PEP 384, using FILE*
> > is /already/ dangerous; because you might compile an extension with a
> > different compiler version than Pyth
On Wed, Sep 1, 2010 at 10:54 PM, Antoine Pitrou wrote:
> Please consider this: even without relying on PEP 384, using FILE*
> is /already/ dangerous; because you might compile an extension with a
> different compiler version than Python was compiled with. So, if we were
> following you, we should
On 01/09/2010 13:54, Antoine Pitrou wrote:
[snip...]
Please consider this: even without relying on PEP 384, using FILE*
is /already/ dangerous; because you might compile an extension with a
different compiler version than Python was compiled with. So, if we were
following you, we should rip out
Le mercredi 01 septembre 2010 à 22:43 +1000, Nick Coghlan a écrit :
> On Wed, Sep 1, 2010 at 8:42 AM, Antoine Pitrou wrote:
> > After all, we don't usually try to workaround platform-specific
> > bugs (not as a low level such as the C API level); at worse, we mention
> > their existence in the doc
On Wed, Sep 1, 2010 at 8:42 AM, Antoine Pitrou wrote:
> After all, we don't usually try to workaround platform-specific
> bugs (not as a low level such as the C API level); at worse, we mention
> their existence in the docs.
You persist in viewing the allowance of multiple C runtimes in a
single
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
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
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 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.
>
>
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
On Mon, Aug 30, 2010 at 6: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
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 384 should be
to define a standard API for Python, (hopefully) spann
On Mon, Aug 30, 2010 at 1:43 AM, Antoine Pitrou wrote:
> On Sun, 29 Aug 2010 22:16:57 +1000
> Nick Coghlan wrote:
> (actually, I'm baffled that Windows has such problems, and I would
> suggest that it's not Python's job to shield Windows
> application developers from Windows-specific development
On Aug 29, 2010, at 8:16 AM, Nick Coghlan wrote:
> However, since even platforms other than Windows aren't immune to
> version upgrades of the standard C runtime
Aren't they? I don't know of any other platform that lets you have two versions
of libc linked into a single address space. Linux has h
On Sun, 29 Aug 2010 22:16:57 +1000
Nick Coghlan wrote:
>
> However, since even platforms other than Windows aren't immune to
> version upgrades of the standard C runtime, I'm still more comfortable
> with the idea that the strict ABI should refuse to pass FILE* pointers
> across extension module
On Sun, Aug 29, 2010 at 7:10 PM, Antoine Pitrou wrote:
> On Sun, 29 Aug 2010 18:41:45 +1000
> Nick Coghlan wrote:
>> I believe both that option, and my third option, would run into
>> trouble due to the potential for errno confusion.
>
> I don't understand. What's the difference with the macro yo
On Sun, 29 Aug 2010 18:41:45 +1000
Nick Coghlan wrote:
> On Sun, Aug 29, 2010 at 6:24 PM, Antoine Pitrou wrote:
> > On Sun, 29 Aug 2010 09:20:56 +1000
> > Nick Coghlan wrote:
> >>
> >> Four options come to mind:
> >>
> >> - just leave it out of the limited API, extensions can do their own
> >>
On Sun, Aug 29, 2010 at 6:24 PM, Antoine Pitrou wrote:
> On Sun, 29 Aug 2010 09:20:56 +1000
> Nick Coghlan wrote:
>>
>> Four options come to mind:
>>
>> - just leave it out of the limited API, extensions can do their own
>> thing to print objects
>> - leave PyObject_Print out of the limited API,
On Sun, 29 Aug 2010 09:20:56 +1000
Nick Coghlan wrote:
>
> Four options come to mind:
>
> - just leave it out of the limited API, extensions can do their own
> thing to print objects
> - leave PyObject_Print out of the limited API, but create a
> PyObject_PrintEx that takes a Python IO stream vi
On Sun, Aug 29, 2010 at 4:52 AM, "Martin v. Löwis" wrote:
>> This is from tp_new and tp_dealloc, right? I think we should probably
>> provide assessors PyObject_Alloc and PyObject_FreeObject.
>
> Correct, and yes, that sounds like a good approach.
>
>>> - PyObject_Print is used, but can't be suppo
> This is from tp_new and tp_dealloc, right? I think we should probably
> provide assessors PyObject_Alloc and PyObject_FreeObject.
Correct, and yes, that sounds like a good approach.
>> - PyObject_Print is used, but can't be supported, as it uses a FILE*
>> parameter
>
> I thought tp_print was
2010/8/28 "Martin v. Löwis" :
> I have now started an initial patch for PEP 384, in the pep-0384 branch.
> This has the following features:
> - modules can be compiled under Py_LIMITED_API
> - Tools/scripts/abitype.py converts C code containing static
> PyTypeObject definitions to use the new API
I have now started an initial patch for PEP 384, in the pep-0384 branch.
This has the following features:
- modules can be compiled under Py_LIMITED_API
- Tools/scripts/abitype.py converts C code containing static
PyTypeObject definitions to use the new API for type definitions.
The following as
61 matches
Mail list logo
