Re: Ideas for a new DEP on long-term Django API compatibility

[Pkl]

Hello Luke,

thanks for your comments, mine are below

On Thursday, August 1, 2019 at 10:34:22 AM UTC+2, Luke Plant wrote:
>
> Hi Pascal,
>
> I know this is a very late reply, but there have been some things going 
> round my head that I thought I should get down.
>
> *First,* some positive changes I think we can make from your suggestions:
>
> 1. I think in our release notes, for breaking changes that might need some 
> justification, we should link to the tickets and/or django-devs discussions 
> behind them. Adding full reasoning in the notes themselves would likely 
> bloat them far too much, but a link could be helpful for anything which is 
> not obviously necessary.
>

Yes documenting the rationale behind breaking changes, via a ticket link or 
another medium, would be indeed a nice improvement.
 

> 2. We should change the wording in our API stability docs 
> , which 
> does indeed initially sound like a promise never to break working code that 
> follows docs:
>
> Django promises API stability and forwards-compatibility since version 1.0.
>
> We do have this line later on:
>
> If, for some reason, an API declared stable must be removed or replaced, 
> it will be declared deprecated but will remain in the API for at least two 
> feature releases. Warnings will be issued when the deprecated method is 
> called.
>
> But we do make changes at a rate faster than that document would make you 
> think.
>
> I suggest that as a contrast to the existing text on that page, we also 
> point out that we are continually improving Django, and have a 
> "(eventually) one way to do it" policy regarding how we plan APIs, which 
> means we will remove old things, while always providing better 
> alternatives. I'm happy to write a patch for this.
>

As you imagine, I'd rather have had a change in actual django policy, 
rather than a doc update to reflect the current status; but it'd be better 
than nothing. However, the second sentence "*If, for some reason, an API 
declared stable must be removed or replaced, it will be declared deprecated 
but will remain in the API for at least two feature releases*" is itself 
still misleading, since at least one recent major breakage violates it 

 
; *A pronouncement of the core dev team would be needed here**: is this 
behaviour change a procedure error? Or is it really the new policy, to 
allow changes which create immediate silent errors, and prevent third-party 
compatibility shims from getting implemented?*

Having "only one obvious way to day it" is a useful and common commitment 
in Python, but please note the "obvious". You won't have "one way to do 
it", ever. If people want to use sys.stdout.write(), or do a libc-cffi call 
to output text to console, instead of just calling print(), they will do 
so. And compatibility shims don't change anything on this matter: the 
"obvious", "standard" way of doing is just the one mentioned in official 
docs and which doesn't trigger DeprecationWarnings.


 

> *Second,* there were things I wanted to say that might be useful to you 
> (Pascal) in understanding why you are not likely to get very far with your 
> current approach.
>
> Your exaggerated tone is not likely to help you. You talk about Django's 
> compatibility breakages as "*ruining the day of thousands of anonymous 
> plugin/website maintainers all over the world*". When we make these kind 
> of changes, we always do it with very clear and detailed upgrade notes, and 
> almost always with several releases emitting deprecation warnings, as per 
> our policy. And no-one is forced to upgrade immediately. Those who value 
> stability above other things can use LTS, which gives them a *3 year 
> release cadence,* not 8 months, which is far from excessively fast 
> compared to other projects.
>


Imho dependency hell is absolutely unrelated to detailed release notes or 
LTS versions. Dependency hell is just the fact that, when each minor 
version breaks compatibility, the app ecosystem inevitably explodes, 
especially in its outskirts (i.e the least popular packages), into a myriad 
fragments, each targeting specific django versions. 
Your project remains on 1.11 LTS ? Nice, but one of your dependency (and 
its latest security bugfixes) require a new feature of Django 2.0; while 
another dependency is stuck on Django 1.10, either because the maintainer 
vanished, or because he is himself trapped by the requirements of a 
subdependency.

