Re: Should the docs suggest namespace packages?

[Aymeric Augustin]

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 weird that the __init__.py files were removed anyway without further 
discussion (that I can find with my browser's search on that page, at least).

It's fairly minor, but I think that ccc25bf should be reverted.

Best regards,

-- 
Aymeric.



> On 20 May 2020, at 14:58, René Fleschenberg  wrote:
> 
> On Github, Tim pointed out that with
> https://github.com/django/django/commit/ccc25bfe4f0964a00df3af6f91c2d9e20159a0c2,
> various __init__.py files in Django's own code were removed.
> 
> I tend to say it would be good to revert that change. Or we could update
> the docs only, since they serve much more directly as an example for
> user code.
> 
> -- 
> René Fleschenberg
> 
> -- 
> You received this message because you are subscribed to the Google Groups 
> "Django developers  (Contributions to Django itself)" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to django-developers+unsubscr...@googlegroups.com.
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/django-developers/5d689d5c-01ab-d017-249c-a53a6d9b1f87%40fleschenberg.net.

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/C9E429E5-DC4C-4C47-8126-17B32D31D245%40polytechnique.org.

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

[Scott Cranfill]

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 there have been no opinions against it.
>
> Because of this I've reopened the older closed ticket #11157: 
> https://code.djangoproject.com/ticket/11157 . Andy/Scott, I hope you can 
> retarget your PR as per my comment there. Thanks!
>
> Admin users still get a preview of the slug and can edit it if needed.
>>
>
> Agree, no need for deprecation warnings. This behaviour is in front of 
> users with an easy override.
>
> ‪On Sat, 16 May 2020 at 03:04, ‫אורי‬‎ > 
> wrote:‬
>
>> I very much prefer a slug "to-be-or-not-to-be-that-is-the-question" 
>> than "be-or-not-be-question" (which doesn't make sense).
>> אורי
>> u...@speedy.net 
>>
>>
>> On Wed, Apr 8, 2020 at 11:35 PM Andy Chosak > > wrote:
>>
>>> Automatic slug generation in ModelAdmin via prepopulated_fields 
>>> 
>>>  
>>> uses a urlify.js 
>>> 
>>>  
>>> file which, among other behaviors, removes certain stop words 
>>> 
>>>  
>>> from the slug. For example, a string like "To be or not to be, that is the 
>>> question" will generate a slug "be-or-not-be-question", not 
>>> "to-be-or-not-to-be-that-is-the-question" as one might expect. I’d like to 
>>> solicit feedback on the idea of removing this logic so that slugs can 
>>> contain these words.
>>>
>>> For reference, the current list is: a, an, as, at, before, but, by, for, 
>>> from, is, in, into, like, of, off, on, onto, per, since, than, the, this, 
>>> that, to, up, via, with.
>>>
>>> Django ticket #30538  
>>> mentions this behavior as part of a more general comparison between 
>>> urlify.js and Python slugify 
>>> .
>>>  
>>> It was closed as wontfix due to reasons of backwards compatibility. Per the 
>>> triaging 
>>> guidelines 
>>> ,
>>>  
>>> I’m making this post to solicit feedback on the more specific question of 
>>> addressing stopword removal in the JS code only -- not to try to address 
>>> any other differences in behavior between these two methods. There’s been 
>>> quite a bit of discussion on generating slugs for non-English languages 
>>> (for example #2282 ), and 
>>> this post is not intended to reopen that discussion.
>>>
>>> The current list of stopwords being removed seems to have been the same 
>>> since 
>>> at least 2005 
>>> 
>>>  
>>> (the earliest code I can find including this logic). Some of these words 
>>> feel a little unexpected, for example “before” and “since”. After 15 years 
>>> it seems reasonable to revisit the list and consider whether it still makes 
>>> sense.
>>>
>>> Was removal of these words introduced for SEO reasons? If so, is this 
>>> still a recommended default behavior? In 2020, search engines like Google 
>>> seem smart enough to interpret them properly. Here's 
>>>  an arbitrary page that 
>>> discusses this and includes a much longer list of what might be considered 
>>> stopwords. As another datapoint, the popular WordPress Yoast SEO plugin 
>>> used to remove stopwords, but stopped doing so 
>>>  a few years back.
>>>
>>> Potentially outdated SEO concerns aside, does this behavior still align 
>>> well with the needs and desires of Django users? Is this something this 
>>> community would be open to revisiting? Thanks for your consideration.
>>>
>>> (One minor point on language support: allowing these words would help to 
>>> resolve at least some of the unequal treatment given to English over other 
>>> languages, for example #12905 
>>> . See also wagtail#4899 
>>> , from which much of 
>>> this post has been copied, for an example of how this logic impacts a 
>>> Django-based CMS.)
>>>
>>> -- 
>>> You received this message because you are subscribed to the Google 
>>> Groups "Django developers (Contributions to Django itself)" group.
>>> To unsubscribe from this group and stop receiving emails from it, send 
>>> an email to 

Re: Disabling .delete() in querysets in Django

[Javier Buzzi]

> 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()

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/f997487a-3b8b-4ae6-b099-e4a7af08e510%40googlegroups.com.

Re: Disabling .delete() in querysets in Django

[Javier Buzzi]

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 
add now() to the aforementioned field. This all seemed great on the 
surface, until we realized the app needed tests, they wrote none. Sometimes 
even in the more severe of cases, you want to do delete(), inside tests or 
otherwise. As an ongoing effort, we have created a soft_delete() and left 
delete() alone, created a Admin mixin called SoftDeleteMixin that adds an 
extra button in the details and a new action to the list view.

What you're suggesting definitely something that should be there, i really 
suggest you reconsider your approach.

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/4f4b6233-dde9-4b20-81ba-10ff377a76a9%40googlegroups.com.

Re: Disabling .delete() in querysets in Django

[Tim Graham]

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 addition of new settings.

On Wednesday, May 20, 2020 at 8:57:08 AM UTC-4, Uri wrote:
>
> Django developers,
>
> I recently disabled .delete() in querysets in all managers in my project, 
> after encountering a bug in a bulk delete queryset in my tests [
> https://code.djangoproject.com/ticket/31600]. Actually it was quite 
> simple to disable .delete() in querysets, but I had to define my 
> own QuerySet class:
>
> class QuerySet(models.query.QuerySet):
> def delete(self):
> raise NotImplementedError("delete is not implemented.")
>
>
> I also disabled bulk_create() in managers for similar reasons. And I 
> thought, maybe you can introduce optional settings in which if it's set, 
> will disable delete() and bulk_create() in managers and querysets? I think 
> this may be useful, since the delete() and bulk_create() methods have 
> problems - they don't call the model's methods and in some cases (such as 
> in my case) related objects from other models don't get deleted (with 
> delete()) and models don't get validated (with bulk_create()).
>
> I also call each model's self.full_clean() method before saving, which 
> may also be a setting in Django. I don't want invalid objects to be saved 
> to the database.
>
> If you think this is a good idea and want me to implement it, I can try to 
> submit a PR.
>
> By the way, I checked and I found out that I can still delete objects from 
> our admin interface, so it probably doesn't use the delete() queryset.
>
> Thanks,
> Uri.
>
> אורי
> u...@speedy.net 
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/943a7ea3-074c-42cb-a259-42714e32fc11%40googlegroups.com.

Re: Disabling .delete() in querysets in Django

[Tom Forbes]

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 queryset.

Tom

> On 20 May 2020, at 13:57, אורי  wrote:
> 
> 
> Django developers,
> 
> I recently disabled .delete() in querysets in all managers in my project, 
> after encountering a bug in a bulk delete queryset in my tests 
> [https://code.djangoproject.com/ticket/31600]. Actually it was quite simple 
> to disable .delete() in querysets, but I had to define my own QuerySet class:
> 
> class QuerySet(models.query.QuerySet):
> def delete(self):
> raise NotImplementedError("delete is not implemented.")
> 
> I also disabled bulk_create() in managers for similar reasons. And I thought, 
> maybe you can introduce optional settings in which if it's set, will disable 
> delete() and bulk_create() in managers and querysets? I think this may be 
> useful, since the delete() and bulk_create() methods have problems - they 
> don't call the model's methods and in some cases (such as in my case) related 
> objects from other models don't get deleted (with delete()) and models don't 
> get validated (with bulk_create()).
> 
> I also call each model's self.full_clean() method before saving, which may 
> also be a setting in Django. I don't want invalid objects to be saved to the 
> database.
> 
> If you think this is a good idea and want me to implement it, I can try to 
> submit a PR.
> 
> By the way, I checked and I found out that I can still delete objects from 
> our admin interface, so it probably doesn't use the delete() queryset.
> 
> Thanks,
> Uri.
> 
> אורי
> u...@speedy.net
> -- 
> You received this message because you are subscribed to the Google Groups 
> "Django developers (Contributions to Django itself)" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to django-developers+unsubscr...@googlegroups.com.
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/django-developers/CABD5YeGBinT0uXyCdmw6%3DARAN5URFWk-Sh%3D1wvb8Fbfuj8c_pQ%40mail.gmail.com.

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/2553E532-E331-41E8-A700-7D5AE5BB572B%40tomforb.es.

Re: QuerySet.iterator together with prefetch_related because of chunk_size

['Taylor' via Django developers (Contributions to Django itself)]

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 
> https://github.com/django/django/pull/10707/files
>
> On Monday, January 14, 2019 at 5:29:18 PM UTC-5, Adam Johnson wrote:
>>
>> I agree with your reasoning, and also favour option 2 now, especially 
>> since the default can break on sqlite.
>>
>> It would also be possible to go through a deprecation period to first 
>> raise a warning and not prefetch, before a later version raises an 
>> exception, which is probably kinder since previously it was documented that 
>> it just was a no-op.
>>
>> On Mon, 14 Jan 2019 at 19:03, charettes  wrote:
>>
>>> > This seems reasonable, but would you do in the case chunk_size isn't 
>>> explicitly defined - throw an exception?
>>>
>>> That's would be the plan.
>>>
>>> > Currently it silently fails to prefetch which means N + 1 queries, so 
>>> even prefetching for the default chunk_size of 2000 would be a huge gain in 
>>> cases where chunk_size isn't defined.
>>>
>>> That's assuming related relationships are actually accessed during 
>>> iteration over the objects. If it's not currently the case turning that on 
>>> would cause P + C extra queries.
>>>
>>> To summarize here's the options we have:
>>>
>>> 1. Always turn on the prefetching feature.
>>> 2. Require chunk_size to be explicitly specified for a deprecation 
>>> period in order to enable the feature.
>>>
>>> Pros/Cons of 1. is that developers who actually didn't follow the 
>>> documentation and/or didn't assert that prefetching didn't work and left 
>>> some lingering prefetch_related() will probably see their code perform less 
>>> queries but result in a slight increase in memory (given they discard 
>>> objects on iterating). This is also likely to break code because of some 
>>> backends (e.g. SQLite) query parameters limits (chunk_size=2000 > 1000)[0]
>>>
>>> Pros/Cons of 2. is that most prefetch_related().iterator() won't break 
>>> for developers that followed the documentation and fail for others 
>>> requiring them to acknowledge what their code is going to start doing.
>>>
>>> As I've expressed in my previous messages I'm slightly in favor of 2 
>>> even if it is likely to cause more breakage because of the exceptional 
>>> situation where this API should have raised an exception from the beginning.
>>>
>>> Cheers,
>>> Simon
>>>
>>> [0] https://code.djangoproject.com/ticket/27833
>>>
>>> Le lundi 14 janvier 2019 09:53:45 UTC-5, Adam Johnson a écrit :

 ...what if we required chunk_size to be explicitly specified when the 
> queryset has prefetch lookups?


 This seems reasonable, but would you do in the case chunk_size isn't 
 explicitly defined - throw an exception? Currently it silently fails to 
 prefetch which means N + 1 queries, so even prefetching for the default 
 chunk_size of 2000 would be a huge gain in cases where chunk_size isn't 
 defined.

 On Sun, 13 Jan 2019 at 02:05, charettes  wrote:

> Replying to my concerns about the P * C queries.
>
> Throwing that idea out there but what if we required chunk_size to be 
> explicitly specified when the queryset has prefetch lookups?
>
> That would at least force the developers to consider how many 
> prefetching queries iterating through the results would require. Plus 
> since 
> the argument was only recently introduced it is less likely to silently 
> cause changes under developers feet.
>
> Simon
>
> Le vendredi 26 octobre 2018 20:12:02 UTC-4, charettes a écrit :
>>
>> Josh, I agree that silently not working is problematic but it has 
>> been this way since prefetch_related() was introduced.
>>
>> Something to keep in mind as well is that silently turning it on 
>> would also perform P * C extra queries where P is the number of 
>> prefetches 
>> requested through prefetch_related() and C the number of chunks the 
>> results 
>> contains. This is non negligible IMO.
>>
>> What I'd be in favor off is raising an exception on 
>> prefetch_related(*prefetches).iterator() in the next release at least to 
>> allow users using this pattern to adjust their code and then ship the 
>> optimization with all the warnings related to the interactions between 
>> prefetch_related(*prefetches) and iterator(chunk_size) in the next one.
>>
>> I'm not completely completely against skipping the exception release 
>> phase entirely given there might be users out there accessing attributes 
>> expected to be prefetched on iterated instances and inadvertently 
>> performing tons of queries but the exception phase just feels safer 
>> given 
>> iterator() is usually used in memory constrained contexts.
>>

Re: QuerySet.iterator together with prefetch_related because of chunk_size

[charettes]

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 of it?

Simon

Le mercredi 20 mai 2020 19:25:21 UTC-4, Taylor a écrit :
>
> 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 
>> https://github.com/django/django/pull/10707/files
>>
>> On Monday, January 14, 2019 at 5:29:18 PM UTC-5, Adam Johnson wrote:
>>>
>>> I agree with your reasoning, and also favour option 2 now, especially 
>>> since the default can break on sqlite.
>>>
>>> It would also be possible to go through a deprecation period to first 
>>> raise a warning and not prefetch, before a later version raises an 
>>> exception, which is probably kinder since previously it was documented that 
>>> it just was a no-op.
>>>
>>> On Mon, 14 Jan 2019 at 19:03, charettes  wrote:
>>>
 > This seems reasonable, but would you do in the case chunk_size isn't 
 explicitly defined - throw an exception?

 That's would be the plan.

 > Currently it silently fails to prefetch which means N + 1 queries, so 
 even prefetching for the default chunk_size of 2000 would be a huge gain 
 in 
 cases where chunk_size isn't defined.

 That's assuming related relationships are actually accessed during 
 iteration over the objects. If it's not currently the case turning that on 
 would cause P + C extra queries.

 To summarize here's the options we have:

 1. Always turn on the prefetching feature.
 2. Require chunk_size to be explicitly specified for a deprecation 
 period in order to enable the feature.

 Pros/Cons of 1. is that developers who actually didn't follow the 
 documentation and/or didn't assert that prefetching didn't work and left 
 some lingering prefetch_related() will probably see their code perform 
 less 
 queries but result in a slight increase in memory (given they discard 
 objects on iterating). This is also likely to break code because of some 
 backends (e.g. SQLite) query parameters limits (chunk_size=2000 > 1000)[0]

 Pros/Cons of 2. is that most prefetch_related().iterator() won't break 
 for developers that followed the documentation and fail for others 
 requiring them to acknowledge what their code is going to start doing.

 As I've expressed in my previous messages I'm slightly in favor of 2 
 even if it is likely to cause more breakage because of the exceptional 
 situation where this API should have raised an exception from the 
 beginning.

 Cheers,
 Simon

 [0] https://code.djangoproject.com/ticket/27833

 Le lundi 14 janvier 2019 09:53:45 UTC-5, Adam Johnson a écrit :
>
> ...what if we required chunk_size to be explicitly specified when the 
>> queryset has prefetch lookups?
>
>
> This seems reasonable, but would you do in the case chunk_size isn't 
> explicitly defined - throw an exception? Currently it silently fails to 
> prefetch which means N + 1 queries, so even prefetching for the default 
> chunk_size of 2000 would be a huge gain in cases where chunk_size isn't 
> defined.
>
> On Sun, 13 Jan 2019 at 02:05, charettes  wrote:
>
>> Replying to my concerns about the P * C queries.
>>
>> Throwing that idea out there but what if we required chunk_size to be 
>> explicitly specified when the queryset has prefetch lookups?
>>
>> That would at least force the developers to consider how many 
>> prefetching queries iterating through the results would require. Plus 
>> since 
>> the argument was only recently introduced it is less likely to silently 
>> cause changes under developers feet.
>>
>> Simon
>>
>> Le vendredi 26 octobre 2018 20:12:02 UTC-4, charettes a écrit :
>>>
>>> Josh, I agree that silently not working is problematic but it has 
>>> been this way since prefetch_related() was introduced.
>>>
>>> Something to keep in mind as well is that silently turning it on 
>>> would also perform P * C extra queries where P is the number of 
>>> prefetches 
>>> requested through prefetch_related() and C the number of chunks the 
>>> results 
>>> contains. This is non negligible IMO.
>>>
>>> What I'd be in favor off is raising an exception on 
>>> prefetch_related(*prefetches).iterator() in the next release at least 
>>> to 
>>> allow users using this pattern to adjust their code and then ship the 
>>> optimization with all the warnings related to the 

Should the docs suggest namespace packages?

[René Fleschenberg]

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 the Google Groups 
"Django developers  (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/a604b2d5-23a5-67da-b8c4-f50e1d434fb7%40fleschenberg.net.

Re: Should the docs suggest namespace packages?

[Carlton Gibson]

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 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 the Google Groups 
> "Django developers  (Contributions to Django itself)" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to django-developers+unsubscr...@googlegroups.com.
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/django-developers/a604b2d5-23a5-67da-b8c4-f50e1d434fb7%40fleschenberg.net.

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/9EF143F1-BB9A-4A3E-B8FF-F4B893A56635%40gmail.com.

Re: Should the docs suggest namespace packages?

[James Bennett]

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 adding/removing their locations
in the import path.

Way way back in the day template tag libraries used to do a hack that
simulated this, where Django would see a "templatetags" directory in
your app and magically make it be importable from under
"django.templatetags" instead. That was one of the last pieces of the
original "magic" to be removed.

There's no reason to create implicit namespace packages for management
commands unless we want to move back to that sort of magical "lives
over *there* but imports as if it's actually over *here*" behavior,
and I'm pretty sure we don't want to do that.

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CAL13Cg_4Ea0%3DAe2zzgHw63JAGDRXH3T40UQ27Nd2OQHy5HhQQg%40mail.gmail.com.