On Tue, Dec 3, 2013 at 3:11 AM, Oleg Broytman <phd@phdru.name> wrote:

On Mon, Dec 02, 2013 at 04:55:22PM +0100, Gregory Salvan <apieum@gmail.com> wrote:

...

For now I've basically called it isducktype(X, A) it returns true if: - X has all attributes of A

Isn't the requirement too strong? When I need a file-like object I seldom need more than .read() and .write() methods, and even of those I seldom need both at once -- I usually need one or the other. Testing for strict conformance is not duck typing IMO -- it's interface.

But you could have a "ReadableFile" that has a .read() method and whatever else you need, thus using that class as a sort of interface. With a little careful scripting and introspection, you might even be able to craft that by source code analysis, which would be extremely cool (eg you run this script over your source code and it notes that elements of this list are indexed with these five keywords, so it constructs a class with those five so you can check what goes into the list). Whether it's actually _useful_ or not remains to be seen, but it would certainly be cool. ChrisA

On Tue, Dec 3, 2013 at 3:33 AM, Gregory Salvan <apieum@gmail.com> wrote:

Ok for pypi. (I've never tried to make python C extension, I feel it's going to be epic :)

Is there any reason this can't be implemented in pure Python? It'd be a lot easier to figure things out that way. Maybe a C implementation could come later, but for a first cut, this ought to be possible in Python. ChrisA

On Mon, Dec 02, 2013 at 05:33:10PM +0100, Gregory Salvan <apieum@gmail.com> wrote:

@Oleg you can override default behaviour with __ducktypecheck__ it's not as strict as an interface as var names can be differents and can have defaults. then instead of declaring an interface with "read" and "write", you just create a base class with these methods.

What solution do you suggest ? I've made a function that returns public members only, maybe this method can be exposed in the api too.

2013/12/2 Oleg Broytman <phd@phdru.name>

...

Hi!

On Mon, Dec 02, 2013 at 04:55:22PM +0100, Gregory Salvan <apieum@gmail.com> wrote:

...

For now I've basically called it isducktype(X, A) it returns true if: - X has all attributes of A

Isn't the requirement too strong? When I need a file-like object I seldom need more than .read() and .write() methods, and even of those I seldom need both at once -- I usually need one or the other. Testing for strict conformance is not duck typing IMO -- it's interface.

I don't suggest any solution as I don't have a problem to solve with interfaces. You are going to implement another interface checker in addition to existing ones? https://pypi.python.org/pypi?%3Aaction=search&term=interface&submit=search No objections from me. Oleg. -- Oleg Broytman http://phdru.name/ phd@phdru.name Programmers don't die, they just GOSUB without RETURN.

On Mon, Dec 02, 2013 at 08:04:19PM +0200, ?????????? <elazarg@gmail.com> wrote:

On Dec 2, 2013 6:12 PM, "Oleg Broytman" <phd@phdru.name> wrote:

...

On Mon, Dec 02, 2013 at 04:55:22PM +0100, Gregory Salvan <apieum@gmail.com> wrote:

...

For now I've basically called it isducktype(X, A) it returns true if: - X has all attributes of A

Isn't the requirement too strong? When I need a file-like object I seldom need more than .read() and .write() methods, and even of those I seldom need both at once -- I usually need one or the other. Testing for strict conformance is not duck typing IMO -- it's interface. Interfaces are for nominal languages. Technically it should be called x.is_structurally_subtype()

I'm sure the terminology in Python is quite stable. There are interfaces (there are many implementations, there is one rejected PEP and one deferred PEP) and there is duck typing. Formalizing duck typing is IMO constructing an interface. Oleg. -- Oleg Broytman http://phdru.name/ phd@phdru.name Programmers don't die, they just GOSUB without RETURN.

