Re: First ASGI pull request is ready for review

[Carlton Gibson]

Yes, I’ll review properly first half of next week.

For the DEP, can you break out how and where people might input. There’s
massive interest. 🙂

Great work as ever Andrew. Thank you so much!

C.

On Wed, 1 May 2019 at 08:46, Andrew Godwin  wrote:

>
>
> On Tue, Apr 30, 2019 at 11:34 PM Mariusz Felisiak <
> felisiak.mari...@gmail.com> wrote:
>
>> Thanks for this patch. Can you add a trac ticket? also Can you give me &
>> Carlton few days for review? I should be able to do this somewhere in the
>> next week.
>>
>
> I can indeed. I wasn't sure if you wanted to get around to reviewing it or
> not, but take all the time you need to review. I'm sure there's some more
> in there that could be tightened up.
>
> (Forgive me if I seem like I am being pushy - just trying to make sure we
> keep forward progress!)
>
>
>>
>> Are we going to create "Async" DEP?
>>
>>
> We probably should do now there is a more solid plan - the discussion on
> the mailing list from before was only really about this first step, not
> about what it would look like to adopt this more fully. I don't think the
> solid agreement from before means we get to skip writing this up, and from
> here on out it becomes much more of a new feature than merely adding safety
> and a new handler.
>
> Andrew
>
> --
> 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 post to this group, send email to django-developers@googlegroups.com.
> Visit this group at https://groups.google.com/group/django-developers.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/django-developers/CAFwN1urbURE-v2wtts49or54OD-ui%3DWEKVaZY%2BFUk9xQbOsu1Q%40mail.gmail.com
> 
> .
> For more options, visit https://groups.google.com/d/optout.
>

-- 
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 post to this group, send email to django-developers@googlegroups.com.
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CAJwKpyR4yME8VyMKrSaFZGkvZdOuh4eQiX6u74Vm-4UFEWs%2Bvw%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: First ASGI pull request is ready for review

[Andrew Godwin]

On Tue, Apr 30, 2019 at 11:34 PM Mariusz Felisiak <
felisiak.mari...@gmail.com> wrote:

> Thanks for this patch. Can you add a trac ticket? also Can you give me &
> Carlton few days for review? I should be able to do this somewhere in the
> next week.
>

I can indeed. I wasn't sure if you wanted to get around to reviewing it or
not, but take all the time you need to review. I'm sure there's some more
in there that could be tightened up.

(Forgive me if I seem like I am being pushy - just trying to make sure we
keep forward progress!)


>
> Are we going to create "Async" DEP?
>
>
We probably should do now there is a more solid plan - the discussion on
the mailing list from before was only really about this first step, not
about what it would look like to adopt this more fully. I don't think the
solid agreement from before means we get to skip writing this up, and from
here on out it becomes much more of a new feature than merely adding safety
and a new handler.

Andrew

-- 
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 post to this group, send email to django-developers@googlegroups.com.
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CAFwN1urbURE-v2wtts49or54OD-ui%3DWEKVaZY%2BFUk9xQbOsu1Q%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: First ASGI pull request is ready for review

[Mariusz Felisiak]

Thanks for this patch. Can you add a trac ticket? also Can you give me & 
Carlton few days for review? I should be able to do this somewhere in the 
next week.

Are we going to create "Async" DEP? 

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 post to this group, send email to django-developers@googlegroups.com.
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/1b122b3f-ac07-4f7b-8277-6f77ed65e827%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: First ASGI pull request is ready for review

[Andrew Godwin]

So, it looks like most of the comments on this PR have happened and been
resolved - unless anyone has any objections, I will merge it in after a
couple more days (just in time for PyCon US).

Andrew

On Wed, Apr 24, 2019 at 1:50 PM Andrew Godwin  wrote:

> Hi everyone,
>
> Just wanted to drop a note and say that the first pull request in the
> series needed to enable async in Django is now ready for review:
> https://github.com/django/django/pull/11209
>
> This is a very minimal amount of work to get Django async-safe and
> understanding ASGI as an application interface, but the idea is to land
> this so it's definitely in 3.0, and then work on getting async abilities
> down to views before the 3.0 feature freeze if we can.
>
> Once those two things are down, we can then expand the effort out a lot
> more and have some work for new contributors to get their teeth into, as we
> can then start making all the other parts of Django async-capable as a
> parallel effort.
>
> Reviews and comments on the PR are encouraged; I want to make sure this is
> not going to hurt existing sync Django when it lands, and that it's a
> useful stepping stone towards async in views.
>
> Andrew
>

