[Python-Dev] Re: RFC on Callable Type Syntax
My apologies! Must be an issue with my email client rendering. Erik On Mon, 11 Oct 2021, Guido van Rossum wrote: On Mon, Oct 11, 2021 at 3:22 PM Erik Demaine wrote: On Mon, 11 Oct 2021, Guido van Rossum wrote: No, I didn't write that, Lukasz did. > I always found the following more obvious: > > def data_to_table(d: Iterable[Mapping[str, float]], *, sort: bool = False, reversed: bool = False) -> Table: > ...___ Python-Dev mailing list -- python-dev@python.org To unsubscribe send an email to python-dev-le...@python.org https://mail.python.org/mailman3/lists/python-dev.python.org/ Message archived at https://mail.python.org/archives/list/python-dev@python.org/message/RXMHRH55S2EBYBVFGPLFXKKVA2RWZIYL/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: RFC on Callable Type Syntax
On Mon, 11 Oct 2021, Guido van Rossum wrote: I always found the following more obvious: def data_to_table(d: Iterable[Mapping[str, float]], *, sort: bool = False, reversed: bool = False) -> Table: ... @dataclass class Stream: converter: data_to_table | None def add_converter(self, converter: data_to_table) -> None: self.converter = converter Another possibility would be that functions can't be used as their types directly, but need a casting operator like so: ``` def add_converter(self, converter: typeof(data_to_table)) -> None: self.converter = converter ``` It's too bad `type` is already taken, but `typeof` is what TypeScript calls it: https://www.typescriptlang.org/docs/handbook/2/typeof-types.html -- perhaps there is a better distinguishing name, but I'll keep using `typeof` for the sake of this discussion. For static analysis, `typing.typeof` should only be used for variables that are assigned (certain) constant values and aren't re-assigned. Potentially this could be a much more general solution. Maybe interesting return values for `typeof` could be defined for `dict`s, `namedtuple`s, etc. And it could co-exist with the (P, Q) -> R proposal (which, as you probably know, is how TypeScript expresses function types). One disadvantage of this is that now arguments HAVE TO be named which raises questions: - should they be considered at type checking time? - how to express "I don't care"? I think it'd be natural for types constructed via `typeof` to include the argument names; I'd intend for an object "just like" this one. But you could imagine another type operator that drops details like this, e.g. `typing.forget_argument_names(typing.typeof(data_table))`. Erik -- Erik Demaine | edema...@mit.edu | http://erikdemaine.org/___ Python-Dev mailing list -- python-dev@python.org To unsubscribe send an email to python-dev-le...@python.org https://mail.python.org/mailman3/lists/python-dev.python.org/ Message archived at https://mail.python.org/archives/list/python-dev@python.org/message/QVW4I2CJVEETXM7I437WYIXLCYSOP4B4/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Porting python.gram to Python
Dear python-dev,
I've been working on a port of cpython/Grammar/python.gram from C (as
currently used in all the {} expressions to build the AST) to Python, directly
building nodes via the ast package. My motivation for this (as opposed to
calling ast.parse, which uses the C parser) is to make it easy to experiment
with adding features to the syntax, without having to build CPython. Porting
is mostly straightforward, but it is a fair amount of work, because there are
a lot of expressions to port
My first question is whether anyone is working on this as well (or has
already done so and I missed it), to avoid duplication of effort.
Assuming not, my next question is where this belongs. Some natural options I
see:
1. Add it to cpython as a grammar maintained in parallel with the C grammar.
This would mean more maintenance when the grammar changes, but the plus side
is it guarantees that the two grammars (and ast) remain synchronized.
2. PyPy
3. 3rd party library (e.g., my own repo)
Let me know what you think would be best.
Erik
--
Erik Demaine | edema...@mit.edu | http://erikdemaine.org/
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at
https://mail.python.org/archives/list/python-dev@python.org/message/UM7ANICTBDU3Q2DLKFZIK6C6OU3THKP4/
Code of Conduct: http://python.org/psf/codeofconduct/
