On Thu, Dec 23, 2021 at 07:04:17PM -0000, asleep.c...@gmail.com wrote:
> One thing that you must consider is that function prototypes
Just to be clear, by "function prototype", do you mean what PEP 677
calls a Callable Type?
> have a few implications beyond typing but it seems like you're
> only looking at it as a tool for type hinting. The interpreter will
> create a function prototype object regardless of if you forget your
> decorator, it needs to pass something to the decorator after all.
What sort of implications beyond typing?
Some questions:
1. What kind of object does `def Func(a:int)->int` create, if you leave
out the decorator? Is that what you are calling a "function prototype
object"?
2. What does it need the @Callable decorator for?
3. What can you do with it, apart from typing?
4. What happens if you leave out the annotations and just say
`def Func(a)` alone?
5. Do you have any response to my other criticisms about this syntax?
> After reading through your reply, I am seeing that the main concern
> is the bloat added by the lambda keyword.
Perhaps you should re-read my reply. The lambda keyword is the *least*
part of my dislike of this proposal.
> The fact that lambda is hard to type has been felt by almost everyone
> who has ever used Python,
Such exaggerations don't help your case. I have never felt the need to
type a lambda expression, and doubt I'm so very unusual.
Annotations have only existed for less than half of Python's existence.
Even today, I doubt that as many as half of Python's user base are heavy
users of typing. Or even casual users of typing. And many of them would
not use lambda, or at least not in places where adding typing to it
would add any value.
In any case, allowing type-hints in lambda expressions is independent of
the question of using the lambda keyword to declare a function
prototype. I have no objection in principle to allowing annotations in
lambda expressions if such a thing would actually be useful. But that
doesn't mean I want to see lambda used as function prototype syntax:
def map(func: lambda (obj: Any) -> Any, items: Sequence[Any]) ->
Sequence[Any]
especially not in preference to just using arrow syntax:
def map(func: (Any)-> Any, items: Sequence[Any]) -> Sequence[Any]
> this isn't just a problem that would be introduced by
> function prototypes. PEP 677 has taken the lazy approach to solving
> this issue
What does that mean? What is lazy about it?
> and has prioritized type hinting over functionality. PEP 667
> also suggests the usage of => for lambdas which would likely
> never be accepted because of the confusion it would cause.
Syntactic sugar for lambda is not part of PEP 667, it merely references
the fact that people have suggested using => as shorthand for a lambda.
For what its worth, I was skeptical about using two different arrows
(one for declaring callable types, one for functions) when I first heard
the idea (I think it was Guido who mentioned it?). But I've come to
believe that whatever confusion there might be in using two arrows
"do I use -> or => here? I never remember which is which"
will be less, not more, than the confusion due to using the same arrow
for both contexts. That is, I think, the experience from other
languages. (Kotlin if I remember correctly? Maybe not.)
But that's a discussion for when somebody writes a PEP for lambda
shortcut syntax.
> As someone who has used typing with Python, I do think that a new
> callable syntax is needed, but I truly believe that PEP 677 is taking the
> wrong approach.
>
> So what if we broke every Python program in existence by creating a
> new lambda syntax, how would it look?
Creating new syntax is backwards compatible: it doesn't break existing
code that is syntactically correct. Only removing, or changing the
meaning of, existing syntax will break "every Python program in
existence".
I doubt the Steering Council would accept such breakage.
--
Steve
_______________________________________________
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/MTWBA5T5ISPCL7S4PM6KE77AIEMPFDTT/
Code of Conduct: http://python.org/psf/codeofconduct/