@Serhiy Not really (only with FooReader, BarReader) as it checks if functions co_argcount and co_kwonlyargcount are equals. In this case it requires BazReader.__ducktypecheck__ to be implemented. I had a doubt when doing this, I agree with you isducktype(BazReader, FooReader) can return True (whereas isducktype(FooReader, BazReader) should stay false) This can easily be changed. @Oleg: The fact there is a lot of interface implementations means certainly it's something needed. Each implementation I've seen add burden on objects whereas the only thing personnally I need, is to be sure I'll be able to call some methods off injected objects. @spir: Names can easily be checked, but I can't see why doing this, it add constraints to developpers without adding safety. @Andrew +1 Maybe inspect is more appropriate as it provides ArgSpec and getmembers ? My code is crappy, I've just do it like that to train me in C then tought it might be interesting to get feedback. 2013/12/2 Serhiy Storchaka <storchaka@gmail.com>

02.12.13 17:55, Gregory Salvan написав(ла):

Hi,

...

I've made a try of a function that check object/class members for duck typing.

For now I've basically called it isducktype(X, A) it returns true if: - X has all attributes of A - X methods have same number of arguments than corresponding A methods

or if A.__ducktypecheck__(X) returns True

Behaviour looks like isinstance and issubclass (support tuples...).

class FooReader: def read(self, n=None): ...

class BarReader: def read(self, amount=-1): ...

class BazReader: def read(self, size=-1, chars=-1, firstline=False): ...

Instances of all three classes can be used where needed an object with the read() method which are called with one positional argument or without arguments. Is it possible to use isducktype() for such case?

_______________________________________________ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas

On 3 December 2013 04:42, Andrew Barnert <abarnert@yahoo.com> wrote:

Shouldn't this be tied to ABCs rather than redesigning and reimplementing most of ABC to add a little bit on top?

This seems like an apropos place for this link: http://docs.python.org/3/library/abc#abc.ABCMeta.__subclasshook__ That's the existing "formalised ducktyping" hook, that already allows things like the following:

...

...

class MyClass: ... def __len__(self): ... return 0 ... from collections.abc import Sized isinstance(MyClass(), Sized) True issubclass(MyClass, Sized) True

The advantage ABCs have over ducktyping alone is that subclassing and explicit registration allow ambiguities like the one between the Sequence and Mapping interfaces to be resolved (you can't always just ducktype those, as they have the same methods - they differ only in how the __*item__ methods handle slice objects). Cheers, Nick. -- Nick Coghlan | ncoghlan@gmail.com | Brisbane, Australia

On Dec 3, 2013, at 21:22, Gregory Salvan <apieum@gmail.com> wrote:

Sorry Andrew, I'm not sure to understand all your point. I don't believe it reimplements things of ABC, or I don't see what.

Almost everything you did reimplements features of ABCs. The builtin isinstance and issubclass functions can check whether you implement the methods of a type, and you can override that by explicitly declaring that you implement the type. That's the core feature set of your proposal, and of ABCs; you've just implemented the same thing with a different API, plus and minus a few minor details. If you haven't read PEP 3119, you really should. (It's also worth reading rejected predecessors like 245/246 and successors like 3124, and of course the pre-existing third party stuff like PyProtocols and the Interface types in Twisted and Zope.)

I agree ABC solution is the cleanest, whereas I would be able to check functions, stay on a runtime checking and being free to define or not a kind of protocol.

I don't understand what you mean here. ABCs can check methods. They do so at runtime. You're free to define or not define any protocol you want. What you have to add is checking the argspecs of the methods rather than just their names. That's a great idea, but it's a much better idea as an addition to what's already there than as a complete parallel API to very similar functionality. And if this were added to the stdlib, I'm pretty sure it would be a modification/extension of the abc module, not a competing and similar but not identical module.

Before reading your comments on ABC, I've released the python version of "isducktype": https://github.com/apieum/ducktype I've modified some behaviours within your comments and made it more stable.

