• Ivan Badger (unregistered)

    frist

  • Kaali (unregistered)

    TRWTF is using Python.

  • (nodebb)

    Having code in a class is the same as having bone marrow floating in your blood: the organism will not survive.

  • Pabz (unregistered)

    All IB's colleagues probably have Dunning Kruger Syndrome...

  • Scott (unregistered) in reply to Pabz

    Like my cow-worker who was given the task of making sure that sensitive data could be masked in a restore-from-production scenario.

    First, create a table that describes the table/column to mask, and the mask to apply. That seems o.k.

    Install that table in the same database as the one being masked, instead of creating a separate database specifically for this process. OK, nto the best, but it works. Makes it more likely that the process will be accidentally run on production, but not a huge issue I guess.

    Here's the process: --restore production to a working db --create a copy of the table being masked, copying data from "real" to "new" table --apply the mask to "new" table --drop any FKs in the "real" table --drop the "real" table --rename "new" table to "real" table --reapply FKs

    When asked why this was ever anything more than generating an update statement from the masking data, "well, I don't know...I'd have to think about that...". I don't know how such a process even occurs to someone to try.

    But nobody can figure out why our code is slow and unreliable.

  • Murray (unregistered)

    Obviously the try-except is also a WTF as no exception can be raised. But if one could be raised, swallowing it would be a terrible idea.

    My guess is that initially extend_f was inside the try.

  • Python Lover (unregistered) in reply to Kaali

    Python over all! Long live Python.

  • P (unregistered)

    When they say Python has powerful libraries they aren't joking, because if you try to write code to do task without offloading all the parts to an existing library, you're TRWTF.

  • ooOOooGa (unregistered) in reply to Mr. TA

    Does that still hold when talking about #ifdef in C code?

    The only functional difference that I see between the C preprocessor and python's ability to inline code into a class definition is the fact that the C preprocessor directives are a completely different language from the language that they are modifying.

  • Worf (unregistered) in reply to ooOOooGa

    No, because preprocessor directives in C are computed at compile time and won't ever change.

    Inline code in bodies change the body dynamically. In the example in the article, the function definition changes dynamically based on the value of X. So if you mishandle the variable you may not be executing the code you think you're executing.

    Powerful in some ways, a big conduit to WTFs in others.

  • Yazeran (unregistered) in reply to Worf

    Well what is the problem with self modifying code? evil grin. It is of of the resulting wonders of the Von Neumann architecture, and it will make sure that we will never run out of content for this site :-)

  • Marian (unregistered)

    This is the second Python-based article in a row.

    Is there a meta-story here? One about any language, however weird and niche at the start, breeds idiots to abuse itself as it gains traction?

    The specimen presented here could not have happened in any other language known to me.

  • witchdoctor (unregistered) in reply to Worf

    No, because preprocessor directives in C are computed at compile time and won't ever change.

    Inline code in bodies change the body dynamically. In the example in the article, the function definition changes dynamically based on the value of X. So if you mishandle the variable you may not be executing the code you think you're executing.

    Powerful in some ways, a big conduit to WTFs in others.

    It doesn't work that way, though you could probably build something that does if you're perverse enough and implement the right magic methods. The class definition acts as a statement that is executed once when the module it's in is loaded. Afterwards the class object is defined and the body doesn't change.

    Just try it in a python interpreter.

  • Herr Otto Flick (unregistered) in reply to Worf
    No, because preprocessor directives in C are computed at compile time and won't ever change.

    Inline code in bodies change the body dynamically. In the example in the article, the function definition changes dynamically based on the value of X.

    You're wrong. In the example in the article, that code runs exactly once - when the module is imported. The definition of mod.Class does not get re-evaluated because mod.x changes, so this is effectively identical to a preprocessor directive. Eg:

    import mod

a = mod.Foo()
mod.x = None
b = mod.Foo()
assert a.bar == b.bar
assert a.bar() is None

    In fact, this kind of code is common if supporting py2/py3, you may define a different function body depending on six.PY3.

Leave a comment on “An Utter Mockery”

Log In or post as a guest

Replying to comment #:

Log Out

« Return to Article