Re: restriction on sum: intentional bug?

Discussion in 'Python' started by Benjamin Peterson, Oct 16, 2009.

  1. Alan G Isaac <alan.isaac <at> gmail.com> writes:
    > So of course join is better, as originally noted,
    > but that does not constitute a reason to intentionally
    > violate duck typing.


    As Stephen pointed out, duck typing is not an absolute.
    Benjamin Peterson, Oct 16, 2009
    #1
    1. Advertising

  2. Benjamin Peterson

    Carl Banks Guest

    On Oct 16, 7:41 pm, Alan G Isaac <> wrote:
    > > Alan G Isaac<alan.isaac<at>  gmail.com>  writes:
    > >> So of course join is better, as originally noted,
    > >> but that does not constitute a reason to intentionally
    > >> violate duck typing.

    >
    > On 10/16/2009 1:03 PM, Benjamin Peterson wrote:
    >
    > > As Stephen pointed out, duck typing is not an absolute.

    >
    > I do not recall anyone suggesting it was.
    > Do you?  If so, cite them.


    I don't recall anyone saying it either, however I'll go on record as
    saying it.

    Duck typing only helps when you don't know what kind of object you're
    getting. In practice, there isn't much useful code you can write that
    contains the call sum(x), but where you don't know whether x is a list
    of strings or a list of numbers. So you usually do know if your list
    contains strings, and if you know you have a list of strings you can
    just call "".join.

    (You might argue that you could write useful code that doesn't know
    whether x is a list of strings or a list of lists. True, but you
    shouldn't be calling sum() on lists or lists, either.)

    What I'm basically saying here is, by shutting out strings from sum,
    you don't really lose much in terms of duck typing, because duck
    typing wouldn't have been that helpful anyway.


    Carl Banks
    Carl Banks, Oct 17, 2009
    #2
    1. Advertising

  3. Benjamin Peterson

    Carl Banks Guest

    On Oct 17, 2:22 pm, Alan G Isaac <> wrote:
    > On 10/17/2009 7:06 AM, Carl Banks wrote:
    >
    > > I'm basically saying here is, by shutting out strings from sum,
    > > you don't really lose much in terms of duck typing, because duck
    > > typing wouldn't have been that helpful anyway.

    >
    > That boils down to an argument for type checking
    > whenever you cannot imagine my use case.  I hope
    > you do not write your own code that way...


    No, it doesn't. It's an argument that the type check, IN THIS CASE,
    doesn't cost you much since duck typing isn't that useful here, IN
    THIS CASE, to begin with. Nothing more.

    Extrapolating this argument to be a general defense of type checking
    is something you did.


    > Here is a use case you might have ruled out with
    > that approach.  A PyX `path` defines `__add__`
    > so that paths can be combined as subpaths of a
    > single path. This is  **VERY USEFUL**.
    > Now if I have a list of paths, it is useful to
    > to combine them: sum(pathlst,path()).


    That's a fair counterargument. It definitely seems a lot more likely
    that some code could be written that works for a list of strings or a
    list of path components, meaning that it'd be desirable to have a
    single operation which works on both, for which sum() seems like it'd
    be a convenient candidate. Consider my argument weakened somewhat.


    Carl Banks
    Carl Banks, Oct 17, 2009
    #3
  4. Benjamin Peterson

    MRAB Guest

    Carl Banks wrote:
    > On Oct 17, 2:22 pm, Alan G Isaac <> wrote:
    >> On 10/17/2009 7:06 AM, Carl Banks wrote:
    >>
    >>> I'm basically saying here is, by shutting out strings from sum,
    >>> you don't really lose much in terms of duck typing, because duck
    >>> typing wouldn't have been that helpful anyway.

    >> That boils down to an argument for type checking
    >> whenever you cannot imagine my use case. I hope
    >> you do not write your own code that way...

    >
    > No, it doesn't. It's an argument that the type check, IN THIS CASE,
    > doesn't cost you much since duck typing isn't that useful here, IN
    > THIS CASE, to begin with. Nothing more.
    >
    > Extrapolating this argument to be a general defense of type checking
    > is something you did.
    >
    >
    >> Here is a use case you might have ruled out with
    >> that approach. A PyX `path` defines `__add__`
    >> so that paths can be combined as subpaths of a
    >> single path. This is **VERY USEFUL**.
    >> Now if I have a list of paths, it is useful to
    >> to combine them: sum(pathlst,path()).

    >
    > That's a fair counterargument. It definitely seems a lot more likely
    > that some code could be written that works for a list of strings or a
    > list of path components, meaning that it'd be desirable to have a
    > single operation which works on both, for which sum() seems like it'd
    > be a convenient candidate. Consider my argument weakened somewhat.
    >

    Here's a suggestion: add a new special method '__sum__' for summing
    sequences.

    If 'sum' isn't given an initial value then the first value in the
    sequence is used as the initial value. The (remainder of) the sequence
    is passed to initial_value.__sum__ to perform the summation. If __sum__
    isn't defined then the __add__ method is used repeatedly as at present.

    The 'str' and 'unicode' classes (although I'd expected it would be the
    'bytes' and 'str' classes in Python 3) would define __sum__ as an
    efficient summation. Other classes like 'list' could do likewise.

    No more special cases!
    MRAB, Oct 18, 2009
    #4
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Tim Chase
    Replies:
    4
    Views:
    275
    Steven D'Aprano
    Oct 17, 2009
  2. Carl Banks
    Replies:
    2
    Views:
    282
    Carl Banks
    Oct 17, 2009
  3. Terry Reedy
    Replies:
    10
    Views:
    460
    Steven D'Aprano
    Oct 18, 2009
  4. Ethan Furman

    Re: restriction on sum: intentional bug?

    Ethan Furman, Oct 19, 2009, in forum: Python
    Replies:
    6
    Views:
    344
    Gabriel Genellina
    Oct 20, 2009
  5. Steve
    Replies:
    3
    Views:
    252
    Steven D'Aprano
    Oct 27, 2009
Loading...

Share This Page