> Easier to ask for forgiveness than permission. This common Python coding style assumes the existence of valid keys or attributes and catches exceptions if the assumption proves false. This clean and fast style is characterized by the presence of many try and except statements. The technique contrasts with the LBYL style common to many other languages such as C.
This SO answers it nicely: http://stackoverflow.com/a/11360880/6189743
try:
bar = dictionary['foo']
except KeyError as ex:
# handling
bar = dictionary.get('foo')
if bar is None:
# optional handling, None might be OK
bar = dictionary.get('foointeger', 0)
# now you don't even need handling
That addresses the specific case mentioned, of course, but not others. Occasionally you do have to handle exceptions but this almost always revolves around I/O, and you can isolate those portions in well-defined types that expose functionality to the rest of your program instead of trying every few lines.
The place to use EAFP in this example is in dict.get itself:
def get(self, key, default=SENTINAL):
try:
return self[key]
except KeyError:
if default is not SENTINAL:
return SENTINAL
raise
I absolutely love Python's exception handling, and I strongly subscribe to EAFP (not just in coding, even), but I rarely use try/except, because most of the time your business logic (where I spend most of my time) should be delegating to something (external/internal library, etc.) that handles exceptions, rather than littering your business logic with low level logic.
I'm reacting to the explanation of EAFP using that example. And no, Python's implementation does not do that, since (a) I'm almost positive dict.get is not Python and (b) your code is quite obviously incorrect.
You sho-bout that?
If you're new to programming, you can learn a lot more by listening than by arguing.
>>> {}.get({}) is None
TypeError: unhashable type: 'dict'
>>> {}.get("key") is None
True
>>> {}.__hash__ is None
True
>>> "key".__hash__ is None
False
def get(self, key, default=None):
try:
return self[key]
except KeyError:
return default
def get(self, key, default=None):
return self[key] if key in self else default
If you're speaking with someone new, you can learn a lot more by not condescendingly assuming competence of the other party, particularly when they correctly spotted those three problems and you didn't. I trust this reply will alleviate the misconception.
[0]: https://github.com/python/cpython/blob/master/Objects/dictob...
[1]: https://github.com/python/cpython/blob/master/Objects/dictob...
I don't know what typo my first example has (the bug you mentioned), but the point is to teach you about the value of using try/except in abstraction, rather than littered throughout your code.
Despite our alpha mentalities, we are not worlds apart, truthfully. My original response came across sounding hardliner pro-try-except, anti-anything-else, but my point was only that people abuse exception handling in their primary business code (e.g., directly handling a network IOError in a Django view). As a result, they have a bad time. Libraries and utils should be relegated to exception handling duties like that. When following principles like developers love Python's try / except blocks for their clarity.
Do not project your "alpha mentality" onto me, please. I am the polar opposite of "alpha." That was all you.
You were wrong, and I didn't stoop down to assuming anything about your competence as you so desperately tried to get me to do. Instead of blaming wine like a child, you should probably objectively look at yourself and your judgments of people. Your attitude is not uncommon, and I specifically look for it when I interview.
I'd have a lot more respect for you if you'd own the mistake, but I can tell that you're not going to, so this will be my last comment in this thread as well.
1) the "except" semantics help hit home the point you expect the key to be there most of the time
2) in cases where the exception will rarely be raised, the "try ... except" route runs faster than the ".get() ... if" route.
Through a link in your link you get: "Look before you leap"
Also, i did not complain at all - i was confused and posted it to help others. You start off assuming i had negative intentions, and i don't appreciate that. I was simply helping.