It would be interesting to have the version wich use ABCMeta, so I'm going to implement it. I've thought to name it SignedMeta, or ProtocolMeta, any opinion ?

First, it sounds like you're focusing on the wrong part of the name--ABCMeta is a metaclass for implementing ABCs; leaving out the ABC part sounds like you're designing a metaclass for something completely unrelated. Less seriously, ProtocolMeta sounds like it's going to add more PyProtocols-style functionality (in particular, adapters from one protocol to another), but there's only so many synonyms available and they're all taken, so I don't think that's a major problem. As for SignedMeta, I don't even know what that's meant to imply. Is it to do with method signatures? If so, I think "signature" is a better word; you don't really think about anything being "signed" in a method signature; that's dragging in associations from a different meaning of the word. But I don't have any better suggestions. Protocol, interface, prototype, type, abstract type, abstract base... As I said, all of the names have already been used up, repeatedly, and none of them have any particular connotations that would explain how your module, metaclass, function, etc. differ from abc. In fact, I'd probably just come up with a stupid package name like abc2 and stick in modules named abc, collections.abc, and numbers and expose names identical to the stdlib ones, so I could play around with it by just using abc2.isinstance, abc2.abc.ABCMeta, abc2.collections.abc.Mapping, etc. Or I could just toss some "from abc2 import"s around. But for any serious use beyond playing around, that would be quite confusing.

2013/12/3 Nick Coghlan <ncoghlan@gmail.com>

...

On 3 December 2013 04:42, Andrew Barnert <abarnert@yahoo.com> wrote:

...

Shouldn't this be tied to ABCs rather than redesigning and reimplementing most of ABC to add a little bit on top?

This seems like an apropos place for this link: http://docs.python.org/3/library/abc#abc.ABCMeta.__subclasshook__

That's the existing "formalised ducktyping" hook, that already allows things like the following:

...

...

...

class MyClass: ... def __len__(self): ... return 0 ... from collections.abc import Sized isinstance(MyClass(), Sized) True issubclass(MyClass, Sized) True

The advantage ABCs have over ducktyping alone is that subclassing and explicit registration allow ambiguities like the one between the Sequence and Mapping interfaces to be resolved (you can't always just ducktype those, as they have the same methods - they differ only in how the __*item__ methods handle slice objects).

Cheers, Nick.

-- Nick Coghlan | ncoghlan@gmail.com | Brisbane, Australia

Thank you for taking time to answer. I trust you, but I've sometimes the feeling we're talking about different things. I didn't know PEP 3124 and PEP 0362, they are great ressources. Signature is particularly usefull, it's a pity it's not documented, I'll suggest something further. I'm ok with what you said (I talked effectively about signatures). The matter I see, is that attributes and methods can be set dynamically (that's why I talked about runtime), either I don't manage these cases, or I have to extend ABCMeta and override __instancecheck__ and __subclasscheck__. The second solution would make duplicate code unless I extract ABCMeta cache and registry operations in a dedicated object. This would be a lot of change and despite _abc_* attributes are protected, I'm afraid some library use them. I've made an example of failure to illustrate dynamic setting matter: https://gist.github.com/apieum/7800992 Maybe it's more effective for attributes which are often defined in __init__ uniquely. Whereas all of this is really interesting we are quite far from the initial target which was simply to avoid these cases:

...

...

class MyClass: ... def __len__(self, enum): ... return 0 ... from collections.abc import Sized isinstance(MyClass(), Sized) True issubclass(MyClass, Sized) True len(MyClass()) Traceback (most recent call last): File "<stdin>", line 1, in <module> TypeError: __len__() missing 1 required positional argument: 'enum'

I'll dig if I can find a better proposal considering all you suggestion. 2013/12/4 Andrew Barnert <abarnert@yahoo.com>

On Dec 3, 2013, at 21:22, Gregory Salvan <apieum@gmail.com> wrote:

Sorry Andrew, I'm not sure to understand all your point. I don't believe it reimplements things of ABC, or I don't see what.

