On Thu, Apr 22, 2021 at 7:53 PM Paul Moore wrote:
> I wonder whether type checkers could handle a "magic" type (let's call
> it DuckTyped for now :-)) which basically means "infer a protocol
> based on usage in this function". So if I do:
>
> def my_fn(f: DuckTyped):
> with f:
> data
On Thu, Apr 22, 2021 at 5:03 PM Ryan Gonzalez wrote:
>
> On Apr 21, 2021, 5:29 PM -0500, Paul Bryan , wrote:
>
> As demonstrated, protocols don't get us there because duck typing isn't a
> matter of having an object exhibit all of the attributes of a duck, but
> rather some subset of attributes
On Thu, 22 Apr 2021 at 11:06, Chris Angelico wrote:
>
> On Thu, Apr 22, 2021 at 7:53 PM Paul Moore wrote:
> > I wonder whether type checkers could handle a "magic" type (let's call
> > it DuckTyped for now :-)) which basically means "infer a protocol
> > based on usage in this function". So if I
On Thu, 22 Apr 2021 at 09:46, Chris Angelico wrote:
> Maybe in some cases, the "smaller protocols" option is practical, but
> it would need to have a useful name. For instance, if it needs to be
> readable, iterable, closeable, and autocloseable via
> __enter__/__exit__, that's ... uhh a
On Thu, 22 Apr 2021 at 11:21, Paul Moore wrote:
>
> On Thu, 22 Apr 2021 at 11:06, Chris Angelico wrote:
> >
> > Someone will likely correct me if this is inaccurate, but my
> > understanding is that that's exactly what you get if you just don't
> > give a type hint. The point of type hints is to
On Thu, 22 Apr 2021 at 13:23, Adrian Freund wrote:
>
> According to PEP 484 all missing annotations in checked functions should be
> handled as Any. Any is compatible with all types.
Yep, that's what I understood to be the case.
> I think from a technical standpoint it should be possible to
On Thu, 22 Apr 2021 at 15:22, Adrian Freund wrote:
>
> On April 22, 2021 3:15:27 PM GMT+02:00, Paul Moore
> wrote:
> >but that's *absolutely* as far as I'd want to go. Note in particular
> >that I don't want to constrain the return value
> The problem is that this isn't enough to have a type
Please let's not try to make Python a "typesafe" language. The success
of Python owes a lot to the fact that duck typing is approachable,
flexible and powerful.
Even if you advocate static typing, I think it's a very good idea to
limit the ambition of the type system if you want to keep most
Am 22.04.21 um 10:42 schrieb Chris Angelico:
File-like objects are used VERY frequently in the stdlib, and actual
open file objects have quite a large interface. The use-case is a
pretty real one: "if I were to create a simulant file object to pass
to json.load(), what methods do I need?".
On April 22, 2021 3:15:27 PM GMT+02:00, Paul Moore wrote:
>On Thu, 22 Apr 2021 at 13:23, Adrian Freund wrote:
>>
>> According to PEP 484 all missing annotations in checked functions should be
>> handled as Any. Any is compatible with all types.
>
>Yep, that's what I understood to be the
According to PEP 484 all missing annotations in checked functions should be
handled as Any. Any is compatible with all types.
I think from a technical standpoint it should be possible to infer protocols
for arguments for most functions, but there are some edge cases where this
would not be
On Thu, Apr 22, 2021 at 4:11 AM Paul Moore wrote:
> On Thu, 22 Apr 2021 at 11:21, Paul Moore wrote:
> >
> > On Thu, 22 Apr 2021 at 11:06, Chris Angelico wrote:
> > >
> > > Someone will likely correct me if this is inaccurate, but my
> > > understanding is that that's exactly what you get if
On Thu, Apr 22, 2021, at 1:01 PM, Brett Cannon wrote:
>
>
> On Thu, Apr 22, 2021 at 4:11 AM Paul Moore wrote:
>> On Thu, 22 Apr 2021 at 11:21, Paul Moore wrote:
>> >
>> > On Thu, 22 Apr 2021 at 11:06, Chris Angelico wrote:
>> > >
>> > > Someone will likely correct me if this is inaccurate,
On Thu, Apr 22, 2021 at 6:57 AM Paul Moore wrote:
>
> On Thu, 22 Apr 2021 at 09:46, Chris Angelico wrote:
> > Maybe in some cases, the "smaller protocols" option is practical, but
> > it would need to have a useful name. For instance, if it needs to be
> > readable, iterable, closeable, and
On Thu, Apr 22, 2021 at 5:43 AM Chris Angelico wrote:
> File-like objects are used VERY frequently in the stdlib, and actual
> open file objects have quite a large interface. The use-case is a
> pretty real one: "if I were to create a simulant file object to pass
> to json.load(), what methods do
On Thu, Apr 22, 2021 at 10:47 AM Matthew Einhorn wrote:
> In PyCharm, the above code will result in it highlighting the number `12`
with the following warning: "Type 'int' doesn't have expected attribute
'close'"
Which gives yet another use for type hints: helping out IDEs.
> If instead you
On 4/22/2021 9:15 AM, Paul Moore wrote:
Absolutely, I see no problem with "use duck typing for this argument"
being opt-in.
As in x: 'duck'? or x: '!', where '!' means
'infer it!', or
from typing import Infer
... x: Infer
?
Ditto for -> ?
--
Terry Jan Reedy
On 4/22/21 5:00 PM, Paul Moore wrote:
> On Thu, 22 Apr 2021 at 15:22, Adrian Freund wrote:
>> On April 22, 2021 3:15:27 PM GMT+02:00, Paul Moore
>> wrote:
>>> but that's *absolutely* as far as I'd want to go. Note in particular
>>> that I don't want to constrain the return value
>> The problem
On Wed, Apr 21, 2021 at 7:31 PM Paul Bryan wrote:
> As demonstrated, protocols don't get us there because duck typing isn't a
> matter of having an object exhibit all of the attributes of a duck, but
> rather some subset of attributes to be used by the consumer. I want this duck
> to quack;
On Thu, 22 Apr 2021 at 21:40, Adrian Freund wrote:
> If I understand correctly your concerns with inferring return types for
> inferred protocols are that it might be to restrictive and prevent
> gradual typing. Here are some examples to show how gradual typing would
> still work.
OK, I have no
On Wed, Apr 21, 2021 at 4:44 PM Christopher Barker wrote:
>> You say this like it's a bad thing, but how is this avoidable, even in
>> principle? Structural typing lets you check whether Foo is duck-shaped
>> -- has appropriate attribute names, etc. But quacking like a duck is
>> harder: you also
On Fri, Apr 23, 2021 at 11:22 AM Larry Hastings wrote:
>
>
> On 4/20/21 10:03 AM, Mark Shannon wrote:
>
> If you guarded your code with `isinstance(foo, Sequence)` then I could not
> use it with my `Foo` even if my `Foo` quacked like a sequence. I was forced
> to use nominal typing; inheriting
On Fri, Apr 23, 2021 at 10:33 AM Chris Angelico wrote:
>
> On Fri, Apr 23, 2021 at 11:22 AM Larry Hastings wrote:
> >
> >
> > On 4/20/21 10:03 AM, Mark Shannon wrote:
> >
> > If you guarded your code with `isinstance(foo, Sequence)` then I could not
> > use it with my `Foo` even if my `Foo`
On 4/20/21 10:03 AM, Mark Shannon wrote:
If you guarded your code with `isinstance(foo, Sequence)` then I could
not use it with my `Foo` even if my `Foo` quacked like a sequence. I
was forced to use nominal typing; inheriting from Sequence, or
explicitly registering as a Sequence.
If I'm
On Apr 21, 2021, 5:29 PM -0500, Paul Bryan , wrote:
> As demonstrated, protocols don't get us there because duck typing isn't a
> matter of having an object exhibit all of the attributes of a duck, but
> rather some subset of attributes to be used by the consumer. I want this duck
> to quack;
25 matches
Mail list logo
