• 0 Posts
  • 31 Comments
Joined 1 year ago
cake
Cake day: August 18th, 2023

help-circle



  • Meh, that’s kind of the point, no? Seems like it would be more jarring to only federate at the community level, as you either a) still have to interact with people from the unwanted instance or b) deal with randomly hidden comments from that instance. If the community dies because it’s on an unpopular instance, well, that’s the way it goes. Can always start up/join a community on another instance that’s federated with yours.







  • I think that’s a little too simplistic. I definitely agree that “we can’t show you the evidence of why we made this decision but trust us” isn’t going to instill confidence in the community, but it’s not like the steering council is some unrelated board of executives. They’re all core developers, theoretically chosen for their dedication and contributions to Python as a whole, and it seems their granted power has made them anxious about showing favoritism among the most seasoned at the expense of upholding the community guidelines that keep the Python community a positive and welcoming place.

    I think a flawed decision was made, or at least the way it was presented was flawed, and that should be considered for the next election. Maybe the council does need to be totally overhauled, that’s a valid position. But this is their work, too, and imply they have no skin in the game is disingenuous.



  • I didn’t want to take this at face value without context so I found when they discussed this. Check around 1:17:00 in this video.

    https://youtu.be/lfBQoWxQaEM?si=6Ev6rx62KESH-HgR

    And yeah, he did say exactly what the OP states. So… yeah.

    To give the absolute benefit of the doubt, I could say they were referring specifically to nuclear fallout rather than the initial explosion, as a full on explosion is less likely in a nuclear plant emergency. But even assuming it was just an incredibly distasteful way to reference that, there are still thousands of deaths and even more injuries/illnesses associated principally with radiation poisoning.

    This is not to say I’m against nuclear energy, but by god we’ve got to have more careful consideration than this.

    Edit: As a bonus, Musk talks about his views on global warming around the 1:10 mark. The issue with greenhouse gasses is, uh… making it hard to breathe?






  • The biggest issue would be muscle atrophy. Even if you’re pretty sedentary, your muscles are doing a lot of work each day just to move you around. Being bedridden for even a few days can cause muscle loss. You also increase the risk of blood clots and bed sores.

    Medically induced comas also come with risk of permanent injury or death, so they really only do them in absolute emergencies.

    And lastly, there are already surgeries and medications for weight loss that work much faster. The issue is, without matching lifestyle changes, all that weight will just come back.



  • For unit tests, you should know the input and expected output from the start. Really responsible devs write the unit tests first, because you should know what you’re going to put in and what you’ll get out before you start writing anything. If you find yourself making the same mistakes in your tests as you do your code, you might be trying to do too much logic in the test itself. Consider moving that logic to its own testable class, or doing a one-time generation of a static set of input/output values to test instead of making them on the fly.

    How granular your tests should be is a matter of constant debate, but generally I believe that different file/class = different test. If I have utility method B that’s called in method A, I generally test A in a way that ensures the function of B is done correctly instead of writing two different tests. If A relies on a method from another class, that gets mocked out and tested separately. If B’s code is suitably complex to warrant an individual test, I’d consider moving to to its own class.

    If you have a super simple method (e.g. an API endpoint method that only fetches data from another class), or something that talks with an external resource (filesystem, database, API, etc.) it’s probably not worth writing a unit test for. Just make sure it’s covered in an integration test.

    Perhaps most importantly, if you’re having a lot of trouble testing your code, think about if it’s the tests or the code that is the problem. Are your classes too tightly coupled? Are your external access methods trying to perform complex logic with fetched data? Are you doing too much work in a single function? Look into some antipatterns for the language/framework you’re using and make sure you’re not falling into any pitfalls. Don’t make your tests contort to fit your code, make your code easy to test.

    If ever you feel lost, remember the words of the great Testivus.