7 ms·
There are some that you can find in [0], but they are often de-contextualized (and sometimes aren't really Python's problem, because there was a trade off that
by tgbugs 6y ago
There are some that you can find in [0], but they are often de-contextualized (and sometimes aren't really Python's problem, because there was a trade off that had to be made, and the LOL is just frustration as a result of the bad ergonomics that it creates), those and some others will eventually go in an longer post when I finally get that set up.
To give one concrete example of an LOL PYTHON consider the @property decorator. While it seems like a really cool and handy idea that could let you save some typing in some cases, it is actually a trap that you should almost never use because when you inevitably discover that there is some parametrization that you need to pass to the ... attribute, you are suddenly faced with a massive refactoring. Also if you ever make the mistake of having boolean properties such as isDir or isUrl and somewhere else you have a predicate that is a function instead of a property then isFile will always return True when you meant isFile(). The only safe solution is to never use properties/attributes as predicates. These are nasty footguns that seem obscure and unlikely to affect you until you have the misfortune to already be in the briar patch.
0. https://github.com/search?q=%22LOL+PYTHON%22+user%3Atgbugs&type=code https://github.com/search?q=%22LOL+PYTHON%22+user%3Atgbugs&t...
- silvester23 6y agoIf I understand correctly, I think the problem with your second example is that you should avoid checking for `True` with something like `if isFile` but instead `if isFile is True`. That would solve this specific problem (and is also slightly more efficient because no implicit boolean conversion is performed).
- roywiggins 6y agoYou can do that, but loose checking for truthiness is pretty pythonic. It's weird to put "true" in there if you think you're checking a boolean property. If you know you're not, then you realize you need to call the function and then you can remove the "is".
- tgbugs 6y agoThis one is a bit more subtle. Assume there are two classes on that uses @property and one that does not. class Here: @property def booleanPredicate(self): return random_bool() class There: def anotherBooleanPredicate(self): return random_bool() here = Here() there = There() What happens in the following cases? here.booleanPredicate # as expected here.booleanPredicate() # loud failure here.anotherBooleanPredicate # silently always True here.anotherBooleanPredicate() # as expected So you might think that you should _always_ use @property for boolean predicates, except that there are libraries that use the anotherBooleanPredicate version so you are now at risk for silent always True behavior (creeping sanity destroying evil behavior). To prevent the silent failure you should always start by calling the predicate so that it can fail loudly. Worse if someone does a refactor and misses going from @property form to function form then the silent failure literally cannot be detected by running the program (!).
- at_a_remove 6y agoI am not trying to be edgy here when I say that I have viewed a lot of the "syntactic sugar" business with a great deal of skepticism. Piggybacking off of your example, upon reflection I believe that me looking askance at decorators is partially a learned fear (I escaped Perl), and partially because decorators seem a little like "bad magic," where you have cast a handy but seemingly innocuous spell only to find that it has deeper consequences later.