Velocity Reviews

Velocity Reviews (http://www.velocityreviews.com/forums/index.php)
-   Python (http://www.velocityreviews.com/forums/f43-python.html)
-   -   Re: restriction on sum: intentional bug? (http://www.velocityreviews.com/forums/t701803-re-restriction-on-sum-intentional-bug.html)

Benjamin Peterson 10-16-2009 05:03 PM

Re: restriction on sum: intentional bug?
 
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.





Carl Banks 10-17-2009 11:06 AM

Re: restriction on sum: intentional bug?
 
On Oct 16, 7:41*pm, Alan G Isaac <alan.is...@gmail.com> 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 10-17-2009 09:59 PM

Re: restriction on sum: intentional bug?
 
On Oct 17, 2:22*pm, Alan G Isaac <alan.is...@gmail.com> 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

MRAB 10-17-2009 11:42 PM

Re: restriction on sum: intentional bug?
 
Carl Banks wrote:
> On Oct 17, 2:22 pm, Alan G Isaac <alan.is...@gmail.com> 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!


All times are GMT. The time now is 04:29 PM.

Powered by vBulletin®. Copyright ©2000 - 2014, vBulletin Solutions, Inc.
SEO by vBSEO ©2010, Crawlability, Inc.