Re: Adding a decorator to include a property in an object's serialization

['Adam Johnson' via Django developers (Contributions to Django itself)]

Hi Diptesh

Django's serialization framework is mostly used for saving model data for
later loading into the DB - normally for setting up environments or tests.
I don't think saving properties is useful in this case. If you're using
serialization for API responses, look at Django REST Framework's
serializers. These are much more customizable and can serialize properties,
or any other attributes.

Thanks,

Adam

On Tue, 8 Jun 2021 at 03:36, Diptesh Choudhuri 
wrote:

> Hello, I hope you are all doing well.
>
> Currently if one wants to have custom properties on their models without
> introducing new columns, they have to use properties:
>
> class Chapter(models.Model):
> name = models.CharField()
> text = models.TextField()
>
> @property
> def word_count(self):
> return len(self.text.split())
>
> chapter_one = Chapter.objects.first()
>
> Now, the word count can be accessed using *chapter_one.wordcount*.
> However, when actually serializing this object, the wordcount isn't
> included:
> {
>   "name":"Technology",
>   "text":"Some long text"
>   // "wordcount": 3 <- this is not included
> }
>
> This problem can be fixed by updating the resultant serialization yourself.
>
> serialized.update({ "wordcount": chapter_one.wordcount })
>
> However, this quickly gets difficult once you have many such properties.
> There are workarounds for this (eg: using the* inspect *module) but they
> are difficult to understand and quickly result in unreadable code.
>
> I propose we add a new decorator which will allow these properties to be
> included in the default object serialization.
>
> *@column_property **# imported from django*
> def word_count(self):
> return len(self.text.split())
>
> What do you think about this change? I think it'd be good since this won't
> introduce any backwards incompatible change. This change will especially
> benefit those who are creating some kind of API since they won't have to
> write complex code for such a simple use case.
>
> I can open a ticket for this on djangoproject, and start working on this
> soon.
>
> Thanks
> Diptesh Choudhuri
>
> --
> 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/b6f33375-cf76-421c-b6d4-3642d0bbb9f1n%40googlegroups.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/CAMyDDM3GurX_dT%2BC8NhHCkF_3t0zfJ4rGAuCU1%2B_W1X7AGgmrw%40mail.gmail.com.

Re: Discussion regarding #32628 and #32823

['Adam Johnson' via Django developers (Contributions to Django itself)]

Sébastien - on your original post: you didn't provide any useful title or
ticket links in your post. That may have stopped readers engaging on the
list. No one knows ticket numbers, but some people will be interested when
they see a post on "the admin autocomplete". Links would make it easy to
catch up. More context makes it easy to engage.


> Carlton: Sorry you feel hard done by here. I think that's perhaps
> unfamiliarity with the workflow.
>

I agree here that it can be down to unfamiliarity. But perhaps the default
copy-paste messages the fellows use could have a little more empathy
towards those who are unfamiliar. The majority of Trac users are only
around for one ticket, or a few.

Mariusz wrote: "Please follow triaging guidelines with regards to wontfix
tickets." The conciseness *can* be read as curt.

I suggest a reword to something like  "I appreciate you'd like to reopen
the ticket, but please *follow the triaging guidelines with regards to
wontfix tickets* and take this to the django-developers mailing list."


> Carlton: The admin's role is not to be a general application development
> platform


💯 agree here. My gut reaction is the same. Most organizations who try to
build their "back office" within the admin end up digging themselves into a
bit of a hole with their customizations. Building your own pieces is
normally a better approach when you need a certain level of customization.

