Nick Coghlan wrote:
> [PEP]
>> Function-like macros (in particular, field access macros) remain
>> available to applications, but get replaced by function calls
>> (unless their definition only refers to features of the ABI, such
>> as the various _Check macros)
> [MAL]
> Includ
[PEP]
> Function-like macros (in particular, field access macros) remain
> available to applications, but get replaced by function calls
> (unless their definition only refers to features of the ABI, such
> as the various _Check macros)
[MAL]
Including Py_INCREF()/Py_DECREF() ?
Functions declared in the following header files are not part
of the ABI:
- cellobject.h
- classobject.h
- code.h
- frameobject.h
- funcobject.h
- genobject.h
- pyarena.h
- pydebug.h
- symtable.h
- token.h
- traceback.h
>>> I don't th
The structure of type objects is not available to applications;
declaration of "static" type objects is not possible anymore
(for applications using this ABI).
>>> Hmm, that's going to create big problems for extensions that
>>> want to expose a C-API for their types: Type checks are
Martin v. Löwis wrote:
>> Now, with the PEP, I have a feeling that the Python C-API
>> will in effect be limited to what's in the PEP's idea of
>> a usable ABI and open up the non-inluded public C-APIs
>> to the same rate of change as the private APIs.
>
> That's certainly not the plan. Instead, t
Nick Coghlan wrote:
> M.-A. Lemburg wrote:
>> Now, with the PEP, I have a feeling that the Python C-API
>> will in effect be limited to what's in the PEP's idea of
>> a usable ABI and open up the non-inluded public C-APIs
>> to the same rate of change as the private APIs.
>
> Not really - before t
> Now, with the PEP, I have a feeling that the Python C-API
> will in effect be limited to what's in the PEP's idea of
> a usable ABI and open up the non-inluded public C-APIs
> to the same rate of change as the private APIs.
That's certainly not the plan. Instead, the plan is to have
a stable ABI
M.-A. Lemburg wrote:
> Now, with the PEP, I have a feeling that the Python C-API
> will in effect be limited to what's in the PEP's idea of
> a usable ABI and open up the non-inluded public C-APIs
> to the same rate of change as the private APIs.
Not really - before this PEP it was already fairly
Martin v. Löwis wrote:
> Thomas Wouters reminded me of a long-standing idea; I finally
> found the time to write it down.
>
> Please comment!
> ...
>
Up until this PEP proposal, we had a very simple scheme for
the Python C-API: all documented functions and variables with
a "Py" prefix were part o
> Something I haven't seen explicitly mentioned as yet (in the PEP or the
> python-dev list discussion) are the memory management APIs and the FILE*
> APIs which can cause the MSVCRT versioning issues on Windows.
>
> Those would either need to be excluded from the stable ABI or else
> changed to u
Jim Jewett gmail.com> writes:
>
> > The accessor macros to these fields (Py_REFCNT, Py_TYPE, Py_SIZE)
> > are also available to applications.
>
> There have been several experiments in memory management, ranging from
> not bothering to change the refcount on permanent objects like None,
> to pro
Martin v. Löwis wrote:
> Functions and function-like Macros
> --
>
> All functions starting with _Py are not available to applications.
> Also, all functions that expect parameter types that are unavailable
> to applications are excluded from the ABI, such as PyAST_
Martin v. Löwis wrote:
It also might make it easier for alternate implementations to support
the same API so some modules could work cross implementation - but I
suspect that's a non-goal of this PEP :).
Indeed :-) I'm also skeptical that this would actually allow
cross-implementat
>>> It also might make it easier for alternate implementations to support
>>> the same API so some modules could work cross implementation - but I
>>> suspect that's a non-goal of this PEP :).
>>>
>>
>> Indeed :-) I'm also skeptical that this would actually allow
>> cross-implementation module
On May 17, 2009, at 4:54 PM, Martin v. Löwis wrote:
Currently, each feature release introduces a new name for the
Python DLL on Windows, and may cause incompatibilities for extension
modules on Unix. This PEP proposes to define a stable set of API
functions which are guaranteed to be available f
Martin v. Löwis wrote:
Dino Viehland wrote:
Dirkjan Ochtman wrote:
It would seem to me that optimizations are likely to require data
structure changes, for exactly the kind of core data structures that
you're talking about locking down. But that's just a high-level view,
I might be wron
Dirkjan Ochtman wrote:
>
> It would seem to me that optimizations are likely to require data
> structure changes, for exactly the kind of core data structures that
> you're talking about locking down. But that's just a high-level view,
> I might be wrong.
>
In particular I would guess that ref co
Dino Viehland wrote:
> Dirkjan Ochtman wrote:
>> It would seem to me that optimizations are likely to require data
>> structure changes, for exactly the kind of core data structures that
>> you're talking about locking down. But that's just a high-level view,
>> I might be wrong.
>>
>
>
> In part
Dirkjan Ochtman wrote:
> On Mon, May 18, 2009 at 12:07 AM, "Martin v. Löwis"
> wrote:
>> I fail to see the relationship, so: no effect that I can see.
>>
>> Why do you think that optimization efforts could be related to
>> the PEP 384 proposal?
>
> It would seem to me that optimizations are like
On Mon, May 18, 2009 at 12:43 AM, Antoine Pitrou wrote:
> Unless I'm misunderstanding something, Martin doesn't advocate locking data
> structures down (except a couple of outliers such as Py_buffer). An
> ABI-compliant application mustn't tinker directly with Python's data
> structures,
> but us
Dirkjan Ochtman ochtman.nl> writes:
>
> It would seem to me that optimizations are likely to require data
> structure changes, for exactly the kind of core data structures that
> you're talking about locking down. But that's just a high-level view,
> I might be wrong.
Unless I'm misunderstanding
>> Header Files and Preprocessor Definitions
>> -
>>
>> Applications shall only include the header file Python.h (before
>> including any system headers), or, optionally, include pyconfig.h, and
>> then Python.h.
>
> What about structmember.h? It's not yet
On Mon, May 18, 2009 at 12:07 AM, "Martin v. Löwis" wrote:
> I fail to see the relationship, so: no effect that I can see.
>
> Why do you think that optimization efforts could be related to
> the PEP 384 proposal?
It would seem to me that optimizations are likely to require data
structure changes
Martin v. Löwis schrieb:
> Header Files and Preprocessor Definitions
> -
>
> Applications shall only include the header file Python.h (before
> including any system headers), or, optionally, include pyconfig.h, and
> then Python.h.
What about structmember.
>> Functions declared in the following header files are not part
>> of the ABI:
>> - cellobject.h
>> - classobject.h
>> - code.h
>> - frameobject.h
>> - funcobject.h
>> - genobject.h
>> - pyarena.h
>> - pydebug.h
>> - symtable.h
>> - token.h
>> - traceback.h
>
> What kind of effect does this have
On Sun, May 17, 2009 at 10:54 PM, "Martin v. Löwis" wrote:
> Excluded Functions
> --
>
> Functions declared in the following header files are not part
> of the ABI:
> - cellobject.h
> - classobject.h
> - code.h
> - frameobject.h
> - funcobject.h
> - genobject.h
> - pyarena.h
> - py
26 matches
Mail list logo