That's why Semantic Versioning was invented: so that developers can 
gradually update their own codebase (since each minor version brings 
improvements and deprecation warnings), while still ensuring all 
dependencies keep working under the same major versions (the project just 
has to install the latest minor version). The concept of "lax semantic 
versioning" soun

Re: Discussing improvements of django.setup()

[Pkl]

Hello,

any news about this issue?

Concerning the thread-safety of setup(), the PR is here - 
https://github.com/django/django/pull/11440

Concerning the tweakability of setup(), I don't get your argument Aymeric: 
"*One 
more or one less monkey patch isn't going to make a difference to these 
projects*".
That's precisely why we need a hook for custom setup operations. To 
monkey-patch test environments, apply DCP fixers, setup gevent-like 
runtimes... for now, there is no single point where one can inject early 
customization. One needs to change uwsgi.py, maybe manage.py, test 
launchers, potential scripts... 
AppConfig.ready() was introduced so that applications have a single point 
to initialize signals and the likes, this proposal only extends this to 
support early-stage setup customization, which is currently missing. 
Wouldn't an environment variable, pointing to a custom setup function, do 
the job?

thanks,
regards,
Pascal


-- 
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/c2bf23f2-ae22-487c-92b9-038e0bcb86cc%40googlegroups.com.

Re: Ideas for a new DEP on long-term Django API compatibility

[Tim Graham]

Pascal, you can read about the reason for the action actions change on the 
ticket https://code.djangoproject.com/ticket/29917 ...and on this mailing 
list... 
https://groups.google.com/d/topic/django-developers/-OWoYL_zryM/discussion. 
I hesitate to link to things like that in the release notes because the 
discussions can be long and somewhat difficult to follow. Rather, as 
appropriate, I tried to include a short summary of the rationale for 
backwards incompatible changes in the release notes.

In my years working on Django, I found it reasonable to occasionally make 
backwards incompatible changes if there's a consensus that a deprecation 
isn't feasible or worthwhile. Sometimes practicality beats purity, in my 
experience.

Luke's experience and views parallel mine. I think the current deprecation 
cycle works well.

On Tuesday, August 6, 2019 at 4:12:23 AM UTC-4, Pkl wrote:
>
> Hello Luke,
>
> thanks for your comments, mine are below
>
> On Thursday, August 1, 2019 at 10:34:22 AM UTC+2, Luke Plant wrote:
>>
>> Hi Pascal,
>>
>> I know this is a very late reply, but there have been some things going 
>> round my head that I thought I should get down.
>>
>> *First,* some positive changes I think we can make from your suggestions:
>>
>> 1. I think in our release notes, for breaking changes that might need 
>> some justification, we should link to the tickets and/or django-devs 
>> discussions behind them. Adding full reasoning in the notes themselves 
>> would likely bloat them far too much, but a link could be helpful for 
>> anything which is not obviously necessary.
>>
>
> Yes documenting the rationale behind breaking changes, via a ticket link 
> or another medium, would be indeed a nice improvement.
>  
>
>> 2. We should change the wording in our API stability docs 
>> , which 
>> does indeed initially sound like a promise never to break working code that 
>> follows docs:
>>
>> Django promises API stability and forwards-compatibility since version 
>> 1.0.
>>
>> We do have this line later on:
>>
>> If, for some reason, an API declared stable must be removed or replaced, 
>> it will be declared deprecated but will remain in the API for at least two 
>> feature releases. Warnings will be issued when the deprecated method is 
>> called.
>>
>> But we do make changes at a rate faster than that document would make you 
>> think.
>>
>> I suggest that as a contrast to the existing text on that page, we also 
>> point out that we are continually improving Django, and have a 
>> "(eventually) one way to do it" policy regarding how we plan APIs, which 
>> means we will remove old things, while always providing better 
>> alternatives. I'm happy to write a patch for this.
>>
>
> As you imagine, I'd rather have had a change in actual django policy, 
> rather than a doc update to reflect the current status; but it'd be better 
> than nothing. However, the second sentence "*If, for some reason, an API 
> declared stable must be removed or replaced, it will be declared deprecated 
> but will remain in the API for at least two feature releases*" is itself 
> still misleading, since at least one recent major breakage violates it 
> 
>  
> ; *A pronouncement of the core dev team would be needed here**: is this 
> behaviour change a procedure error? Or is it really the new policy, to 
> allow changes which create immediate silent errors, and prevent third-party 
> compatibility shims from getting implemented?*
>
> Having "only one obvious way to day it" is a useful and common commitment 
> in Python, but please note the "obvious". You won't have "one way to do 
> it", ever. If people want to use sys.stdout.write(), or do a libc-cffi call 
> to output text to console, instead of just calling print(), they will do 
> so. And compatibility shims don't change anything on this matter: the 
> "obvious", "standard" way of doing is just the one mentioned in official 
> docs and which doesn't trigger DeprecationWarnings.
>
>
>  
>
>> *Second,* there were things I wanted to say that might be useful to you 
>> (Pascal) in understanding why you are not likely to get very far with your 
>> current approach.
>>
>> Your exaggerated tone is not likely to help you. You talk about Django's 
>> compatibility breakages as "*ruining the day of thousands of anonymous 
>> plugin/website maintainers all over the world*". When we make these kind 
>> of changes, we always do it with very clear and detailed upgrade notes, and 
>> almost always with several releases emitting deprecation warnings, as per 
>> our policy. And no-one is forced to upgrade immediately. Those who value 
>> stability above other things can use LTS, which gives them a *3 year 
>> release cadence,* not 8 months, which is far from excessively fast 
>> compared to other projects.
>>
>
>
> Imho 

