[Python-ideas] [Wild Idea] Static Ducks
digitalxero at gmail.com
Sun Sep 20 02:33:55 CEST 2009
On Sat, Sep 19, 2009 at 6:00 PM, Steven D'Aprano <steve at pearwood.info> wrote:
> You ignored most of my questions. I'll *guess* what your intention is.
> You want the compiler to perform declarative type checking at compile
> time, with no type inference. You're proposing a syntax to declare
> types, with no implementation at all for how the compiler should
> actually do that checking.
> (I'm guessing compile time because you call it *static* ducks, even
> though you state it should raise TypeError. But you never actually say
> whether that will be raised when the compiler compiles the code, or
> when it runs it.)
Actually I would say it does it at run time because of the requirement
that it work along side code that does not use this, both being
imported to and importing non static ducked code. In the case it
imports code that is not using static ducks it would have to check
anything you pass in to a method that is typed or assigned to an
attribute that is.
> Personally, I'm not convinced that declarative type checking without
> type inference has enough benefit to be worth the pain of declarations.
> Nor am I sure that "static duck typing" makes sense in dynamic languages
> like Python. Consider this example:
> Is a goose sufficiently duck-like to be treated as a duck? Does it walk
> like a duck, swim like a duck and quack like a duck?
If all you are about are that it can walk swim and quack, then yes. If
you care how it walks, swims or quacks, then you would have to have a
duck and goose type that just checks if it is an instance of the right
class (like my int example). The point of duck typing is that you
generally dont care how just that it can. For file like objects you
dont care how it reads or writes just that it does
> At *compile time*, how do you know if the goose you receive is
> sufficiently duck-like or not? I don't think you can.
> For static checking, it actually gets worse. I can do this:
> g.__class__ = Duck
> and totally mess up isinstance() checks as well. Just because something
> is created as a Duck doesn't mean it will still be a Duck by the time
> it gets to your function.
If it is messing up isinstance then it is going to break any manual
type checking the user would try and setup as well, so I see no issue
More information about the Python-ideas