-- 
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 post to this group, send email to django-developers@googlegroups.com.
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CAFwN1uoyQb_f2fbEaYfDHDgJL-L_oazV74Pa-5gaF8GXiQRoTQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: A different approach for the auto-reloader

[Andrew Godwin]

>From my read this also looks like it would make the auto-reloader able to
work a lot better with an async-capable server, so I would be in favour
given that is likely in the future as well.

Andrew

On Tue, Apr 23, 2019 at 9:33 PM Ramiro Morales  wrote:

> Hi all,
>
> I had a stab at a somewhat simpler development server automatic reloading
> strategy
> https://github.com/django/django/compare/master...ramiro:synch-reloader
>
> Intention is to test how an implementation of a design by Gary Bernhardt
> would look. The best written description I could find is this:
>
> https://github.com/devlocker/tychus/issues/3
>
> Gary also had posted some tweets (this is how I got interested in the
> topic) which seems to have been deleted since then.
>
> Main idea is: Actual checking of changes on the filesystem for modules
> under monitoring isn't performed in a loop or by depending on a OS kernel
> feature but per-HTTP request by a front-end proxy process which is in
> charge of restarting the 'upstream' web server process (in our case a
> dumbed-down runserver dev server) only when it detects there have been
> changes.
>
> Been meaning to try this for some time. It would have been much harder
> before Tom Forbes' work on refactoring and cleaning up the reloading code
> for Django 2.2. IMHO Tom's code is so very well thought that for example I
> just had to lightly subclass StatReload to implement this totally different
> strategy.
>
> Current form of the code is a new experimental 'serverrun' (for lack of a
> better name) added to the Django code base whose command line UI mimics
> 100% the runserver one.
>
> It copies code from a few places of our code base: The runserver command,
> the WSGI app hosting code, etc.
>
> I decided to implement this as a new built-in command for now a) to ease
> experimentation and b) because it needs some minor changes to the
> 'runserver' command to handle cosmetic details (logging). If the idea is
> accepted (read further below for reasons in favor of this) then maybe we
> can switch runserver to this code. Or if the idea isn't deemed appropate
> for Django core them I might implement it as an standalone django
> app/project.
>
> If the idea of a smarter stat()-based FS status monitor like this gets
> actually tested and validated in the field (i.e. by users with big source
> code trees) it could allow us to possibly stop needing to depend on all of:
>
> * watchman
> * pyinotify
> * watchdog
> (and removing our support code for them from the Django code base).
>
> Also, this would mean:
>
> * Setup simplification for final users (no third party Python libraries or
> system daemon to install)
> * Better cross-platform portability for Django (we go back to
> piggy-backing stat() from the stdlib as our only way yo trigger code
> reloading).
>
> Additionally, as the reloading is performed fully (by restarting the whole
> HTTP server) and is triggered from another process (the transparent http
> proxy one) we can drop some contortions we currently need to make:
>
> - Having to wait for the app registry stabilization
> - Avoiding race conditions with the url resolver
>
> I suspect there could be power efficiency advantages too as:
>
> * The scanning for changes is triggered by HTTP requests which should be
> less frequent than periodically every N seconds.
> * If the developer modifies more than one file before switching to the
> browser there is need of only one FS scan to cater for all these changes,
> which is performed just in time for the first HTTP request so the code
> executed to render/serve it is 100% accurate in regard to actually
> reflecting the state of the code on disk.
>
> Similar projects include:
> - serveit: https://github.com/garybernhardt/serveit
> - tychus: https://github.com/devlocker/tychus
> - wsgiwatch: https://github.com/dpk/wsgiwatch
>
> Feedback is welcome!
>
> Regards,
>
> --
> Ramiro Morales
> @ramiromorales
>
> --
> 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 post to this group, send email to django-developers@googlegroups.com.
> Visit this group at https://groups.google.com/group/django-developers.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/django-developers/CAO7PdF99hUobeXs8JQyb%3DywDJ6bkkKWyhUYC%3DEa9JzwQM%2BH_5Q%40mail.gmail.com
> 
> .
> For more options, visit https://groups.google.com/d/optout.
>

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

