5 ms·

You're confusing improper lack of abstraction with error handling methodology. The place to use EAFP in this example is in dict.get itself: def get(self,

You're confusing improper lack of abstraction with error handling methodology. 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 (made-up implementation ^ I'm not sure if Python's stdlib actually does exactly that) 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.

jsmthrowaway 10y ago
I'm not confused about anything aside from your claiming I'm confused and then agreeing with me in your conclusion. 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.
- deleted 10y ago
  [deleted]
- mangeletti 10y ago
  > Your code is quite obviously incorrect. You sho-bout that? https://repl.it/Cbu8/4 https://repl.it/Cbu8/4 If you're new to programming, you can learn a lot more by listening than by arguing.
  - jsmthrowaway 10y ago
    Yes, I'm quite sure, since your code above contains "return SENTINAL" and you fixed the bug in your link. (It's also sentinel.) It's doubly incorrect even in a specification sense, since dict.get defaults to None by returning NULL (it is implemented in C in CPython[0][1], and I'm assuming you can read those references based on your assertion of skill) and no sentinel is used or needed. In your Python translation, that'd be defaulting to None instead of a sentinel. It's triply incorrect because dict.get also does not re-raise a KeyError; it always returns something barring a runtime error of some kind or asking for a key that cannot be hashed: >>> {}.get({}) is None TypeError: unhashable type: 'dict' >>> {}.get("key") is None True >>> {}.__hash__ is None True >>> "key".__hash__ is None False Let me fix your example for you: def get(self, key, default=None): try: return self[key] except KeyError: return default Although really, the C implementation does this, indirectly: def get(self, key, default=None): return self[key] if key in self else default The reason I say indirectly is because (a) there's no exception handling in use in the C case and (b) there's no equivalent to the hash table lookup failing when written in Python, so it's an inexpressible concept. That Python will search twice, while the C does not. The KeyError except is a nice analog, but CPython does not futz with stack frames at all if the key lookup fails, so it's not directly comparable to your version. My final version is the closest you'll get to translating what Python does to Python. 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/dictobject.c#L2632 https://github.com/python/cpython/blob/master/Objects/dictob... [1]: https://github.com/python/cpython/blob/master/Objects/dictobject.c#L2347-L2374 https://github.com/python/cpython/blob/master/Objects/dictob...
    - mangeletti 10y ago
      I don't have time to read your reply yet, for the same reason I didn't have time to waste on typos, etc., because I'm on my phone (traveling through Europe, no notebook), but it's clear your ego is preceding you, and thus you won't learn from my comment anyway. The others that upvoted me did. 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.
      - jsmthrowaway 10y ago
        You have to be trolling.
        mangeletti 10y ago
        TBH, this is what happens when an immovable object meets an unstoppable force haha. I saw the rest of your comment above now, and I realize (please bear in mind, I was typing on my phone while walking through noisy Praha, after some wine) that I was thinking of getattr while I was typing that. I also scrolled up to realize the bug you mentioned (re: returning the sentinel value). Also, my gratuitous use of the misspelled "SENTINAL". 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.
        jsmthrowaway 10y ago
        No, that's not "what happens haha." Those are several lame and, frankly, childish excuses instead of just owning that you arrogantly and condescendingly misjudged my competence and inappropriately spoke down to me like you were the universe's gift to comprehension of error handling in Python. You should learn from the experience and assume at all times that you are not the most skilled person in the conversation. I am never the most skilled person in any conversation, which, ironically given your assertions about me earlier in this thread, allows me to learn quite a bit. 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.

jsmthrowaway 10y ago

I'm not confused about anything aside from your claiming I'm confused and then agreeing with me in your conclusion. 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.

deleted 10y ago
[deleted]
mangeletti 10y ago
> Your code is quite obviously incorrect. You sho-bout that? https://repl.it/Cbu8/4 https://repl.it/Cbu8/4 If you're new to programming, you can learn a lot more by listening than by arguing.
- jsmthrowaway 10y ago
  Yes, I'm quite sure, since your code above contains "return SENTINAL" and you fixed the bug in your link. (It's also sentinel.) It's doubly incorrect even in a specification sense, since dict.get defaults to None by returning NULL (it is implemented in C in CPython[0][1], and I'm assuming you can read those references based on your assertion of skill) and no sentinel is used or needed. In your Python translation, that'd be defaulting to None instead of a sentinel. It's triply incorrect because dict.get also does not re-raise a KeyError; it always returns something barring a runtime error of some kind or asking for a key that cannot be hashed: >>> {}.get({}) is None TypeError: unhashable type: 'dict' >>> {}.get("key") is None True >>> {}.__hash__ is None True >>> "key".__hash__ is None False Let me fix your example for you: def get(self, key, default=None): try: return self[key] except KeyError: return default Although really, the C implementation does this, indirectly: def get(self, key, default=None): return self[key] if key in self else default The reason I say indirectly is because (a) there's no exception handling in use in the C case and (b) there's no equivalent to the hash table lookup failing when written in Python, so it's an inexpressible concept. That Python will search twice, while the C does not. The KeyError except is a nice analog, but CPython does not futz with stack frames at all if the key lookup fails, so it's not directly comparable to your version. My final version is the closest you'll get to translating what Python does to Python. 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/dictobject.c#L2632 https://github.com/python/cpython/blob/master/Objects/dictob... [1]: https://github.com/python/cpython/blob/master/Objects/dictobject.c#L2347-L2374 https://github.com/python/cpython/blob/master/Objects/dictob...
  - mangeletti 10y ago
    I don't have time to read your reply yet, for the same reason I didn't have time to waste on typos, etc., because I'm on my phone (traveling through Europe, no notebook), but it's clear your ego is preceding you, and thus you won't learn from my comment anyway. The others that upvoted me did. 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.
    - jsmthrowaway 10y ago
      You have to be trolling.
      - mangeletti 10y ago
        TBH, this is what happens when an immovable object meets an unstoppable force haha. I saw the rest of your comment above now, and I realize (please bear in mind, I was typing on my phone while walking through noisy Praha, after some wine) that I was thinking of getattr while I was typing that. I also scrolled up to realize the bug you mentioned (re: returning the sentinel value). Also, my gratuitous use of the misspelled "SENTINAL". 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.
        jsmthrowaway 10y ago
        No, that's not "what happens haha." Those are several lame and, frankly, childish excuses instead of just owning that you arrogantly and condescendingly misjudged my competence and inappropriately spoke down to me like you were the universe's gift to comprehension of error handling in Python. You should learn from the experience and assume at all times that you are not the most skilled person in the conversation. I am never the most skilled person in any conversation, which, ironically given your assertions about me earlier in this thread, allows me to learn quite a bit. 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.