Re: Should the docs suggest namespace packages?

[Adam Johnson]

+1 for reverting ccc25bf .

On Wed, 20 May 2020 at 19:54, Aymeric Augustin <
aymeric.augus...@polytechnique.org> wrote:

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


-- 
Adam

-- 
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/CAMyDDM2%3Dr4eANtv48ibUWn95U0qsRqobtaZoWR5VYAbnyyZ%2B0A%40mail.gmail.com.

Re: Admin accessibility

[Adam Johnson]

Hi Tom

It's a laudable goal to make the admin accessible. Thank you for doing the
research on currently laws and guidelines.

I haven't audited the entire admin, but I have run a checker through some
> pages.
>

Which checker did you use? I see Google's Lighthouse checks for many
accessibility issues: https://web.dev/lighthouse-accessibility/

I think fixing any "low hanging fruit" would be acceptable PR's right now.

Setting a target and keeping to it would be harder though. Documentation is
easy to write, but it can easily be forgotten/ignored, so I'd prefer a CI
solution. One potential CI solution is running admin tests through the
Lighthouse CLI.

There will certainly add an ongoing maintenance cost. Would you be able to
work on this on an ongoing basis? If you know others who are interested,
perhaps we could even form a Django a11y team, just like we have an i18n
team.

On Tue, 19 May 2020 at 12:11, Tom Carrick  wrote:

