Back

Related bite-size take on the core issue here...

https://fosstodon.org/@carlton/113470040765876827

@CodenameTim @ehmatthes Thanks Tim. Yes. I’ve raised more questions at the end than I have answers for there, but I do think the general strategy is right. Let’s lean into to what we already do well. (And that thought that you can solve social problems with technical solutions keeps coming back to me unbidden.)

@carlton To give an example, when I was still teaching, my students (17–21) had to experiment with several front-end frameworks.

To my surprise—as they would often skip the docs and go straight for ChatGPT—I often heard the argument that they liked Tailwind over Bootstrap because the former has “better” documentation.

As the old UX wisdom goes, “If the user can’t find it, it doesn’t exist.” Django has one of the few documentations I navigate via search engine, so there’s a point.

@mahryekuh thanks Marijke l, yes, I think I agree. Mentally we could ask what we’d do if technically Django were frozen? How would we advance it then?

Obvs we’ll keep advancing, but I think the answer to that is where the low hanging fruit really is. (Sometimes the **if only we had X new feature** is catnip)

@carlton I doubt Django would be frozen feature-wise, since the majority of contributions center around code.

Not everyone thinks about pure documentation changes as a form of contribution, and it almost feels like the translation team lives in obscurity (as in, they’re not mentioned enough in the process).

I think Django would be OK if temporarily feature frozen because there is already a lot and in packages. However…

@mahryekuh Sure! I meant as a **mental exercise** only. If I **imagine** that I can't change the code, what then?

@carlton Thanks! I wonder how long before we have to get Daniele on board of this conversation. Although he Djangonaut Space session is already enlightening, and I should probably watch it again.

@mahryekuh I don’t think I’m saying anything in that direction

@carlton I went on a little side quest there.

I’ve gotten a few Django apps into and out of core, but it took a lot of effort and probably more privilege than reasonable. Maybe with more people working on Django as their day job, without strings attached, maybe we’d have more time to work on stewarding a framework like Django? I’m worried we’ll always err on the side of caution and scarcity otherwise, given the scale of use. (2/3)

I don’t believe that “stdlib is where packages go to die” is the right metaphor BTW, it’s a pretty bleak worldview IMO. Working on built-in features just necessarily has a higher bar for stability and restraint (!=features) than 3rd party packages that can be easily installed with our favorite package managers, whenever needed. (3/3)

@jezdez Thanks Janis — Yes, it feels like something we should have Solved by now I'd love your insights!

I think you're right on the stability point (vs flexibility maybe?)

I guess I'd put the graveyard point down to hyperbole… — I absolutely miss more batteries (but understand how the tide flows)

@sethmlarson @jezdez re: "stdlib is where packages go to die" I have never been a fan of it either.

If we had a week of funding for every time I have heard a CPython core mention it, we'd each have a few years of runway.

I think it's mostly projecting how they view it vs. how it should be.

@webology @sethmlarson @jezdez Uhm, no. It's projecting how Hyrum's Law and Python's backward compatibility guarantees interact. We've seen it numerous times in bug reports: any substantial change to _any_ aspect of _any_ stdlib module ends up unacceptably affecting users. The risk of substantial changes becomes too high, and there is no way to sensibly evolve anything, because there's no way to have experimental features. They are evolutionary dead.

@Yhg1s @sethmlarson @jezdez You missed the point

@webology @sethmlarson @jezdez Maybe I have. My point is that Core Devs saying "the stdlib is where packages go to die" has nothing to do with funding or support or the will to change things, nor about "just a higher bar".

@Yhg1s @webology @sethmlarson @jezdez Yea, I agree with this take. Once software has a large number of users, it basically makes it impossible to change. Bringing something into core dramatically expands the number of users, which then makes it impossible to change.

@nanorepublica Thanks Andy, yes. I've been following your posts, and they've stimulated a lot of thoughts.

There's room in core for the right things, but (I agree) if we can solve the social problem the plugin approach gives more flexibility and power.

@carlton @nanorepublica I wonder if more features could have the kind of "VIP" status that Django-Tasks has: something that is created in a context where it will _likely_ make its way in core at some point, and is created with that in mind.
A feature that is first managed as an external package only while its implementation is fine-tuned and feedback is gathered from the community... But is designed to be (hopefully) merged into Django.

Could there be a specific named process for such things?

@dunsap @nanorepublica You’ve described the DEP process.

@carlton @nanorepublica Ah, true! I forgot that Django-Tasks was built with a DEP attached.
Thanks for your reply

@hvdklauw The tasks interface is pretty simple. Clients can use it independently of the backend. Hopefully there will be various implementations. I've be using Django-Q forever, having a django.tasks backend for that will allow me to migrate to the new API in my own time. I think that's pretty cool.

@EmmaDelescolle Thanks Emma. Your thoughts are some of those that have informed my own thinking. I look forward to reading your further ones when you’ve simmered on them.

@d ah, passkeys. Not sure about that one. I KEEP reading that the implementation has betrayed the promise, so I’m postponing judgment there.

I’m pretty sure we should be able to do (say) a TOTP solution (with maybe an interface contract in the Django way) or something in core ourselves. (Have notes for a proposal here that might see daylight next year.)

@carlton I get the hesitation. But the JavaScript interface is also the way to support FIDO keys so would be useful either way. Either way, the contract system would be the way to go.

@d Sure! Current status: IDK

But this might be the perfect case-study... — there are several good community solutions here.

Q: Are we able to point to them in such a way that isn't susceptible to the upkeep, rot, and politics issues, but still feels *recommended* enough to be *batteries included*?

I'm not sure what the answer is, but that feels to me to be the circle to be squared. (As it is for MFA so it is for many other features.)

As I say: Current status: IDK

@frank Thanks Frank. I think steering input (at least) is always helpful! You’re in