This really needs a new thread, maybe even a new PEP, but ...
On Sat, Jan 8, 2022 at 5:27 PM Steven D'Aprano <st...@pearwood.info> wrote:
> > > If I can make a wild suggestion: why not create a little language
> > > for type specifications?
>
> Any time we are tempted to prefix a question with "Why not ...", the
> question is backwards. The right question is, "why should we ...".
>
OK -- we should create a little language for type specifications because
it's proving to be really difficult to cleanly express types with Python's
current allowable syntax. This is documented by the PEP that started this
thread -- if you have to expand the syntax of Python to make clean
expression of typing possible, it's time to make a new language., rather
than complicating Python.
> ... we should be conservative when it comes
> to language changes (including syntax).
exactly -- we are now faced with changing language syntax to satisfy the
needs of one particular optional corner of Python -- we should be
particularly very careful about that!
(and it's not just callables -- there was a long thread in python-ideas
about a yeear (?) ago about extending indexing syntax, that started with
the needs of typing.
> > If you look at other programming languages you’ll see that the “type
> > > definition sub-language” is often completely different from the
> > > “execution sub-language”
>
> Yes, and that makes other programming languages harder to use and harder
> to learn.
I would argue that hat's because you have to learn type specifications at
all -- not because they have different syntax.
IN fact, in my very limited C experience I found it very confusing that
often declare a function was the same as defining it -- which is this bit
of code doing? In practice the declarations are usually in a header file,
but that's not (I think) required by the language. IT would be less
confusing if the type declaration were clearly different.
But anyway, right now in PYthon, type declarations use standard
Pyhton syntax, but they use it in a non-convensional way. Is it more or
less confusing that:
list[int]
means "a list full of integers"
and
a_list[an_int] means return the value (which could be any type) of the item
at index an_int?
Does the same syntax with very different meanings make it easier or harder
to learn??
> For example, the arrow syntax for Callable `(int) -> str` (if accepted)
> could be a plain old Python expression, usable anywhere the plain old
> Python expression `Callable[[int], str]` would be.
>
but what would `` -> `` mean ?!?! if all it meant was create an instance of
the Callable class, then you have a typing mini-language that can be used
anywhere -- more or less confusing ?!?
Or it could be used as a new way to spell lambda -- I know a lot of folks
would like a cleaner way to spell lambda, but would that really make the
language simpler?
I think a good way of putting it is that the typing module defines a
> little DSL (Domain Specific Language) for type hints, but annotations
> themselves are just Python expressions.
>
OK -- and if you had t" " -- then that would be a Python expression, too :-)
>
> > > What if we created a little language that is clearly flagged, for
> > > example as t”….” or t’….’? Then we could simply define the
> > > typestring language to be readable, so you could indeed say t”(int,
> > > str) -> bool”. And we could even allow escapes (similar to
> > > f-strings) so that the previous expression could also be specified,
> > > if you really wanted to, as t”{typing.Callable[[int, str], bool}”.
>
> The following are not rhetorical questions. I don't know the answers,
> which is why I am asking.
>
>
> 1. Are these t-strings only usable inside annotations, or are they
> expressions that are usable everywhere?
>
as you say -- not much point if they aren't usable anywhere -- why not?
> 2. If only usable inside annotations, why bother with the extra prefix
> t" and suffix "? What benefit do they give versus just the rule
> "annotations use this syntax"?
>
Agreed - -though I think there is a certain clarity about it -- also, it
would make a the transition a bit easier if the idea was adopted.
> 3. If usable outside of annotations, what runtime effect do they have?
> The t-string must evaluate to an object. What object?
>
I'm just spit-balling here, but maybe an "Annotation Object" -- which could
be a pre-compiled or normalized version of the annotation string. kind of
like a pre-compiled regex, maybe? I have not idea if MyPy and friends have
sucha. normalized version, but it does seem like it could be handy.
> 4. If the syntax allowed inside the t-string is specified as part of the
> Python language definition, why do we need the prefix and suffix?
>
> E.g. if we can write:
>
> # Equivalent to T = Callable[[int], str]
> T = t"(int) -> str"
>
> and have the arrow syntax defined by the language, then surely the
> prefix and suffix is redundant.
>
I think the idea is that , e.g. -> wouldn't be allowed outside an t-string
and other things, like [] might mean sometihng different.
But in the end, if they are not going to be pre-processed, anon only
allowed in annotations, then yes, no nead for the t"" at all.
I think the first question is whether a typing language is a good idea at
all -- then we can worry about these details.
This is not the case with f-strings, where they actually do add
> something to the code: `f"{expr}"` is not the same as `expr`.
>
right, and f-strings ultimately evaluate to normal strings as well.
-CHB
--
Christopher Barker, PhD (Chris)
Python Language Consulting
- Teaching
- Scientific Software Development
- Desktop GUI and Web Development
- wxPython, numpy, scipy, Cython
_______________________________________________
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/ZEDPRAJJMECJUVFM2G2OR3YEHTRHPTFV/
Code of Conduct: http://python.org/psf/codeofconduct/
