>>108749060
Do not use exceptions for flow control.

>>108749060
second one is what someone brown would write

Which ever one your job requires, you.. are employed, yes?

>>108749060
WHAT LANGUAGE IS THIS
WHY DOESN'T IT HAVE CURLY BRACES OR SEMICOLONS AT THE END?
ALSO WHAT THE FUCK, YOU'RE NOT SUPPOSED TO USE TRY CATCH BLOCKS LIKE THAT

>>108749060
niggerlicious

>>108749069
this is what python does. They implemented their iterators this way, throwing when its exhausted

To me Style A implies we're not sure whether `obj` will have the "foo" attribute (and want to gracefully handle both scenarios); whereas Style B implies we expect `obj` to have the "foo" attribute (but we'll handle the scenario where it doesn't, just in case).

Notably, Style A doesn't actually attempt to access `obj.foo` - so if a future developer were to attempt to access the property, guarded by the `if hasattr` check, there could be goofy ah bullshit where actually accessing the value fails. Style B discards the results of `obj.foo`, plus is relying on exceptions, so it seems like it'll be more expensive at runtime - but depending on whether we expect future developers to actually want to act on the value, it might be worth it to make it clear up-front that the value is available in that scope.

Are exceptions part of some underlying attribute API's domain model? If so, it may be preferable to rely on their validation (which could have more complex rules at runtime than are expressed by `hasattr`, and handling the exception is their preferred pattern. (In the best case, assuming the rules are the same, we might be incurring the same check twice - once in our scope, and again in theirs).

File: 1747375393349752.jpg (96 KB, 720x959)

96 KB JPG

>>108749060
Using exceptions for control flow is pure jeetshit.
Therefore, anything in Python is pure jeetshit.

>>108749263
I'll add it to my list of reasons to hate kikethon for

>>108749060
To put it in English:

Style A:

If this object has attribute of type "fruit",
  print to the standard console that the object in question has attribute of type "fruit"

In all other circumstances, print "no fruit" to the standard console.

So yeah, I'm going with Style A

>>108749060
if-else is fast
try-except is slow
>>108749069

>>108749069
depends on the task at hand
not everything is a big complicated machine desu

only time exception should be raised in general is if there is something blocking the programming from proceeding in earnest

but then we'd start talking about async

>>108750663
hasattr has exception built-in

File: python_hurt.png (71 KB, 500x494)

71 KB PNG

>>108749091