Re: Proposal to format Django using black

[Andrew Godwin]

Hi all,

As per the DEP process, I have merged DEP 8, Formatting Code With Black,
into the DEP repo as a draft. This doesn't mean it's decided yet - any DEP
that meets quality requirements gets merged as a draft - but it means that
we're one step closer to doing so.

What follows is further discussion until it is either revised, withdrawn,
or the author thinks they have enough feedback to put it to the technical
board.

I will draw attention to the following part of DEP 1:

"However, wherever possible, long open-ended discussions on public mailing
lists should be avoided. Strategies to keep the discussions efficient
include: setting up a separate mailing list for the topic, having the DEP
author accept private comments in the early design phases, setting up a
wiki page, etc. DEP authors should use their discretion here"

Given this thread is now over 100 replies long, we might want to consider a
better avenue for constructive feedback.

Andrew

On Tue, Apr 30, 2019 at 12:31 PM Christian González <
christian.gonza...@nerdocs.at> wrote:

>
> Am 30.04.19 um 14:28 schrieb 'Laurens A. Bosscher' via Django developers
> (Contributions to Django itself):
> > The Chrome team fixed this issue with
> > git-hyper-blame:
> https://commondatastorage.googleapis.com/chrome-infra-docs/flat/depot_tools/docs/html/git-hyper-blame.html
> >
> >
> > That could be a solution that would work for Django. IDE support for
> > git-hyper-blame is lacking (at the moment) but might improve in the
> > future.
>
> I made a feature request for git itself, and they told me this is
> already in the works *within* git dev:
>
> https://public-inbox.org/git/20190410162409.117264-1-b...@google.com/
>
> So on the long run, no need for git-hyper-blame.
>
> Christian
>
> --
> Dr. Christian González
> https://nerdocs.at
>
> --
> 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 post to this group, send email to django-developers@googlegroups.com.
> Visit this group at https://groups.google.com/group/django-developers.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/django-developers/74e4842c-24fa-6055-2b1e-d70b42153b69%40nerdocs.at
> .
> For more options, visit https://groups.google.com/d/optout.
>

-- 
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 post to this group, send email to django-developers@googlegroups.com.
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CAFwN1uq0AEP4wL0%3D1xQOF%2BWBVQfGgU5Zfz0V5BurVCbyMeOA3Q%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Deferring "Sign the CLA"

[Tobias McNulty]

I'd be happy to try setting something up, but a quick search didn't turn up
any obvious choices.

In the absence of information to the contrary, I'd hazard a guess that we
still need the CLAs...

Tobias

On Sat, Apr 27, 2019, 1:26 PM Carlton Gibson 
wrote:

>
> On 27 Apr 2019, at 18:51, Florian Apolloner  wrote:
>
> I think the question is if we need those at all. This is something the DSF
> should be able to answer.
>
>
> Ah, you’ve preempted a later question. 🙂
>
> Right now I just wanted to move it down the page.
>
> Maybe some online signing service would be good. (?)
> (Anyone think they could get us setup quickly?)
>
> I mentioned tying it into the Github workflow a while back, but that’s
> probably overkill.
> (We don’t have so many signings that an online service we link to wouldn’t
> be enough, is the thought.)
>
> I’ve asked Frank (DSF president) if the board can discuss whether we still
> need the CLA.
>
> C.
>
> --
> 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 post to this group, send email to django-developers@googlegroups.com.
> Visit this group at https://groups.google.com/group/django-developers.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/django-developers/F70B1E18-7FF7-4985-9906-46D5A4677C11%40gmail.com
> 
> .
> For more options, visit https://groups.google.com/d/optout.
>

-- 
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 post to this group, send email to django-developers@googlegroups.com.
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CAMGFDKQh4Dtk43KWsYNgWP%3DespMw3X0%3Dod5he8%3D%3Ds9oPvP8X-g%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Proposal to format Django using black

[jacob . rief]