Just yesterday I was advising a client who wanted some different
autocomplete customizations. I also recommended trying django-select2, as
Johannes wrote on the ticket (
https://code.djangoproject.com/ticket/32628#comment:5 ).

-- 
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/CAMyDDM1jX0V3mWZjEs19bsYo3V2qMvHOaW5Ky8mSST2ePP%3D%3D6w%40mail.gmail.com.

Re: Django website Down

[Roger Gammans]

It may have had something to do with this? I seem to remember fastly
did offer some OSS projects some CDN services.

https://www.bbc.co.uk/news/technology-57399628


On Tue, 2021-06-08 at 14:17 +0100, Wadinga Leonard Ngonga wrote:
> It’s up, I can access it from my location(Buea, Cameroon). Try with a
> VPN it could be your ISP.
> 
> 
> 
> Sincerely,
> Wadinga Leonard.
> 
> > On 8 Jun 2021, at 14:13, danushka padrushka <
> > danupadrus...@gmail.com> wrote:
> > 
> > Hi,
> > 
> > Not sure if this is the right email to report it but Django website
> > is down,
> > 
> > -- 
> > 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/6EAF8BA5-DD5A-4CF6-85D6-B4216EA5A07E%40gmail.com
> > .
> > 
> > 
> > 
> > 
> > Dan
> > 
> > Sent from my iPhone
> > 
> > -- 
> > 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/6EAF8BA5-DD5A-4CF6-85D6-B4216EA5A07E%40gmail.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/71749f2f705b9c72827117d3defab2a7f1b35074.camel%40gammascience.co.uk.

Re: Django website Down

['Adam Johnson' via Django developers (Contributions to Django itself)]

Yes we use fastly and that's the reason it has been down.

On Tue, 8 Jun 2021 at 14:38, Roger Gammans 
wrote:

> It may have had something to do with this? I seem to remember fastly
> did offer some OSS projects some CDN services.
>
> https://www.bbc.co.uk/news/technology-57399628
>
>
> On Tue, 2021-06-08 at 14:17 +0100, Wadinga Leonard Ngonga wrote:
> > It’s up, I can access it from my location(Buea, Cameroon). Try with a
> > VPN it could be your ISP.
> >
> >
> >
> > Sincerely,
> > Wadinga Leonard.
> >
> > > On 8 Jun 2021, at 14:13, danushka padrushka <
> > > danupadrus...@gmail.com> wrote:
> > >
> > > Hi,
> > >
> > > Not sure if this is the right email to report it but Django website
> > > is down,
> > >
> > > --
> > > 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/6EAF8BA5-DD5A-4CF6-85D6-B4216EA5A07E%40gmail.com
> > > .
> > > 
> > >
> > >
> > >
> > > Dan
> > >
> > > Sent from my iPhone
> > >
> > > --
> > > 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/6EAF8BA5-DD5A-4CF6-85D6-B4216EA5A07E%40gmail.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/71749f2f705b9c72827117d3defab2a7f1b35074.camel%40gammascience.co.uk
> .
>

-- 
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/CAMyDDM1S%3DHsY1F0quBtrZE-JF5Fc7Gvt1DvYR7oszM4PW7oUkg%40mail.gmail.com.

Re: Django website Down

[danushka padrushka]

Hi Wadinga Leonard, 

I checked from different networks, it wasn’t working in the morning at least 
where I live (Montréal). After like 30 min I noticed it was working fine ☺️

Dan

Sent from my iPhone

> On Jun 8, 2021, at 9:39 AM, Roger Gammans  wrote:
> 
> It may have had something to do with this? I seem to remember fastly
> did offer some OSS projects some CDN services.
> 
> https://www.bbc.co.uk/news/technology-57399628
> 
> 
>> On Tue, 2021-06-08 at 14:17 +0100, Wadinga Leonard Ngonga wrote:
>> It’s up, I can access it from my location(Buea, Cameroon). Try with a
>> VPN it could be your ISP.
>> 
>> 
>> 
>> Sincerely,
>> Wadinga Leonard.
>> 
>>> On 8 Jun 2021, at 14:13, danushka padrushka <
>>> danupadrus...@gmail.com> wrote:
>>> 
>>> Hi,
>>> 
>>> Not sure if this is the right email to report it but Django website
>>> is down,
>>> 
>>> -- 
>>> 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/6EAF8BA5-DD5A-4CF6-85D6-B4216EA5A07E%40gmail.com
>>> .
>>> 
>>> 
>>> 
>>> 
>>> Dan
>>> 
>>> Sent from my iPhone
>>> 
>>> -- 
>>> 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/6EAF8BA5-DD5A-4CF6-85D6-B4216EA5A07E%40gmail.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/71749f2f705b9c72827117d3defab2a7f1b35074.camel%40gammascience.co.uk.

-- 
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/4411DC00-38AF-4FE2-8073-C550D5486E74%40gmail.com.

Re: Discussion regarding #32628 and #32823

[Contributions to Django itself]

Thanks a lot for the kind answers.

*But perhaps the default copy-paste messages the fellows use could have a 
little more empathy towards those who are unfamiliar. The majority of Trac 
users are only around for one ticket, or a few.*

I agree with you Adam, my emotional perception of the messages I received 
may boil down to conciseness and formalism of the copy/paste (almost 
automatic) answer. However I totally understand the overwhelming load of 
tickets on the Trac team and the need to process them efficiently. I don't 
know Trac under the hood, but maybe longer "automatic" answers can be 
written down somewhere, that explain things more thoroughly and gently, 
especially to newcomers. Your rewording suggestion sounds like a good 
start. If you are willing to discuss the topic I'd be happy to suggest 
longer versions (if technically possible to implement).

*Sébastien - on your original post: you didn't provide any useful title or 
ticket links in your post. That may have stopped readers engaging on the 
list. No one knows ticket numbers, but some people will be interested when 
they see a post on "the admin autocomplete". Links would make it easy to 
catch up. More context makes it easy to engage.*

You're totally right. I feel stupid for not thinking of that in the first 
place. That will serve as a lesson for my future posts to this board, sorry.



Now about the issue itself.

I think I understand the underlying point here, being: the admin is not 
meant to please every possible user, and thus should not be bloated with 
every possible feature. I definitely understand the need for the admin (and 
Django itself for that matter) to stay generic and encourage overriding.
My understanding of this argument stops early though, as I do not 
understand why the $.fn.djangoAdminSelect2 function would accept an options 
parameter *at all* then. This options parameter is never used in Django's 
own code, as far as I can tell.
The very presence of this parameter led me to think that I (as a regular 
Django user) could use the $.fn.djangoAdminSelect2 function when extending 
the admin for my own needs. Using it made me feel that I got my back 
covered since I used Django's implementation of Select2 and would then 
benefit future code evolution, which would avoid breaking of my own code.
This is why I suggested that, since this parameter exists, it should be 
fully and correctly implemented. In its current state, it allows to provide 
*any* Select2 option *except* those nested under the ajax key. If Django 
calls to $.fn.djangoAdminSelect2 were to evolve in future versions, and 
provided, say, the Select2 tags option, it could break my own calls to 
$.fn.djangoAdminSelect2 that provided the tags option.
The current situation seems totally counter-intuitive to me. I would expect 
options to be either absent (telling me that, if I want to instantiate 
autocomplete widgets for my own needs then I'm on my own) OR, if present, 
to be fully usable (meaning that I could really provide it any Select2 
option, since Johannes Maron suggested it should respect Select2 API).

Additionally, I do not see how this would add complexity to the code and/or 
the API. The API would remain strictly the same (
$.fn.djangoAdminSelect2(options)) and the code itself needs only an 
additional ~5 lines.

Overrides of back-end autocomplete views, though useful, do not solve the 
same usecases.

Thanks again for your answers.
Best regards,

Sébastien Gélis

Le mardi 8 juin 2021 à 13:15:11 UTC+2, Adam Johnson a écrit :

> Sébastien - on your original post: you didn't provide any useful title or 
> ticket links in your post. That may have stopped readers engaging on the 
> list. No one knows ticket numbers, but some people will be interested when 
> they see a post on "the admin autocomplete". Links would make it easy to 
> catch up. More context makes it easy to engage.
>  
>
>> Carlton: Sorry you feel hard done by here. I think that's perhaps 
>> unfamiliarity with the workflow.
>>
>
> I agree here that it can be down to unfamiliarity. But perhaps the default 
> copy-paste messages the fellows use could have a little more empathy 
> towards those who are unfamiliar. The majority of Trac users are only 
> around for one ticket, or a few.
>
> Mariusz wrote: "Please follow triaging guidelines with regards to wontfix 
> tickets." The conciseness *can* be read as curt.
>
> I suggest a reword to something like  "I appreciate you'd like to reopen 
> the ticket, but please *follow the triaging guidelines with regards to 
> wontfix tickets* and take this to the django-developers mailing list."
>  
>
>> Carlton: The admin's role is not to be a general application development 
>> platform
>
>
> 💯 agree here. My gut reaction is the same. Most organizations who try to 
> build their "back office" within the admin end up digging themselves into a 
> bit of a hole with their customizations. Building your own pieces is 
> normally a better approach wh

Re: Discussion regarding #32628 and #32823

[Mariusz Felisiak]

> Additionally, I do not see how this would add complexity to the code 
and/or the API. The API would remain strictly the same (
$.fn.djangoAdminSelect2(options)) and the code itself needs only an 
additional ~5 lines.

The number of lines is not the most important factor. There is no point in 
adding a new feature without tests and docs, because without them we will 
add a feature only for a single user, i.e. for the reporter. Also, we 
cannot add features just because they are not complex (*"death by a 
thousand cuts"*), each of them has a maintenance cost. Moreover, adding new 
features to the admin which are not used by admin itself is quite 
controversial.

My 2 cents. 

Best,
Mariusz

-- 
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/07713c30-7d56-4f34-b802-8e4d3cfc2bc6n%40googlegroups.com.

Fellow Reports - June 2021

[Mariusz Felisiak]

Week ending June 6, 2021

Participated in the *DjangoCon Europe* conference.

*Triaged:*
    https://code.djangoproject.com/ticket/32800 - CsrfViewMiddleware 
unnecessarily masks CSRF cookie (accepted)
    https://code.djangoproject.com/ticket/32804 - Add 'link' attribute 
to admin display function to enable custom link (wontfix)
    https://code.djangoproject.com/ticket/32805 - makemigrations seems 
to generate an unnecessary AlterField (invalid)
    https://code.djangoproject.com/ticket/32806 - Send email with a 
content_type=text/* attachment (invalid)
    https://code.djangoproject.com/ticket/32807 - JSONField.bound_data 
raises TypeError when data is None (accepted)
    https://code.djangoproject.com/ticket/32205 - sqlmigrate crashes 
after removing squashed migrations. (invalid)
    https://code.djangoproject.com/ticket/32808 - 
DiscoverRunner.build_suite() does not restore 
self.test_loader.testNamePatterns (accepted)
    https://code.djangoproject.com/ticket/32802 - Ability to generate 
GenericForeignKey from class properties (wontfix)
    https://code.djangoproject.com/ticket/32803 - Not obvious 
interaction between Postgresql trgm index and icontains lookup (duplicate)
    https://code.djangoproject.com/ticket/32809 - Filtering with Q and 
OR gets duplicated entries (needsinfo)
    https://code.djangoproject.com/ticket/32811 - Annotate removes 
Meta.ordering (invalid)
    https://code.djangoproject.com/ticket/32810 - 
django.utils.formats.number_format calculates a value for use_l10n which 
isn't re-used for calls to get_format (accepted)
    https://code.djangoproject.com/ticket/32815 - Failed to reset 
ContextVars in sync/async middlewares (invalid)
    https://code.djangoproject.com/ticket/32814 - Improve performance 
of TextNode rendering by providing a special-case of render_annotated 
(accepted)
    https://code.djangoproject.com/ticket/32816 - QuerysetEqual Test 
error on the polls app. (invalid)
    https://code.djangoproject.com/ticket/32818 - Add pyproject.toml 
config for black formatter (invalid)


*Reviewed/committed:*
    https://github.com/django/django/pull/14460 - Refs #24121 -- Added 
__repr__() to Engine.
    https://github.com/django/django/pull/14471 - Fixed #32796 -- 
Changed CsrfViewMiddleware to fail earlier on badly formatted cookie tokens.
    https://github.com/django/django/pull/14150 - Refs #32552 -- Added 
DiscoverRunner.log() to allow customization.
    https://github.com/django/django/pull/14474 - Fixed #28154 -- 
Prevented infinite loop in FileSystemStorage.save() when a broken 
symlink with the same name exists.
    https://github.com/django/django/pull/14476 - Refs #32641 -- Made 
DiscoverRunner's "Found X tests" message work for finding one test.
    https://github.com/django/django/pull/14477 - Refs #32668 -- 
Refactored runtests.py's setup() and get_test_modules().
    https://github.com/django/django/pull/14483 - Fixed #32812 -- 
Restored immutability of named values from QuerySet.values_list().
    https://github.com/django/django/pull/14391 - Refs #32338 -- 
Improved accessibility of RadioSelect examples in docs.
    https://github.com/django/django/pull/14427 - Made SerializeMixin 
check lockfile attr at import time.
    https://github.com/django/django/pull/14492 - Fixed #32810 -- 
Optimized django.utils.formats.number_format() a bit.
    https://github.com/django/django/pull/14491 - Refs #32668 -- 
Simplified start_at/start_after logic in runtests.py's setup().


*Authored:*
    https://github.com/django/django/pull/14478 - Fixed #32808 -- 
Prevented DiscoverRunner.build_suite() from mutating test loader patterns.
    https://github.com/django/django/pull/14482 - Refs #31356 -- 
Changed IRC links to the Libera.Chat webchat.
    https://github.com/django/django/pull/14486 - Refs #32355 -- Used 
addClassCleanup() in tests.


Best,
Mariusz

--
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/7325811d-1a81-8d13-fe94-dd5f48f4ba49%40gmail.com.

Re: Django website Down

[Tobias McNulty]

Here's the incident report from Fastly:
https://status.fastly.com/incidents/vpk0ssybt3bj


*Tobias McNulty*Chief Executive Officer

tob...@caktusgroup.com
www.caktusgroup.com


On Tue, Jun 8, 2021 at 9:58 AM danushka padrushka 
wrote:

> Hi Wadinga Leonard,
>
> I checked from different networks, it wasn’t working in the morning at
> least where I live (Montréal). After like 30 min I noticed it was working
> fine ☺️
>
> Dan
>
> Sent from my iPhone
>
> > On Jun 8, 2021, at 9:39 AM, Roger Gammans 
> wrote:
> >
> > It may have had something to do with this? I seem to remember fastly
> > did offer some OSS projects some CDN services.
> >
> > https://www.bbc.co.uk/news/technology-57399628
> >
> >
> >> On Tue, 2021-06-08 at 14:17 +0100, Wadinga Leonard Ngonga wrote:
> >> It’s up, I can access it from my location(Buea, Cameroon). Try with a
> >> VPN it could be your ISP.
> >>
> >>
> >>
> >> Sincerely,
> >> Wadinga Leonard.
> >>
> >>> On 8 Jun 2021, at 14:13, danushka padrushka <
> >>> danupadrus...@gmail.com> wrote:
> >>>
> >>> Hi,
> >>>
> >>> Not sure if this is the right email to report it but Django website
> >>> is down,
> >>>
> >>> --
> >>> 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/6EAF8BA5-DD5A-4CF6-85D6-B4216EA5A07E%40gmail.com
> >>> .
> >>> 
> >>>
> >>>
> >>>
> >>> Dan
> >>>
> >>> Sent from my iPhone
> >>>
> >>> --
> >>> 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/6EAF8BA5-DD5A-4CF6-85D6-B4216EA5A07E%40gmail.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/71749f2f705b9c72827117d3defab2a7f1b35074.camel%40gammascience.co.uk
> .
>
> --
> 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/4411DC00-38AF-4FE2-8073-C550D5486E74%40gmail.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/CAMGFDKSYMb3boJn6U672vB6bwX5f_ES1aDPwTBjPjA47VRQqpQ%40mail.gmail.com.

Fellow Reports -- June 2021

[Carlton Gibson]

Hi all, 


Calendar Week 22 -- ending 06 June.


Mostly at/doing DjangoCon Europe


Released Django 3.2.4, 3.1.12, and 2.2.24. 


Triaged:

https://code.djangoproject.com/ticket/32790 -- Django test client 
redirecting to URLs without a trailing slash redirects instead to the 
current view (Accepted)
https://code.djangoproject.com/ticket/32791 -- Documentation unclear on 
custom user models (needsinfo)
https://code.djangoproject.com/ticket/32798 -- StreamingHttpResponse raises 
SynchronousOnlyOperation in ASGI server (Accepted)



Reviewed:

https://github.com/django/django/pull/14470 -- Fixed #32793 -- Fixed loss 
of precision for temporal operations with DecimalFields on MySQL.



Kind Regards,

Carlton

-- 
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/2d5e53b6-47f6-4f69-bfac-a2cee78f7683n%40googlegroups.com.

Re: Discussion regarding #32628 and #32823

['Adam Johnson' via Django developers (Contributions to Django itself)]

>
> I'd be happy to suggest longer versions (if technically possible to
> implement).
>

At least the documentation for triaging tickets is here:
https://github.com/django/django/blob/main/docs/internals/contributing/triaging-tickets.txt
.

 I do not understand why the $.fn.djangoAdminSelect2 function would accept
> an options parameter at all then. This options parameter is never used in
> Django's own code, as far as I can tell.
>

This looks like an oversight in the original commit to add the function:
https://github.com/django/django/commit/94cd8efc50c717cd00244f4b2233f971a53b205e
. The parameter has indeed never been used by Django.

Django's policy for what is maintained and extensible as "public API" is
only those things that have been documented. This is its "deprecation
policy":
https://docs.djangoproject.com/en/dev/internals/release-process/#internal-release-deprecation-policy
. Since neither the function nor the parameter have been documented, no one
should not rely on them. It's the same for an unused parameter in an
internal Python function. We remove many such parameters in each Django
version without deprecation.

If anything, your highlighting the parameter has made me think we could
remove it.

On Tue, 8 Jun 2021 at 15:55, Mariusz Felisiak 
wrote:

> > Additionally, I do not see how this would add complexity to the code
> and/or the API. The API would remain strictly the same (
> $.fn.djangoAdminSelect2(options)) and the code itself needs only an
> additional ~5 lines.
>
> The number of lines is not the most important factor. There is no point in
> adding a new feature without tests and docs, because without them we will
> add a feature only for a single user, i.e. for the reporter. Also, we
> cannot add features just because they are not complex (*"death by a
> thousand cuts"*), each of them has a maintenance cost. Moreover, adding
> new features to the admin which are not used by admin itself is quite
> controversial.
>
> My 2 cents.
>
> Best,
> Mariusz
>
> --
> 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/07713c30-7d56-4f34-b802-8e4d3cfc2bc6n%40googlegroups.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/CAMyDDM07DAJ%2BVtw2t3soegoZEdBCYcp%2BhshvzQVwT%2BPEeDfnQg%40mail.gmail.com.

Re: Discussion regarding #32628 and #32823

[Contributions to Django itself]

> *The number of lines is not the most important factor. There is no point 
in adding a new feature without tests and docs, because without them we 
will add a feature only for a single user, i.e. for the reporter. Also, we 
cannot add features just because they are not complex ("death by a thousand 
cuts"), each of them has a maintenance cost. Moreover, adding new features 
to the admin which are not used by admin itself is quite controversial.*

Totally agree with you on that. My point was therefore: let's either 
implement this feature fully or, as Adam later suggested, remove the options 
parameter.

> *Django's policy for what is maintained and extensible as "public API" is 
only those things that have been documented. This is its "deprecation 
policy": 
https://docs.djangoproject.com/en/dev/internals/release-process/#internal-release-deprecation-policy
 

 
. Since neither the function nor the parameter have been documented, no one 
should not rely on them. It's the same for an unused parameter in an 
internal Python function. We remove many such parameters in each Django 
version without deprecation.*

Thanks for this important clarification. I'll refactor my code to use a 
totally custom JS then, and leave this undocumented autocomplete.js alone 
for good :-)

> *If anything, your highlighting the parameter has made me think we could 
remove it.*

Count me in favor of this + documenting how front-end overrides of 
autocomplete are expected to be done (complete override of autocomplete.js 
or custom version compatible with AutocompleteJsonView).
Would be happy to push a commit in this direction.

Thanks again to you guys for taking the time to lead me through this!

Sébastien

Le mardi 8 juin 2021 à 17:39:22 UTC+2, Adam Johnson a écrit :

> I'd be happy to suggest longer versions (if technically possible to 
>> implement).
>>
>
> At least the documentation for triaging tickets is here: 
> https://github.com/django/django/blob/main/docs/internals/contributing/triaging-tickets.txt
>  
> .
>
>  I do not understand why the $.fn.djangoAdminSelect2 function would accept 
>> an options parameter at all then. This options parameter is never used in 
>> Django's own code, as far as I can tell.
>>
>
> This looks like an oversight in the original commit to add the function: 
> https://github.com/django/django/commit/94cd8efc50c717cd00244f4b2233f971a53b205e
>  
> . The parameter has indeed never been used by Django. 
>
> Django's policy for what is maintained and extensible as "public API" is 
> only those things that have been documented. This is its "deprecation 
> policy": 
> https://docs.djangoproject.com/en/dev/internals/release-process/#internal-release-deprecation-policy
>  
> . Since neither the function nor the parameter have been documented, no one 
> should not rely on them. It's the same for an unused parameter in an 
> internal Python function. We remove many such parameters in each Django 
> version without deprecation.
>
> If anything, your highlighting the parameter has made me think we could 
> remove it.
>
> On Tue, 8 Jun 2021 at 15:55, Mariusz Felisiak  
> wrote:
>
>> > Additionally, I do not see how this would add complexity to the code 
>> and/or the API. The API would remain strictly the same (
>> $.fn.djangoAdminSelect2(options)) and the code itself needs only an 
>> additional ~5 lines.
>>
>> The number of lines is not the most important factor. There is no point 
>> in adding a new feature without tests and docs, because without them we 
>> will add a feature only for a single user, i.e. for the reporter. Also, we 
>> cannot add features just because they are not complex (*"death by a 
>> thousand cuts"*), each of them has a maintenance cost. Moreover, adding 
>> new features to the admin which are not used by admin itself is quite 
>> controversial.
>>
>> My 2 cents. 
>>
>> Best,
>> Mariusz
>>
>> -- 
>> 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-develop...@googlegroups.com.
>> To view this discussion on the web visit 
>> https://groups.google.com/d/msgid/django-developers/07713c30-7d56-4f34-b802-8e4d3cfc2bc6n%40googlegroups.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/11f4a625-f80f-4b7a-b821-e40d0e7e9a5fn%40googlegro