Stefan Krah added the comment: I would be willing to write an (alternative) PEP, but I'm not quite satisfied with my own proposal yet. Also, I'd need to understand the positional-only part better, but the _cursesmodule.c example does not seem to compile here. :)
So, *disregarding* the positional-only situation, I've been thinking about the os.stat example and what I want from the DSL: 1) We already have a partial DSL, namely "O&|$O&p". This is concise, unambiguous and well understood. 2) "O&" denotes a custom converter function with a user specified type. For example, path_converter() has type [string, bytes, int] -> path_t, where [string, bytes, int] are the alternatives that path_converter() accepts. "p" can be seen as a default converter function with type bool -> int. 3) Specifying the kind (required, etc.) and the default values of arguments is most readable in the standard Python form: os.stat(path, *, dir_fd=None, follow_symlinks=True) -> stat_result I've tried to come up with a declaration that merges 2) and 3), while reusing the existing conversion specifiers. It emphasizes the converter functions (which ultimately decide the static typing): /*[preprocessor] # Declaration os.stat ( { path, path_converter : [string, bytes, int] -> path_t }, *, { dir_fd=None, OS_STAT_DIR_FD_CONVERTER : [int, None] -> int }, { follow_symlinks=True, "p" : bool -> int } ) -> stat_result # User code path_t path = PATH_T_INITIALIZE("stat", 0, 1); int dir_fd = DEFAULT_DIR_FD; int follow_symlinks = 1; [preprocessor]*/ The declaration should be read as follows: Declare os.stat as a function ... 1) taking the required argument "path", to which the user-supplied function path_converter() of type [string, bytes, int] -> path_t will be applied for conversion. 2) taking a keyword-only argument "dir_fd" with the default value None, to which the user-supplied function OS_STAT_DIR_FD_CONVERTER() of type [int, None] -> int will be applied for conversion. 3) taking a keyword-only argument "follow_symlinks" with the default value True, to which the default converter "p" of type bool -> int will be applied for conversion. ... returning stat_result. The user code section could be type-checked against the declaration. What are the advantages? 1) The structure of the Python function is part of the declaration. 2) AFAICS, using the conversion specifiers directly eliminates the need for these flags: encoding, length, zeroes, bitwise, nullable, types, keyword-only, required, default, converter. 3) The converter-oriented statically typed spec forces the user to think about the types (a good thing IMO). 4) Due to the rigid structure (better) error messages should be easier to produce. If this sounds like a viable alternative, I can try to write a PEP. ---------- _______________________________________ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue16612> _______________________________________ _______________________________________________ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com