[Python-Dev] __slots__ (was: mandatory use of cyclic GC ...)

[Thomas Heller]

Christian Tismer <tismer@tismer.com> writes:

> Thomas Heller wrote:
> 
> [extending __slots__]
> 
> > May I suggest to use an ordered sequence (of pairs) instead of a dict
> > for __slots__.  Then you also can completely control the layout that
> > C code sees and construct C compatible structures or other data types
> > from pure Python code.
> 
> Huh, are you fast!
> I was about to propose exactly this same thing:
> If we deal with flat types, then we also can
> define their precise layout.
> 
> Using a dict would anyway be nicer to read,
> because the colons are quite illustrative.
> For literal dicts, it would be imaginable to
> hook into the build_dict and grab the objects
> from the stack in order...
> ...I see Guido's head shaking :-)
Yes...

It would be nice to write something like this
  D(x=1, y=2, z=3)
or
 { "x": 1, "y": 2, "z": 3 }
to create a sequence which maintains the order, but I've given up
on this.
OTOH, the sequence of tuples looks somewhat like Scheme (replace
the '[' by '(', and remove the commas ;-)

> 
> Another way would be not to go away from __slots__ as
> a simple list, but allow to use structure objects
> with the necessary attribute like name, type, whatever
> instead of the name strings. This could go as far as
> to also allow redefining getters and setters at the same
> time.
> 
> Is this going too far?
> Am I re-inventing something like CTypes?
The aasic ideas are IIUC the same.

The core of ctypes (if you would like to name it this way) is to
provide an (extensible) system of classes which describe C data types.

These are used to

- construct from Python and manipulate from Python *and* from C code
  instances of these data types transparently

- convert Python objects into C data (for C function calls)

- convert C data into Python objects (for results from C function calls)

- define new C data types structures, unions, pointers, whatever,
  from pure Python code (kind of 'typedef')

> > <plug>
> > [...]
> </plug>

Where is my validator =;-)

> 
> What would this C data type be? Other structs as well,
> or only atomic types? Do you think of even specifying
> (name, bitsize, alignment), or is this overdone?
(Bitsizes are not (yet) supported, alignment is derived using standard
rules from the base data types.)

See above: anything which you could also do in C.
I'm currently working on a simple COM client and server 'framework',
where you define, use, and implement COM interfaces in pure Python
with help from ctypes.

I could further explain this if there's interest, but this is probably
more on-topic for pypy-dev or ctypes-users.

> 
> ciao - chris

Thomas

PS: The reason I'm explaining this in detail several times is that I
think that ctypes has large potential (although it's too unsafe to go
into the Python core), and I want to attract more people looking at
it.  I want to make sure I got everything correct in the API.
Understandable if you know Python and C at least.