1. 17

  2. 2

    another interesting one that’s not mentioned there, that I only learned recently. Instead of the “try…except: pass” anti pattern - use with contextlib.suppress when you want to ignore a possible exception.

    1. 1

      What makes try ... except: pass an anti pattern? Is it that except is supposed to be used for handling exceptions, and by passing you’re not actually doing it? Because I would probably find contextlib.suppress less obvious, unless I was familiar with the function already (suppress? suppress what?) than try ... except: pass.

      (I’m assuming that in either case you will want to comment on why you’re supressing / passing on the exception)

      1. 2
        1. While I don’t find suppress less obvious I get that it might seem so to some. You’re asking “suppress what” - well you call suppress with the exception type you want to suppress just like the except clause you’d write. is with contextlib.suppress(OSError):... less obvious than try...except OSError:pass.
          Also consider that the op’s link mentions for..else. One of the least obvious things that you need to know about this somewhat obscure language feature. But I agree with them that it’s better than the alternative, and for idiomatic python code it should be that not using them is an anti-pattern.

        2. I think try...except:pass as an anti-pattern because it defines an error-handling clause without any error handling in it. Instead it means “there’s no error to handle, this shouldn’t be considered an error”. And “suppressing an error” is a logical term for it and is a much cleaner solution.

        3. Sometimes you’ll want to comment on what you are suppressing. sometimes it should be obvious. The documentation of suppress brings up the case of trying to open a file and suppressing FileNotFoundError as an example of use. I wouldn’t feel the need to comment about that (either when using suppress or in an empty except clause). What do you do when the file wasn’t found and why you don’t handle that error case is up to your program’s logic, sometimes it would make obvious sense. Other times it won’t.

        1. 1

          Thanks for the explanation, that all makes sense to me 🙂

    2. -2

      Using open() is an anti-pattern now? Eventually people stop taking this crap seriously.

      1. 5

        That’s not what it said, it said it’s best practice to use with open() as file: because that way it’s guaranteed that the file will be gracefully closed/etc. if there’s an exception thrown within the with block. If you just use f = open() then there’s no guarantee everything will be handled gracefully if your program just dies with the file opened.

        1. 0

          It’s a bit more complicated than that, and @WilhelmVonWeiner is partly right.

          I would totally agree that opening a file for writing warrants using with every time. Because you never want to end up with an un-flushed write buffer in case of an accident. But opening a file for reading only is always safe. Even if your program crashes all your open descriptors will be cleaned up by the OS, there’s nothing “noble” in closing them all yourself. In this case insisting on a with prevents short, readable call compositions like cvs.reader(open('filename')) or return sys.stdin if filename is None else open(filename).

          1. 5

            I’m not sure this is always a good idea on Windows. IIRC that OS will prevent operations like removing a file if any process has it open. I can imagine getting annoyed with the above in, for example, the case of a config file for a long-running program.

            1. 5

              But opening a file for reading only is always safe.

              Unless you do it a lot in a short period of time and run over your OS’s limit of how many open files you can have. And yes, I’ve seen that actually happen with a python program that was written with the “opening for reading is safe” mentality and didn’t use with open and of course also ran into bugs of not closing files. (You can imagine that wasn’t the only thing wrong with how that program was written, but it was a big one.)

              1. 1

                Wait, are you seriously advocating not cleaning up allocated resources after you are done with them with the argument that you can sometimes get away with it without your program breaking?!

                Is this a common idea of how to manage resources? No wonder modern software runs out of them so quickly…