Well, this thread is a very good example of Parkinson's law of triviality 
.

––
Jacob

-- 
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 post to this group, send email to django-developers@googlegroups.com.
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/6fe41df0-f071-4958-93c7-fcbb9bba24e2%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: A different approach for the auto-reloader

[Carlton Gibson]

Hi Ramiro. 

I had a quick look at this — it looks great. (And various folks are having 
fun with Watchman, so if the promise delivers it'll be welcome.) 

Do you want to make an actual PR (perhaps with a ticket) so we can get a 
proper review going? 

Thanks for the input, as ever! 🙂

Kind Regards,

Carlton


On Wednesday, 24 April 2019 06:33:50 UTC+2, Ramiro Morales wrote:
>
> Hi all,
>
> I had a stab at a somewhat simpler development server automatic reloading 
> strategy 
> https://github.com/django/django/compare/master...ramiro:synch-reloader
>
> Intention is to test how an implementation of a design by Gary Bernhardt 
> would look. The best written description I could find is this:
>
> https://github.com/devlocker/tychus/issues/3
>
> Gary also had posted some tweets (this is how I got interested in the 
> topic) which seems to have been deleted since then.
>
> Main idea is: Actual checking of changes on the filesystem for modules 
> under monitoring isn't performed in a loop or by depending on a OS kernel 
> feature but per-HTTP request by a front-end proxy process which is in 
> charge of restarting the 'upstream' web server process (in our case a 
> dumbed-down runserver dev server) only when it detects there have been 
> changes. 
>
> Been meaning to try this for some time. It would have been much harder 
> before Tom Forbes' work on refactoring and cleaning up the reloading code 
> for Django 2.2. IMHO Tom's code is so very well thought that for example I 
> just had to lightly subclass StatReload to implement this totally different 
> strategy.
>
> Current form of the code is a new experimental 'serverrun' (for lack of a 
> better name) added to the Django code base whose command line UI mimics 
> 100% the runserver one. 
>
> It copies code from a few places of our code base: The runserver command, 
> the WSGI app hosting code, etc.
>
> I decided to implement this as a new built-in command for now a) to ease 
> experimentation and b) because it needs some minor changes to the 
> 'runserver' command to handle cosmetic details (logging). If the idea is 
> accepted (read further below for reasons in favor of this) then maybe we 
> can switch runserver to this code. Or if the idea isn't deemed appropate 
> for Django core them I might implement it as an standalone django 
> app/project.
>
> If the idea of a smarter stat()-based FS status monitor like this gets 
> actually tested and validated in the field (i.e. by users with big source 
> code trees) it could allow us to possibly stop needing to depend on all of:
>
> * watchman
> * pyinotify
> * watchdog
> (and removing our support code for them from the Django code base).
>
> Also, this would mean:
>
> * Setup simplification for final users (no third party Python libraries or 
> system daemon to install)
> * Better cross-platform portability for Django (we go back to 
> piggy-backing stat() from the stdlib as our only way yo trigger code 
> reloading).
>
> Additionally, as the reloading is performed fully (by restarting the whole 
> HTTP server) and is triggered from another process (the transparent http 
> proxy one) we can drop some contortions we currently need to make:
>
> - Having to wait for the app registry stabilization
> - Avoiding race conditions with the url resolver
>
> I suspect there could be power efficiency advantages too as:
>
> * The scanning for changes is triggered by HTTP requests which should be 
> less frequent than periodically every N seconds.
> * If the developer modifies more than one file before switching to the 
> browser there is need of only one FS scan to cater for all these changes, 
> which is performed just in time for the first HTTP request so the code 
> executed to render/serve it is 100% accurate in regard to actually 
> reflecting the state of the code on disk.
>
> Similar projects include:
> - serveit: https://github.com/garybernhardt/serveit
> - tychus: https://github.com/devlocker/tychus
> - wsgiwatch: https://github.com/dpk/wsgiwatch
>
> Feedback is welcome!
>
> Regards,
>
> -- 
> Ramiro Morales
> @ramiromorales
>

-- 
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 post to this group, send email to django-developers@googlegroups.com.
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/edf0baf4-f6d0-468d-86e3-c4f06d5e82d3%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Proposal to format Django using black

