On 18-06-18 01:45 AM, Daniel Pope wrote:
Is this for a public C API or just internal to Pygame?
It is internal to Pygame, though if it is formalized and documented
someone might use it in another package.
I know from experience how much more of a headache it is to
build/distribute native extensions that depend on other native
extensions' ABIs (numpy, specifically).
Do Pygame Surface/Sound objects support the Buffer Protocol? This
would be a convenient way to to read and update object data without
needing to compile against Pygame.
Pygame has better buffer support than Python 3.
On Sun, 17 Jun 2018, 12:19 Thomas Kluyver, <tak...@gmail.com
<mailto:tak...@gmail.com>> wrote:
I'm not really familiar with C APIs, but I thought that the 0/-1
inconsistency was necessary because 0 may be a valid return value
in some contexts, and there is no -1 if you're using a unsigned
integer type. Looking quickly at the Python docs, the pattern
seems to be that functions returning a pointer return NULL on
error, and the rest use -1 to indicate an error - though I don't
know if that's always followed.
I would think that API changes don't belong in a 1.9.x release,
but that's not my decision. :-)
On 15 June 2018 at 23:45, Lenard Lindstrom <le...@telus.net
<mailto:le...@telus.net>> wrote:
Hi everyone,
A part of the preparation for pygame 2 I have documented the
functions and types exported by various pygame extension
modules. For instance, the pygame.surface module exports C
functions for creating and accessing pygame.Surface instances.
These are used in other modules, such as pygame.display and
pygame.image, where surfaces are created. In total, twelve
extension modules make C functions available for use in other
extension modules.
While documenting the C API I renamed C types, functions, and
variables to be consistent with Python's PEP 7. Names starting
with 'Py' and 'Pg' were changed to use the 'pg' prefix. This
avoids conflicts with possible future Python C functions as
well as make the pygame naming convention consistent. I have
also found other inconsistencies in the pygame C API.
Functions that return a Python object are consistent in
returning NULL to indicate an error. However, for functions
that return an error code, some may use -1 to indicate an
error, while others use 0. Should I make an effort to make
pygame error handling consistent within the C API? Would it
make sense to do this before pygame 1.9.4 is released, or wait
until pygame 2? Python is not much help since it has mixed
error codes within its C API.
Lenard Lindstrom
