42 ms·
What might, possibly, redeem Python in my eyes as a potential language for making production applications (something that today, it is most certainly not) would
by davedx 1y ago
What might, possibly, redeem Python in my eyes as a potential language for making production applications (something that today, it is most certainly not) would be if the type checker worked across the broader ecosystem of common Python packages.
For example, as my recent struggles showed, SQLAlchemy breaks `pyright` in all kinds of ways. Compared with how other 'dynamic' ORMs like Prisma interact with types, it's just a disaster and makes type checking applications that use it almost pointless.
How does Ty play with SQLAlchemy?
- jakewins 1y agoMy experience is this is nearly impossible, the solution is new packages written after typing was introduced. I don’t know about SQLAlchemy, but for libraries like pandas I just don’t see how it can be done, and so people are actively replacing them with modern typed alternatives
- davedx 1y agoHa. I just finished a huge rewrite at work from sync SQLAlchemy to async SQLAlchemy, because the async version uses a totally different API (core queries) to sync. So this implies if I want type checking I need to use a different ORM and start again? I love how Python makes me so much faster due to its dynamic nature! Move fast, break things!
- mapcars 1y agoI don't agree that dynamic nature makes things necessarily faster, if you compare Python to C or Java it is true, but if you compare to Typescript it is not. With a decent typing system and a good editor that makes use of it (and AI-assistants nowadays) the prototyping can actually be both faster and more stable.
- wpeterw 1y agoYou mean Python is not a language for production applications ?
- pjmlp 1y agoOnly when performance doesn't matter, then it becomes a DSL for C and C++ libraries.
- ukblewis 1y agoHave you tried SQLModel?
- triyambakam 1y agoI've tried using it but it's still so immature and poorly documented. I wish it were different because I love the idea of it.
- pjmlp 1y agoFor me, until it gets a production quality JIT, or PyPy and GraalPY get more community love, it remains a scripting language for learning on how to program, automating OS and applications tasks.
- Spivak 1y agoInstagram I think would like a word with you on its viability for production.
- pjmlp 1y agoMaybe you should first investigate all the gimmicks they had to do, between amount of servers they had to ramp up burning needless budget, rewriting code into C and C++ libraries, Go or whatever else they ended up adding, before doing such statements. https://stackshare.io/instagram/instagram https://stackshare.io/instagram/instagram
- Nab443 1y agoAny other link to share about that? The stackshare url does not even mention anything related.
- reubenmorais 1y agoThis is a weakness of the Python typing system and not necessarily of individual typecheckers. Pyright has a policy of only implementing what's standardized, and the Python type system is simply inadequate to annotate most real world Python code out there. It's been years now and something as basic as properly typing kwargs is still not supported. Ty could solve this if they rebel and decide to ignore the Python typing standards, which I honestly would appreciate, but if they take the sensible approach and follow the standards, it won't change anything.
- Spivak 1y ago> properly typing kwargs is still not supported. I've been typing them with TypedDict for a while now and it's been fine. What can't you do?
- reubenmorais 1y agoTwo examples that come to mind are: https://discuss.python.org/t/pep-692-using-typeddict-for-more-precise-kwargs-typing/17314 https://discuss.python.org/t/pep-692-using-typeddict-for-mor... and: https://github.com/python/typing/issues/1252 https://github.com/python/typing/issues/1252
- 9dev 1y agoPython code feels like back in the day when JavaScript was typed using JSDoc comments, and libraries would use all kinds of fantastical object shapes for their option parameters, so users could pass "just about anything" and it would work. You would never know how to configure an Express app without digging through the documentation, for example. I loathe the Python convention of just using kwargs instead of clearly annotated parameters; most libraries don't even have doc comments in the code, so you're really required to look up the documentation, hope that it actually describes the method you're interested in and contains more than stuff like "foo: the foo to use"—or fall back to rummaging in the library intestines to figure out how it works. It's pathetic.
- oxcabe 1y ago
- bootsmann 1y agoOnly tangentially related but does anyone else here get very bothered when looking at the SQLAlchemy documentation? It seems so hard to find what kind of magic incantation you need to do in which order when trying to do a somewhat non-trivial query and I often just write the SQL I want and then tell chatGPT to rewrite it to SQLAlchemy operations but thats not really a sustainable solution.
- globular-toast 1y agoHave you sat down and read the SQLAlchemy docs properly? It made a lot more sense to me once I'd set aside an hour or two to work through the Unified Tutorial.[0] I feel like these days people just want quick answers to do very specific things but that's a very inefficient way to learn something like SQLAlchemy. If you know the SQL you want it's just a matter of writing it in SQLAlchemy's query language which is quite close to SQL. Should just be a matter of practice to become fluent in it. "Complex queries" usually turn up when you're doing something like rendering a table or report or something. You don't need the ORM for this kind of thing, just write a query. An ORM is useful when you want to write domain logic to do read/write operations against domain entities and persist them back to a database. IMO people get hung up on ORMs and think if they're using one then they have to use it for everything then do the most horrible contortions that should have just been db queries. SQLAlchemy allows you to use the ORM judiciously. [0] https://docs.sqlalchemy.org/en/20/tutorial/index.html https://docs.sqlalchemy.org/en/20/tutorial/index.html
- 9dev 1y ago> I feel like these days people just want quick answers to do very specific things but that's a very inefficient way to learn something like SQLAlchemy. Good documentation should absolutely provide a usable reference to quickly look up common ways to solve common problems. Even the PHP docs got that right twenty years ago. Also, I disagree: A library should be as self-evident and incrementally understandable as possible, not require reading a full tome and grow a grey beard before being accessible. > "Complex queries" usually turn up when you're doing something like rendering a table or report or something. You don't need the ORM for this kind of thing, just write a query. Or, when building generic filtering/sorting/pagination logic for a bog-standard CRUD app. Or to do full-text search. Or when doing lateral joins to minimize queries. Or to iterate over a huge table. There's lots of cases where I want the ergonomics and malleability of ORM query instances even when working with complex queries.
- melodyogonna 1y agoWhat version of SQLAlchemy? SQLAlchemy v2 is built with with type-hinting support, I didn't have any issues with it when I used it few months ago