Re: The blacklist / master issue

[Jure Erznožnik]

+1 on this discussion progression. I too struggled with certain 
expressions in my earlier English-learning days, but today the used 
expressions don't carry any unnecessary baggage for me as my 
understanding of them is purely technical. So, while I myself don't have 
a problem with them, I can see that others might.


I'd also dare to say there shouldn't be much flak to take anyway. The 
cause seems OK, but there is heightened pressure due to recent events. I 
would say this alone is the only thing that I see might be an issue: why 
exactly now?


LP,
Jure

On 15/06/2020 23:31, Aymeric Augustin wrote:

Hello,

In the context of access control, blacklist / whitelist makes sense 
only if the reader has a preconceived assumption that black = bad, 
illegal, forbidden / white = good, legal, authorized. You can probably 
see where I'm going.


Sure, blacklist / whitelist has nothing to do with race to start with, 
but I find the parallel with Apartheid sufficiently obvious to make it 
embarrassing, certainly because I'm not a native English speaker and I 
don't have enough background on what has racial overtones and what 
doesn't.


I mean, I had been living in the US for several months whet someone 
had to tell me the difference between "to screw" and "to screw up". 
(I'm grateful.) Do you really expect a guy like me to know that 
"blackface" has racial overtones but "blacklist" doesn't, and thus 
interpret the words correctly?


Besides, the connection didn't exist in the first place, but when 
people start making it, can we still pretend it doesn't exist? If I 
wanted to troll a linguist, I'd say it's akin to pretending that words 
people actually use don't exist until they're written in a dictionary ;-)


Lastly, another argument for the statu quo is that humans are good at 
interpreting words based on context, so "black" in "blacklist" isn't a 
problem. However, I counter that humans are even better at making 
connections and detecting patterns, even subconsciously and sometimes 
even when the pattern doesn't actually exist. That's quite likely to 
happen here.


I agree that this isn't as clear cut as master / slave. That must be 
why it took us six years to go from the master / slave discussion to 
the blacklist / whitelist discussion.


No one's gonna get confused on the meaning regardless of whether we 
make the change or not. This is "just" a political marker. It doesn't 
have one correct answer. It has several answers whose correctness vary 
over time.


I think we'll make the change at some point. Some progressives will 
hate us for taking so much time. Some conservatives will hate us for 
being snowflakes. Since we already started spending time on this 
discussion, we might just as well do the change while we're there, 
take some flak for a couple days, and move on.


Best regards,

--
Aymeric.

On 15 Jun 2020, at 21:56, Daniele Procida > wrote:


Tom Carrick wrote:


I don't think there is an easy answer here, and I open this can of worms
somewhat reluctantly. I do think Luke is correct that we should be
concerned with our credibility if we wrongly change this, but I'm also
worried about our credibility if we don't.


There are plenty of black-something terms in English that are both 
negative and have nothing whatsoever to do with race. The black and 
the dark are those things that are hidden and sinister, as contrasted 
with those that are in the light and open to scrutiny (black magic, 
dark arts, black legs, blackguards, blackmail, etc).


I think it would look pretty silly to confuse meanings that refer to 
what's shadowy and obscure with things that have racial overtones, 
and I think we should steer well clear of that. It's not at all like 
metaphors such as master/slave.


If we made such a change and tried to justify it on the grounds of a 
connection between race and the word "black" in those terms, we'd be 
rightly laughed at.


1000 neckbeards would immediately come out of the woodwork having 
done some basic web searches going 'neeer neeer neeer, the Django 
Software Foundation overflowing with snowflakes who think that 
"blacklist" means [etc etc etc]', and who has the stomach for that?


Even choosing to do it on the basis of the potential for offence 
seems to be a fairly flimsy argument.


On the other hand, we can do whatever the hell we like.

We don't have to justify anything to anyone. If we want to change 
words in *our* framework, it's absolutely nobody's business but our own.


If black members of the DSF or the community are disheartened that 
the word "black" gets to refer to so many negative things and are 
bothered when they see them in Django, then that alone is sufficient 
justification.


If we want a reason for changing "blacklist" (or whatever), it's that 
people in our community said they would feel better about it and 
asked to have it changed.


Acknowledging how someone feels about something and acting because 
you care about their fee

Re: The blacklist / master issue

[Claude Paroz]

Note that the term "blacklist" only appears twice in the Django tree and 
only in comments/docs, as shown by David's patch. The first one can be 
omitted while the second one can be replaced by "exclude". That is trivial 
to do and shouldn't even require a discussion.

About replacing "whitelist" par "allowlist", I'm not totally convinced but 
will accept any community decision. It has a very small impact change in 
code (in EmailValidator).

Changing git "master" branch names is really looking ridiculous to me, but 
I can understand that it might be linked to cultural sensibilities. This 
will generate many work overhead, for what gain? A "master" is a totally 
valid word in many contexts that have nothing to do with slavery.
We should primarily fight against racism by education and our own 
day-to-day behavior.

Claude

-- 
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/d327c497-18f7-4b50-8b38-93b0c0bea330o%40googlegroups.com.

Re: Overriding template blocks without copy/pasting entire template files

[Carlton Gibson]

Yes! Absolutely. There's even a ticket for that: 
https://code.djangoproject.com/ticket/29336

There was a PR, but we couldn't get it down to size... (Review 
)

On Tuesday, 16 June 2020 08:29:27 UTC+2, Josh Smeaton wrote:
>
> Upon reflection, would you agree that this should be documented a little 
> better? The release notes at the time had a vague deprecation note about `
> supports_recursion` being removed, and the main docs 
> https://docs.djangoproject.com/en/3.0/ref/templates/builtins/#std:templatetag-extends
>  have 
> no such explanation about recursive inheritance either.
>
> I pointed out this thread to a few people in my team, and none of them 
> were aware of this fix/feature, and they were all using 3rd party packages 
> for support.
>
> Funnily enough, 
> https://docs.djangoproject.com/en/3.0/ref/contrib/admin/#overriding-vs-replacing-an-admin-template
>  seems 
> to suggest this was always possible, so I'm quite confused.
>  
>
> On Tuesday, 16 June 2020 15:54:11 UTC+10, Josh Smeaton wrote:
>>
>> Changed 5 years ago 
>> 
>>  by Preston Timmons
>>
>> 🤦‍♀️
>>
>> Thanks Carlton - I guess it has *only* been 5 years though :)
>>
>> On Tuesday, 16 June 2020 15:41:29 UTC+10, Carlton Gibson wrote:
>>>
>>> Hi Josh. 
>>>
>>> This was added in Django 1.9 here 
>>> https://github.com/django/django/commit/fc2147152637e21bc73f991b50fa06254af02739
>>>
>>> It leverages the extends tag, re-using the same template name: 
>>>
>>> # myapp/templates/admin/base.html
>>> {% extends "admin/base.html" %}
>>> {% block footer %}this site is restricted, blah blah legal text blah
>>> {% endblock %}
>>>
>>> So as long as myapp/templates are loaded before contrib.admin's then it 
>>> you should see the result you're after. 
>>>
>>> #15053  references 
>>> django-overextends as the influence. 
>>>
>>>
>>> Kind Regards,
>>>
>>> Carlton
>>>
>>>
>>>
>>> On Tuesday, 16 June 2020 07:03:53 UTC+2, Josh Smeaton wrote:

 Something that has bugged me for awhile is the requirement to copy and 
 paste an entire template when you would just like to override a single 
 block. This arises mostly when overriding admin templates, like 
 `admin/base.html`.

 In my ideal world, I'd be able to do something like this:

 # myapp/templates/admin/base.html
 {% override "admin/base.html" %}
 {% block footer %}this site is restricted, blah blah legal text 
 blah{% endblock %}


 And then the template loading system would find the next 
 `admin/base.html` in the chain and use my overrides.

 There is prior art too. https://pypi.org/project/django-apptemplates/ 
 allows you to override a template from a specific app using this syntax:

 # myapp/templates/admin/base.html
 {% extends "admin:admin/base.html" %}
 {% block footer %}this site is restricted, blah blah legal text 
 blah{% endblock %}


 I think this kind of functionality should be included within Django 
 itself. If others agree, should there be a new name such as override, or 
 would overloading extends be good enough?