Ignoring accept_language in localization middleware based on prefixed URL patterns

[Janez Kranjc]

Hi guys! I’m Janez Kranjc, I’ve been using Django for a bit now - since 1.3 
and I’ve recently come across and issue that’s been bothering me in 
multiple projects that I’m working on.

Localization middleware ignores the accept language header if ANY url 
pattern exists that is i18n prefixed regardless of the current URL of the 
request.

So the problem is the following: I have some URLs that are prefixed, and a 
lot that are not (such as all of the API endpoints). I sometimes need to 
return some translated strings in the API as well and for that I rely on 
the accept-language header. However in the middleware it is ignored because 
an unrelated part of the project has an i18n prefixed url pattern.

Another way to look at the problem is this:

Let’s say I have a SPA that uses i18n on its API endpoints and you rely on 
accept-language to serve the responses in the correct locale. I then decide 
to add a new app to your django project - a sales page. Instead of relying 
on accept-language I wish to have i18n prefixed URLs (maybe for SEO reasons 
or whatever). Suddenly the behaviour of the API changes even though I’ve 
made changes to an entirely different part of the project.

Would it not make more sense for the middleware to check if the current URL 
pattern (the one that the request URL resolves to) is prefixed or not.

The way I see it, this should be changed:

i18n_patterns_used, prefixed_default_language = 
is_language_prefix_patterns_used(urlconf)

Instead of checking the entire urlconf it should only check the current 
request URL and see if it resolves to a pattern that is i18n prefixed.

To get around this I need to use a custom localization firmware in a lot of 
my projects. I would like to hear the devs’ opinion regarding this.

-- 
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/1b315c0b-9200-417b-816a-dd3c3b90ec67%40googlegroups.com.

retriving all table from database

[vishal singh]

can anyone help me to pull all table name(schema wise ) from database
into  a dropdown.

it will be best if someone give codesnippits or examples , how to do??

-- 
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/CAMSP2ackag-xH%3D2AN7NHVAsCsPRgp86qpGL0aoK1b%3DhT1K2JAw%40mail.gmail.com.

Display labels for autocomplete fields

[bjw]

At present the admin autocomplete docs mention 
`ModelAdmin.autocomplete_fields` and
`ModelAdmin.search_fields` which are used to configure select2. There are 
also options for overriding the queryset used.