> Sorry, long post incoming.
>
> The admin currently has some accessibility issues. Not a huge amount,
> actually, but they should be fixed regardless. I hope I don't need to
> convince anyone here of the importance of accessibility, but I'll try to
> make the case as briefly as possible for the benefit of the wider community.
>
> There is a trend towards stronger accessibility laws - there is a good
> roundup of them here: https://www.w3.org/WAI/policies/ - and I'll come
> back to this later. Most of these cover the public sector and small
> segments of the private sector, but there's also an overview of some laws
> used against private entities more generally here:
> https://en.wikipedia.org/wiki/Web_Content_Accessibility_Guidelines#Legal_obligations
>
> I should make it clear that I'm not a lawyer and have no idea if any of
> this would apply to the admin, since it's not intended for general
> consumption, so I think I'd rather make this point: Developers and other
> people using the admin - "staff users" of some kind - can have disabilities
> too, and we should be catering for them, especially since the remedies are
> not at all difficult. It's also worth pointing out that accessibility
> improvements almost always improve the general experience. For example,
> making sure everything is easily accessible for keyboard only users is also
> beneficial to power users. Better contrast and larger fonts are more
> legible for everyone, not just for those with low vision, etc.
>
> So I think the place to start here is to decide on a guideline to aim for,
> and I'm pretty convinced at this point that WCAG 2.1 at Level AA is the way
> to go: https://www.w3.org/TR/WCAG21/
>
> Why not AAA? Well, it's really hard / time-consuming. For example, users
> have to be able to select their own foreground / background colours, if a
> user's session expires, they need to be able to login in again and pick off
> where they left off (forms filled, etc.), and more. Moreover, every law
> I've looked at seems to use WCAG 2.0 (2.1 is just a couple years old and is
> backwards compatible) at Level AA, so this seems like the target to aim
> for. I don't see a reason to not make specific improvements to AAA where
> they're relatively simple, however, but my point is that we should make AA
> a minimum requirement.
>
> So if that is accepted, we need a few things:
>
> 1. Document it and update the contributing docs.
> 2. Audit the admin properly.
> 3. Fix any issues.
> 4. Make sure reviewers have this in mind for admin changes (I'm not sure
> if there's any CI solution for this, but it would be nice to have).
>
> I haven't audited the entire admin, but I have run a checker through some
> pages. The main issues are with contrast and small font sizes, and the
> changelist also seems quite painful. For example, there are no labels on
> the checkboxes to select rows, which is going to be pretty hard to
> understand and use if you're blind. A quick aria-label can fix this without
> affecting it for sighted users.
>
> Another issue here is harder to solve, it requires two tabs to move to
> another row of the change list in the default state (one for the checkbox,
> one for the link to the change form page). If you have editable fields in
> the change list, it's another tab for each. It would be nice to be able to
> use vim keys to move up and down rows, perhaps be able to hit * to select a
> row for an action. In general, keyboard shortcuts would be handy elsewhere
> too. It would be nice to be able to hit a key to open the nav sidebar which
> also sets tab focus on the first link, for example.
>
> But these details aren't the point of the post. The point of the post is
> to decide if this is worth it (clearly I think it is), and how to move
> forwards on it. Any thoughts?
>
> --
> 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+

Re: Admin accessibility

[Tom Carrick]

Hi Adam,

> Which checker did you use?

I had a brief check with a few. Firefox's devtools, Lighthouse, and
WebAIM's WAVE browser extension. WAVE is quite nice in that it shows the
problems directly on the page, but they all give more or less the same
information. If Lighthouse can be integrated into the CI it seems the most
logical option. Lighthouse also gives a 0 - 100 score metric for each page,
which would be nice as part of a coverage-style CI process, i.e. the score
can remain the same or increase, but a decrease will fail the test.

> Would you be able to work on this on an ongoing basis? If you know others
who are interested, perhaps we could even form a Django a11y team, just
like we have an i18n team.

I'm happy to work on this on an ongoing basis. Thinking over the idea of an
a11y team, at first I thought it would have too narrow a scrope as it only
really concerns the admin, but I realised it also concerns the docs, the
djangoproject website, and other sites under the django org (django-people
and so on), so perhaps it's worth doing. That said, I don't have any
physical disabilities to speak of. My eyes are pretty bad, small text can
be a problem, but that's about it. It would be good to get some feedback
from people that this directly affects, but I don't know of many. It'd also
be hugely beneficial of course if any a11y team includes people with
physical disabilities or at least experience with it. I can only
immediately think of one person in the Django community that might fit, so
I will reach out to them and ask if they'd be interested in giving any
input here, but more voices would be useful.

For the low-hanging fruit, I will run Lighthouse on some more pages and
write some tickets up when I get some time, hopefully over the weekend.

Cheers,
Tom

On Thu, 21 May 2020 at 14:04, Adam Johnson  wrote:

> Hi Tom
>
> It's a laudable goal to make the admin accessible. Thank you for doing the
> research on currently laws and guidelines.
>
> I haven't audited the entire admin, but I have run a checker through some
>> pages.
>>
>
> Which checker did you use? I see Google's Lighthouse checks for many
> accessibility issues: https://web.dev/lighthouse-accessibility/
>
> I think fixing any "low hanging fruit" would be acceptable PR's right now.
>
> Setting a target and keeping to it would be harder though. Documentation
> is easy to write, but it can easily be forgotten/ignored, so I'd prefer a
> CI solution. One potential CI solution is running admin tests through the
> Lighthouse CLI.
>
> There will certainly add an ongoing maintenance cost. Would you be able to
> work on this on an ongoing basis? If you know others who are interested,
> perhaps we could even form a Django a11y team, just like we have an i18n
> team.
>
> On Tue, 19 May 2020 at 12:11, Tom Carrick  wrote:
>
>> Sorry, long post incoming.
>>
>> The admin currently has some accessibility issues. Not a huge amount,
>> actually, but they should be fixed regardless. I hope I don't need to
>> convince anyone here of the importance of accessibility, but I'll try to
>> make the case as briefly as possible for the benefit of the wider community.
>>
>> There is a trend towards stronger accessibility laws - there is a good
>> roundup of them here: https://www.w3.org/WAI/policies/ - and I'll come
>> back to this later. Most of these cover the public sector and small
>> segments of the private sector, but there's also an overview of some laws
>> used against private entities more generally here:
>> https://en.wikipedia.org/wiki/Web_Content_Accessibility_Guidelines#Legal_obligations
>>
>> I should make it clear that I'm not a lawyer and have no idea if any of
>> this would apply to the admin, since it's not intended for general
>> consumption, so I think I'd rather make this point: Developers and other
>> people using the admin - "staff users" of some kind - can have disabilities
>> too, and we should be catering for them, especially since the remedies are
>> not at all difficult. It's also worth pointing out that accessibility
>> improvements almost always improve the general experience. For example,
>> making sure everything is easily accessible for keyboard only users is also
>> beneficial to power users. Better contrast and larger fonts are more
>> legible for everyone, not just for those with low vision, etc.
>>
>> So I think the place to start here is to decide on a guideline to aim
>> for, and I'm pretty convinced at this point that WCAG 2.1 at Level AA is
>> the way to go: https://www.w3.org/TR/WCAG21/
>>
>> Why not AAA? Well, it's really hard / time-consuming. For example, users
>> have to be able to select their own foreground / background colours, if a
>> user's session expires, they need to be able to login in again and pick off
>> where they left off (forms filled, etc.), and more. Moreover, every law
>> I've looked at seems to use WCAG 2.0 (2.1 is just a couple years old and is
>> backwards compatible) at Level AA, so this seems like