>>>

-- 
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/dc4c9fd5-206a-4734-95c7-3c7a2212c015o%40googlegroups.com.

Re: The blacklist / master issue

[Sanskar Jaiswal]

Just my 2 cents on this discussion as a junior contributor. I am very fond
of how inclusive and progressive the Django community is.
With that said, I believe that we shall definitely try to stop using the
term blacklist for “bad/unwanted” things. If this change makes even only a
few contributors, more comfortable, I think we should move forward with the
same.

Thanks
Sanskar

On Tue, 16 Jun 2020 at 12:30, Jure Erznožnik 
wrote:

> +1 on this discussion progression. I too struggled with certain
> expressions in my earlier English-learning days, but today the used
> expressions don't carry any unnecessary baggage for me as my understanding
> of them is purely technical. So, while I myself don't have a problem with
> them, I can see that others might.
>
> I'd also dare to say there shouldn't be much flak to take anyway. The
> cause seems OK, but there is heightened pressure due to recent events. I
> would say this alone is the only thing that I see might be an issue: why
> exactly now?
>
> LP,
> Jure
> On 15/06/2020 23:31, Aymeric Augustin wrote:
>
> Hello,
>
> In the context of access control, blacklist / whitelist makes sense only
> if the reader has a preconceived assumption that black = bad, illegal,
> forbidden / white = good, legal, authorized. You can probably see where I'm
> going.
>
> Sure, blacklist / whitelist has nothing to do with race to start with, but
> I find the parallel with Apartheid sufficiently obvious to make it
> embarrassing, certainly because I'm not a native English speaker and I
> don't have enough background on what has racial overtones and what doesn't.
>
> I mean, I had been living in the US for several months whet someone had to
> tell me the difference between "to screw" and "to screw up". (I'm
> grateful.) Do you really expect a guy like me to know that "blackface" has
> racial overtones but "blacklist" doesn't, and thus interpret the words
> correctly?
>
> Besides, the connection didn't exist in the first place, but when people
> start making it, can we still pretend it doesn't exist? If I wanted to
> troll a linguist, I'd say it's akin to pretending that words people
> actually use don't exist until they're written in a dictionary ;-)
>
> Lastly, another argument for the statu quo is that humans are good at
> interpreting words based on context, so "black" in "blacklist" isn't a
> problem. However, I counter that humans are even better at making
> connections and detecting patterns, even subconsciously and sometimes even
> when the pattern doesn't actually exist. That's quite likely to happen here.
>
> I agree that this isn't as clear cut as master / slave. That must be why
> it took us six years to go from the master / slave discussion to the
> blacklist / whitelist discussion.
>
> No one's gonna get confused on the meaning regardless of whether we make
> the change or not. This is "just" a political marker. It doesn't have one
> correct answer. It has several answers whose correctness vary over time.
>
> I think we'll make the change at some point. Some progressives will hate
> us for taking so much time. Some conservatives will hate us for being
> snowflakes. Since we already started spending time on this discussion, we
> might just as well do the change while we're there, take some flak for a
> couple days, and move on.
>
> Best regards,
>
> --
> Aymeric.
>
> On 15 Jun 2020, at 21:56, Daniele Procida  wrote:
>
> Tom Carrick wrote:
>
> I don't think there is an easy answer here, and I open this can of worms
> somewhat reluctantly. I do think Luke is correct that we should be
> concerned with our credibility if we wrongly change this, but I'm also
> worried about our credibility if we don't.
>
>
> There are plenty of black-something terms in English that are both
> negative and have nothing whatsoever to do with race. The black and the
> dark are those things that are hidden and sinister, as contrasted with
> those that are in the light and open to scrutiny (black magic, dark arts,
> black legs, blackguards, blackmail, etc).
>
> I think it would look pretty silly to confuse meanings that refer to
> what's shadowy and obscure with things that have racial overtones, and I
> think we should steer well clear of that. It's not at all like metaphors
> such as master/slave.
>
> If we made such a change and tried to justify it on the grounds of a
> connection between race and the word "black" in those terms, we'd be
> rightly laughed at.
>
> 1000 neckbeards would immediately come out of the woodwork having done
> some basic web searches going 'neeer neeer neeer, the Django Software
> Foundation overflowing with snowflakes who think that "blacklist" means
> [etc etc etc]', and who has the stomach for that?
>
> Even choosing to do it on the basis of the potential for offence seems to
> be a fairly flimsy argument.
>
> On the other hand, we can do whatever the hell we like.
>
> We don't have to justify anything to anyone. If we want to change words in
> *our* framework, it's absolu

Re: The blacklist / master issue

[Fran Hrženjak]

Meaning "owner of slaves" is only one of many meanings of the word, and not
its primary meaning:

https://dictionary.cambridge.org/dictionary/english/master
https://www.merriam-webster.com/dictionary/master

Renaming the master branch would mean we agree that this one meaning is
somehow more important and should be elevated above all other meanings.
Even though some of those other meanings apply much more closely in the
case of git branches:

> "having chief authority, dominant"
> "an original from which copies can be made"

To me this looks like a final revenge of the slavers. They are all long
dead and gone, their social order destroyed and condemned as it should be,
and yet here we are in 2020 giving up useful words as if only the savers'
use was correct and the rest of us were wrong ever since.

Master/slave database, that is (was) a completely different argument. But
please let's keep the master branch.

Even if the change is simple for Django and for its users, somebody made a
great point recently (on another topic here) that we cannot change the
internet. There are numerous references to "master" out there which will
become obsolete and a tripping stone for newcomers.

-0 from me.

 * What about everyones' master's degrees?
 * If a dog can have a master, then surely git branches can have a master
branch.
 * Rembrandt was a master painter.
 * Related words: masterpiece, masterful, mastery, remastered (movies),
mistress...

-- 
Fran


On Tue, 16 Jun 2020 at 09:10, Sanskar Jaiswal 
wrote:

