Path: csiph.com!usenet.pasdenom.info!gegeweb.org!de-l.enfer-du-nord.net!feeder2.enfer-du-nord.net!cs.uu.nl!news.stack.nl!newsfeed.xs4all.nl!newsfeed3.news.xs4all.nl!xs4all!newsgate.cistron.nl!newsgate.news.xs4all.nl!post.news.xs4all.nl!not-for-mail
Newsgroups: comp.lang.python
Date: Sat, 9 Feb 2013 22:25:55 -0800 (PST)
In-Reply-To: <mailman.1525.1360372044.2939.python-list@python.org>
Complaints-To: groups-abuse@google.com
Injection-Info: glegroupsg2000goo.googlegroups.com; posting-host=70.196.110.82; posting-account=h3aEwQoAAACiuqX-oR3gvCVFm8lLHoWj
References: <mailman.2132.1342341291.4697.python-list@python.org> <5002a1f9$0$29995$c3e8da3$5496439d@news.astraweb.com> <mailman.2141.1342369188.4697.python-list@python.org> <7b027612-a07e-40f9-8ad2-3e95c5440482@googlegroups.com> <mailman.2148.1342375350.4697.python-list@python.org> <bbc44546-ffb7-4ff9-bd43-3bfa068df75f@googlegroups.com> <mailman.2154.1342389192.4697.python-list@python.org> <86872ad2-fda0-403b-9f18-d1cb18e41860@t32g2000yqd.googlegroups.com> <CAPTjJmov--b_s5e=OYsWWV8w6byj5a+28NNu-vRWGV8mr8w5cg@mail.gmail.com> <mailman.2159.1342404957.4697.python-list@python.org> <50039290$0$29978$c3e8da3$5496439d@news.astraweb.com> <mailman.2197.1342498752.4697.python-list@python.org> <9309333c-13a0-464c-bd94-9c682363b8c9@googlegroups.com> <511516db$0$29969$c3e8da3$5496439d@news.astraweb.com> <ee71b775-b527-4bb3-a080-12aad962b0ba@googlegroups.com> <62c3e7bb-d023-43b4-b759-f424707fd346@googlegroups.com> <mailman.1525.1360372044.2939.python-list@python.org>
User-Agent: G2/1.0
MIME-Version: 1.0
Subject: Re: Implicit conversion to boolean in if and while statements
From: Rick Johnson <rantingrickjohnson@gmail.com>
To: comp.lang.python@googlegroups.com
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Cc: Python <python-list@python.org>, Rick Johnson <rantingrickjohnson@gmail.com>
Precedence: list
Message-ID: <mailman.1574.1360477564.2939.python-list@python.org>
Lines: 112
NNTP-Posting-Host: 2001:888:2000:d::a6
Xref: csiph.com comp.lang.python:38558

On Friday, February 8, 2013 7:06:34 PM UTC-6, Ian wrote:
> On Fri, Feb 8, 2013 at 12:58 PM, Rick Johnson
>  wrote:
> > I'm a bit unnerved by the sum function. Summing a
> > sequence only makes sense if the sequence in question
> > contains /only/ numeric types. For that reason i decided
> > to create a special type for holding Numerics.
> > [...]
> > Of course someone could
> > probably find a legitimate reason to apply a sum method
> > to non-numeric values; if so, then inherit from
> > NumericSequence and create your custom type!
>
> Are you aware that the approach you're advocating here is bad OOP
> design?  If you declare a class NumericSequence with the property that
> it contains only numeric types, and then you declare a subclass
> NonnumericSequence that does not share that property, then guess what?
> You've just violated the Liskov Substitution Principle.

I totally agree! Really, no sarcasm here O:-)

Not only because we would be attempting to bend a numeric type into somethi=
ng it is not, but even more foolishly because the very method we hope to ga=
in (sum) would need to be completely re-written anyway. I must have lost my=
self in the rant because that was a foolish thing to say. Thanks for pointi=
ng this out.

