Travis E. Oliphant schrieb: > Travis E. Oliphant wrote: >> Thanks for all the comments that have been given on the data-type >> (data-format) PEP. I'd like opinions on an idea for revising the PEP I >> have. > >> >> 1) We could define a special string-syntax (or list syntax) that covers >> every special case. The array interface specification goes this >> direction and it requires no new Python types. This could also be seen >> as an extension of the "struct" module to allow for nested structures, etc. >> >> 2) We could define a Python object that specifically carries data-format >> information. >> >> >> Does that explain the goal of what I'm trying to do better? > > In other-words, what I'm saying is I really want a PEP that does this. > Could we have a discussion about what the best way to communicate > data-format information across multiple extension modules would look > like. I'm not saying my (pre-)PEP is best. The point of putting it in > it's infant state out there is to get the discussion rolling, not to > claim I've got all the answers. IIUC, so far the 'data-object' carries information about the structure of the data it describes. Couldn't it go a step further and have also some functionality? Converting the data into a Python object and back? This is what the ctypes SETFUNC and GETFUNC functions do, and what also is implemented in the struct module... Thomas
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4