Path: csiph.com!usenet.pasdenom.info!news.albasani.net!rt.uk.eu.org!newsfeed.xs4all.nl!newsfeed3.news.xs4all.nl!xs4all!post.news.xs4all.nl!not-for-mail
MIME-Version: 1.0
In-Reply-To: <51b0565d$0$11118$c3e8da3@news.astraweb.com>
References: <687dea63-84da-4c45-9366-cb5a10665d1f@googlegroups.com> <51ab95d5$0$29966$c3e8da3$5496439d@news.astraweb.com> <a46a1835-9960-4cc3-b15e-7c027f054919@googlegroups.com> <51ad7daf$0$11118$c3e8da3@news.astraweb.com> <c694719e-03d7-485c-a88b-0a7770d4d133@googlegroups.com> <c70964e8-059e-4b19-b822-d54250ea2118@googlegroups.com> <mailman.2708.1370422741.3114.python-list@python.org> <31ca14e1-973d-44e6-886c-011a55755d76@googlegroups.com> <mailman.2747.1370451556.3114.python-list@python.org> <96cd7a31-40ce-4e51-9489-446b7f002a0e@googlegroups.com> <51afec46$0$29966$c3e8da3$5496439d@news.astraweb.com> <mailman.2783.1370485793.3114.python-list@python.org> <51b0565d$0$11118$c3e8da3@news.astraweb.com>
Date: Thu, 6 Jun 2013 19:45:49 +1000
Subject: Re: Bools and explicitness [was Re: PyWart: The problem with "print"]
From: Chris Angelico <rosuav@gmail.com>
To: python-list@python.org
Content-Type: text/plain; charset=ISO-8859-1
Precedence: list
Newsgroups: comp.lang.python
Message-ID: <mailman.2790.1370511951.3114.python-list@python.org>
Lines: 56
NNTP-Posting-Host: 2001:888:2000:d::a6
Xref: csiph.com comp.lang.python:47202

On Thu, Jun 6, 2013 at 7:29 PM, Steven D'Aprano
<steve+comp.lang.python@pearwood.info> wrote:
> Whatever benefit there is in declaring the type of a function is lost due
> to the inability to duck-type or program to an interface. There's no type
> that says "any object with a 'next' method", for example. And having to
> declare local variables is a PITA with little benefit.
>
> Give me a language with type inference, and a nice, easy way to keep duck-
> typing, and I'll reconsider. But until then, I don't believe the benefit
> of static types comes even close to paying for the extra effort.

Here are some classic ways to do the multiple-types-accepted option.

//C++ style: overloading
int max(int a,int b) {return a>b ? a : b;}
float max(float a,float b) {return a>b ? a : b;}
//C++ also lets you go for templates, but leave that aside

//Pike style: piped types
int|float max(int|float a,int|float b) {return a>b ? a : b;}
//This lets you write one lot of code but doesn't let
//you declare that both args must be the same type

# Python style: accept anything, then (maybe) check
def max(a,b): return a if a>b else b
//Pike does this too:
mixed max(mixed a,mixed b) {return a>b ? a : b;}
/* So does C, but only with pointers: */
void *max(void *a,void *b) {... uhh, this is nontrivial actually ...}

For the "accept any object that has a next() method" sorts of rules, I
don't know of any really viable system that does that usefully. The
concept of implementing interfaces in Java comes close, but the class
author has to declare that it's implementing some named interface. In
theory there could be something that deduces the validity from the
given structure, but I'm not aware of any language that does this. But
it would let you do stuff like this (prototyped in Python):

class Integers:
    def __init__(self): self.value=0
    def next(self):
        self.value+=1
        return self.value

interface Iterable:
    next(self)

def grab_three_values(Iterable iter):
    return iter.next(),iter.next(),iter.next()

With a language that checks these sorts of things at compile time,
it's not a big deal to test. With something fully dynamic like Python,
it's probably not worth the effort. But maybe checks like this could
be useful to something like Coverity.

ChrisA