> Just my 2 cents on this discussion as a junior contributor. I am very fond
> of how inclusive and progressive the Django community is.
> With that said, I believe that we shall definitely try to stop using the
> term blacklist for “bad/unwanted” things. If this change makes even only a
> few contributors, more comfortable, I think we should move forward with the
> same.
>
> Thanks
> Sanskar
>
> On Tue, 16 Jun 2020 at 12:30, Jure Erznožnik 
> wrote:
>
>> +1 on this discussion progression. I too struggled with certain
>> expressions in my earlier English-learning days, but today the used
>> expressions don't carry any unnecessary baggage for me as my understanding
>> of them is purely technical. So, while I myself don't have a problem with
>> them, I can see that others might.
>>
>> I'd also dare to say there shouldn't be much flak to take anyway. The
>> cause seems OK, but there is heightened pressure due to recent events. I
>> would say this alone is the only thing that I see might be an issue: why
>> exactly now?
>>
>> LP,
>> Jure
>> On 15/06/2020 23:31, Aymeric Augustin wrote:
>>
>> Hello,
>>
>> In the context of access control, blacklist / whitelist makes sense only
>> if the reader has a preconceived assumption that black = bad, illegal,
>> forbidden / white = good, legal, authorized. You can probably see where I'm
>> going.
>>
>> Sure, blacklist / whitelist has nothing to do with race to start with,
>> but I find the parallel with Apartheid sufficiently obvious to make it
>> embarrassing, certainly because I'm not a native English speaker and I
>> don't have enough background on what has racial overtones and what doesn't.
>>
>> I mean, I had been living in the US for several months whet someone had
>> to tell me the difference between "to screw" and "to screw up". (I'm
>> grateful.) Do you really expect a guy like me to know that "blackface" has
>> racial overtones but "blacklist" doesn't, and thus interpret the words
>> correctly?
>>
>> Besides, the connection didn't exist in the first place, but when people
>> start making it, can we still pretend it doesn't exist? If I wanted to
>> troll a linguist, I'd say it's akin to pretending that words people
>> actually use don't exist until they're written in a dictionary ;-)
>>
>> Lastly, another argument for the statu quo is that humans are good at
>> interpreting words based on context, so "black" in "blacklist" isn't a
>> problem. However, I counter that humans are even better at making
>> connections and detecting patterns, even subconsciously and sometimes even
>> when the pattern doesn't actually exist. That's quite likely to happen here.
>>
>> I agree that this isn't as clear cut as master / slave. That must be why
>> it took us six years to go from the master / slave discussion to the
>> blacklist / whitelist discussion.
>>
>> No one's gonna get confused on the meaning regardless of whether we make
>> the change or not. This is "just" a political marker. It doesn't have one
>> correct answer. It has several answers whose correctness vary over time.
>>
>> I think we'll make the change at some point. Some progressives will hate
>> us for taking so much time. Some conservatives will hate us for being
>> snowflakes. Since we already started spending time on this discussion, we
>> might just as well do the change while we're there, take some flak for a
>> couple days, and move on.
>>
>> Best regards,
>>
>> --
>> Aymeric.
>>
>> On 15 Jun 2020, at 21:56, Daniele P

Re: The blacklist / master issue

[Kye Russell]

Git’s default branch name is a bit of a misnomer, however it refers to a
master-slave relationship:
https://mail.gnome.org/archives/desktop-devel-list/2019-May/msg00066.html

Kye


On 16 June 2020 at 4:24:32 pm, Fran Hrženjak (fran.hrzen...@gmail.com)
wrote:

Meaning "owner of slaves" is only one of many meanings of the word, and not
its primary meaning:

https://dictionary.cambridge.org/dictionary/english/master
https://www.merriam-webster.com/dictionary/master

Renaming the master branch would mean we agree that this one meaning is
somehow more important and should be elevated above all other meanings.
Even though some of those other meanings apply much more closely in the
case of git branches:

> "having chief authority, dominant"
> "an original from which copies can be made"

To me this looks like a final revenge of the slavers. They are all long
dead and gone, their social order destroyed and condemned as it should be,
and yet here we are in 2020 giving up useful words as if only the savers'
use was correct and the rest of us were wrong ever since.

Master/slave database, that is (was) a completely different argument. But
please let's keep the master branch.

Even if the change is simple for Django and for its users, somebody made a
great point recently (on another topic here) that we cannot change the
internet. There are numerous references to "master" out there which will
become obsolete and a tripping stone for newcomers.

-0 from me.

 * What about everyones' master's degrees?
 * If a dog can have a master, then surely git branches can have a master
branch.
 * Rembrandt was a master painter.
 * Related words: masterpiece, masterful, mastery, remastered (movies),
mistress...

-- 
Fran


On Tue, 16 Jun 2020 at 09:10, Sanskar Jaiswal 
wrote:

> Just my 2 cents on this discussion as a junior contributor. I am very fond
> of how inclusive and progressive the Django community is.
> With that said, I believe that we shall definitely try to stop using the
> term blacklist for “bad/unwanted” things. If this change makes even only a
> few contributors, more comfortable, I think we should move forward with the
> same.
>
> Thanks
> Sanskar
>
> On Tue, 16 Jun 2020 at 12:30, Jure Erznožnik 
> wrote:
>
>> +1 on this discussion progression. I too struggled with certain
>> expressions in my earlier English-learning days, but today the used
>> expressions don't carry any unnecessary baggage for me as my understanding
>> of them is purely technical. So, while I myself don't have a problem with
>> them, I can see that others might.
>>
>> I'd also dare to say there shouldn't be much flak to take anyway. The
>> cause seems OK, but there is heightened pressure due to recent events. I
>> would say this alone is the only thing that I see might be an issue: why
>> exactly now?
>>
>> LP,
>> Jure
>> On 15/06/2020 23:31, Aymeric Augustin wrote:
>>
>> Hello,
>>
>> In the context of access control, blacklist / whitelist makes sense only
>> if the reader has a preconceived assumption that black = bad, illegal,
>> forbidden / white = good, legal, authorized. You can probably see where I'm
>> going.
>>
>> Sure, blacklist / whitelist has nothing to do with race to start with,
>> but I find the parallel with Apartheid sufficiently obvious to make it
>> embarrassing, certainly because I'm not a native English speaker and I
>> don't have enough background on what has racial overtones and what doesn't.
>>
>> I mean, I had been living in the US for several months whet someone had
>> to tell me the difference between "to screw" and "to screw up". (I'm
>> grateful.) Do you really expect a guy like me to know that "blackface" has
>> racial overtones but "blacklist" doesn't, and thus interpret the words
>> correctly?
>>
>> Besides, the connection didn't exist in the first place, but when people
>> start making it, can we still pretend it doesn't exist? If I wanted to
>> troll a linguist, I'd say it's akin to pretending that words people
>> actually use don't exist until they're written in a dictionary ;-)
>>
>> Lastly, another argument for the statu quo is that humans are good at
>> interpreting words based on context, so "black" in "blacklist" isn't a
>> problem. However, I counter that humans are even better at making
>> connections and detecting patterns, even subconsciously and sometimes even
>> when the pattern doesn't actually exist. That's quite likely to happen here.
>>
>> I agree that this isn't as clear cut as master / slave. That must be why
>> it took us six years to go from the master / slave discussion to the
>> blacklist / whitelist discussion.
>>
>> No one's gonna get confused on the meaning regardless of whether we make
>> the change or not. This is "just" a political marker. It doesn't have one
>> correct answer. It has several answers whose correctness vary over time.
>>
>> I think we'll make the change at some point. Some progressives will hate
>> us for taking so much time. Some conservatives will hate us for being
>> s

What's wrong with the jenkins testrun failing on ASGI (I think?)

[Florian Apolloner]

Hi,

do we have any idea what is happening on 
https://djangoci.com/job/pr-mariadb/database=mysql,label=mariadb,python=python3.8/6459/
 
? It seems as if (mostly) the same set of tests is failing over and over. 
Is this ASGI/concurrency related?

Cheers,
Florian

-- 
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/69e9c9a2-7945-4a5f-96e2-e1f594f773ebo%40googlegroups.com.

