TheDoctor [they/them]

  • 0 Posts
  • 41 Comments
Joined 9 months ago
cake
Cake day: March 25th, 2024

help-circle


  • Technology is great to discuss because it’s just logic and facts and objective arguments. But bring in politics and it becomes a mess and that’s the problem with this divide in the privacy community.

    Good post in general, but I disagree with this in particular. All technology is political. Not in a Democrat/Republican way but in a “how do we distribute resources within society?” way. Not to mention a big selling point for privacy tools is that they can be used by political dissidents. I think a problem does arise when a community manages to fool itself into believing it’s apolitical when what it’s really done is develop an orthodoxy to shut down political discussion.




  • TheDoctor [they/them]@hexbear.nettoProgrammer Humor@lemmy.mlDebugging
    link
    fedilink
    English
    arrow-up
    10
    ·
    edit-2
    1 month ago

    I did both of these at once last week.

    Added a breakpoint. Debugger didn’t break.

    Added an echo "here";. Debugger didn’t print.

    Added a throw new Exception('fuck');. Debugger didn’t throw.

    Stepped through. Debugger wouldn’t let me step in.

    It took me almost an hour to realize it wasn’t the debugger’s fault and that a variable I thought was guaranteed to be truthy at that point was actually falsey due to upstream changes in a spreadsheet parser. I felt kind of stupid for not trusting the debugger at that point.




  • In the way that’s common in languages like Java where you’re making a property read-only, yes. But there’s a whole protocol in Python called descriptors where you can override the . on a field. The most common form of these is class methods annotated with the @property annotation, which makes it so the method can be accessed as if it were a property.



  • I helped a friend debug a script last week that was working inconsistently in really weird ways. I looked at the script and it was all event hooks littered with sleep calls. I told him he was basically fuzz testing his own script and then getting surprised when he found race conditions. Shit was wild. Also, sometimes getters in Python are a mistake.









  • I often use comments as ways to say, “I know this is cursed, but here’s why the obvious solution won’t work.” Like so:

    /**
     * The column on this table is badly named, but
     * renaming it is going to require an audit of our
     * db instances because we used to create them
     * by hand and there are some inconsistencies
     * that referential integrity breaks. This method
     * just does some basic checks and translates the
     * model’s property to be more understandable.
     * See [#27267] for more info.
     */
    

    Edit: to answer your question more directly, the “why not what” advice is more about the intent of whether to write a comment or not in the first place rather than rephrasing the existing “what” style comments. What code is doing should be clear based on names of variables and functions. Why it’s doing that may be unclear, which is why you would write a comment.