[Aymeric Augustin]

So this thread just passed the 100 message mark... I wish we could redirect 
some of that energy to things that actually matter to end users...

Anyway, I updated DEP 8 to account for all comments made so far. Thanks 
everyone who provided feedback!

-- 
Aymeric.

-- 
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 post to this group, send email to django-developers@googlegroups.com.
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/0F32D990-E59B-4795-967A-5CF436CC6A7F%40polytechnique.org.
For more options, visit https://groups.google.com/d/optout.

Re: Proposal to format Django using black

[Christian González]

Am 30.04.19 um 14:28 schrieb 'Laurens A. Bosscher' via Django developers
(Contributions to Django itself):
> The Chrome team fixed this issue with
> git-hyper-blame: 
> https://commondatastorage.googleapis.com/chrome-infra-docs/flat/depot_tools/docs/html/git-hyper-blame.html
>
>
> That could be a solution that would work for Django. IDE support for
> git-hyper-blame is lacking (at the moment) but might improve in the
> future.

I made a feature request for git itself, and they told me this is
already in the works *within* git dev:

https://public-inbox.org/git/20190410162409.117264-1-b...@google.com/

So on the long run, no need for git-hyper-blame.

Christian

-- 
Dr. Christian González
https://nerdocs.at

-- 
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 post to this group, send email to django-developers@googlegroups.com.
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/74e4842c-24fa-6055-2b1e-d70b42153b69%40nerdocs.at.
For more options, visit https://groups.google.com/d/optout.


pEpkey.asc
Description: application/pgp-keys

Re: Fellow Reports -- April 2019

[Carlton Gibson]

Hi all. 


Calendar Week 17 -- ending 28 April.


Triaged:

https://code.djangoproject.com/ticket/30395 -- Document ModelForm 
specifying field class corresponding to model fields with choices. 
(Accepted)
https://code.djangoproject.com/ticket/30392 -- Onboarding new contibutors 
improvements (needsinfo)
https://code.djangoproject.com/ticket/30348 -- Add superuser_required 
decorator. (Accepted)
https://code.djangoproject.com/ticket/21048 -- Error page should not invoke 
callables passed through WSGI META structure (wontfix)



Reviewed:

https://github.com/django/django/pull/11166 -- Fixed #30312 -- Relaxed 
admin check from django.contrib.sessions to SessionMiddleware subclasses.
https://code.djangoproject.com/ticket/30361 -- Watchman timing out when 
loading server
https://github.com/django/django/pull/11276 -- Fixed #30399 -- Changed 
django.utils.html.escape()/urlize() to use html.escape()/unescape().
https://github.com/django/django/pull/11169 -- Fixed #30318 -- Added check 
for when custom error handler cannot be imported.
https://github.com/django/django/pull/11275 -- Fixed #30362 -- Noted 
partial indexes and constraints restrictions with abstract base classes.
https://github.com/django/django/pull/11228 -- Fixed #30366 -- Fixed 
StatReloaderTests with HFS+ filesystems
https://code.djangoproject.com/ticket/30342 -- Remove the 
LANGUAGES_BIDI<=LANGUAGES check.
https://github.com/django/django/pull/11203 -- Fixed #27086 - Doc'd 
multithreading error while testing on MacOS.
https://github.com/django/django/pull/11165 -- Fixed #30310 -- Added 
support for looking up HttpHeaders.headers using underscores.



Authored:

https://github.com/django/django/pull/11283 -- Fixed #30351 -- Adjusted 
proxy model permission data migration to handle pre-existing permissions.




Calendar Week 18 -- ending 05 May.


