• Quite (unregistered)

    Consfued? You will be frist ...

  • Sole Purpose Of Visit (unregistered)

    Love the expectation (according to the comment) that somehow adding extra unit tests will make the terrible design go away ...

  • (nodebb)

    It occurs to me that, in a general sense, to_number will do strange things if the number is an integer (no fractions), but big enough to be impossible to coerce to int.

  • Sauron (unregistered)

    The original author probably has the potential of triggering worldwide shortage of LSD when they code.

  • (nodebb)

    I read the first method, had my mind blown, and decided it was enough WTF for the day. Thank you to the author! Your work trying to understand more of it is truly appreciated.

  • homsar (unregistered) in reply to Steve_The_Cynic

    Since Python 3, integers are unlimited length, so I think that problem would only occur if the code were still using Python 2.x in 2022. Which isn't impossible if the code was written 6 years ago, but doesn't seem that likely.

  • Hal (unregistered)

    Clear examples of coding-around-the-problem if I have ever seen them. Obviously this person started with little understanding of what they were really trying to do. They proceeded to shotgun edit the code until all the runtime errors went away and they got the output they wanted for their test data.

    It probably produces correct results often enough nobody realizes how broken it is. However it can't be understood because it does not do what it claims to do. Eventually someone will want to replace this with something rational that actually implements the rules the business believes it has; maybe some more disciplined folks will be in charge of software by then and someone will get the idea they run transactions in parallel for a while - when they do they will see the results are NOT the same then the tortured effort re-implement the old logic so customers get the same bill begins...

  • Stella (unregistered)

    Considering the unit test comment, and to my own experience, fixing expectations is way harder than fixing the software.

  • Michael P (unregistered)

    With apologies to Robert Towne: Forget it, Jake, it's Python.

  • (nodebb) in reply to homsar

    OK, so integers are all bignums?

    Re: use of 2.x: you'd be surprised. Don't forget RedHat's Anaconda installer from way back, which still used Python 1.6 way past its sell-by date.

  • davethepirate (unregistered)

    Looks like a Perl programmer that was required to code in Python.

  • xtal256 (unregistered)

    I just realised that the word "product" can also mean "the result of a multiplication". So the variable named "product_product" seems almost intentionally confusing! Like this was the original author's idea of a joke.

  • (nodebb) in reply to Sauron

    The authors have already used up all the hash themselves.

  • (nodebb) in reply to Steve_The_Cynic

    integers are all bignums?

    Conceptually, yes. It's a pretty common approach across many languages that gets rid of a lot of weird edge cases. Doesn't mean that they have to be implemented that way the whole time, but you won't notice the shenanigans inside the box if you only look at the outside of the box.

  • Luter995 (unregistered)
    Comment held for moderation.
  • Erin (unregistered)
    Comment held for moderation.

Leave a comment on “Very Productive Code”

Log In or post as a guest

Replying to comment #:

Log Out

« Return to Article