Re: What's wrong with the jenkins testrun failing on ASGI (I think?)

[Mariusz Felisiak]

It's an issue with the asgiref==3.2.8, see 
https://github.com/django/asgiref/issues/170. We temporarily pinned 
asgiref==3.2.7 [1].

Best,
Mariusz

[1] 
https://github.com/django/django/commit/dcb4d79ef719d824431a8b3ff8ada879bbab21cc

-- 
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/202a42db-3a59-45b7-8e6b-a9025fae714do%40googlegroups.com.

Re: What's wrong with the jenkins testrun failing on ASGI (I think?)

[Florian Apolloner]

Ok, so rebasing PRs to current master will fix this (leaving this here as 
note for others who run into this).

On Tuesday, June 16, 2020 at 10:39:13 AM UTC+2, Mariusz Felisiak wrote:
>
> It's an issue with the asgiref==3.2.8, see 
> https://github.com/django/asgiref/issues/170. We temporarily pinned 
> asgiref==3.2.7 [1].
>
> Best,
> Mariusz
>
> [1] 
> https://github.com/django/django/commit/dcb4d79ef719d824431a8b3ff8ada879bbab21cc
>

-- 
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/c775e1a0-9485-46da-b4d9-015e8ee019b9o%40googlegroups.com.

Re: The blacklist / master issue

[Jorge Gimeno]

I would suggest that this a relatively small change that would provide the 
community with a large return in being more inclusive.

-Jorge

On Monday, June 15, 2020 at 9:28:23 AM UTC-7, Tom Carrick wrote:
>
> This ticket was closed wontfix 
>  as requiring a 
> discussion here.
>
> David Smith mentioned this Tox issue 
>  stating it had been closed, 
> but to me it seems like it hasn't been closed (maybe there's something I 
> can't see) and apparently a PR would be accepted to add aliases at the 
> least (this is more recent than the comment on the Django ticket).
>
> My impetus to bring this up mostly comes from reading this ZDNet article 
> 
>  
> - it seems like Google have already made moves in this direction and GitHub 
> is also planning to. Usually Django is somewhere near the front for these 
> types of changes.
>
> I'm leaning towards renaming the master branch and wherever else we use 
> that terminology, but I'm less sure about black/whitelist, though right now 
> it seems more positive than negative. Most arguments against use some kind 
> of etymological argument, but I don't think debates about historical terms 
> are as interesting as how they affect people in the here and now.
>
> I don't think there is an easy answer here, and I open this can of worms 
> somewhat reluctantly. I do think Luke is correct that we should be 
> concerned with our credibility if we wrongly change this, but I'm also 
> worried about our credibility if we don't.
>

-- 
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/ee566c2b-28c5-4845-ba94-9f9c4fe5c035o%40googlegroups.com.

Re: Overriding template blocks without copy/pasting entire template files

[Arvind Nedumaran]

Could you elaborate on how this is different from extending a base template
and re-defining the necessary blocks?

#base.html
{% block title %}{{ section.title }}{% endblock %}
.

{% extends "base.html" %}{% block title %} My custom title that isn't
section.title {% endblock %}


This much is already possible right?


On Tue, Jun 16, 2020 at 10:34 AM Josh Smeaton 
wrote:

> Something that has bugged me for awhile is the requirement to copy and
> paste an entire template when you would just like to override a single
> block. This arises mostly when overriding admin templates, like
> `admin/base.html`.
>
> In my ideal world, I'd be able to do something like this:
>
> # myapp/templates/admin/base.html
> {% override "admin/base.html" %}
> {% block footer %}this site is restricted, blah blah legal text blah{%
> endblock %}
>
>
> And then the template loading system would find the next `admin/base.html`
> in the chain and use my overrides.
>
> There is prior art too. https://pypi.org/project/django-apptemplates/
> allows you to override a template from a specific app using this syntax:
>
> # myapp/templates/admin/base.html
> {% extends "admin:admin/base.html" %}
> {% block footer %}this site is restricted, blah blah legal text blah{%
>  endblock %}
>
>
> I think this kind of functionality should be included within Django
> itself. If others agree, should there be a new name such as override, or
> would overloading extends be good enough?
>
> --
> 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/6cf43971-1ea9-4b93-9a35-aaab5908327co%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/CAF_6RoMTbiq4S9qFBL1qU4B_KcJU%3DveP2%3D%2BMaT0%3D1Uxee%2BiEAQ%40mail.gmail.com.

Re: Proposal - Warn user when creating or applying a delete migration?

[sourav tiwari]

I m in search of job Can any one help me to find out a job

On Tue, 16 Jun 2020, 12:00 Carlton Gibson,  wrote:

> Looking at the proposed ticket here #31700
> , I'm *Meh* at best:
>
> * - + ~
> * Green, yellow, red
>
> I'm not sure I want to look at either of those. Visual noise for X
> benefit, where I think X is likely very small.
> Not sure it's worth the complication.
>
> I'll close as needsinfo. If there's a lot of +1s here then we can reopen
> and accept.
>
> Thanks.
> C.
>
> On Friday, 12 June 2020 13:57:06 UTC+2, Tom Forbes wrote:
>>
>> However we could make the `makemigrations` output more noticeable if it
>> contains destructive operations? We could make the this line[1] output red
>> text on destructive operations, yellow on maybe destructive (like altering
>> a type), and green on safe operations?
>>
>> 1.
>> https://github.com/django/django/blob/master/django/core/management/commands/makemigrations.py#L216
>>
>> --
> 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/91028857-8ef6-42cc-991c-3c092370341co%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/CAPzZG3shAjR-pOFd7VSLbTQhHcAT_57fhjY6PZfWArwU-Ti-mg%40mail.gmail.com.

Re: Proposal - Warn user when creating or applying a delete migration?

[Tobias McNulty]

I'm +1 to doing *something.* Absent a louder reminder, I think it's
unrealistic to expect everyone to read the output of makemigrations all the
time.

As others have said, I'm not sure `manage.py migrate` is the right time. I
think it's too late. The code may have already been committed, who knows
what machine the migrations are being run on, etc.

During makemigrations, on the other hand, I don't see anything wrong with
formatted text or +/-, but I might go a step further. We already prompt for
things like renames and merges. Why not forcibly gain user acceptance
before creating a migration that deletes something? We could repeat the
reminder to double check it or allow the user to cancel the migration
altogether, for example:

"You are creating a migration that DELETES one or more columns or database
tables. As with any migration, if you continue, you should inspect the
created migration BEFORE running `manage.py migrate` to ensure it does what
you expect. Press Y to continue or N to cancel." (needs copyediting of
course)

It would be easy enough to bypass with --no-input if someone doesn't want
the interruption.

Cheers,


*Tobias McNulty*Chief Executive Officer

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


On Tue, Jun 16, 2020 at 2:30 AM Carlton Gibson 
wrote:

> Looking at the proposed ticket here #31700
> , I'm *Meh* at best:
>
> * - + ~
> * Green, yellow, red
>
> I'm not sure I want to look at either of those. Visual noise for X
> benefit, where I think X is likely very small.
> Not sure it's worth the complication.
>
> I'll close as needsinfo. If there's a lot of +1s here then we can reopen
> and accept.
>
> Thanks.
> C.
>
> On Friday, 12 June 2020 13:57:06 UTC+2, Tom Forbes wrote:
>>
>> However we could make the `makemigrations` output more noticeable if it
>> contains destructive operations? We could make the this line[1] output red
>> text on destructive operations, yellow on maybe destructive (like altering
>> a type), and green on safe operations?
>>
>> 1.
>> https://github.com/django/django/blob/master/django/core/management/commands/makemigrations.py#L216
>>
>> --
> 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/91028857-8ef6-42cc-991c-3c092370341co%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/CAMGFDKQ8chsk0OVq9OVvx0BqspR7Phs8qePkSNW7V2oSXboZPQ%40mail.gmail.com.

