Re: Should the docs suggest namespace packages?

Hello, Commit ccc25bf refers to ticket #23919 in the commit message. In that ticket, I argued that the __init__.py files should be kept: https://code.djangoproject.com/ticket/23919#comment:102 . No one brought a counter argument. It's

Re: Proposal: Allow stopwords in slugs generated by ModelAdmin.prepopulated_fields

Thanks for the additional feedback, folks! We have opened a fresh PR, rebased on the latest master and referencing #11157, at https://github.com/django/django/pull/12945 Best, Scott On Saturday, May 16, 2020 at 5:25:29 AM UTC-4, Adam Johnson wrote: > > There's a bit more support now, and

Re: Disabling .delete() in querysets in Django

> I can still delete objects from our admin interface, so it probably doesn't use the delete() queryset. I think you should look at https://github.com/django/django/blob/master/django/contrib/admin/options.py#L1095-L1103 Individual objects are deleted individually, using the object.delete() --

Re: Disabling .delete() in querysets in Django

More to Tom's point, I'm currently working on an old app that the original intent was to never delete anything, ever. The original programmers did something similar to what you did with the exception that they added a "deleted_ts" field to every model, the model/queryset delete() would just

Re: Disabling .delete() in querysets in Django

Hi Uri, I think you've mostly come across documented behaviors rather than "problems". You haven't provided enough details in the bug report to say for sure on that issue. I don't think the things you've implemented are generally applicable to many Django projects such that they warrant the

Re: Disabling .delete() in querysets in Django

I don’t think a Django-wide setting to disable Queryset.delete() is appropriate. As you said, it’s easy enough to configure for the specific models that may (or may not!) benefit from this. A Django-wide setting like this would also break just about everything that calls “delete()” on a

Re: QuerySet.iterator together with prefetch_related because of chunk_size

Checking in here. What are the next steps to make a decision? On Wednesday, February 13, 2019 at 2:06:29 PM UTC-5, Taylor wrote: > > I agree that 2 makes sense and isn't a huge usability issue. It looks like > the PR is ready to go whenever this is decided >

Re: QuerySet.iterator together with prefetch_related because of chunk_size

Taylor, I think that 2. is the way forward. It looks like the linked PR doesn't ensure a chunk_size is specified to turn on the feature though. I like Adam's idea to first warn and don't do a prefetch if chunk_size is not specified and eventually turn that into an exception. What do you think

Should the docs suggest namespace packages?

Hi, https://github.com/django/django/pull/12939 My opinion on this is not particularly strong, but it seems odd to me that we tell users to create namespace packages, without any explanation. What do you think? -- René Fleschenberg -- You received this message because you are subscribed to

Re: Should the docs suggest namespace packages?

As far as I can see, standard packages are what users want in almost every case. So +1. (Q:What is the use-case for namespace packages?) > On 20 May 2020, at 12:44, René Fleschenberg wrote: > > Hi, > > https://github.com/django/django/pull/12939 > > My opinion on this is not particularly

Re: Should the docs suggest namespace packages?

The use case for namespace packages is the ability to fragment portions of a single package across multiple disparate locations on the filesystem. And, potentially, to install or selectively enable/disable access to only certain sub-portions of the package by choosing which parts are present or by