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

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.

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

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

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

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 a

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

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

Overriding template blocks without copy/pasting entire template files

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

Re: The blacklist / master issue

The Django it is a community framework and we have to pay attention to that. History play a major role in our daily lives and we have to avoid any word that have racial connection. Django community is growing fast in Africa and we hate things that taking us back to Apartheid/Slave era since

Re: The blacklist / master issue

Agreed. I thought DHH's argument was equally as compelling for making this change for rails: Regardless of origin, allow/deny are simply clearer terms that does not > require tracing the history of black/white as representations of that > meaning. We can simply use the meaning directly. htt

Re: The blacklist / master issue

Just my small contribution to the discussion... Independent of "social" aspects to the choice of words, the move towards "self explanatory terminology" is preferable, IMHO. As an example, it takes less mental effort or historical context to know what an "allow_list" is compared to a "whitelist"

Re: The blacklist / master issue

On Monday, June 15, 2020 at 2:56:45 PM UTC-5, Daniele Procida wrote: > > 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

Re: The blacklist / master issue

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 st

Re: The blacklist / master issue

I'd be in favor of changing blacklist/whitelist into something that makes sense. In many cases, that's going to be context dependent, but often blocklist/allowlist will work. With regards to "master" as the development branch on GitHub, I'd like to pick whatever GitHub eventually goes with as a

Re: The blacklist / master issue

I don't participate in this list much but this is a solid +1 from me. We should do our best to adopt neutral language. Etymology/history is important, yes, but much less important that current impact and usage. On Monday, June 15, 2020 at 9:28:23 AM UTC-7, Tom Carrick wrote: > > This ticket was

Re: The blacklist / master issue

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

Re: The blacklist / master issue

Hi, just my 2 cents: While I am generally critical of changing language to achieve social progress, I see no harm in using "main", "develop" or something like that instead of "master". There might be a tool or two out there that treat "master" specially, but I can't think of anything that would d

Re: The blacklist / master issue

My initial response on the original PR was, looking it up, that “blacklist” wasn’t a race-related term. I then said, unless there are additional uses... It seems there are. In which case this seems a no-brainer. We should use better words. That’s an easy change. +1 On Mon, 15 Jun 2020 at 19:05,

Re: The blacklist / master issue

I was preparing a post on this Tom, it was sitting in my drafts awaiting a little more research, but here we go. My summary: This small language change has been suggested many times in the technology sphere for two reasons. First, the allow/deny terms avoid the potentially offensive assocation of

The blacklist / master issue

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

Re: Fellow Reports - June 2020

Week ending June 14, 2020. *Triaged:* https://code.djangoproject.com/ticket/31669 - migrate --fake-initial doesn't work when only a subset of tables exists in database. (invalid) https://code.djangoproject.com/ticket/31674 - debug error view doesn't respect exc.__suppress_context__ (PEP 415) (ac

Django 3.1 beta 1 released

Details are available on the Django project weblog: https://www.djangoproject.com/weblog/2020/jun/15/django-31-beta-1-released/ -- You received this message because you are subscribed to the Google Groups "Django developers (Contributions to Django itself)" group. To unsubscribe from this gro

Django 3.1 beta 1 released

Details are available on the Django project weblog: https://www.djangoproject.com/weblog/2020/jun/15/django-31-beta-1-released/ -- You received this message because you are subscribed to the Google Groups "Django developers (Contributions to Django itself)" group. To unsubscribe from this grou

Django 3.1 beta 1 released

Details are available on the Django project weblog: https://www.djangoproject.com/weblog/2020/jun/15/django-31-beta-1-released/ -- You received this message because you are subscribed to the Google Groups "Django developers (Contributions to Django itself)" group. To unsubscribe from this grou