Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > Python > Re: restriction on sum: intentional bug?

Reply
Thread Tools

Re: restriction on sum: intentional bug?

 
 
Benjamin Peterson
Guest
Posts: n/a
 
      10-16-2009
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.




 
Reply With Quote
 
 
 
 
Carl Banks
Guest
Posts: n/a
 
      10-17-2009
On Oct 16, 7:41*pm, Alan G Isaac <(E-Mail Removed)> 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
 
Reply With Quote
 
 
 
 
Carl Banks
Guest
Posts: n/a
 
      10-17-2009
On Oct 17, 2:22*pm, Alan G Isaac <(E-Mail Removed)> 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
 
Reply With Quote
 
MRAB
Guest
Posts: n/a
 
      10-17-2009
Carl Banks wrote:
> On Oct 17, 2:22 pm, Alan G Isaac <(E-Mail Removed)> 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!
 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
Re: restriction on sum: intentional bug? Steve Python 3 10-27-2009 09:12 PM
Re: restriction on sum: intentional bug? Ethan Furman Python 6 10-20-2009 02:42 AM
Re: restriction on sum: intentional bug? Terry Reedy Python 10 10-18-2009 04:58 AM
Re: restriction on sum: intentional bug? Carl Banks Python 2 10-17-2009 10:46 AM
Re: restriction on sum: intentional bug? Tim Chase Python 4 10-17-2009 07:34 AM



Advertisments