• GiorgioBoymoder [none/use name]@hexbear.net
    link
    fedilink
    English
    arrow-up
    17
    ·
    edit-2
    21 hours ago

    it’s really fucking with me that neither axis follows a progressive ordering so I’m going to post a fixed (debugged) version. EDIT: lmao this is the most fucked up, inconsistent alignment chart I’ve seen. here it is fixed:

    everything -> sometimes -> nothing

    know -> not sure -> don’t know

  • BlueMagaChud [any]@hexbear.net
    link
    fedilink
    English
    arrow-up
    5
    ·
    21 hours ago

    the “sometimes works, don’t know why” is the most maddening, I love tearing my hair out just trying to get it to fail reliabily so I’ve got a single hint

  • TheDoctor [they/them]@hexbear.net
    link
    fedilink
    English
    arrow-up
    6
    ·
    23 hours ago

    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.

    • jollyrogue@lemmy.ml
      link
      fedilink
      arrow-up
      4
      ·
      21 hours ago

      Aren’t setters and getters discouraged in Python?

      I remember reading something like, “This isn’t C++ , and Python doesn’t have private vars. Just set the var directly.”

      • TheDoctor [they/them]@hexbear.net
        link
        fedilink
        English
        arrow-up
        1
        ·
        19 hours ago

        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.

    • ☆ Yσɠƚԋσʂ ☆@lemmy.mlOP
      link
      fedilink
      arrow-up
      5
      ·
      22 hours ago

      I find setters/getters are generally an antipattern because they obfuscate behavior. When you access a field you know what it looks like, but if you pass it through some implicit transformation in a getter then you have to know what that was.

      • TheDoctor [they/them]@hexbear.net
        link
        fedilink
        English
        arrow-up
        5
        ·
        22 hours ago

        Yeah. I can understand the use case when it’s something relating to keeping simple state in sync by replacing it with derived state. But this particular case was flushing a cache after each get, which made each get of the property non-deterministic based on the class’s state.