Adding json lines (jsonl) serializer to django

[Ali Vakilzade]

Hi!

A while back I opened a pull request on this topic and there is no updates 
on the my request for a while. I know people might be busy and not having 
time to review but I'm sending this mail hoping to bring the pull request 
back up and not die on github. I think supporting "JSON lines" is a small 
feature which can be very useful for many people.

pull request: https://github.com/django/django/pull/12267
ticket: https://code.djangoproject.com/ticket/30190
previous discussion: 
https://groups.google.com/forum/#!topic/django-developers/MMm1AGS2Ibg

thanks

-- 
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/c8d6a616-e322-42c6-a8cf-046e9cab1d1e%40googlegroups.com.

Re: Adding json lines (jsonl) serializer to django

[Tim Graham]

Hi Ali, as I noted on the PR, the ticket isn't in the review queue because 
"needs tests" is checked.

On Thursday, May 21, 2020 at 9:47:53 AM UTC-4, Ali Vakilzade wrote:
>
> Hi!
>
> A while back I opened a pull request on this topic and there is no updates 
> on the my request for a while. I know people might be busy and not having 
> time to review but I'm sending this mail hoping to bring the pull request 
> back up and not die on github. I think supporting "JSON lines" is a small 
> feature which can be very useful for many people.
>
> pull request: https://github.com/django/django/pull/12267
> ticket: https://code.djangoproject.com/ticket/30190
> previous discussion: 
> https://groups.google.com/forum/#!topic/django-developers/MMm1AGS2Ibg
>
> thanks
>

-- 
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/ad34bab0-5b83-45c4-a18a-2bfb9607be4f%40googlegroups.com.

Re: Admin accessibility

[Kye Russell]

Hi all,

I am legally blind. Accessibility discussions tend to largely revolve
around contrast and screen readers (which I do not use) as it’s easy to
measure for (albeit poorly without actually trying to use a screen reader
yourself, which nobody tends to do).

I am unsure if I have any valuable / unique perspective to share, and I
probably don’t, but I am always happy to help. I have wanted an excuse to
get involved in the framework's development and this would be as good a
time as any.

The one thing I will say (and this doesn’t come from any lived experience,
rather what I’ve heard) is not to rely to heavily on automated
accessibility metrics, especially when it comes to screen reader
friendliness. An interface can tick all the automated boxes but still be
terrible to use. Just as with other user interfaces, automation can only
get us so far and additional manual checking would be worthwhile.

Kye




On 21 May 2020 at 9:33:51 pm, Tom Carrick (t...@carrick.eu) wrote:

Hi Adam,

> Which checker did you use?

I had a brief check with a few. Firefox's devtools, Lighthouse, and
WebAIM's WAVE browser extension. WAVE is quite nice in that it shows the
problems directly on the page, but they all give more or less the same
information. If Lighthouse can be integrated into the CI it seems the most
logical option. Lighthouse also gives a 0 - 100 score metric for each page,
which would be nice as part of a coverage-style CI process, i.e. the score
can remain the same or increase, but a decrease will fail the test.

