chrstphrhrt

If you want to integrate with the data science ecosystem, would you use modern Python for APIs as well, or do Go services with minimal Python bits?

EDIT: coming from someone who has had great experiences with FastAPI and Uvicorn combined with Dask and Redis.

Do you track down their email or just send a message on LinkedIn? How customized are the initial communications (e.g. common elements per type of work or type of company)?

Yeah, we've graduated to using militarized police to do that for a while now.

I'm working on a project that depends on Graphene and Django (not my choice). Any ideas off hand about doing the same thing there? IIRC Django can also use SQLAlchemy but it didn't used to be very nice back in the day.

Too bad it got hobbled on the last Mac update. With Metal I find it completely unplayable and it doesn't do fullscreen.

Agree 110%, and I want to take your notion as a cue to expound a little more from personal trauma :)

I find OOP useful for configuration and library-level APIs (e.g. for injecting dependencies and wrapping things), when there is really zero expectation that a user should have to understand the class definition entirely. But that's about it.

Where it seems to break down for me is when classes are actively used at the application implementation level for general encapsulation. E.g. data access layers. This can be done perfectly fine with modules/packages. Adding inheritance is just asking for trouble in a team setting IMHO.

Trouble comes when there is no clear peer review and style policy to avoid classes for anything other than config or distributing libraries (as separate projects). What ends up happening is a proliferation of subclasses or method overrides when developers are in a rush to ship features without understanding the whole codebase. This is a technical loan with very high interest.

It makes sense rationally in the moment, as classes have an inviting feel to the user as a kind of grab bag of related functionalities that are easily introspected (at first). Compare it to searching through docs for all the different namespaces in a package and learning what types their various functions support, it requires more thought and grasping the concepts of the library. Alternatively, a class with a broadly defined purpose starts to look like a common utility to throw things at. It's a grab bag of stuff that is more amenable to hacking with blinders on, in a way.

Next thing you know the chains of inheritance and method overrides have grown into a very hard to disentangle hydra. The accumulated overhead of maintaining it is compounded by the debugging challenge of knowing where exactly a given instance is coming from and which layers it has been through on its way to a given breakpoint.

Can't wait to see what a judge thinks about this.

Same thing happens on HN. Comments that go against the kooolaid-driven white saviour ethos of certain VC-backed ideas are often downvoted. Still not as bad as popular Reddit subs though.

There is so much dystopian doublespeak in startup marketing, and people continue to believe it, because not doing so threatens their careers. Of course there are also many startups out there that actually do improve lives, but I wouldn't say it's the majority.

Aaand I finally read the article and PEP and there's no escape from the GIL :( Damn wishful thinking.

True true, my comment was not clear. With asyncio it's still a single threaded event loop (that can be clustered like Node or any Python processes as has always been done).

With sub-interpreters, I wonder how different it is from normal multithreading like in JVM. Need to read up on this idea. I can't see how it wouldn't require the same locking and mutexes or message passing if multiple interpreters are to work on logically related data.

So my immediate thoughts were about leveraging it as a replacement for multithreading and event loop clustering by treating the interpreters as lightweight processes and having them communicate over some kind of protocol. Like how the BEAM does built-in process supervision.

The "supervisor" process itself is async in the way it coordinates the tree.

This makes sense. Combine it with asyncio and you have a full Node-like runtime without relying on Uvicorn and the like (even though clustering is still good for scaling).

If it's your primary residence that you live in for e.g. 80% of the year and you swap with other primary residences or actually stay in normal hotels when travelling, I can't see any distortion there.

Not trying to apologize for hosts or hotels in particular, I just feel like primary residence swapping is pretty harmless. Also, if hotel licenses are required, how is adding more hotels distorting the hotel market other than adding a tiny amount of fair and regulated competition?

Nice downvotes, found the sycophant Airbnb managers who just fired everyone :)