What's the best way to minimize the need of run time checks?

[Juan Pablo Romero Méndez]

2016-08-09 18:28 GMT-07:00 Steven D'Aprano <steve+python at pearwood.info>:

> On Wed, 10 Aug 2016 04:29 am, Juan Pablo Romero Méndez wrote:
>
> > Hello,
> >
> > In online forums sometimes people complain that they end up having to
> test
> > constantly for None,
>
> Then don't return None to indicate an error. If you write this:
>
> def create_spam(arg):
>     if condition:
>         return Spam(arg)
>     else:
>         return None
>
>
> then you are doing it wrong. It sounds like they are writing C in Python,
> where they think that returning None (instead of a null pointer) is the way
> to indicate an error. Instead:
>
> def create_spam(arg):
>     if condition:
>         return Spam(arg)
>     raise MyExceptionError('cannot create spam because reasons')
>
>
> Now you can decide on a error-handling scheme:
>
> - try...except and handle the exception exactly when it occurs;
>
> - wrap your entire application in a single try...except or
>   exception handler, and catch the exception in a single place;
>
> - don't even bother catching the exception in the application at all,
>   treat it as a debugging aid. Any time your tests generate that
>   exception, that's a bug to be fixed.
>
>
> There's no reason why you can't decide on a combination of all three:
>
> - the app catches the exception, logs it as a bug, and exits;
>
> - but individual parts of your code base treat this exception as an
>   EXPECTED error, wrapping that individual call in a try...except:
>
>
>     try:
>         myspam = create_spam(99)
>     except MyExceptionError:
>         # Only occurs when the server has hung
>         reboot_server()
>         myspam = create_spam(99)
>
>
> Only catch exceptions you expect, and can recover from.
>
> If your *data* could be None, well that's no different from any other
> sentinel or missing value. You have to deal with it somewhere. One way is
> to filter it early:
>
> # filter out None
> data = [obj for obj in data if data is not None]
>
> # or if you prefer
> data = filter(lambda obj: obj is not None, data)
>
>
> and now you can be sure that data doesn't contain None.
>
>
> [...]
> > Do you guys have any resources you like that addresses the following
> > issue: What is the best way to use the dynamic features of Python to
> avoid
> > having to write a poor's man type system?
>
> This is an old, old, old debate that applies to Lisp, Perl, Javascript,
> Lua,
> Ruby and others, not just Python. Google for "dynamic typing versus static
> typing" for more. Also google for "duck typing".
>
>

Yeah, I've been on both sides of the debate over my programming years ;)

What I find frustrating to be honest about this debate (and the reason it
will never die probably) is that your perspective on it really depends
mostly on anecdotal evidence, your own knowledge, experience, etc.

I've been trying to find (without success so far) an example of a situation
where the dynamic features of a language like Python provides a clear
advantage over languages with more than one type.



> One useful perspective is that languages are converging on a mix of both:
> statically typed languages are growing dynamic features, and dynamically
> typed languages are growing static checkers.
>
>
> http://steve-yegge.blogspot.com.au/2008/05/dynamic-
> languages-strike-back.html
>
>
> And some background information on the debate:
>
> https://cdsmith.wordpress.com/2011/01/09/an-old-article-i-wrote/
>
>
>
>
> --
> Steve
> “Cheer up,” they said, “things could be worse.” So I cheered up, and sure
> enough, things got worse.
>
> --
> https://mail.python.org/mailman/listinfo/python-list
>