Learning freshman geology, so I can research a pun for a package name.
In other news, do sign up to my webinar on Schedule Orientated Practices!
Learning freshman geology, so I can research a pun for a package name.
In other news, do sign up to my webinar on Schedule Orientated Practices!
@simon @jacob I guess I'm a curious outlier, in that I find that bit already solved, but I'm still using virtualenvwrapper, and never stopped
I'm interested to see how all this plays out. I very much would like the core tools, pip in particular, to pick up the wins that are available.
Current status: more or less.
This is a lovely conversation, with some interesting thoughts on the recent progress of uv.
For all the concerns raised, I’d be happy if I could see a plan to merge the available performance wins (non just “it’s Rust” ones) back upstream into pip.
Bring on the money, but plan for when it goes away, is more or less my take. We still need native community owned tooling on that day.
From: @jacob
https://social.jacobian.org/@jacob@jacobian.org@[email protected]/113091418140504394
@mahryekuh I like to bookmark everything and then binge read just as a feature approaches Actually Available Most Places. It’s like saving up a series on the tele
@anze3db @hruske Good! I wanted to query you on that: You don't use the cached loader in development?
After parsing, a template is just a node list, stored in-memory, so the loader literally just does a lookup for it, so include shouldn't be slow, not really. (Like nano-whatsits for a couple of stack frames is about all)
Most of the performance difference there is in the parsing phase, which is moot since the cached template loader is used in recent versions.
The DTL may be marginally slower to render, but not such that you'd expect template rendering to dominate. There must be some particular reason this is taking an age.
Aside: over the years I've done web apps is Every Language With Every Framework. Template rendering is ALWAYS 2nd slowest. There's more to tell here. Seguro.
@anze3db that last point can be telling. Maybe the RPi is just doing something else when that request comes in…
@anze3db ah… yes… the limits of an RPi become clear.
@anze3db interesting. It would be fun to dig into what’s taking the time there. Template rendering is ALWAYS the second slowest bit… 🧐
@anze3db you sure it’s the template rendering, and not cheeky DB queries that you’ve got going on during that?
@jake @simon @webology @wsvincent @ghickman The way forward is to make the WSGI/ASGI distinction transparent. WSGI is still the way to go for most of your application. (Just is). But that “need some ASGI” bit shouldn’t require a whole stack change. Users shouldn’t really have to think about this.
@jake @webology @wsvincent @[email protected]@[email protected] @ghickman @simon no, probably not
The existing one is the stdlib’s wsgsiref, so not really homebrew either.
@jake @webology @wsvincent @[email protected] @ghickman What would I say there? I’d say, I’d don’t know a single Python project that you wouldn’t (e.g.) put Nginx in front of, but there are plenty I think that Django could wrap with it’s own sauce that would leave us in a net positive.
(Reply with @simon crossed but that too!)
This prompted by @simon’s very old post.
I’ve read this post before but, I didn’t know/recall that he’d called his talk “Django Heresies”, which is a topic close to my mind since my #Diango #retirement
djng is nearly two weeks old now, so it’s about time I wrote a bit about the project. I presented a keynote at EuroDjangoCon in Prague earlier this month entitled …
(simonwillison.net)
//cc @ghickman
Hot take: the cutting edge is stuff we left on the floor in 2009.