On 2021-03-12 19:57, Eric V. Smith wrote:
Basically, I want to add a flag, to each field, stating whether the
field results in a normal parameter, a positional-only parameter, or a
keyword-only parameter to __init__. Then when I'm generating __init__,
I'll examine those flags and put the positional-only ones first,
followed by the normal ones, followed by the keyword-only ones.
The trick becomes: how do you specify what type of parameter each field
represents?
Without getting too much into the details of your proposal, my main
reaction to all this is that it's either trying to shoehorn too much
into the typing annotations, or being too timid about what to put in the
typing annotations.
If we want to use typing annotations to document types then we should
use them for that, and not try to sneakily also use them to define
actual behavior.
If, on the other hand, we *are* okay with using type annotations for
defining behavior, then there isn't any need to resort to odd tricks
like `_: dataclasses.KW_ONLY`. You can just put the behavior constraint
directly in the annotation:
@dataclass
class Foo:
a: (Any, dataclasses.KW_ONLY)
# or
b: {'type': Any, 'kw_only': True}
# or (where "Any" and kw_only are is some new objects provided by a
library that handles this usage)
c: Any + kw_only
. . . and then say that it's the job of dataclass and of typecheckers to
separate the different sorts of information.
I don't see value in trying to force additional information into type
annotations while simultaneously trying to obey various conventions
established by typechecking libraries that expect types to be specified
in certain ways. I was never a big fan of the type annotations and I
think this kind of thing illustrates the difficulty of having
"advisory-only" annotations that aren't supposed to affect runtime
behavior but then gradually begin to do so via things like dataclasses.
If type annotations are advisory only they should remain 100% advisory
only and for use only by static type checkers with zero effect on the
code's runtime behavior. If we're going to use type checking to
influence runtime behavior then we should acknowledge that people can
put ANYTHING in the type annotations and thus ANY library can make
totally arbitrary use of any type annotation to perform arbitrary
actions at runtime.
So basically, if we want to indicate stuff like keyword-only-ness using
type annotations, that's fine, but we should acknowledge that at that
point we are no longer annotating types. We are using type annotation
syntax to implement arbitrary runtime behavior, and we should accept
that doing that may break typecheckers or make life painful for their
maintainers.
--
Brendan Barnwell
"Do not follow where the path may lead. Go, instead, where there is no
path, and leave a trail."
--author unknown
_______________________________________________
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at
https://mail.python.org/archives/list/python-ideas@python.org/message/L72RGBLIZ7I64IE6IV5VQVS7KJ7X3L4P/
Code of Conduct: http://python.org/psf/codeofconduct/
