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 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 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 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 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 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 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 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 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 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 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 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 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 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
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?".
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
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
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 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 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, 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, 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, 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 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