Re: PEP 612: Parameter Specification Variables
I personally prefer shorter to type names, so ArgsSpec looks better in my eyes. Concatenate and ListVariadic seems satisfactory for positional arguments. You know, Python supports positional-only, keyword-only, *args and **kwargs also. Could ArgsSpec (or ParameterSpecifications) be extended to explicitly provide these kinds of parameters explicitly? Another thing is the default argument. The exact value of the default is not significant for typing but a flag of the default value presence is important. Can ArgsSpec provide this information? -- Thanks, Andrew Svetlov
Hi Andrew, After discussing offline with Ivan & Jukka, I think folks in general are partial towards shorter names. For that reason the three of us came to a consensus on ParamSpec. I much less partial to ArgSpec, as I'd like to preserve the distinction between parameters (the interface of a callable, and thus what a ParamSpec would actually capture), and arguments, which are particular to a given call-site. What are your thoughts on ParamSpec? As for all of those kinds of parameter kinds (positional only, keyword only, *args, **kwargs, default), the complexity of those and their inability to be captured by other typing constructs was the driving force behind the idea of ParamSpecs. I'm not sure what you mean by "provid[ing] these kinds of parameters explicitly", but the implementation of pyre_extensions.ParameterSpecification we have does in fact capture all of that information and propagate it. For example: ``` P = ParamSpec("P") def decorator(x: Callable[P, int]) -> Callable[P, str]: ... @decorator def foo(__positional_only: bool, normal: int, *args: str, keyword_only: float, **kwargs: int): -> int... reveal_type(foo) # equivalent in every way to the above definition, only altering the return type ``` Is that what you're wondering about? Best, Mark Mendoza
I will say that for me, `ArgSpec` makes me think of `inspect.getargspec()` and friends: https://docs.python.org/3/library/inspect.html#inspect.getargspec.
+1 to what Bret said.
I think a lot of people use argument and parameter interchangeably too, at
least that's what I noticed.
On Thu, Jan 2, 2020, 4:10 PM Brett Cannon
I will say that for me, `ArgSpec` makes me think of `inspect.getargspec()` and friends: https://docs.python.org/3/library/inspect.html#inspect.getargspec. _______________________________________________ Typing-sig mailing list -- typing-sig@python.org To unsubscribe send an email to typing-sig-leave@python.org https://mail.python.org/mailman3/lists/typing-sig.python.org/
Hi Mark.
ParamSpec sounds satisfactory for me; the name is short enough to type
it without the code completion help :)
Regarding explicit support for pos-only and kw-only parameters.
I thought about things like
@add_logging
def f(a: int, /, b: str, c: float) -> None:
...
@add_logging
def g(a: int = 0) -> None:
...
"f()" can be called as f(1, "abc", c=3.14) or f(1, b="abc", c=3.14);
f(a=1, b="abc", c=3.14) is forbidden for example.
"g()" allows g() and g(1).
There are very many different call variants with interesting corner cases.
I suspect that the proposed PEP ignores these differences, please
correct me if I'm wrong.
On Fri, Jan 3, 2020 at 2:38 AM Ethan Smith
+1 to what Bret said.
I think a lot of people use argument and parameter interchangeably too, at least that's what I noticed.
On Thu, Jan 2, 2020, 4:10 PM Brett Cannon
wrote: I will say that for me, `ArgSpec` makes me think of `inspect.getargspec()` and friends: https://docs.python.org/3/library/inspect.html#inspect.getargspec. _______________________________________________ Typing-sig mailing list -- typing-sig@python.org To unsubscribe send an email to typing-sig-leave@python.org https://mail.python.org/mailman3/lists/typing-sig.python.org/
_______________________________________________ Typing-sig mailing list -- typing-sig@python.org To unsubscribe send an email to typing-sig-leave@python.org https://mail.python.org/mailman3/lists/typing-sig.python.org/
-- Thanks, Andrew Svetlov
Hi Andrew, My intention in the writing of this PEP was to require implementations to handle all of those cases. Our example implementation in Pyre does in fact preserve all of that information, and your example would work in the way you described. Is there some wording that you think we should add to the PEP in order to make this more explicit? Best, Mark Mendoza
Hi Andrew, My intention in the writing of this PEP was to require implementations to handle all of those cases. Our example implementation in Pyre does in fact preserve all of that information, and your example would work in the way you described. Is there some wording that you think we should add to the PEP in order to make this more explicit? Best, Mark Mendoza
Let me add my +1 to this.
To me, ParamSpec is just longer (and slower to pronounce) for a reason
that's debatable and smells like hyper-correctness. After all we typically
write *args and **kwargs so the term "arguments" still comes up frequently
when discussing function definitions.
I used to believe in the rule that "parameters" are what's part of the
function definition and "arguments" are used in a function call, but now I
think that the distinction is just a distraction, and trying to follow it a
lost cause and probably a form of hyper-correctness.
On Thu, Jan 2, 2020 at 4:38 PM Ethan Smith
+1 to what Bret said.
I think a lot of people use argument and parameter interchangeably too, at least that's what I noticed.
On Thu, Jan 2, 2020, 4:10 PM Brett Cannon
wrote: I will say that for me, `ArgSpec` makes me think of `inspect.getargspec()` and friends: https://docs.python.org/3/library/inspect.html#inspect.getargspec. _______________________________________________ Typing-sig mailing list -- typing-sig@python.org To unsubscribe send an email to typing-sig-leave@python.org https://mail.python.org/mailman3/lists/typing-sig.python.org/
_______________________________________________ Typing-sig mailing list -- typing-sig@python.org To unsubscribe send an email to typing-sig-leave@python.org https://mail.python.org/mailman3/lists/typing-sig.python.org/
-- --Guido van Rossum (python.org/~guido) *Pronouns: he/him **(why is my pronoun here?)* http://feministing.com/2015/02/03/how-using-they-as-a-singular-pronoun-can-c...
Don’t have strong opinions on this and definitely don’t want the naming to block the PEP.
I don’t think correctness when it comes to terminology for something as fundamental as a programming language is a bad thing. Given how prevalent Python is as a teaching tool in CS101 classes I think using the right words for things – even if the distinction is not as clear in Python – to me personally seems like something that’s worth prioritizing.
From: Guido van Rossum
participants (6)
-
Andrew Svetlov
-
Brett Cannon
-
Dominik Gabi
-
Ethan Smith
-
Guido van Rossum
-
Mark Mendoza