On Thu, Jul 30, 2020 at 7:27 PM Rebecca Chen via Typing-sig <typing-sig@python.org> wrote:
Hi Mark,

I really like this PEP - it'll be useful to have more expressive ways of annotating decorators. The current form looks pretty good to me. A few comments:

* `typing.type_variable_operators` is quite verbose. How about just `typing.operators`?

Hm, why a submodule at all?
 
* For user-defined generic classes using a ParamSpec, I think it would be useful to include an example of how such a class is constructed, since it wasn't obvious to me where values with the parameters_expression type would come from at runtime. Is
class X(Generic[P]):
  def __init__(self, x: Callable[P, int]): ...
and variations the only way to create such a class? Or do P.args and P.kwargs come into play in some way?

Yes, this would be helpful to readers.

* "Inside the function, args has the type P.args, not Tuple[P.args, ...] as would be with a normal annotation (and likewise with the **kwargs)" (in the ParamSpec semantics section). If I'm reading this correctly, it's saying that P.args represents the full type of args, Tuple and all, unlike a normal args annotation which describes just the contained type. Why is that the case? It seems like it would be better to not have this inconsistency unless it's necessary.

It is indeed an inconsistency. But how else would you spell it? In PEP 484, the type of `*args` and `**kwargs` is *always* the type for an individual item (so without the tuple or dict). But `P.args` and `P.kwargs` doesn't have a single item type. If we could make up new syntax, we could write e.g. `f(*args: *P.args, **kwargs: *P.kwargs)` but I really don't think we should try to invent new syntax -- it would make it infeasible to use the new feature before Python 3.10. Essentially `P.args` and `P.kwargs` are magic cookies -- the type checker will have to special-case these no matter what. (And these cannot be used in any other context, the PEP makes clear.)
 
Also, some typos and such I noticed:

* "an concrete instance" has an extraneous "n": https://github.com/python/peps/blame/master/pep-0612.rst#L231
* I found the x_int_y_str, y_int_x_str example hard to read, since the slight differences between the two foo calls are hard to spot. One way I can think of to improve this would be to make the function names shorter (maybe just x_y and y_x?) so it takes less time to spot the difference.
* Is this supposed to be Callable[[int, str], int]? https://github.com/python/peps/blame/master/pep-0612.rst#L291
* The parameter to the remove function is defined as `x` and later referred to as `f`: https://github.com/python/peps/blame/master/pep-0612.rst#L465

Thanks! I fixed the first and the last of these (and two I caught myself) and quietly pushed the correction. The 2nd and 3rd I'll leave for Mark to fix.

And FWIW, once we are clear on the final few issues, I intend to recommend this PEP for approval by the SC. (In fact, I think the only contentious issue is the namespace where Concatenate should live.)

--Guido
 
Best,
Rebecca

On Mon, Jul 13, 2020 at 8:47 PM Mark Mendoza <mendoza.mark.a@gmail.com> wrote:
Hi All,
I want to start off by thanking everyone that gave feedback on the first round of review of PEP 612.  Your feedback illuminated a lot of things that I think have made this PEP a lot better.
Over the past few weeks I have had the time to rewrite much of that document to integrate all of that feedback.
Notably, this included integrating `typing.type_variable_operators.Concatenate` to support decorators that modify a finite number of positional parameters.

With that being said, I'd appreciate another round of feedback from all of you to determine whether this form of the PEP is ready to move on to the Steering Council.

Thanks again!

Mark Mendoza
_______________________________________________
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/
Member address: rechen@google.com
_______________________________________________
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/
Member address: guido@python.org


--
--Guido van Rossum (python.org/~guido)