• 3stdev (unregistered)

    assert "First" == "Frist"

  • bvs23bkv33 (unregistered)

    Стас? ты опять выходишь на связь?

  • someone (unregistered)

    I like thepass in there. Clearly added the print without thinking too much.

    Explanation for non-python devs: since python is extremely picky about indentation (TRWTF), one must specify pass when the parser expects an indented block but there isn't one (e.g. you want to create a subclass but don't want to actually add anything new).

  • Ben (unregistered)

    lol

  • Zach (unregistered)

    I messed up. lol :D

  • Raj (unregistered) in reply to someone

    TRWTF in python is that try-except blocks are considered a best practice to test non-error conditions. For instance if you want to make sure a file doesn't exist before creating it, the pythonic way to do it is to delete it in a try block.

    It takes a while to get used to python when you have worked with other languages, and vice-versa.

  • my name is missing (unregistered)

    Our code is crap, our customers are angry, executives are jumping out of windows, but lol.

  • Dlareg (unregistered)

    It is better then the except: pass parts I see in the code all the time, that just swallows the error.. and gives you real horror. I am planning of making a git hook, which does not allow you push such changes. If only I knew git well enough.

  • Pine (unregistered) in reply to bvs23bkv33

    Google переводит на победу.

  • Matt (unregistered)

    python is extremely picky about indentation (TRWTF)

    Forgive the lurch into action because someone is Wrong On The Internet, but in fact this is one of the best features of Python. Traditionally indentation is for humans, braces (or whatever) are for computers. But if you have both, they can get out of sync. So why not use just one, preventing you from getting screwed up by mismatched whitespace and formatting characters? And if you just use one, why not use the one that's easy for humans to read?

    As far as the article itself, I'll just quote from The Zen of Python: Errors should never pass silently. Unless explicitly silenced.

  • Fredde (unregistered) in reply to Dlareg

    There's a pretty useful idiom that involves empty except blocks: a one-or-two-line try block that performs a side effect (such as reassigning a variable) only if a return value shows that the side effect is applicable. If instead a specific type of exception signals that no valid return value can be produced for an expected reason, the side effect isn't performed. But all that is yet more clearly expressed using contextlib.suppress().

  • JBadger (unregistered)

    Assert is actually never supposed to be used this way. If someone runs your python script with a '-o' , or if 'debug' gets mis-set, assert statements never get run, and the validation never happens.

    https://dbader.org/blog/python-assert-tutorial

  • (nodebb) in reply to Raj

    if you want to make sure a file doesn't exist before creating it

    Um, don't you achieve this atomically by asking the OS to "create or fail"?

  • Developer Dude (google) in reply to Dlareg

    Almost all of our legacy code swallows exceptions, either totally ignoring them altogether, or printing the stack trace. At best, in a very few cases, the user is presented with a dialog saying (to the effect) "something bad happened - too bad so sad".

  • siciac (unregistered) in reply to my name is missing

    executives are jumping out of windows, but lol.

    Autodefenestration means you're doing something right.

  • Somebody Somewhere (unregistered)

    That'd be a forgivable excuse, except the 'lol' at the end. Those three little letters change the tone of the response from "Sorry about that, I'll be more vigilant in the future," to "Hahaha I don't know what I'm doing and I don't care! Wheeee!", and would make me want to garrote the programmer with a keyboard cord.

  • snoofle (unregistered) in reply to Dlareg

    As opposed to something like "On Error Resume Next"

  • Karl Bielefeldt (github) in reply to Raj

    Using exceptions is the correct way to ensure against file race conditions in many languages. Otherwise you have the possibility of a file being created by another process in between when you do the os.path.isfile("my_file") and open("my_file").

  • someone (unregistered) in reply to Raj

    That's a fair point. I've never liked how the "best" way to try converting user input into a float is to just do it and catch the error.

    I do sort of understand though, I guess the idea is that you can't accidentally introduce bugs because you have to explicitly check for failure.

  • Hans van der Waal (unregistered)

    I am an old Cobol, Dibol and Vb, Vba, Foxpro guy 75 years of age and just for the fun of it I learned Scratch amazing what kids can do with it, Ruby and Python. After a while I liked the strict way my country man Van Rossem asks from you. I tried several editors to get used to and Wings is my favorite. But I hate the loose way with the variables which stands in sharp contradiction with the discipline of the coding style. So I have made it a habit of declaring the variables in the Vb style with comment for each variable what it does. If you look at a program which you made half a year ago and want to alter it, you look at your code and ask yourself -did I write that and what does it do. I think the guys who are in charge of Python should alter it and change to strict typing and declaring of the variables. It is a very weak point in an overall beautifull language.

  • ax6 (unregistered) in reply to snoofle

    That's just as bad (but not always!), but everyone knows that one.

    The "not always" comes from the fact that some things in VB can only be done by blindly trying. Consider a function thay returns the size of a dynamic array that may be empty:

    Public Function MyArraySize () As Long On Error Resume Next MyArraySize = 0 MyArraySize = UBound(MyArray) - _ LBound(MyArray) + 1 End Function

    TRWTF is that there's no better way to write this function, though.

  • Shortest Circuit (unregistered) in reply to Somebody Somewhere

    A wired keyboard... how quaint. How's the new compiler for Fortran77 coming along? (you have to tell these fairies they can't drink chai tea for a day for each written smiley, lol, whoops, etc...)

  • someone (unregistered) in reply to Shortest Circuit

    I can't stand wireless keyboards; I hate batteries. Which was a problem back when I was looking for a keyboard a while ago that had calculator and multimedia buttons. I managed to find a nice one in the end though.

  • HK-47 (unregistered) in reply to Karl Bielefeldt

    That is why you don’t do it like that. You create file using system API and specify flag FAIL_IF_EXISTS.

  • Tiucric Tsetrohs (unregistered)

    My rule to preserve residual sanity is: If you can use a wire - do it.

    I use my hammer drill gladly to punch a hole in the wall if that means I don't have to deal with shit like:

    1. Bored neighbours hacking the shitty device.
    2. Random interference and horrible performance because of invisible things.
    3. Dead batteries.

    If you use radio to let your keyboard on your desk speak to your laptop also on your desk, I won't ask you if you are retarded anymore.

  • IP Guru (unregistered)

    1 Python is a strongly typed language. 2 Pythons try: except process is usually a very good way to handle this type of problem, try to open file, catch error if one occurs. what is not good practice is a bare expect. you should only capture the explicit error conditions you are expecting & can correctly recover from, anything else should be let to bubble up to the calling routine.

    1. asserts are NOT a good way to control a python application as they can be disabled at runtime. this example should be replaced with a simple if, Else check (& probably should do something more with the error condition.)
  • (nodebb) in reply to Somebody Somewhere
    That'd be a forgivable excuse, except the 'lol' at the end. Those three little letters change the tone of the response from "Sorry about that, I'll be more vigilant in the future," to "Hahaha I don't know what I'm doing and I don't care! Wheeee!", and would make me want to garrote the programmer with a keyboard cord LOL.

    FTFY

  • (nodebb)

    That's why commenting helps:

        try: # HTH
        assert r.status_code == 201 # IMHO
    except: # WTF
        print(r.text) # NSFW
        pass # LOL
  • Dr Pedantic (unregistered)

    Fails when -O is passed on the command-line or PYTHONOPTIMIZE is set.

Leave a comment on “Assertive Programming”

Log In or post as a guest

Replying to comment #:

Log Out

« Return to Article