> *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
<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 <[email protected]>
> 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 [email protected].
>> To view this discussion on the web visit
>> https://groups.google.com/d/msgid/django-developers/07713c30-7d56-4f34-b802-8e4d3cfc2bc6n%40googlegroups.com
>>
>> <https://groups.google.com/d/msgid/django-developers/07713c30-7d56-4f34-b802-8e4d3cfc2bc6n%40googlegroups.com?utm_medium=email&utm_source=footer>
>> .
>>
>
--
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 [email protected].
To view this discussion on the web visit
https://groups.google.com/d/msgid/django-developers/11f4a625-f80f-4b7a-b821-e40d0e7e9a5fn%40googlegroups.com.