Almost everything you did reimplements features of ABCs. The builtin isinstance and issubclass functions can check whether you implement the methods of a type, and you can override that by explicitly declaring that you implement the type. That's the core feature set of your proposal, and of ABCs; you've just implemented the same thing with a different API, plus and minus a few minor details.

If you haven't read PEP 3119, you really should. (It's also worth reading rejected predecessors like 245/246 and successors like 3124, and of course the pre-existing third party stuff like PyProtocols and the Interface types in Twisted and Zope.)

I agree ABC solution is the cleanest, whereas I would be able to check functions, stay on a runtime checking and being free to define or not a kind of protocol.

I don't understand what you mean here. ABCs can check methods. They do so at runtime. You're free to define or not define any protocol you want.

What you have to add is checking the argspecs of the methods rather than just their names. That's a great idea, but it's a much better idea as an addition to what's already there than as a complete parallel API to very similar functionality. And if this were added to the stdlib, I'm pretty sure it would be a modification/extension of the abc module, not a competing and similar but not identical module.

Before reading your comments on ABC, I've released the python version of "isducktype": https://github.com/apieum/ducktype I've modified some behaviours within your comments and made it more stable.

It would be interesting to have the version wich use ABCMeta, so I'm going to implement it. I've thought to name it SignedMeta, or ProtocolMeta, any opinion ?

First, it sounds like you're focusing on the wrong part of the name--ABCMeta is a metaclass for implementing ABCs; leaving out the ABC part sounds like you're designing a metaclass for something completely unrelated.

Less seriously, ProtocolMeta sounds like it's going to add more PyProtocols-style functionality (in particular, adapters from one protocol to another), but there's only so many synonyms available and they're all taken, so I don't think that's a major problem. As for SignedMeta, I don't even know what that's meant to imply. Is it to do with method signatures? If so, I think "signature" is a better word; you don't really think about anything being "signed" in a method signature; that's dragging in associations from a different meaning of the word.

But I don't have any better suggestions. Protocol, interface, prototype, type, abstract type, abstract base... As I said, all of the names have already been used up, repeatedly, and none of them have any particular connotations that would explain how your module, metaclass, function, etc. differ from abc.

In fact, I'd probably just come up with a stupid package name like abc2 and stick in modules named abc, collections.abc, and numbers and expose names identical to the stdlib ones, so I could play around with it by just using abc2.isinstance, abc2.abc.ABCMeta, abc2.collections.abc.Mapping, etc. Or I could just toss some "from abc2 import"s around. But for any serious use beyond playing around, that would be quite confusing.

2013/12/3 Nick Coghlan <ncoghlan@gmail.com>

...

On 3 December 2013 04:42, Andrew Barnert <abarnert@yahoo.com> wrote:

...

Shouldn't this be tied to ABCs rather than redesigning and reimplementing most of ABC to add a little bit on top?

This seems like an apropos place for this link: http://docs.python.org/3/library/abc#abc.ABCMeta.__subclasshook__

That's the existing "formalised ducktyping" hook, that already allows things like the following:

...

...

...

class MyClass: ... def __len__(self): ... return 0 ... from collections.abc import Sized isinstance(MyClass(), Sized) True issubclass(MyClass, Sized) True

The advantage ABCs have over ducktyping alone is that subclassing and explicit registration allow ambiguities like the one between the Sequence and Mapping interfaces to be resolved (you can't always just ducktype those, as they have the same methods - they differ only in how the __*item__ methods handle slice objects).

Cheers, Nick.

-- Nick Coghlan | ncoghlan@gmail.com | Brisbane, Australia

It's covered in the inspect module docs:

Oups, I've missed it was introduced in v3.3

I'd be open to an "abc.invalidate_caches()" function as a

more obvious way to force cache invalidation.

Does this implementation make sense ? https://gist.github.com/apieum/7805431