PEP 646: Add explicit section on endorsements #2055
Conversation
|
Oops - fixed. |
pep-0646.rst
Outdated
| Endorsements | ||
| ============ | ||
|
|
||
| This purpose of this PEP is to make life easier for the numerical computing |
There was a problem hiding this comment.
While numerical computing is a key motivation, I don't think it is the only purpose of the PEP. As the numerical computing folks have pointed out, this PEP would be worth having even for non-Tensor purposes. The PEP itself links to a python/typing issue with many use cases.
Perhaps we can clarify that a bit here. Otherwise, it reads like Tensor authors are the only, narrow set of users for this feature and this feature would live or die by adoption from the few libraries, which is not true.
For example, there are plenty of real-world callbacks that expect a variadic *args:
def call_soon(callback: Callable[[*Ts], R], *args: *Ts) -> R:
...
return callback(*args)
There was a problem hiding this comment.
Good point. What do you think of the revised wording?
pep-0646.rst
Outdated
| community. How likely is it that numerical computing libraries will actually | ||
| make use of the features proposed in this PEP? |
There was a problem hiding this comment.
I think it's worth clarifying that variadic tuples will be useful in Tensor library stubs, not their official implementations. In other words, even if PyTorch, NumPy, etc. never use variadic tuples in their source code, users would still benefit from having stubs with variadic tuples. For the purposes of typechecking, what matters is the stub. These libraries are often written in C++ anyway, meaning that they aren't really the target users. The main targets are people who use Tensors in their code and want to catch shape errors up front.
So, while it is nice to have endorsements from Tensor libraries, I don't see it as make-or-break for Tensor shape types. The community will be maintaining a set of stubs anyway, like we began in pytorch_examples.
There was a problem hiding this comment.
That's true, but if the steering council are sceptical, I think this argument won't sway them: it would be strange for a language to adopt a controversial language feature only to support community stubs. I think the weight of this section depends on big library authors themselves making use of what we propose (even if it's in stubs that they provide rather than the actual implementation, considering that the implementation is mostly not Python).
|
I have asked to someone in JAX if he could provide an endorsement and about Bas I am waiting for a reply. |
|
Sorry for the slow reply - busy couple of weeks! |
@fylux Any updates? |
|
Bas replied that he will do it (he is catching up after holidays) but of Jax finally they feel that they do not have much to say. |
|
Great - thanks @fylux and @ BvB93! @gvanrossum I think this is ready to merge now. |
As suggested by @gvanrossum.
@fylux Anything else to add here - should we ask the JAX folks you talked to whether they want to contribute a statement for the PEP? And any word from Bas?
@pradeep90 too.