5
points
_ZeD_
Joined 2,264 karma
- keep in mind that, apart from the money throw at js runtime interpreters by google and others, there is also the fact that python - as a language - is way more "dynamic" than javascript.
Even "simple" stuff like field access in python may refer to multiple dynamically-mapped method resolution.
Also, the ffi-bindings of python, while offering a way to extend it with libraries written in c/c++/fortran/... , limit how freely the internals can be changed (see the bug-by-bug compatibility work done for example by pypy, just to name an example, with some constraint that limit some optimizations)
- Honestly I don't buy it. Worse, this is one of the reason I prefer to do "minimal integration tests" instead of unit tests. Take the example snippet of code
and the very first comment just belowdef get_user_settings() -> str: with open(Path("~/settings.json").expanduser()) as f: return json.load(f) def add_two_settings() -> int: settings = get_user_settings() return settings["opt1"] + settings["opt2"]>>> The thing we want to avoid is opening a real file
and then the article goes and goes around patching stdlib stuff etc.
But instead I would suggest the real way to test it is to actually create the damn file, fill it with the "normal" (fixed) content and then run the damn test.
This is because after years of battling against mocks of various sort I find that creating the "real" resource is actually less finicky than monkeypatching stuff around.
Apart from that; yeah, sure the code should be refactored and the paths / resources moved out of the "pure logical" steps, but 1) this is an example and 2) this is the reality of most of the actual code, just 10x more complex and 100x more costly to refactor.
- 3 points
- gosh...
no, no, no!try { val user = authService.register(registrationRequest.email, registrationRequest.password) return user } catch (exception: Exception) { // log exception throw exception }the whole point of the exceptions (and moreso of the unchecked ones) is to be transparent!
if you don't know what to do with an exception do NOT try to handle it
that snippet should just be
return authService.register(registrationRequest.email, registrationRequest.password) - what baffles me is how much more rage is coming from any other creative workers (painters, filmmakers, musicians) than from programmers.
Why are programs - the result of the ingenuity of people working in software field - not protected against AI slop stuff.
Why is there not any kind of narrative out there describing how fake and soulless is code written by any AI agent?
- Honestly, in my experience, the only good reason to have microservices in a "software solution" is to be able to match 1 service -> 1 mantainer/team and have a big (read "nested", with multiple level of middle-managers) group of teams, each that may have different goals. In this way it's very easy to "map" a manager/team to a "place" in the solution map, with very explicit and documented interactions between them
- but then the websites may offer a banner to ask the user to opt-in again and this information can be saved in a cookie, so it would not be asked again
maybe they can call it the "cookie banner"
oh, and also, if it would be annoying to keep saying "no, I don't want to opt-in again" the websites owners may say that it is government fault, as now they are required by law to show this banner
- > I would gladly take a command line flag that I can pass to python that makes all module loading lazy.
oh, you want a "break my libraries" flag? :D
seriously, in theory lazy imports may be "transparent" for common use cases, but I've saw too many modules rely on the side effects of the importing, that I understand why they needed to make this a "double opt in" feature
I don't want a promotion. I don't want a new role.
I want more money to keep doing what I already do.