restriction on sum: intentional misfeature?

[Carl Banks]

On Oct 17, 2:15 am, Tim Chase <python.l... at tim.thechases.com> wrote:
> Carl Banks wrote:
> > On Oct 16, 12:40 pm, Tim Chase <python.l... at tim.thechases.com> wrote:
> >> Then I'm fine with sum() being smart enough to recognize this
> >> horrid case and do the "right" thing by returning ''.join()
> >> instead.
>
> > You don't want Python to get into this business.  Trust me.  Just
> > don't go there.
>
> Well python is already in this business of special cases -- it
> trys to be smart about a dumb operation by raising an error.

Which is irrelevant to what I was saying.

I followed up to the suggestion to transparently replace sum() with
"".join, but it's not the special-casing, per se, that's the issue.
It's micro=optimizing special cases at run time that I have a problem
with and where Python should never, ever go.

If Python starts doing stuff like that, everyone and their mother is
going to want Python to do the same thing for their own pet
performance bottlenecks.  People will post here whining that sum()
optimizing strings, why doesn't it optimize lists.  Let Python
optimize the general case, not the specific case.

I am fine with other kinds of special-case behaviors, like throwing an
exception for an particularly bad argument.  That's is merely
something you want to avoid in general.

Let's sum up:

Special-casing to raise an error, avoid in general.
Special-casing to mirco-optimize stuff, don't go there.

Now, if you want to argue that lots of special-case optimization do
occur in Python, or that they dsn't but should, be my guest.  At least
you'll be answering my actual objection.


> AFAICT, "".join() does not call __str__ on its elements:

You are correct.  Withdrawn.  Perhaps "".join does do the same thing
in all non-pathological cases as sum.  In which case I'd upgrade this
proposal from "not an option" to "a very, very bad option".


> > It'd be better to just remove the special case.
>
> I'd be happy with either solution for summing strings.  Be slow
> or be fast, but don't be erroneous.

It's not erroneous.  It does exactly what it's documented to do.

The options should be "slow", "fast", and (in your opinion) "poor
design choice".


Carl Banks