TL;DR: IMHO, debug code has no place in production code.
Debug code is, as per its name, code to help you debug your program. That level of debugging should be completed before the product is shipped.
Equally, any form of error message in production use should be sufficient to inform support, but be opaque enough that an user doesn't really know what it ...
I prefer the former, because if there are multiple errors then they are handled one after another without further indentation of the non-error code:
if not error-condition1:
if not error-condition2:
I’ve seen code doing a few operations that could all potentially fail, with a 20 times nested if. Inserting another error condition after test #11 was practically impossible.
At some point a code structure that handles one condition after the other in a linear fashion is just better.
In newer languages, like Swift, you have “optional” types, including “optional bool”. An optional bool has values false, true, or nil. In that case, an explicit comparison gives exactly what you ask for. x == false tells you x is false, not true or nil. x != true tells you that x is not true, but either false or nil.
So in Swift, x == false would catch ...
Conditional compilation is commonly used for debugging statement. You will therefore find these #ifdef DEBUG of NDEBUG blocks in production quality code. Because the same code that was not guaranteed as production quality just before it passed the extensive quality assurance.
Interestingly, the symbol NDEBUG was already used in the C89 standard library to ...
You use whatever helps you finding problems in your code. You may want logging that customers can send to you to identify problems in the field. You want configurable logging on your developer machine. You want crash reports that get sent to you automatically.
Remember that defs can be nested, so another PEP8-compliant implementation would be
def inclusion_exclusion_principle(nums_divisible_by, divisors):
return (itertools.combinations(x, r) for r in range(start, len(x) + 1))
return 1 if x % 2 == 0 else -1
A positive approach to answer this: lambdas come from the "lambda calculus", a rather important area of Computer Science, which, in a nutshell is concerned with exploring what happens if you use functions as "first class citizens". I.e., functions which can themselves be used as values and thus can be given as parameters to other ...
The answer is right there, in your quote:
This is more useful for tracebacks and string representations in general
That is, if you have an exception thrown from inside your function, it would be named, if you have declared it with def:
Traceback (most recent call last):
File "p_fun.py", line 6, in <module>
lambdas remove an indication that the definition is a function. I think this makes it harder to read as you have lost information.
IDEs work less well you lose their searching and autocompletion of function names and the highlighting of the use of the function. (or even simple grep for functions)
As for length lets see as you are doing one liners
sign = ...
Honestly, this looks like a Haskel code more than anything else. Python is all about readability. Your code looks a lot like my practice math register. No one reads my register so it's all good. But when someone does need to read it, he will need probably the same amount of time I needed to solve it or more.
So if you are doing this for yourself and do not ...
"Pythonic" is not an objective standard. It really means "code that an experienced python programmer likes". Turns out "experienced python programmers" don't all universally have the same taste in code.1
As someone who has written a lot of functional style code in Python, and who frequently takes PEP-8 with a grain of salt, I ...
You're sort of approaching it like a mathematician, where the purpose of writing the supporting functions is to "prove your work." Software isn't generally read that way. The goal is usually to choose good enough names that you don't have to read the helper functions.
You likely know what a powerset or alternating sum is without reading the code. ...
Despite the Zen of Python, there is sometimes more than one obvious way to do it.
I agree that your preferred way to phrase this code has a certain functional elegance to it.
But it's also plain to see that your preference for this style is purely aesthetical/subjective, and that PEP-8 gives objective reasons why named defs are preferable.