Am 24.04.2021 um 01:26 schrieb Gregory P. Smith:
Practically speaking, one issue I have is how easy it is to write
isinstance or issubclass checks. It has historically been much more
difficult to write and maintain a check that something looks like a duck.
`if hasattr(foo, 'close') and
On Thu, 22 Apr 2021 12:47:42 -0300
Luciano Ramalho wrote:
>
> Go is by far the most successful statically typed language created so
> far in the 21st century,
First, it seems gratuitous to restrict your search to "created so
far in the 21st century". I suppose that allows you to eliminate
On Wed, 21 Apr 2021 12:36:34 -0700
Christopher Barker wrote:
>
> But that's not what duck typing is (at least to me :-) ) For a given
> function, I need the passed in object to quack (and yes, I need that quack
> to sound like a duck) -- but I usually don't care whether that object
> waddles
Chris Angelico writes:
> On Sat, Apr 24, 2021 at 10:14 AM Nick Coghlan wrote:
> > Duck typing usually falls squarely into the EAFP category.
>
> Isn't it orthogonal?
Not really. If you ask 'thing' to 'thing[0]', you don't find out
whether it is a list or a dict (or any number of other
On Sat, Apr 24, 2021 at 10:14 AM Nick Coghlan wrote:
>
>
>
> On Sat, 24 Apr 2021, 10:02 am Skip Montanaro,
> wrote:
>>
>>
>>> Practically speaking, one issue I have is how easy it is to write
>>> isinstance or issubclass checks. It has historically been much more
>>> difficult to write and
On Fri, 23 Apr 2021, 12:34 pm Inada Naoki, wrote:
>
> I think using ABC to distinguish sequence or mapping is a bad idea.
>
> There are three policies:
>
> a) Use duck-typing; just us it as sequence. No type check at all.
> b) Use strict type checking; isinstance(x, list) / isinstance(x, (list,
On Sat, 24 Apr 2021, 10:02 am Skip Montanaro,
wrote:
>
> Practically speaking, one issue I have is how easy it is to write
>> isinstance or issubclass checks. It has historically been much more
>> difficult to write and maintain a check that something looks like a duck.
>>
>> `if hasattr(foo,
> Practically speaking, one issue I have is how easy it is to write
> isinstance or issubclass checks. It has historically been much more
> difficult to write and maintain a check that something looks like a duck.
>
> `if hasattr(foo, 'close') and hasattr(foo, 'seek') and hasattr(foo,
> 'read'):`
When reading this, I wrote most of it early and left a draft to bake
Then deleted a ton of it after other people replied. I'm conscious that my
terminology might be all over the map. Keep that in mind before hitting
reply. It'll take me a while to digest and pedantically use Luciano's
terms,
We can add .keys() to Mapping to distinguish Mapping and Sequence.
But it is breaking change, of course. We shouldn’t change it.
We could use the presence of .keys in the subclasses hook only after first
checking
explicit cases (i.e. actual subclass or has been registered). Yes this
would break
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;
Luciano,
Thank you for such a thoughtful and eloquent response. Your wisdom is
definitely appreciated, and I agree this is an opportunity to go forward
with more clarity. I'm so proud of the Python dev community for their
thoughtful and respectful conversation.
All, Without the efforts of Larry,
My personal motivating example for PEP 637 was shorthand for protocols.
`x: Protocol[foo=int, bar=Callable[str, int]]` could say x has attribute
foo which is an int and method bar from str to int.
On Wed, Apr 21, 2021 at 4:23 PM Paul Bryan wrote:
> I agree, that's duck typing with a protocol,
I agree, that's duck typing with a protocol, and precisely the tedious
type style I would want to avoid.
I don't know what would be a good suggestion. Something where you
reference a "fully equipped" type and cherry pick the attributes you
want? Something like `Protocol[Duck, ("quack",
El mié, 21 abr 2021 a las 15:30, Paul Bryan () escribió:
> 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
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; someone else will want it to waddle. I don't see
how type hints
at a glance if what you have in an innocently looking
`except Exception` is correct or not. In my async/await code I'd have
to always check the `__group__` attribute to make sure it's not an
exception group in disguise.
So while you're "simplifying" the proposal by removing a coupl
Thanks Mark for posting this. I know some of us are uneasy about the pace
of the typing train
On Tue, Apr 20, 2021 at 11:20 AM Nathaniel Smith 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
Am 20.04.2021 um 19:03 schrieb Mark Shannon:
PEP 544 supports structural typing, but to declare a structural type
you must inherit from Protocol.
That smells a lot like nominal typing to me.
I'm not sure what inheriting from Protocol has to do with nominal
typing, even though I would
Now, given the terms I used in the last e-mail, it does worry me that
the push towards supporting STATIC TYPING in Python sometimes ignores
the needs of people who use the other typing disciplines. For example,
Pydantic is an example of using type hints for GOOSE TYPING.
And it alwo worries me
Hi Luciano,
On 20/04/2021 11:35 pm, Luciano Ramalho wrote:
I am not taking sides now, but I want to share with you a useful
diagram to reason about typing support in Python.
I struggled to explain what Python offers until I came up with this diagram:
I am not taking sides now, but I want to share with you a useful
diagram to reason about typing support in Python.
I struggled to explain what Python offers until I came up with this diagram:
https://standupdev.com/wiki/doku.php?id=python_protocols#the_typing_map
The Typing Map has two
On Tue, Apr 20, 2021 at 10:03 AM Mark Shannon wrote:
> ...
> PEP 544 supports structural typing, but to declare a structural type you
> must inherit from Protocol.
> That smells a lot like nominal typing to me.
>
Note that to implement a protocol you do not have to inherit from anything.
You
On 4/20/21 10:03 AM, Mark Shannon wrote:
Then came PEP 563 and said that if you wanted to access the
annotations of an object, you needed to call typing.get_type_hints()
to get annotations in a meaningful form.
This smells a bit like enforced static typing to me.
I'm working to address
On Tue, Apr 20, 2021 at 10:07 AM Mark Shannon wrote:
>
> Hi everyone,
>
> Once upon a time Python was a purely duck typed language.
>
> Then came along abstract based classes, and some nominal typing starting
> to creep into the language.
>
> If you guarded your code with `isinstance(foo,
On Wed, Apr 21, 2021 at 3:04 AM Mark Shannon wrote:
> Then came type hints. PEP 484 explicitly said that type hints were
> optional and would *always* be optional.
>
> Then came along many typing PEPs that assumed that type hints would only
> used for static typing, making static typing a bit
50 matches
Mail list logo
