Path: csiph.com!fu-berlin.de!uni-berlin.de!not-for-mail From: Michael Selik Newsgroups: comp.lang.python Subject: Re: Looking for feedback on weighted voting algorithm Date: Sat, 16 Apr 2016 00:35:02 +0000 Lines: 33 Message-ID: References: <3567e3a1-6a55-4471-ad70-dc23e9ad05f4@googlegroups.com> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 X-Trace: news.uni-berlin.de 4djt14C7BmeGYVcjd3Hygw4006H5c2Nt0e19aG5eVAhg== Return-Path: X-Original-To: python-list@python.org Delivered-To: python-list@mail.python.org X-Spam-Status: OK 0.004 X-Spam-Evidence: '*H*': 0.99; '*S*': 0.00; 'wrong,': 0.09; 'python': 0.10; 'thursday,': 0.13; 'suggest': 0.15; 'received:74.125.82.44': 0.15; 'user.': 0.15; '*other*': 0.16; '2016': 0.16; 'downstream': 0.16; 'inputs': 0.16; 'nan': 0.16; 'nans': 0.16; 'received:io': 0.16; 'received:psf.io': 0.16; 'traceback.': 0.16; 'write.': 0.16; 'wrote:': 0.16; "wouldn't": 0.16; '>': 0.18; 'email addr:gmail.com>': 0.18; 'to:2**1': 0.21; 'header:In-Reply- To:1': 0.24; 'script': 0.25; 'helpful': 0.27; 'error': 0.27; 'fri,': 0.27; 'handling': 0.27; 'mostly': 0.27; 'to:no real name:2**1': 0.27; 'message-id:@mail.gmail.com': 0.27; '14,': 0.27; 'data,': 0.27; 'went': 0.28; 'crash': 0.29; 'division': 0.29; 'restart': 0.29; 'raise': 0.29; 'program,': 0.29; "i'm": 0.30; 'print': 0.30; 'code': 0.30; '15,': 0.30; "i'd": 0.31; 'error.': 0.31; 'source': 0.33; 'michael': 0.33; 'server': 0.34; 'advice': 0.35; 'gets': 0.35; 'received:google.com': 0.35; 'clear': 0.35; 'something': 0.35; 'received:74.125.82': 0.35; 'instead': 0.36; 'depends': 0.36; 'to:addr:python-list': 0.36; 'subject:: ': 0.37; 'someone': 0.38; 'sure': 0.39; 'rather': 0.39; 'to:addr:python.org': 0.40; 'organization': 0.60; 'more': 0.63; '500': 0.63; 'hints': 0.66; 'utc-7,': 0.84; 'have.': 0.93 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:references:in-reply-to:from:date:message-id:subject:to; bh=BnjQFuTLbgaTqWFlpLhlpk15kYlkPVcxPXOrZHWYYB8=; b=dHPMKLJj17NawpoAY49qs9LTeUF6uhFBnp43R9OfrsTEbyXSynfDSCrJIcyEbsd3cW e0RXWAhk75HwmefP2XtqEIoks54iHq1X7Q15L44vX9OabS4UYk+EJeohkMBQTwwruAeq LJ2GAuCe4fSdKyDQos65aM5D8FftaJ9uQdFXsRKmsyeN3RbrRtHyYzRsSdRw85Sx9AYf LpfQpW/iP7iU0itsuBrHldvDe/uylB7UVtMaFBFs++eVPzS8LoVJCV2uaOZjimrs7Twx 1JXbp3zNbZOxWdG9x8+t2JFZq6ygaWbg/DNsdWh8aT8zCFcHPweEitZ3zBeROGX0t9pt OW2w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to; bh=BnjQFuTLbgaTqWFlpLhlpk15kYlkPVcxPXOrZHWYYB8=; b=OwcSMFECTu+482aUexPse5aeJ32zmJFMOnmgGZQpwQSvnmzsgr1OMxK70jmZgflJf3 dApADyV9r1E/Hyv13sDJPSdhYd5TLLNJWOgZ5mxLdfumgtBgTDEifSxJKIOVSkpHNcDT NA4eNsb4uBdWkDnmUzjgMr8ELDAZy0RzCjDJooBPkepvRycysltDK4Gnem+tBdKzlYCz LVIYXI6lfitPfzZ9ZtFe9OoaXEbttaQSu9oXw/O5fHOQwBAiyR+XbeeJ157v0OvKE+tl 7FhRjNAkmhpeEx05LfW/1rgzpZDuE/P76ObhPB2I8fFMdwhj3QQgLE+DpF8hdoWnBQO7 Zwxg== X-Gm-Message-State: AOPr4FWQcOd+GYOMVwpFzsN8uG1u2G0Voejr7MPTw4vKJM7acNXPq1kSi+shQa6luAaLhTJ9+RZoCEqHD7odEw== X-Received: by 10.28.141.141 with SMTP id p135mr6760208wmd.8.1460766912215; Fri, 15 Apr 2016 17:35:12 -0700 (PDT) In-Reply-To: <3567e3a1-6a55-4471-ad70-dc23e9ad05f4@googlegroups.com> X-Content-Filtered-By: Mailman/MimeDel 2.1.21 X-BeenThere: python-list@python.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: General discussion list for the Python programming language List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-Mailman-Original-Message-ID: X-Mailman-Original-References: <3567e3a1-6a55-4471-ad70-dc23e9ad05f4@googlegroups.com> Xref: csiph.com comp.lang.python:107073 On Fri, Apr 15, 2016, 7:56 PM wrote: > On Thursday, April 14, 2016 at 1:48:40 PM UTC-7, Michael Selik wrote: > > I suggest not worrying about sanitizing inputs. If someone provides bad > > data, Python will do the right thing: stop the program and print an > > explanation of what went wrong, often a more helpful message than one > you'd > > write. Use error handling mostly for when you want to do something > *other* > > than stop the program. > > > > I'm not sure I'd use NaN instead of raise division by zero error. NaNs > can > > be troublesome for downstream code that might not notice until it gets > > confusing. A div-by-zero error is clear and easier to track down because > of > > the traceback. > > I'd much rather sanitize the inputs and tell the user they did something > bad than to have the script crash and give a 500 Internal Server Error to > the user. > Right, my advice was only good if the user can read the original error and traceback. And can restart the program, etc. Even worse, I definitely wouldn't want to give any hints of the source code > organization by letting the user see the traceback. > Depends on the kind of user you have. >