> The goal you're trying to achieve here is nonsensical anyway.  Ask
> yourself what the semantic meaning of the sum() function is, what
> purpose it is meant to serve.  My answer: it is the reduction of the
> addition operator.

I think that for Numeric Types your answer is spot on! And i'll bet if we r=
uminated long enough we could probably find a few more transformations of t=
he word "sum" into unique contexts. But i digress, we'll have to save that =
synergy for a time when you are buying the beer! ;-)

> The implication of this is that the input type of
> the sum() function is not "numbers", but rather "things that can be
> added".

Indeed. Contrary to what a few folks have stated in this thread, if two dif=
ferent objects have methods named "sum", that does NOT mean that we have br=
oken the fine principles of "code reuse", no. Why? Because two methods name=
d "sum" can contain completely different code! Yes, i know that's difficult=
 for some to believe, but it's the truth!

Consider a sum method of a "Numeric Type" compared to the sum method of a "=
Sequence Type". Not only is the algorithm different, but the result is diff=
erent. Summing N numerics requires utilizing the strict rules of mathematic=
al addition, keeping a running total, and returning a type (Integer) that i=
s different from the input type, whereas summing sequences requires expandi=
ng the first sequence with the values of the second sequence (all whilst ma=
intaining linear order) and returning a new instance of the same type (f.e.=
 list).=20

Of course you could write a single monolithic function that can operate on =
multiple types transparently (*cough* saum!) however:

 * Nobody can predict the future (at least not yet) so you
   will eventually encounter a new type that breaks the
   god @#$% function.

 * Your language will rely on "magic", thereby confusing
   it's users, with well, magic!

 * But most disappointing of all: you will break the accepted
   OOP convention of encapsulation, whereby the object
   /itself/ should operate on the data, not some outside god
   @#$% function!

But let's dig a little deeper here so we might understand /why/ encapsulati=
on is /so/ gawd @#$%ed important to OOP.=20

Why do we prefer objects to operate on their own data rather than some "mag=
ical-all-knowing-god-like-creature-from-another-planet-who-thinks-his-bowel=
-movements-smell-like-bakery-fresh-cinnamon-rolls? Is it because we want ob=
jects to feel a sense of "belonging" or "importance"? ...OF COURSE NOT! Obj=
ects neither think nor feel!

We employ encapsulation because by doing so we keep all the relevant code u=
nder one class, one module, one package. By doing so we create a hierarchy;=
 and since hierarchies are much easier to search than random sequences, we =
will thank ourselves later!

If you want a fine example of this consider a list and a dict object. If yo=
u want to find a value in a list you are forced to search the entire list "=
item-by-item" until you find a match; there are NO shortcuts here! However,=
 when we have data in a dict all we need is a key, and voila!, we have a di=
rect path to the item! Same applies to code.

RR: "GOOD paradigms solve problems when /writing/ code, GREAT paradigms sol=
ve problems when writing and /maintaining/ code!"

> That includes numbers, but since I see from your proposed
> class hierarchy that you are retaining the __add__ method on
> sequences, it also includes sequences.  Are you really going to tell
> the user that (1, 2, 3) + (4, 5, 6) is perfectly fine, but that the
> semantic equivalent sum([(1, 2, 3), (4, 5, 6)]) is nonsense?

Yes. Because if the user has a problem understanding /why/ adding two seque=
nces together results in a new sequence and /not/ a number, he can simply o=
pen the source for the Sequence object, locate the sum method, and read cod=
e that is ONLY RELEVANT TO SUMMING A SEQUENCE OBJECT. [1]

Whereas with a global function --which has been whored-out to operate on ma=
ny types, and will probably include a massive conditional!-- he will need t=
o read through many lines of irrelevant code just to find the relevant code=
, then /hopefully/ he has the cognitive power remaining to find the answer.

[1] Of course this is not the /only/ reason why encapsulation is so importa=
nt.