On Wed, Nov 12, 2014 at 1:35 PM, Ben Finney <ben+pyt...@benfinney.id.au> wrote: > The more things people need to keep in mind when reading my code that > isn't stated explicitly in the code, the worse I consider the code to > be.
Then the ternary if/else operator should also be abolished. track["APIC:"].data if "APIC:" in track else None (With PEP 463, this would be: track["APIC:"].data except KeyError: None But this is from Python 2.7 code, so that was never going to happen anyway.) When you read the if/else version, you need to remember that it's evaluated middle-to-outside rather than outside-to-inside, and more importantly, that the first expression won't be evaluated at all if the key isn't present. So should we treat if/else as a "clever but obfuscatory trick, opposed to that property of Python" too? Or should people just get to know the language they're using? At least with 'assert', it's consistent across all Python programs; with my DEBUG example, it's per-project, as it's custom crafted. ChrisA -- https://mail.python.org/mailman/listinfo/python-list
