homepage

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.