Stephan Tolksdorf schrieb: > While Travis' proposal encompasses the data format functionality within > the struct module and overlaps with what ctypes has to offer, it does > not aim to replace ctypes.
This discussion could have been a lot shorter if he had said so. Unfortunately (?) he stated that it was *precisely* a motivation of the PEP to provide a standard data description machinery that can then be adopted by the struct, array, and ctypes modules. > I also do not understand why the data format type should attempt to > fully describe arbitrarily complex data formats, like fragmented > (non-continuous) data structures in memory. You'd probably need a full > programming language for that anyway. For an FFI application, you need to be able to describe arbitrary in-memory formats, since that's what the foreign function will expect. For type safety and reuse, you better separate the description of the layout from the creation of the actual values. Otherwise (i.e. if you have to define the layout on each invocation), creating the parameters for a foreign function becomes very tedious and error-prone, with errors often being catastrophic (i.e. interpreter crashes). Regards, Martin _______________________________________________ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