However there seems to be no way of specifyng what is shown in the 
autocomplete... it just calls `__str__` on the objects returned.

Would it be possible to add a `search_display_fields` on the relevant 
ModelAdmin, alongside `search_fields` to customise the display in the form 
select box? This could be either a model field or a callable on the model 
or modeladmin.

Cheers!

bjw

-- 
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/8b785f3f-4158-4a7d-8f9a-41f82995671f%40googlegroups.com.

Make Development More Accessible

[John Gooding]

I'd like to propose moving Django issues to github and make a real decision 
on it here in this thread. If there has been a recent discussion on this I 
apologize, but searching for issue tracking / github links to about every 
thread ever posted here.

I believe this would lower the barrier to entry and to help promote 
community involvement. People are already there, people already use it, and 
we already do pull requests there. Now I could be wrong here, but I also 
feel that it would improve and promote discussion about changes and feature 
additions to Django, because right now they are pretty hidden away in the 
current system. 

I'd also like to see the inclusion of a "discussion" label or similar for 
issues. I think many of the conversations here on this forum would be much 
better off as github issues. I see a lot of great stuff, and it's not clear 
at all what the status is, has it moved forward, been officially denied? 
etc. If they are github issues they will have definitive resolutions, 
whatever it may be, and links to relevant code, PR's etc if needed.

I think there is a huge amount to gain by consolidating the ticket system 
and many of the discussions on this forum into github's issue tracker. I 
don't see any reason why it wouldn't be wroth the effort, and we only have 
much to gain as a community from it. But that's just my 2 cents. I'd love 
to hear what others think, for or against it.

John


-- 
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/da5ca4b1-fb84-4ed4-b2cb-324b8bea9c42%40googlegroups.com.

Re: Ignoring accept_language in localization middleware based on prefixed URL patterns

[Aymeric Augustin]

Hello,

Yes, I think this change makes sense, assuming no unexpected difficulties arise 
in the implementation.

Best regards,

-- 
Aymeric.



> On 6 Aug 2019, at 10:58, Janez Kranjc  wrote:
> 
> Hi guys! I’m Janez Kranjc, I’ve been using Django for a bit now - since 1.3 
> and I’ve recently come across and issue that’s been bothering me in multiple 
> projects that I’m working on.
> 
> Localization middleware ignores the accept language header if ANY url pattern 
> exists that is i18n prefixed regardless of the current URL of the request.
> 
> So the problem is the following: I have some URLs that are prefixed, and a 
> lot that are not (such as all of the API endpoints). I sometimes need to 
> return some translated strings in the API as well and for that I rely on the 
> accept-language header. However in the middleware it is ignored because an 
> unrelated part of the project has an i18n prefixed url pattern.
> 
> Another way to look at the problem is this:
> 
> Let’s say I have a SPA that uses i18n on its API endpoints and you rely on 
> accept-language to serve the responses in the correct locale. I then decide 
> to add a new app to your django project - a sales page. Instead of relying on 
> accept-language I wish to have i18n prefixed URLs (maybe for SEO reasons or 
> whatever). Suddenly the behaviour of the API changes even though I’ve made 
> changes to an entirely different part of the project.
> 
> Would it not make more sense for the middleware to check if the current URL 
> pattern (the one that the request URL resolves to) is prefixed or not.
> 
> The way I see it, this should be changed:
> 
> i18n_patterns_used, prefixed_default_language = 
> is_language_prefix_patterns_used(urlconf)
> 
> Instead of checking the entire urlconf it should only check the current 
> request URL and see if it resolves to a pattern that is i18n prefixed.
> 
> To get around this I need to use a custom localization firmware in a lot of 
> my projects. I would like to hear the devs’ opinion regarding this.
> 
> -- 
> 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/1b315c0b-9200-417b-816a-dd3c3b90ec67%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/09EBC24C-868E-4197-AEAE-87CB82787DDE%40polytechnique.org.