On Thu, Dec 23, 2021 at 5:13 PM Guido van Rossum wrote:
> On Thu, Dec 23, 2021 at 3:24 PM Steven D'Aprano
> wrote:
>
>> On Thu, Dec 23, 2021 at 02:09:50PM -0800, Guido van Rossum wrote:
>>
>> > Without decorator too (that was Lukasz’ idea). Why bother with the
>> > decorator (*if* we were to go
Steven D'Aprano wrote:uble the size of Callable.
> > I think it takes only the characters needed to write the name IntToIntFunc.
> ... you may only use it once.
Could you provide an example where it is only used once?
The only way I can imagine is that you use it here when when defining your
> On 26 Dec 2021, at 02:16, Steven D'Aprano wrote:
>
>> Hard enough that you really ought to help your reader out with a
>> name,
>
> What are you going to name it?
>
>Int_and_Float_and_Int_returns_List_of_Int_Function
>
> tells us nothing that
>
>(int, float, int) -> list[int]
>
I've done some more thinking more about Serhiy's worry about changing a
factory function to a class, and how that would change the meaning of
type-hints. Say:
def spam(x: Eggs, y:Cheese) -> _Aardvark:
# actual factory function implementation
# later, we use it as a function
On Fri, Dec 24, 2021 at 06:24:03PM -, Jim J. Jewett wrote:
> Steven D'Aprano wrote:
> > In comparison, Mark's version:
> > @Callable
> > def IntToIntFunc(a:int)->int:
> > pass
> > # in the type declaration
> > func: IntToIntFunc
> > uses 54 characters, plus spaces and
On Fri, Dec 24, 2021 at 11:53:22AM +0200, Serhiy Storchaka wrote:
> Some library provide function foo() which returns an instance of private
> type _Foo and people start using it as a type hint.
If people want to shoot themselves in the foot, is it our job to stop
them? Typically the only
Steven D'Aprano wrote:
> In comparison, Mark's version:
> @Callable
> def IntToIntFunc(a:int)->int:
> pass
> # in the type declaration
> func: IntToIntFunc
> uses 54 characters, plus spaces and newlines (including 7 punctuation
> characters); it takes up three extra lines, plus a
I like the Callable decorator idea very much.
It supports all Python function flavors out of the box, isn't it?
Also, what is about allowing to make callable types from existing functions
(and even methods maybe) with type hints?
def f(a: int, /, b: float) -> str:
return str(a*b)
F =
24.12.21 00:09, Guido van Rossum пише:
> Without decorator too (that was Lukasz’ idea). Why bother with the
> decorator (*if* we were to go there)?
It is errorprone.
Some library provide function foo() which returns an instance of private
type _Foo and people start using it as a type hint. A new
On Thu, Dec 23, 2021 at 7:38 PM Barry Warsaw wrote:
>
> On Dec 23, 2021, at 17:09, Guido van Rossum wrote:
> >
> > Mark's proposal was
> > ```
> > @Callable
> > def func(params): pass
> > ```
> > My question is, why does it need `@Callable`? Lukasz proposed just using
> > any (undecorated)
There were multiple threads about this (or maybe the thread was split by
mailers) and I already stated that the colon-free (and hence body-less)
syntax with def is too confusing to consider. Please look it up in the
archives. Happy Holidays!
On Thu, Dec 23, 2021 at 18:36 Steven D'Aprano wrote:
> Just to be clear, by "function prototype", do you mean what PEP 677
> calls a Callable Type?
A "function prototype" would be a concrete type that exists alongside
the function type. The objects would hold the arguments, defaults,
annotations and name of a function.
> What sort of implications
On Fri, Dec 24, 2021 at 01:54:35PM +1100, Chris Angelico wrote:
> My reading of this is that a function IS the type of a function with
> that signature, just like how None means the type NoneType. Is that
> correct?
That's not the status quo, but I think the idea is that it will be.
Except that
On Fri, Dec 24, 2021 at 01:28:44PM +1100, Steven D'Aprano wrote:
> Honestly, I cannot see a single positive to using `def` statements.
...
> This is not a rhetorical question.
Hmm, I think I may have come up with one.
If we did teach type checkers to use actual functions as prototypes,
that
On Fri, Dec 24, 2021 at 1:36 PM Steven D'Aprano wrote:
> > My question is, why does it need `@Callable`? Lukasz proposed just using
> > any (undecorated) function, with the convention being that the body is
> > `...` (to which I would add the convention that the function *name* be
> >
On Thu, Dec 23, 2021 at 05:09:18PM -0800, Guido van Rossum wrote:
> > def func(params)
> >
> > makes a Callable type object?
> >
>
> No, no, no. That syntax has already been discredited.
It has? Where? Have I missed something?
This thread is about using that syntax as an alternative to
Yes, and yes. (Or the PEP could say it has to be ‘…’ and static checkers
could enforce it. But checkers already carry everything they need to check
this with them, for checking calls.)
Downside of this idea is that it requires you to invent a name for every
callable type you use.
On Thu, Dec
On Thu, Dec 23, 2021 at 07:04:17PM -, 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
>
On Dec 23, 2021, at 17:09, Guido van Rossum wrote:
>
> Mark's proposal was
> ```
> @Callable
> def func(params): pass
> ```
> My question is, why does it need `@Callable`? Lukasz proposed just using any
> (undecorated) function, with the convention being that the body is `...` (to
> which I
On Thu, Dec 23, 2021 at 3:24 PM Steven D'Aprano wrote:
> On Thu, Dec 23, 2021 at 02:09:50PM -0800, Guido van Rossum wrote:
>
> > Without decorator too (that was Lukasz’ idea). Why bother with the
> > decorator (*if* we were to go there)?
>
> So that
>
> def func(params): pass
>
> creates a
On Thu, Dec 23, 2021 at 02:09:50PM -0800, Guido van Rossum wrote:
> Without decorator too (that was Lukasz’ idea). Why bother with the
> decorator (*if* we were to go there)?
So that
def func(params): pass
creates a function object, and
def func(params)
makes a Callable type object?
Without decorator too (that was Lukasz’ idea). Why bother with the
decorator (*if* we were to go there)?
On Thu, Dec 23, 2021 at 13:16 Joao S. O. Bueno
wrote:
> My eyes are bleeding with these incomplete function definitions.
> If you are using decorators and "def", then, please, there is no
>
My eyes are bleeding with these incomplete function definitions.
If you are using decorators and "def", then, please, there is no
need for special syntax that would just be a syntax error
in "normal"Python., Just add ": pass" to the end.
If eyes bleeding is not enough of an argument for you:
the
On 2021-12-23 19:04, asleep.c...@gmail.com wrote:
Hello and thank you for the much needed feedback.
One thing that you must consider is that function prototypes
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
Hello and thank you for the much needed feedback.
One thing that you must consider is that function prototypes
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
On Thu, Dec 23, 2021 at 03:00:03PM -, asleep.c...@gmail.com wrote:
> Mark Shannon initially proposed that functions be used as types and provided
> this example:
>
> @Callable
> def IntToIntFunc(a:int)->int:
> pass
>
> def flat_map(
> l: list[int],
> func: IntToIntFunc
> )
How about instead of omitting the body, it contains a single expression,
say:
def int(x: float): -> float
typing.Prototype
It doesn’t totally break protocol to have a function complie differently
depending on its content— that’s done with generator functions.
-CHB
On Thu, Dec 23, 2021 at
27 matches
Mail list logo
