Speaking of find\_item, is the `for..else` loop (which can be used to write find\_item in another way) considered Pythonic? I personally like `for..else` loops but I don't know where the consensus is at.
Anti-Patterns in Python Programming
51–60 of 242 posts
Re: Anti-Patterns in Python Programming
#52The more frequent and dangerous pitfalls are, in my humble opinion: - Bare except: statements (that catches everything , even Ctrl-C) - Mutables as default function/method arguments - Wildcard imports!
Agreed on all counts. However I do find myself using mutables as default arguments sometimes because the generated documentation is clearer.
For example, this is a real method in one of my projects:
def listen(self, address, ssl=False, ssl_args={}):
pass
Re: Anti-Patterns in Python Programming
#53Earlier quoted context omitted.
The l (lowercase L) and the 1 (one) look really similar. Could that be the cause of some confusion? Of course, the function name helps, but most developers have learned not to trust function names to be an accurate description of what the function does, especially in tricky interview questions. Still, I'd change this to something like: def append_five(l=[]): l.append(5) return l It tests the same thing (knowledge of…
I'm not a Python expert, but iirc from various blog posts the "l" variable does not get reset between function calls which will cause undesired behavior. So calling the function 3 times without argument would produce a list of size 1,2, and 3 with the third call rather than 3 lists of size 1. Can any Python guru's confirm?
Yes that is correct. The default value gets created when the function is interpreted ("compiled").
Re: Anti-Patterns in Python Programming
#54I always struggle to understand why a list comprehension alist = [foo(word) for word in words] is considered more Pythonic than map alist = map(foo, words)
Don't know if this is why, but the list comprehension takes an expression at the "foo(word)" location, and is therefore more general than map, which requires a function. The comprehension in that case is simpler.
words = ['w1', 'w2', 'w3']
[word[1] for word in words]
['1', '2', '3']
map(lambda x: x[1], words)
['1', '2', '3']
Re: Anti-Patterns in Python Programming
#55Earlier quoted context omitted.
> Mutables as default function/method arguments It would really make sense to change the semantics of Python to fix this issue.
Change them how, to no longer have functions be first class objects? The behavior of mutable default arguments is clear if you know how Python treats function objects. Any "fix" would handicap the language.
> to no longer have functions be first class objects?
There are other dynamic languages with functions as first class objects which don't share the "mutable default arguments" gotcha.
But having said that, any change regarding this would break backward compatibility.
Re: Anti-Patterns in Python Programming
#56Earlier quoted context omitted.
The l (lowercase L) and the 1 (one) look really similar. Could that be the cause of some confusion? Of course, the function name helps, but most developers have learned not to trust function names to be an accurate description of what the function does, especially in tricky interview questions. Still, I'd change this to something like: def append_five(l=[]): l.append(5) return l It tests the same thing (knowledge of…
I'm not a Python expert, but iirc from various blog posts the "l" variable does not get reset between function calls which will cause undesired behavior. So calling the function 3 times without argument would produce a list of size 1,2, and 3 with the third call rather than 3 lists of size 1. Can any Python guru's confirm?
The key is object mutability. A list type is mutable and a tuple type is immutable.
If the candidate correctly deduces what will happen, I'll ask them to write a bug-free version, which looks like one of the below:
def append_one(var=None):
var = var or []
var.append(1)
return var
if var is None:
var = []
var.append(1)
return var
Re: Anti-Patterns in Python Programming
#57Earlier quoted context omitted.
Change them how, to no longer have functions be first class objects? The behavior of mutable default arguments is clear if you know how Python treats function objects. Any "fix" would handicap the language.
Can you clarify? def foo(default_arg = []): Why can't that just be shorthand for: def foo(default_arg = ParamNone): if default_arg == ParamNone: default_arg = [] How would that break first class functions?
How would the above work for duck-typed lists, for example? How would the language "know" which types are mutable?
Re: Anti-Patterns in Python Programming
#58I find that the testing for empty is a bit misguided if you want to be rigorous with types.
for instance:
>>>def isempty(l):
>>> return not bool(l)
>>>isempty([])
True
>>>isempty(None)
True
Re: Anti-Patterns in Python Programming
#59The more frequent and dangerous pitfalls are, in my humble opinion: - Bare except: statements (that catches everything , even Ctrl-C) - Mutables as default function/method arguments - Wildcard imports!
Possibly the most interesting anti-pattern I saw was: a_list_of_words = "my list of words".split(" ") I never enquired why, since there were bigger issues in the code e.g. "unit testing" by running the code, taking the result and putting it as the check value. By running repr(value), copying out the string then comparing self.assertEqual(repr(value), '[ , ...]')
This is actually useful: you may want to experiment with different list_of_words in the future and typing the words between [" ", " ", " "] is time consuming. It's also less readable.
Re: Anti-Patterns in Python Programming
#60I can't think of a single case where using sentinel values is necessary or appropriate in Python. Generally speaking, one should just return from within the loop.
Funky OS of FFI APIs... but Python has a nice way of abstracting away the pattern using the second argument to iter().