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". 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