Path: csiph.com!v102.xanadu-bbs.net!xanadu-bbs.net!feeder.erje.net!eu.feeder.erje.net!xlned.com!feeder3.xlned.com!newsfeed.xs4all.nl!newsfeed3a.news.xs4all.nl!xs4all!newsgate.cistron.nl!newsgate.news.xs4all.nl!post.news.xs4all.nl!not-for-mail Return-Path: X-Original-To: python-list@python.org Delivered-To: python-list@mail.python.org X-Spam-Status: OK 0.003 X-Spam-Evidence: '*H*': 0.99; '*S*': 0.00; 'skip:[ 20': 0.04; 'explicitly': 0.05; 'interpreter': 0.05; 'subject:Python': 0.06; 'test,': 0.07; 'difference,': 0.09; 'function,': 0.09; 'latter': 0.09; 'subject:Why': 0.09; 'python': 0.11; 'def': 0.12; '>>': 0.16; 'caring': 0.16; 'check.': 0.16; 'integer,': 0.16; 'integers,': 0.16; 'numpy': 0.16; 'personally,': 0.16; 'so;': 0.16; 'truncates': 0.16; 'types,': 0.16; 'language': 0.16; 'wrote:': 0.18; 'code.': 0.18; 'code,': 0.22; 'example': 0.22; 'email addr:gmail.com>': 0.22; "shouldn't": 0.24; "i've": 0.25; '>': 0.26; 'first,': 0.26; 'this:': 0.26; 'pass': 0.26; 'asking': 0.27; 'values': 0.27; 'header:In-Reply-To:1': 0.27; 'point': 0.28; 'function': 0.29; 'correct': 0.29; 'am,': 0.29; 'raise': 0.29; "doesn't": 0.30; 'message-id:@mail.gmail.com': 0.30; "i'm": 0.30; 'code': 0.31; 'decimal': 0.31; 'equivalent.': 0.31; 'second,': 0.31; 'probably': 0.32; 'handled': 0.32; 'maybe': 0.34; 'case,': 0.35; 'but': 0.35; 'received:google.com': 0.35; 'in:': 0.36; 'yield': 0.36; 'subject:?': 0.36; 'should': 0.36; 'detail': 0.37; 'two': 0.37; 'list': 0.37; 'generic': 0.38; 'handle': 0.38; 'whatever': 0.38; 'to:addr:python-list': 0.38; 'pm,': 0.38; 'little': 0.38; 'expect': 0.39; 'sure': 0.39; 'to:addr:python.org': 0.39; 'skip:p 20': 0.39; 'ensure': 0.60; 'ian': 0.60; 'worry': 0.60; 'most': 0.60; "you're": 0.61; '20,': 0.68; 'special': 0.74; 'complex,': 0.84; 'difference.': 0.84; 'divide': 0.84; 'float,': 0.84; 'sum.': 0.84; 'cast': 0.91; 'divided': 0.91; 'average': 0.93 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=rrwyg4VEo0sdZh35/bKx3zF1XHJcQQj/frd8Pdvm09c=; b=M7AOQVcfwPb43W8x9zpeJjOWOdOf0TsYvDaaJOW9yAWQ/Syo209UYc4JlJDwpJa8Yf fBXXWSbwuYJQxMbuzrSNaAneJHHIJ8C9TO6O0OIzvo8TrK8Y8ZQ7lrGHVA25WQULGr7y ghltK1bCSVCM/mXzBJxA1v3MXbMJruazF76kH14bYaJrt6tEu46VG6Hnoxg2DmDlthqk NPEU6RSMxSxL3tpru5N1fHpxacI+r/Bin/Mws3NEpStLZqqtfPWF/rGoKZDtS93RcMq2 /Pgc7tmPoCsICROwBrwx7jSQ66SUWrQv365U39v40DNRGSiIRZZ3S/hQhkRgxHiZieVL tDIg== MIME-Version: 1.0 X-Received: by 10.68.134.198 with SMTP id pm6mr33624592pbb.9.1398010949308; Sun, 20 Apr 2014 09:22:29 -0700 (PDT) In-Reply-To: References: <7x8ur1esa5.fsf@ruckus.brouhaha.com> Date: Sun, 20 Apr 2014 10:22:29 -0600 Subject: Re: Why Python 3? From: Ian Kelly To: Python Content-Type: multipart/alternative; boundary=047d7b10cb290696ac04f77bca36 X-BeenThere: python-list@python.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: General discussion list for the Python programming language List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Newsgroups: comp.lang.python Message-ID: Lines: 119 NNTP-Posting-Host: 2001:888:2000:d::a6 X-Trace: 1398010958 news.xs4all.nl 2916 [2001:888:2000:d::a6]:34920 X-Complaints-To: abuse@xs4all.nl Xref: csiph.com comp.lang.python:70418 --047d7b10cb290696ac04f77bca36 Content-Type: text/plain; charset=UTF-8 On Apr 19, 2014 2:54 PM, "Chris Angelico" wrote: > > On Sun, Apr 20, 2014 at 6:38 AM, Ian Kelly wrote: > >> Or you just cast one of them to float. That way you're sure you're > >> working with floats. > > > > Which is inappropriate if the type passed in was a Decimal or a complex. > > In that case, you already have a special case in your code, so whether > that special case is handled by the language or by your code makes > little difference. Is your function so generic that it has to be able > to handle float, Decimal, or complex, and not care about the > difference, and yet has to ensure that int divided by int doesn't > yield int? Then say so; put in that special check. Personally, I've > yet to meet any non-toy example of a function that needs that exact > handling; most code doesn't ever think about complex numbers, and a > lot of things look for one specific type: When I'm writing a generic average function, I probably don't know whether it will ever be used to average complex numbers. That shouldn't matter, because I should be able to rely on this code working for whatever numeric type I pass in: def average(values): return sum(values) / len(values) This works for decimals, it works for fractions, it works for complex numbers, it works for numpy types, and in Python 3 it works for ints. > Maybe it's not your code that should be caring about what happens when > you divide two integers, but the calling code. If you're asking for > the average of a list of numbers, and they're all integers, and the > avg() function truncates to integer, then the solution is to use sum() > and explicitly cast to floating point before dividing. First, that's not equivalent. Try the following in Python 3: values = [int(sys.float_info.max / 10)] * 20 print(average(values)) Now try this: print(average(map(float, values))) I don't have an interpreter handy to test, but I expect the former to produce the correct result and the latter to raise OverflowError on the call to sum. Second, why should the calling code have to worry about this implementation detail anyway? The point of a generic function is that it's generic. --047d7b10cb290696ac04f77bca36 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Apr 19, 2014 2:54 PM, "Chris Angelico" <rosuav@gmail.com> wrote:
>
> On Sun, Apr 20, 2014 at 6:38 AM, Ian Kelly <ian.g.kelly@gmail.com> wrote:
> >> Or you just cast one of them to float. That way you're su= re you're
> >> working with floats.
> >
> > Which is inappropriate if the type passed in was a Decimal or a c= omplex.
>
> In that case, you already have a special case in your code, so whether=
> that special case is handled by the language or by your code makes
> little difference. Is your function so generic that it has to be able<= br> > to handle float, Decimal, or complex, and not care about the
> difference, and yet has to ensure that int divided by int doesn't<= br> > yield int? Then say so; put in that special check. Personally, I'v= e
> yet to meet any non-toy example of a function that needs that exact > handling; most code doesn't ever think about complex numbers, and = a
> lot of things look for one specific type:

When I'm writing a generic average function, I probably = don't know whether it will ever be used to average complex numbers. Tha= t shouldn't matter, because I should be able to rely on this code worki= ng for whatever numeric type I pass in:

def average(values):
=C2=A0=C2=A0=C2=A0 return sum(values) / len(values)

This works for decimals, it works for fractions, it works fo= r complex numbers, it works for numpy types, and in Python 3 it works for i= nts.

> Maybe it's not your code that should be caring abou= t what happens when
> you divide two integers, but the calling code. If you're asking fo= r
> the average of a list of numbers, and they're all integers, and th= e
> avg() function truncates to integer, then the solution is to use sum()=
> and explicitly cast to floating point before dividing.

First, that's not equivalent.=C2=A0 Try the following in= Python 3:

values =3D [int(sys.float_info.max / 10)] * 20
print(average(values))

Now try this:

print(average(map(float, values)))

I don't have an interpreter handy to test, but I expect = the former to produce the correct result and the latter to raise OverflowEr= ror on the call to sum.

Second, why should the calling code have to worry about this= implementation detail anyway? The point of a generic function is that it&#= 39;s generic.

--047d7b10cb290696ac04f77bca36--