> Would you be able to work on this on an ongoing basis? If you know others
who are interested, perhaps we could even form a Django a11y team, just
like we have an i18n team.

I'm happy to work on this on an ongoing basis. Thinking over the idea of an
a11y team, at first I thought it would have too narrow a scrope as it only
really concerns the admin, but I realised it also concerns the docs, the
djangoproject website, and other sites under the django org (django-people
and so on), so perhaps it's worth doing. That said, I don't have any
physical disabilities to speak of. My eyes are pretty bad, small text can
be a problem, but that's about it. It would be good to get some feedback
from people that this directly affects, but I don't know of many. It'd also
be hugely beneficial of course if any a11y team includes people with
physical disabilities or at least experience with it. I can only
immediately think of one person in the Django community that might fit, so
I will reach out to them and ask if they'd be interested in giving any
input here, but more voices would be useful.

For the low-hanging fruit, I will run Lighthouse on some more pages and
write some tickets up when I get some time, hopefully over the weekend.

Cheers,
Tom

On Thu, 21 May 2020 at 14:04, Adam Johnson  wrote:

> Hi Tom
>
> It's a laudable goal to make the admin accessible. Thank you for doing the
> research on currently laws and guidelines.
>
> I haven't audited the entire admin, but I have run a checker through some
>> pages.
>>
>
> Which checker did you use? I see Google's Lighthouse checks for many
> accessibility issues: https://web.dev/lighthouse-accessibility/
>
> I think fixing any "low hanging fruit" would be acceptable PR's right now.
>
> Setting a target and keeping to it would be harder though. Documentation
> is easy to write, but it can easily be forgotten/ignored, so I'd prefer a
> CI solution. One potential CI solution is running admin tests through the
> Lighthouse CLI.
>
> There will certainly add an ongoing maintenance cost. Would you be able to
> work on this on an ongoing basis? If you know others who are interested,
> perhaps we could even form a Django a11y team, just like we have an i18n
> team.
>
> On Tue, 19 May 2020 at 12:11, Tom Carrick  wrote:
>
>> Sorry, long post incoming.
>>
>> The admin currently has some accessibility issues. Not a huge amount,
>> actually, but they should be fixed regardless. I hope I don't need to
>> convince anyone here of the importance of accessibility, but I'll try to
>> make the case as briefly as possible for the benefit of the wider community.
>>
>> There is a trend towards stronger accessibility laws - there is a good
>> roundup of them here: https://www.w3.org/WAI/policies/ - and I'll come
>> back to this later. Most of these cover the public sector and small
>> segments of the private sector, but there's also an overview of some laws
>> used against private entities more generally here:
>> https://en.wikipedia.org/wiki/Web_Content_Accessibility_Guidelines#Legal_obligations
>>
>> I should make it clear that I'm not a lawyer and have no idea if any of
>> this would apply to the admin, since it's not intended for general
>> consumption, so I think I'd rather make this point: Developers and other
>> people using the admin - "staff users" of some kind - can have disabilities
>> too, and we should be catering for them, especially since the remedies are
>> not at all difficult

Re: QuerySet.iterator together with prefetch_related because of chunk_size

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

That makes sense to me. It is a little weird, but it’s the best option.

I will post a comment on the PR. I am happy to update the code if he’s not
available.

On Wed, May 20, 2020 at 9:59 PM charettes  wrote:

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

Re: QuerySet.iterator together with prefetch_related because of chunk_size

[Adam Johnson]

After over a year, it's probably reasonable to create a new PR. You can use
Co-Authored-By to credit the original author:
https://github.blog/2018-01-29-commit-together-with-co-authors/

On Fri, 22 May 2020 at 05:43, 'Taylor Hakes' via Django developers
(Contributions to Django itself)  wrote:

> That makes sense to me. It is a little weird, but it’s the best option.
>
> I will post a comment on the PR. I am happy to update the code if he’s not
> available.
>
> On Wed, May 20, 2020 at 9:59 PM charettes  wrote:
>
>> 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 si