Re: Overriding template blocks without copy/pasting entire template files

[Florian Apolloner]

If you look at the mails beyond the first one, you will see that Josh & 
Carlton already came to that conlusion ;)

On Tuesday, June 16, 2020 at 2:16:31 PM UTC+2, Arvind Nedumaran wrote:
>
> Could you elaborate on how this is different from extending a base 
> template and re-defining the necessary blocks? 
>
> #base.html
> {% block title %}{{ section.title }}{% endblock %}
> . 
>
> {% extends "base.html" %}{% block title %} My custom title that isn't 
> section.title {% endblock %}
> 
>
> This much is already possible right? 
>
>
> On Tue, Jun 16, 2020 at 10:34 AM Josh Smeaton  > wrote:
>
>> Something that has bugged me for awhile is the requirement to copy and 
>> paste an entire template when you would just like to override a single 
>> block. This arises mostly when overriding admin templates, like 
>> `admin/base.html`.
>>
>> In my ideal world, I'd be able to do something like this:
>>
>> # myapp/templates/admin/base.html
>> {% override "admin/base.html" %}
>> {% block footer %}this site is restricted, blah blah legal text blah
>> {% endblock %}
>>
>>
>> And then the template loading system would find the next 
>> `admin/base.html` in the chain and use my overrides.
>>
>> There is prior art too. https://pypi.org/project/django-apptemplates/ 
>> allows you to override a template from a specific app using this syntax:
>>
>> # myapp/templates/admin/base.html
>> {% extends "admin:admin/base.html" %}
>> {% block footer %}this site is restricted, blah blah legal text blah
>> {% endblock %}
>>
>>
>> I think this kind of functionality should be included within Django 
>> itself. If others agree, should there be a new name such as override, or 
>> would overloading extends be good enough?
>>
>> -- 
>> 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-d...@googlegroups.com .
>> To view this discussion on the web visit 
>> https://groups.google.com/d/msgid/django-developers/6cf43971-1ea9-4b93-9a35-aaab5908327co%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/89b8d89a-d7e4-44fa-a5b8-cb8e1c910785o%40googlegroups.com.

Re: Proposal - Warn user when creating or applying a delete migration?

[René Fleschenberg]

Hi,

During makemigrations, on the other hand, I don't see anything wrong 
with formatted text or +/-, but I might go a step further. 


This sounds like a good idea to me. It would break cases where 
makemigrations is run non-interactively, which might be a good thing. 
It's a common mistake to run makemigrations && migrate on deployment 
instead of committing the migrations to version control.


Regards,
René

--
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/c43e301d-5bf8-3ff5-34c6-fd199fb09682%40fleschenberg.net.

Re: Overriding template blocks without copy/pasting entire template files

[Arvind Nedumaran]

Something must be faulty with my email delivery I suppose. I sent that email a 
good 8 hours ago. :)

Onward,
Arvind

Sent from Outlook Mobile


From: django-developers@googlegroups.com  
on behalf of Florian Apolloner 
Sent: Tuesday, June 16, 2020 6:46:45 PM
To: Django developers (Contributions to Django itself) 

Subject: Re: Overriding template blocks without copy/pasting entire template 
files

If you look at the mails beyond the first one, you will see that Josh & Carlton 
already came to that conlusion ;)

On Tuesday, June 16, 2020 at 2:16:31 PM UTC+2, Arvind Nedumaran wrote:
Could you elaborate on how this is different from extending a base template and 
re-defining the necessary blocks?

#base.html
{% block title %}{{ section.title }}{% endblock %}
.

{% extends "base.html" %}
{% block title %} My custom title that isn't section.title {% endblock %}


This much is already possible right?


On Tue, Jun 16, 2020 at 10:34 AM Josh Smeaton  wrote:
Something that has bugged me for awhile is the requirement to copy and paste an 
entire template when you would just like to override a single block. This 
arises mostly when overriding admin templates, like `admin/base.html`.

In my ideal world, I'd be able to do something like this:

# myapp/templates/admin/base.html
{% override "admin/base.html" %}
{% block footer %}this site is restricted, blah blah legal text blah{% 
endblock %}


And then the template loading system would find the next `admin/base.html` in 
the chain and use my overrides.

There is prior art too. https://pypi.org/project/django-apptemplates/ allows 
you to override a template from a specific app using this syntax:

# myapp/templates/admin/base.html
{% extends "admin:admin/base.html" %}
{% block footer %}this site is restricted, blah blah legal text blah{% 
endblock %}


I think this kind of functionality should be included within Django itself. If 
others agree, should there be a new name such as override, or would overloading 
extends be good enough?

--
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-d...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/6cf43971-1ea9-4b93-9a35-aaab5908327co%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/89b8d89a-d7e4-44fa-a5b8-cb8e1c910785o%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/BYAPR14MB2918A6E0935FE4DABCD96991A39D0%40BYAPR14MB2918.namprd14.prod.outlook.com.

Re: The blacklist / master issue

[אורי]

I think *master* is the default branch name in any Git repository. It's not
about Django and even not GitHub. Do you want to change the default branch
name in Git?
אורי
u...@speedy.net


On Mon, Jun 15, 2020 at 7:28 PM Tom Carrick  wrote:

> This ticket was closed wontfix
>  as requiring a
> discussion here.
>
> David Smith mentioned this Tox issue
>  stating it had been closed,
> but to me it seems like it hasn't been closed (maybe there's something I
> can't see) and apparently a PR would be accepted to add aliases at the
> least (this is more recent than the comment on the Django ticket).
>
> My impetus to bring this up mostly comes from reading this ZDNet article
> 
> - it seems like Google have already made moves in this direction and GitHub
> is also planning to. Usually Django is somewhere near the front for these
> types of changes.
>
> I'm leaning towards renaming the master branch and wherever else we use
> that terminology, but I'm less sure about black/whitelist, though right now
> it seems more positive than negative. Most arguments against use some kind
> of etymological argument, but I don't think debates about historical terms
> are as interesting as how they affect people in the here and now.
>
> I don't think there is an easy answer here, and I open this can of worms
> somewhat reluctantly. I do think Luke is correct that we should be
> concerned with our credibility if we wrongly change this, but I'm also
> worried about our credibility if we don't.
>
> --
> 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/CAHoz%3DMZrOAQ94Whn0PpDa%2BuJzGSs%3DWAWHbO0nn8rc0D94uUAcw%40mail.gmail.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/CABD5YeH3ixuxTqBvB6FdLzimDbB4D5uGHKEawwjvqXVHU%3DcvKg%40mail.gmail.com.

Re: The blacklist / master issue

[Arvind Nedumaran]

The "default" is name is just a convention. It can be other things and after a 
few days of "teething" issues, and everyone will be back to being as productive 
as they are right now.

Sent from Outlook Mobile


From: django-developers@googlegroups.com  
on behalf of אורי 
Sent: Tuesday, June 16, 2020 7:05:19 PM
To: Django developers (Contributions to Django itself) 

