• 3 Posts
  • 126 Comments
Joined 2 years ago
cake
Cake day: June 10th, 2023

help-circle








  • You need to get over the bloat of virtual environments. It’s the same as node_modules and it’s completely necessary if you want more than a single python project to live on your machine.

    I personally use poetry as my dependency manager and build tool. It’s not perfect but it’s a lot better than pipenv or just rawdogging pip like a maniac. uv is the new hotness, but I haven’t tried it so can’t vouch. People seem to like it though.

    JavaScript is also an interpreted language with tons of build tools. The reason to have one for python is mainly about packaging and code distribution, so same as JavaScript. If you want to distribute a program you probably don’t want to just point people to a GitHub repo, and if you want to publish a package on pypi it needs to be bundled correctly.

    For ecosystem there isn’t much I can do for you, it completely depends on what you’ll be working on. Baseline you want pydantic for parsing objects, assuming some APIs will be involved. You want black for code formatting, flake8 for linting, pytest for testing. If you’re gonna write your own APIs you can’t go wrong with fastapi, which works great with pydantic. For nice console stuff there’s click for building cli apps and rich and textual for console output and live console apps respectively.

    People are actively trying to replace flake8 and black with feature compatible stuff written in rust but again I haven’t tried those so can’t vouch.

    Coming from react you’re gonna need to pretty quickly switch gears to thinking more object oriented. You’re gonna be annoyed at how you can’t just quickly declare a deeply nested interface, that’s just how it is. The biggest change other than object oriented thinking will probably be decorators. Typescript had them experimentally and only for classes, python has them for classes and functions natively. They’re a bit tricky to wrap your mind around when you want to write your own, but not too bad. A lot of Google hits will be outdated on this front. Google specifically “decorators ParamSpec” to see how to make them properly.

    Good luck in your new job, you’ll be grand!


  • Definitely those used to be pain points, but they do exist now so type erasure after decorator application isn’t a problem anymore, which used to be another huge one for me.

    The discussion around how unpopular it was in other languages seems like such an obvious side track to me. Typing in general went out of fashion and then made a comeback when it was opt-in, why wouldn’t the same apply to exceptions? Of course I’m not wanting warnings in every func call because of a potential MemoryCorruptionError, but if a library has some set of known exceptions as a de facto part of its interface then that’s currently completely unknown to me and my static type checker.

    One kinda bad example is playwright. Almost all playwright functions have the chance to raise a TimeoutError, but even if you know this you’ll probably shoot yourself in the foot at least once because it’s not the built-in TimeoutError, oh no, it’s a custom implementation from the library. If you try to simply try...except TimeoutError:, the exception will blow right by you and crash your script, you’ve got to import the correct TimeoutError. If it was properly typed then pyright would be able to warn you that you still need to catch the other kind of TimeoutError. It’s a bad example because like I said almost all playwright functions can raise this error so you’d get a lot of warnings, but it also demonstrates well the hidden interface problem we have right now, and it’s the most recent one that screwed me, so it’s the one I remember off the top of my head.





  • I code both typescript and python professionally, and python is almost as much of a mess, just a different kind of mess. The package manager ecosystem is all over the place, nobody is agreeing on a build system, and the type system is still unable to represent fairly simple concepts when it comes to function typing. Also tons of libraries just ignore types altogether. I love it, but as a competitor to JavaScript in the messiness department it’s not a good horse.





  • I’m sorry if I misinterpreted the quote about places with legal gun owners having less illegal gun owners. How else should I have interpreted it?

    You pulled a statistic, please provide a source for it.

    Yes, a person entering an empty room with a gun on the table is absolutely statistically in danger of mishandling the gun and harming themselves. The actual meta study referenced here is behind a paywall but people do not behave well when put in a room alone with a dangerous thing. As far as I can tell no one has replicated the experiment with an actual gun, though I’d love to see that. Now I don’t want to strawman too much here but you might be tempted to say that the problem isn’t the gun but the combination of human stupidity and guns. That’s generally what makes dangerous things dangerous, and isn’t the gotcha people on the gun side often think it is. In a world with only guns and no humans there’s no gun violence, hooray.

    I’ll let you have the final word here if you wish, I’m pretty done with this discussion. I’ll just reiterate one last time that this is all you trying to convince me that I should not be feeling more safe in a place that doesn’t allow guns and I think that’s pretty fucked.