[Python-ideas] [Wild Idea] Static Ducks

[Steven D'Aprano]

On Sun, 20 Sep 2009 08:21:24 am Dj Gilcrease wrote:
> On Sat, Sep 19, 2009 at 3:16 AM, Steven D'Aprano <steve at pearwood.info> 
wrote:
> > On Sat, 19 Sep 2009 06:19:25 pm Dj Gilcrease wrote:
> >> I do not expect this idea to gain much traction but it has been an
> >> idea rolling around in my head for a year or two, so I decided to
> >> write it all down and see what other thought.
> >
> > For starters, it's not clear what a static duck is.
> >
> > Is it a type? Is it a syntax? Is it an extension to existing
> > built-in types? All of the above?
> >
> > When enabled, does the compiler do the type checking at compile
> > time? Does it happen at runtime? Both? What sort of type checking
> > is done? Pascal-style declarative type checking, or Haskell-style
> > type inference?
> >
> > Why "static duck"? What does this have to do with duck typing?
> >
> > Rather than give an implementation of how users can create their
> > own static ducks, it would be better to give some use-cases for
> > where you would use them and what the behaviour is.
>
> The reason I called it static ducks is because you can do "static
> duck typing". I didnt list file type objects because that means
> something different to different people.

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.)

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:


class Duck(object):
    def walk(self):
        return "waddle waddle"
    def swim(self):
        return "paddle paddle swim paddle"
    def quack(self):
        return "quack quack"


class Goose(object):
    def walk(self):
        return "waddle waddle flap waddle"
    def swim(self):
        return "paddle paddle swim paddle swim"
    def quack(self):
        return "honk honk hiss"


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?
    
g = Goose()
hasattr(g, 'walk') and hasattr(g, 'swim') and hasattr(g, 'quack')
-> returns True, so it's a duck
Goose.waddle = Goose.walk
del Goose.walk
hasattr(g, 'walk')
-> returns False, so it's not a duck
Goose.walk = lambda self: "waddle flap flap waddle waddle"
hasattr(g, 'walk')
-> returns True, it's a duck again
del Goose.walk
g.walk = g.waddle
hasattr(g, 'walk')
-> returns True but only for this instance


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.



-- 
Steven D'Aprano