Subject: Re: The blacklist / master issue

I think master is the default branch name in any Git repository. It's not about 
Django and even not GitHub. Do you want to change the default branch name in 
Git?
אורי
u...@speedy.net


On Mon, Jun 15, 2020 at 7:28 PM Tom Carrick 
mailto:t...@carrick.eu>> wrote:
This ticket was closed 
wontfix as requiring a 
discussion here.

David Smith mentioned this Tox 
issue stating it had been closed, 
but to me it seems like it hasn't been closed (maybe there's something I can't 
see) and apparently a PR would be accepted to add aliases at the least (this is 
more recent than the comment on the Django ticket).

My impetus to bring this up mostly comes from reading this ZDNet 
article
 - it seems like Google have already made moves in this direction and GitHub is 
also planning to. Usually Django is somewhere near the front for these types of 
changes.

I'm leaning towards renaming the master branch and wherever else we use that 
terminology, but I'm less sure about black/whitelist, though right now it seems 
more positive than negative. Most arguments against use some kind of 
etymological argument, but I don't think debates about historical terms are as 
interesting as how they affect people in the here and now.

I don't think there is an easy answer here, and I open this can of worms 
somewhat reluctantly. I do think Luke is correct that we should be concerned 
with our credibility if we wrongly change this, but I'm also worried about our 
credibility if we don't.

--
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/CAHoz%3DMZrOAQ94Whn0PpDa%2BuJzGSs%3DWAWHbO0nn8rc0D94uUAcw%40mail.gmail.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/CABD5YeH3ixuxTqBvB6FdLzimDbB4D5uGHKEawwjvqXVHU%3DcvKg%40mail.gmail.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/BYAPR14MB2918D1D9008D787BC2AF1F95A39D0%40BYAPR14MB2918.namprd14.prod.outlook.com.

Re: The blacklist / master issue

[Roger Gammans]

Funny you should say that but the git developers mailing list in is
awash with patches and shouting about just this at the moment.
It looks likely the patches will go in too -  so that's not much of an
arguement against.

On Tue, 2020-06-16 at 16:35 +0300, אורי wrote:
> I think master is the default branch name in any Git repository. It's
> not about Django and even not GitHub. Do you want to change the
> default branch name in Git?
> אורי
> u...@speedy.net
> 
> On Mon, Jun 15, 2020 at 7:28 PM Tom Carrick  wrote:
> > This ticket was closed wontfix as requiring a discussion here.
> > 
> > David Smith mentioned this Tox issue stating it had been closed,
> > but to me it seems like it hasn't been closed (maybe there's
> > something I can't see) and apparently a PR would be accepted to add
> > aliases at the least (this is more recent than the comment on the
> > Django ticket).
> > 
> >  My impetus to bring this up mostly comes from reading this ZDNet
> > article - it seems like Google have already made moves in this
> > direction and GitHub is also planning to. Usually Django is
> > somewhere near the front for these types of changes.
> > 
> > I'm leaning towards renaming the master branch and wherever else we
> > use that terminology, but I'm less sure about black/whitelist,
> > though right now it seems more positive than negative. Most
> > arguments against use some kind of etymological argument, but I
> > don't think debates about historical terms are as interesting as
> > how they affect people in the here and now.
> > 
> > I don't think there is an easy answer here, and I open this can of
> > worms somewhat reluctantly. I do think Luke is correct that we
> > should be concerned with our credibility if we wrongly change this,
> > but I'm also worried about our credibility if we don't.
> > 
> > 
> > 

-- 
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/1b47e74f1811390add42c91dab4ccea104b89fcf.camel%40gammascience.co.uk.

Re: Overriding template blocks without copy/pasting entire template files

[Florian Apolloner]

Ah, might be that you got hold up in a moderation queue or similar. Google 
groups is weird sometimes -- sorry!

On Tuesday, June 16, 2020 at 3:20:25 PM UTC+2, Arvind Nedumaran wrote:
>
> Something must be faulty with my email delivery I suppose. I sent that 
> email a good 8 hours ago. :) 
>
> Onward, 
> Arvind 
>
> Sent from Outlook Mobile 
>
> --
> *From:* django-d...@googlegroups.com  <
> django-d...@googlegroups.com > on behalf of Florian 
> Apolloner >
> *Sent:* Tuesday, June 16, 2020 6:46:45 PM
> *To:* Django developers (Contributions to Django itself) <
> django-d...@googlegroups.com >
> *Subject:* Re: Overriding template blocks without copy/pasting entire 
> template files 
>  
> If you look at the mails beyond the first one, you will see that Josh & 
> Carlton already came to that conlusion ;)
>
> On Tuesday, June 16, 2020 at 2:16:31 PM UTC+2, Arvind Nedumaran wrote: 
>
> Could you elaborate on how this is different from extending a base 
> template and re-defining the necessary blocks? 
>
> #base.html
> {% block title %}{{ section.title }}{% endblock %}
> . 
>
> {% extends "base.html" %}{% block title %} My custom title that isn't 
> section.title {% endblock %}
> 
>
> This much is already possible right? 
>
>
> On Tue, Jun 16, 2020 at 10:34 AM Josh Smeaton  wrote:
>
> Something that has bugged me for awhile is the requirement to copy and 
> paste an entire template when you would just like to override a single 
> block. This arises mostly when overriding admin templates, like 
> `admin/base.html`.
>
> In my ideal world, I'd be able to do something like this:
>
> # myapp/templates/admin/base.html
> {% override "admin/base.html" %}
> {% block footer %}this site is restricted, blah blah legal text blah{% 
> endblock %}
>
>
> And then the template loading system would find the next `admin/base.html` 
> in the chain and use my overrides.
>
> There is prior art too. https://pypi.org/project/django-apptemplates/ 
> allows you to override a template from a specific app using this syntax:
>
> # myapp/templates/admin/base.html
> {% extends "admin:admin/base.html" %}
> {% block footer %}this site is restricted, blah blah legal text blah{%
>  endblock %}
>
>
> I think this kind of functionality should be included within Django 
> itself. If others agree, should there be a new name such as override, or 
> would overloading extends be good enough?
>
> -- 
> 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-d...@googlegroups.com.
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/django-developers/6cf43971-1ea9-4b93-9a35-aaab5908327co%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-d...@googlegroups.com .
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/django-developers/89b8d89a-d7e4-44fa-a5b8-cb8e1c910785o%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/a357fb57-55b3-4f65-bf59-cf64c3e412bbo%40googlegroups.com.

Re: Overriding template blocks without copy/pasting entire template files

[Arvind Nedumaran]

No worries 👍

Sent from Outlook Mobile


From: django-developers@googlegroups.com  
on behalf of Florian Apolloner 
Sent: Tuesday, June 16, 2020 7:40:56 PM
To: Django developers (Contributions to Django itself) 

Subject: Re: Overriding template blocks without copy/pasting entire template 
files

Ah, might be that you got hold up in a moderation queue or similar. Google 
groups is weird sometimes -- sorry!

On Tuesday, June 16, 2020 at 3:20:25 PM UTC+2, Arvind Nedumaran wrote:
Something must be faulty with my email delivery I suppose. I sent that email a 
good 8 hours ago. :)

Onward,
Arvind

Sent from Outlook Mobile


From: django-d...@googlegroups.com  on behalf of 
Florian Apolloner 
Sent: Tuesday, June 16, 2020 6:46:45 PM
To: Django developers (Contributions to Django itself) 