(I'm off the rest of the week. May update, but likely not.)


Triaged:

https://code.djangoproject.com/ticket/30372 -- Django (moderately) High CPU 
usage at Idle (needsinfo)
https://code.djangoproject.com/ticket/30398 -- Check database 
connection's health before its reused (Accepted)
https://code.djangoproject.com/ticket/30375 -- Use "NO KEY" when 
doing select_for_update for PostgreSQL (Accepted)
https://code.djangoproject.com/ticket/30416 -- Runserver's reloading 
mechanism should restore terminal state completely (Accepted)
https://code.djangoproject.com/ticket/30411 -- Improve traceback formatting 
in technical 500 text responses (Accepted)
https://code.djangoproject.com/ticket/30415 -- Refactor runtests.py to 
allow using other test runners. (Accepted)
https://code.djangoproject.com/ticket/30424 -- Queries within 
AppConfig.ready() can cause issues with some Django db commands (Invalid)
https://code.djangoproject.com/ticket/30426 -- Make security headers 
default (Accepted)



Reviewed:

https://code.djangoproject.com/ticket/30419 -- Minor improvements for docs 
related to Meta.indexes


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 post to this group, send email to django-developers@googlegroups.com.
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/af822b18-c077-4b4f-a7b5-bf6cf0136641%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Proposal to format Django using black

[J. Pic]

Also note that even for people that don't use an IDE, they might like when
GitHub's blame feature work, so that would also be a pro for rewriting the
git history rather than creating a new commit for the code rewrite.

-- 
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 post to this group, send email to django-developers@googlegroups.com.
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CAC6Op1_5qkcs-44eSM6CxukDnYdq4VmeCYFDvnoFf7EyOTQTxQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: What should i do to build a django app on any linux distro which one can use by one-click install

[Adam Johnson]

This mailing list is for the development of Django itself, not for support
using Django. Please use the django-users mailing list for that, or IRC
#django on freenode, or a site like Stack Overflow.

On Tue, 30 Apr 2019 at 02:29, Meow  wrote:

> It seems appimage can do these, but i don’t know how to do it. Is there
> anyone can help me or give me some advices?
> Thank you.
>
> --
> 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 post to this group, send email to django-developers@googlegroups.com.
> Visit this group at https://groups.google.com/group/django-developers.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/django-developers/88838990-4f50-4c57-90d6-7c9153406c70%40Spark
> 
> .
> For more options, visit https://groups.google.com/d/optout.
>


-- 
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 post to this group, send email to django-developers@googlegroups.com.
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CAMyDDM0cQ30vMhOKX2ggjw_9N4Jspzomp%2BgxSFFvtxpU8vkq6A%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Proposal to format Django using black

['Laurens A. Bosscher' via Django developers (Contributions to Django itself)]

The Chrome team fixed this issue with git-hyper-blame: 
https://commondatastorage.googleapis.com/chrome-infra-docs/flat/depot_tools/docs/html/git-hyper-blame.html

That could be a solution that would work for Django. IDE support for 
git-hyper-blame is lacking (at the moment) but might improve in the future.

Op maandag 29 april 2019 09:12:00 UTC+2 schreef Carlton Gibson:
>
> Hi Alex. 
>
> So I use git blame on Django *a lot: *a new ticket comes in, I have no 
> idea at all how to triage it so I need to look at the history to make a 
> sensible decision. I use git blame to find the commit, to find the original 
> ticket, in which there's a discussion, which 🤞 explains why things are as 
> they are. (Mostly...)
>
> But we're already at the the point where more times than not I need to 
> skip multiple commits to get back to the original decision. 
>
> Look at `master` right now. 
> https://github.com/django/django/commits/master
> (Screenshot attached) 
>
> The last three commits from this morning are all "tidy-ups" that obscure 
> the history. This is typical. Rarely now is there such a old block that 
> hasn't been adjusted at all. So it's normal to have to jump commits. 
>
> A big Black commit will add to this. (It's the concern I do have.) But 
> it's not a game changer. It's just more of the same. I'm pretty sure it's 
> the motivation needed to up my git blame foo to the next level, at which 
> point I'll likely save time ironically. 
>
> For this reason, weighed against the benefits, I don't think the git 
> history should be a blocker. I hope that makes sense. 
>
> 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 post to this group, send email to django-developers@googlegroups.com.
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/54da6b8a-fac4-4229-a124-00822d5626cb%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

What should i do to build a django app on any linux distro which one can use by one-click install

[Meow]

It seems appimage can do these, but i don’t know how to do it. Is there anyone 
can help me or give me some advices?
Thank you.

-- 
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 post to this group, send email to django-developers@googlegroups.com.
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/88838990-4f50-4c57-90d6-7c9153406c70%40Spark.
For more options, visit https://groups.google.com/d/optout.