Subject: Re: Overriding template blocks without copy/pasting entire template 
files

If you look at the mails beyond the first one, you will see that Josh & Carlton 
already came to that conlusion ;)

On Tuesday, June 16, 2020 at 2:16:31 PM UTC+2, Arvind Nedumaran wrote:
Could you elaborate on how this is different from extending a base template and 
re-defining the necessary blocks?

#base.html
{% block title %}{{ section.title }}{% endblock %}
.

{% extends "base.html" %}
{% block title %} My custom title that isn't section.title {% endblock %}


This much is already possible right?


On Tue, Jun 16, 2020 at 10:34 AM Josh Smeaton  wrote:
Something that has bugged me for awhile is the requirement to copy and paste an 
entire template when you would just like to override a single block. This 
arises mostly when overriding admin templates, like `admin/base.html`.

In my ideal world, I'd be able to do something like this:

# myapp/templates/admin/base.html
{% override "admin/base.html" %}
{% block footer %}this site is restricted, blah blah legal text blah{% 
endblock %}


And then the template loading system would find the next `admin/base.html` in 
the chain and use my overrides.

There is prior art too. https://pypi.org/project/django-apptemplates/ allows 
you to override a template from a specific app using this syntax:

# myapp/templates/admin/base.html
{% extends "admin:admin/base.html" %}
{% block footer %}this site is restricted, blah blah legal text blah{% 
endblock %}


I think this kind of functionality should be included within Django itself. If 
others agree, should there be a new name such as override, or would overloading 
extends be good enough?

--
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-d...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/6cf43971-1ea9-4b93-9a35-aaab5908327co%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-d...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/89b8d89a-d7e4-44fa-a5b8-cb8e1c910785o%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/a357fb57-55b3-4f65-bf59-cf64c3e412bbo%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/BYAPR14MB291880739C1BB3E52F821C18A39D0%40BYAPR14MB2918.namprd14.prod.outlook.com.

Re: What's wrong with the jenkins testrun failing on ASGI (I think?)

[Andrew Godwin]

Yup, I'm seeing if we can get asgiref fixed today, otherwise I'll revert the 
change that broke Django and issue 3.2.9.

Andrew

On Tue, Jun 16, 2020, at 2:48 AM, Florian Apolloner wrote:
> Ok, so rebasing PRs to current master will fix this (leaving this here as 
> note for others who run into this).
> 
> On Tuesday, June 16, 2020 at 10:39:13 AM UTC+2, Mariusz Felisiak wrote:
>> It's an issue with the asgiref==3.2.8, see 
>> https://github.com/django/asgiref/issues/170. We temporarily pinned 
>> asgiref==3.2.7 [1].
>> 
>> Best,
>> Mariusz
>> 
>> [1] 
>> https://github.com/django/django/commit/dcb4d79ef719d824431a8b3ff8ada879bbab21cc
> 

> --
>  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/c775e1a0-9485-46da-b4d9-015e8ee019b9o%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/49b08050-05ac-418b-a5a0-e4d57ace87e2%40www.fastmail.com.

Re: The blacklist / master issue

[Tom Carrick]

On moving away from the master branch, it would be a lot of effort (not
just in the repo, but docs, Trac, etc.), but I think it's worth doing
regardless. I think there is often some reluctance to do something
time-consuming because it takes someone's time away from technical issues.
I don't think this is necessarily true. Although we could always use more
contributors, this is something that's fairly easy for a newcomer (talking
specifically about the changes to docs). There's no requirement to know
about ORM internals, async implementation, or anything else. Just some time
and thoroughness. I'd be happy to put the time in, and I'm sure there are
many other (potential) contributors willing to do so, and It doesn't stop
the more technical people working on the issues they want to. I think all
that is really required - if/when a decision is made, would be to review
the PR, change the branch in Github, migrate Trac. Of course I don't know
what else is affected, so maybe I'm being optimistic here.

This does have some precedent also, there was a move from trunk to master
when moving from SVN to git. That was part of a bigger change to a new VCS
system, admittedly, but I think this is also important. With that said, I
do think we should wait and see what naming convention git / GitHub /
GitLab etc. decide on. It seems like "main" has the most traction, which
seems fine to me, and, as has been mentioned, is less of a misnomer anyway.

One argument I've seen against both of these that I don't think has been
addressed in this thread is that this will set off a trend of renaming more
things, mastery, masters degrees, and so on. In case it needs to be
addressed, this strikes me as a slippery slope fallacy. Just because we do
one thing, doesn't mean we must necessarily do another vaguely related
thing. I don't see (or foresee) any interest in this, and I think as is
always the case in these things, we go where the consensus is. For example,
trolls aside, I don't see any criticism of e.g. Frontend Masters.

Just some further thoughts.
Tom


On Tue, 16 Jun 2020 at 15:44, Roger Gammans 
wrote:

> Funny you should say that but the git developers mailing list in is awash
> with patches and shouting about just this at the moment.
>
> It looks likely the patches will go in too - so that's not much of an
> arguement against.
>
>
> On Tue, 2020-06-16 at 16:35 +0300, אורי wrote:
>
> I think *master* is the default branch name in any Git repository. It's
> not about Django and even not GitHub. Do you want to change the default
> branch name in Git?
> אורי
> u...@speedy.net
>
>
> On Mon, Jun 15, 2020 at 7:28 PM Tom Carrick  wrote:
>
> This ticket was closed wontfix
>  as requiring a
> discussion here.
>
> David Smith mentioned this Tox issue
>  stating it had been closed,
> but to me it seems like it hasn't been closed (maybe there's something I
> can't see) and apparently a PR would be accepted to add aliases at the
> least (this is more recent than the comment on the Django ticket).
>
> My impetus to bring this up mostly comes from reading this ZDNet article
> 
> - it seems like Google have already made moves in this direction and GitHub
> is also planning to. Usually Django is somewhere near the front for these
> types of changes.
>
> I'm leaning towards renaming the master branch and wherever else we use
> that terminology, but I'm less sure about black/whitelist, though right now
> it seems more positive than negative. Most arguments against use some kind
> of etymological argument, but I don't think debates about historical terms
> are as interesting as how they affect people in the here and now.
>
> I don't think there is an easy answer here, and I open this can of worms
> somewhat reluctantly. I do think Luke is correct that we should be
> concerned with our credibility if we wrongly change this, but I'm also
> worried about our credibility if we don't.
>
> --
> 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/1b47e74f1811390add42c91dab4ccea104b89fcf.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

Re: The blacklist / master issue

[Adam Johnson]

On the branch rename, right now I'd rather wait to see what GitHub builds
that could help with this. It might allow aliasing master->main so that
existing PR's don't need targeting, local clones don't need updating, etc.
It also seems Git will make a change and it might be worth waiting to see
what that looks like.

On the blacklist/whitelist rename, I've reopened the ticket and Tim Graham
already reopened the PR.

On Tue, 16 Jun 2020 at 19:46, Tom Carrick  wrote:

> On moving away from the master branch, it would be a lot of effort (not
> just in the repo, but docs, Trac, etc.), but I think it's worth doing
> regardless. I think there is often some reluctance to do something
> time-consuming because it takes someone's time away from technical issues.
> I don't think this is necessarily true. Although we could always use more
> contributors, this is something that's fairly easy for a newcomer (talking
> specifically about the changes to docs). There's no requirement to know
> about ORM internals, async implementation, or anything else. Just some time
> and thoroughness. I'd be happy to put the time in, and I'm sure there are
> many other (potential) contributors willing to do so, and It doesn't stop
> the more technical people working on the issues they want to. I think all
> that is really required - if/when a decision is made, would be to review
> the PR, change the branch in Github, migrate Trac. Of course I don't know
> what else is affected, so maybe I'm being optimistic here.
>
> This does have some precedent also, there was a move from trunk to master
> when moving from SVN to git. That was part of a bigger change to a new VCS
> system, admittedly, but I think this is also important. With that said, I
> do think we should wait and see what naming convention git / GitHub /
> GitLab etc. decide on. It seems like "main" has the most traction, which
> seems fine to me, and, as has been mentioned, is less of a misnomer anyway.
>
> One argument I've seen against both of these that I don't think has been
> addressed in this thread is that this will set off a trend of renaming more
> things, mastery, masters degrees, and so on. In case it needs to be
> addressed, this strikes me as a slippery slope fallacy. Just because we do
> one thing, doesn't mean we must necessarily do another vaguely related
> thing. I don't see (or foresee) any interest in this, and I think as is
> always the case in these things, we go where the consensus is. For example,
> trolls aside, I don't see any criticism of e.g. Frontend Masters.
>
> Just some further thoughts.
> Tom
>
>
> On Tue, 16 Jun 2020 at 15:44, Roger Gammans 
> wrote:
>
>> Funny you should say that but the git developers mailing list in is awash
>> with patches and shouting about just this at the moment.
>>
>> It looks likely the patches will go in too - so that's not much of an
>> arguement against.
>>
>>
>> On Tue, 2020-06-16 at 16:35 +0300, אורי wrote:
>>
>> I think *master* is the default branch name in any Git repository. It's
>> not about Django and even not GitHub. Do you want to change the default
>> branch name in Git?
>> אורי
>> u...@speedy.net
>>
>>
>> On Mon, Jun 15, 2020 at 7:28 PM Tom Carrick  wrote:
>>
>> This ticket was closed wontfix
>>  as requiring a
>> discussion here.
>>
>> David Smith mentioned this Tox issue
>>  stating it had been closed,
>> but to me it seems like it hasn't been closed (maybe there's something I
>> can't see) and apparently a PR would be accepted to add aliases at the
>> least (this is more recent than the comment on the Django ticket).
>>
>> My impetus to bring this up mostly comes from reading this ZDNet article
>> 
>> - it seems like Google have already made moves in this direction and GitHub
>> is also planning to. Usually Django is somewhere near the front for these
>> types of changes.
>>
>> I'm leaning towards renaming the master branch and wherever else we use
>> that terminology, but I'm less sure about black/whitelist, though right now
>> it seems more positive than negative. Most arguments against use some kind
>> of etymological argument, but I don't think debates about historical terms
>> are as interesting as how they affect people in the here and now.
>>
>> I don't think there is an easy answer here, and I open this can of worms
>> somewhat reluctantly. I do think Luke is correct that we should be
>> concerned with our credibility if we wrongly change this, but I'm also
>> worried about our credibility if we don't.
>>
>> --
>> 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

Re: The blacklist / master issue

[Andrew Godwin]

I've definitely in favour of fixing all of the problematic word usage - after 
all, we eliminated master/slave from the database documentation years ago, 
we've just been a bit negligent at fixing the others.

Agreed with Adam, though, about seeing what GitHub builds - they announced 
they're working on something, and if it allows seamless migration, that'd be 
great. That said, if they take more than a month or two, we should just change 
it and get it over with.

Andrew

On Tue, Jun 16, 2020, at 12:59 PM, Adam Johnson wrote:
> On the branch rename, right now I'd rather wait to see what GitHub builds 
> that could help with this. It might allow aliasing master->main so that 
> existing PR's don't need targeting, local clones don't need updating, etc. It 
> also seems Git will make a change and it might be worth waiting to see what 
> that looks like.
> 
> On the blacklist/whitelist rename, I've reopened the ticket and Tim Graham 
> already reopened the PR.
> 
> On Tue, 16 Jun 2020 at 19:46, Tom Carrick  wrote:
>> On moving away from the master branch, it would be a lot of effort (not just 
>> in the repo, but docs, Trac, etc.), but I think it's worth doing regardless. 
>> I think there is often some reluctance to do something time-consuming 
>> because it takes someone's time away from technical issues. I don't think 
>> this is necessarily true. Although we could always use more contributors, 
>> this is something that's fairly easy for a newcomer (talking specifically 
>> about the changes to docs). There's no requirement to know about ORM 
>> internals, async implementation, or anything else. Just some time and 
>> thoroughness. I'd be happy to put the time in, and I'm sure there are many 
>> other (potential) contributors willing to do so, and It doesn't stop the 
>> more technical people working on the issues they want to. I think all that 
>> is really required - if/when a decision is made, would be to review the PR, 
>> change the branch in Github, migrate Trac. Of course I don't know what else 
>> is affected, so maybe I'm being optimistic here.
>> 
>> This does have some precedent also, there was a move from trunk to master 
>> when moving from SVN to git. That was part of a bigger change to a new VCS 
>> system, admittedly, but I think this is also important. With that said, I do 
>> think we should wait and see what naming convention git / GitHub / GitLab 
>> etc. decide on. It seems like "main" has the most traction, which seems fine 
>> to me, and, as has been mentioned, is less of a misnomer anyway.
>> 
>> One argument I've seen against both of these that I don't think has been 
>> addressed in this thread is that this will set off a trend of renaming more 
>> things, mastery, masters degrees, and so on. In case it needs to be 
>> addressed, this strikes me as a slippery slope fallacy. Just because we do 
>> one thing, doesn't mean we must necessarily do another vaguely related 
>> thing. I don't see (or foresee) any interest in this, and I think as is 
>> always the case in these things, we go where the consensus is. For example, 
>> trolls aside, I don't see any criticism of e.g. Frontend Masters.
>> 
>> Just some further thoughts.
>> Tom
>> 
>> 
>> On Tue, 16 Jun 2020 at 15:44, Roger Gammans  
>> wrote:
>>> Funny you should say that but the git developers mailing list in is awash 
>>> with patches and shouting about just this at the moment.
>>> 
>>> It looks likely the patches will go in too - so that's not much of an 
>>> arguement against.
>>> 
>>> 
>>> On Tue, 2020-06-16 at 16:35 +0300, אורי wrote:
 I think *master* is the default branch name in any Git repository. It's 
 not about Django and even not GitHub. Do you want to change the default 
 branch name in Git?
 אורי
 u...@speedy.net
 
 
 On Mon, Jun 15, 2020 at 7:28 PM Tom Carrick  wrote:
> This ticket was closed wontfix 
>  as requiring a 
> discussion here.
> 
> David Smith mentioned this Tox issue 
>  stating it had been closed, 
> but to me it seems like it hasn't been closed (maybe there's something I 
> can't see) and apparently a PR would be accepted to add aliases at the 
> least (this is more recent than the comment on the Django ticket).
> 
> My impetus to bring this up mostly comes from reading this ZDNet article 
> 
>  - it seems like Google have already made moves in this direction and 
> GitHub is also planning to. Usually Django is somewhere near the front 
> for these types of changes.
> 
> I'm leaning towards renaming the master branch and wherever else we use 
> that terminology, but I'm less sure about black/whitelist, though right 
> now it seems more positive than negative. Most arguments against use some