Re: f-strings again.

[laym...@gmail.com]

Hi folks,

I personally like to use f-strings wherever it makes sense, so +1.

I agree with Mariusz. I think we should only allow %-formatting and 
f-strings from now on.
And yes, bulk updates should not be done. Aside from making unnecessary 
noise, there's always a risk in doing that kind of thing.

Regards,
Sage
On Tuesday, 21 July 2020 at 14:28:54 UTC+7 Mariusz Felisiak wrote:

> Hi y'all,
>
> I will not stand against f-strings, I think we can allow them. My main 
> concerns is readability. f-strings are powerful and it's quite common that 
> they are used with functions calls and complex formatting which makes code 
> hard to understand and maintain, *"With great power comes great 
> responsibility" ...*
>
> I'm strongly against any bulk updates to conform to this style. This 
> will just create unnecessary noise in the history, I know that there are 
> tools, please don't start this discussion again :)
>
> I would also be in favor of keeping only %-formatting and f-strings in 
> Coding style docs. I don't see any reason to use also `format()` in a new 
> code.
>
> 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 view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/8a0cbf42-1879-4ed1-9d3c-8e6985012155n%40googlegroups.com.

Set up autolinks on Django's GitHub repositories

[laym...@gmail.com]

Hi folks,

I came across this feature on GitHub today:
https://docs.github.com/en/github/administering-a-repository/configuring-autolinks-to-reference-external-resources

In short, it adds autolinks to external resources (e.g. our issue tracker) 
by referencing them using a prefix in GitHub comments or commits. So, 
instead of using Markdown to manually link to a ticket, we can just use the 
prefix followed by the ticket number, e.g. *TR-123* and GitHub will 
automatically convert it to a link.

Currently, we use the # character as a convention to refer to the tickets. 
However, this conflicts with the use of # on GitHub which automatically 
links to PRs (and issues if enabled). As a result, commits that refer to a 
ticket whose number is also a valid PR number, incorrectly link to the PR. 
Here's an example: 
https://github.com/django/django/commit/5d4b9c1cab03f0d057f0c7751862df0302c65cf9

As you can see, the commit message links to PR#12990 which actually isn't 
relevant. This also generates noise in the PR 
itself: https://github.com/django/django/pull/12990. I think that can be 
misleading to new contributors.

By using the autolinks, we can properly link the reference to the tickets. 
Sadly, we can't replace GitHub's # autolinks. So, we need to create a new 
prefix. This has some downsides, though:

   - It breaks the current convention of using # to refer to tickets.
   - The prefix must only contain letters, numbers, or -:/#
   - The prefix is 3 characters minimum, so this means commit messages will 
   be at least 2 characters longer than with the current convention.
   
However, considering the benefits:

   - No more incorrect links to irrelevant PRs.
   - No more noise in PRs from irrelevant commits.
   - Clickable ticket numbers in commits that take you to the tickets.
   - Quick linking to tickets in GitHub comments (no need to use Markdown).
   - Less confusion to new contributors.

I think it's worth it.

What do y'all think? If we're to agree upon this, I guess we need to come 
up with the prefix. I don't have any preference; as long as it makes sense, 
I'm in.

Oh, and one more thing: maybe we can also set up a prefix for PRs to easily 
differentiate between the two from now on. Here are some proposals:

   - *TR-1234* for TRac tickets, and *PR-5678* for PRs.
   - *TR#1234* for TRac tickets, and *PR#5678* for PRs.

And maybe we can set up another for DEPs, but that may not be necessary...

Regards,
Sage

-- 
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/e070dd97-0d22-4566-a605-867141f7e0aan%40googlegroups.com.

Re: Set up autolinks on Django's GitHub repositories

[laym...@gmail.com]

Hi Markus,

Thanks, I must've missed that 😅. Then, I guess I'd suggest adding a 
briefer one *and using it in commit messages*. So yep, the contributing 
guide needs to be updated as well. However, this changes the convention 
which has been there for years. I'd like to hear what the Fellows or board 
think about this.

Sage

On Monday, 3 August 2020 at 14:52:31 UTC+7 in...@markusholtermann.eu wrote:

> Hi Sage, 
>
> thank you for the suggestion. There's already autolinking setup for 
> `ticket-123`. I'm happy to add another one which would be a bit briefer. 
> But if this is done, the contribution documentation needs to be updated as 
> well. 
>
> /Markus 
>
> On Mon, Aug 3, 2020, at 8:06 AM, laym...@gmail.com wrote: 
> > Hi folks, 
> > 
> > I came across this feature on GitHub today: 
> > 
> https://docs.github.com/en/github/administering-a-repository/configuring-autolinks-to-reference-external-resources
>  
> > 
> > In short, it adds autolinks to external resources (e.g. our issue 
> > tracker) by referencing them using a prefix in GitHub comments or 
> > commits. So, instead of using Markdown to manually link to a ticket, we 
> > can just use the prefix followed by the ticket number, e.g. *TR-123* 
> > and GitHub will automatically convert it to a link. 
> > 
> > Currently, we use the # character as a convention to refer to the 
> > tickets. However, this conflicts with the use of # on GitHub which 
> > automatically links to PRs (and issues if enabled). As a result, 
> > commits that refer to a ticket whose number is also a valid PR number, 
> > incorrectly link to the PR. Here's an example: 
> > 
> https://github.com/django/django/commit/5d4b9c1cab03f0d057f0c7751862df0302c65cf9
>  
> > 
> > As you can see, the commit message links to PR#12990 which actually 
> > isn't relevant. This also generates noise in the PR itself: 
> > https://github.com/django/django/pull/12990. I think that can be 
> > misleading to new contributors. 
> > 
> > By using the autolinks, we can properly link the reference to the 
> > tickets. Sadly, we can't replace GitHub's # autolinks. So, we need to 
> > create a new prefix. This has some downsides, though: 
> > * It breaks the current convention of using # to refer to tickets. 
> > * The prefix must only contain letters, numbers, or -:/# 
> > * The prefix is 3 characters minimum, so this means commit messages 
> > will be at least 2 characters longer than with the current convention. 
> > However, considering the benefits: 
> > * No more incorrect links to irrelevant PRs. 
> > * No more noise in PRs from irrelevant commits. 
> > * Clickable ticket numbers in commits that take you to the tickets. 
> > * Quick linking to tickets in GitHub comments (no need to use 
> > Markdown). 
> > * Less confusion to new contributors. 
> > I think it's worth it. 
> > 
> > What do y'all think? If we're to agree upon this, I guess we need to 
> > come up with the prefix. I don't have any preference; as long as it 
> > makes sense, I'm in. 
> > 
> > Oh, and one more thing: maybe we can also set up a prefix for PRs to 
> > easily differentiate between the two from now on. Here are some 
> > proposals: 
> > * *TR-1234* for TRac tickets, and *PR-5678* for PRs. 
> > * *TR#1234* for TRac tickets, and *PR#5678* for PRs. 
> > And maybe we can set up another for DEPs, but that may not be 
> > necessary... 
> > 
> > Regards, 
> > Sage 
> > 
> > -- 
> > 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-develop...@googlegroups.com. 
> > To view this discussion on the web visit 
> > 
> https://groups.google.com/d/msgid/django-developers/e070dd97-0d22-4566-a605-867141f7e0aan%40googlegroups.com
>  
> <
> https://groups.google.com/d/msgid/django-developers/e070dd97-0d22-4566-a605-867141f7e0aan%40googlegroups.com?utm_medium=email&utm_source=footer>.
>  
>
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/5f2fb712-a0eb-49c4-a368-2c01adeec8e1n%40googlegroups.com.

Should django-admin allow specifying hidden directories for --template?

[laym...@gmail.com]

Hi everyone,

I've been playing around with the --template  option for 
django-admin 
startproject 

 
lately, and I noticed that it ignores hidden directories 

 
(those that start with period) and __pycache__.

I was trying to create a template that includes a GitHub Actions workflow, 
but I realized that it wasn't in the generated project. The files are 
stored in the .github/workflows directory, so it's ignored by Django. I 
don't know if this has been discussed before, but a quick search only led 
me to this StackOverflow question 

.

Do you think we should add an option to override this? I can think of some 
options:

   - Add something like --hidden-dirs to include hidden directories.
   - For files specified using --name, always include them even if they're 
   inside hidden directories, or maybe allow the option to accept directories.
   - Add something like --directory to specify hidden directories 
   explicitly.

I can create a ticket and write a patch for this if you support it. Thanks!

Regards,
Sage

-- 
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/22fce477-9273-49f6-868b-c1e6860f2e76n%40googlegroups.com.

Re: Should django-admin allow specifying hidden directories for --template?

[laym...@gmail.com]

Hi René,

Thanks for the feedback! From my observations, Django does not ignore 
hidden *files*,
it only ignores hidden *directories*. So, the files that you listed should 
work fine.

As for the built-in exclusion list, I'm not sure if we should add that. I 
think ignoring .git
by default is fine, but we shouldn't assume that people would like to 
ignore .coverage.

Regarding exclusion vs inclusion... I'm not sure what the best option is, 
though! :)

Sage


On Thursday, 1 October 2020 at 20:47:48 UTC+7 re...@fleschenberg.net wrote:

> Hi,
>
> I can see several use-cases for hidden files / directories in a project 
> template. Here are some examples from one of my current projects:
>
> .coveragerc
> .editorconfig
> .flake8
> .gitignore
> .gitlab-ci.yml
> .isort.cfg
>
> Instead of introducing a command line option to explicitly include 
> things, can we replace the current behavior with a built-in exclusion 
> list? And maybe an --exclude option to exclude additional things?
>
> Candidates for the exclusion list that come to my mind:
>
> __pycache__
> .git
> .coverage
>
> 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/3f5fd60d-f830-4353-ae94-ce1649a6889an%40googlegroups.com.

Re: Participation in GSOC 2021

[laym...@gmail.com]

Hi Nishith and Sanju,

This is a common question on this mailing list.
I believe you can find similar threads with the "gsoc" keyword and find 
other students who are also looking to participate in GSoC.

To start, I'd suggest reading the Contributing Guide 
https://docs.djangoproject.com/en/3.1/internals/contributing/.
The guide should cover most, if not all, of the things you need to start 
contributing.
Feel free to ask if there's something you don't find in there.

Cheers!

Sage

On Saturday, 26 December 2020 at 02:05:58 UTC+7 sanju...@gmail.com wrote:

> Sorry for 2021
>
> On Fri, Dec 25, 2020, 8:34 PM Kacper Szmigiel  
> wrote:
>
>> Bruh, GSoC 2020 has ended in August
>>
>> pt., 25 gru 2020, 15:53 użytkownik SaNju  napisał:
>>
>>> Hello Sir/Mam, 
>>> I am Sanju  from the Rajdhani engineering college Jaipur. 
>>> During my stay of onr and half years at REC Jaipur, I had participated 
>>> in various roles, I have worked with different technologies in last one 
>>> year: React*, backend development, * etc, different frameworks like 
>>> *Django* and *flask*, databases such as *MySQL, POSTGRESQL* 
>>> I wish to be an active participant for your organization in the GSoC 
>>> 2020.
>>> Kindly let me know about the necessary steps which I need to follow in 
>>> order to participate and be an active developer for your organization in 
>>> GSoC 2020
>>>
>>> i have one year experince in python full stack developement 
>>>
>>> Looking forward to hearing from 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-develop...@googlegroups.com.
>>> To view this discussion on the web visit 
>>> https://groups.google.com/d/msgid/django-developers/6d230bca-7841-4cbd-906e-751a3c4b90den%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-develop...@googlegroups.com.
>>
> To view this discussion on the web visit 
>> https://groups.google.com/d/msgid/django-developers/CAFfZ%2Bb75W6vpyqUJQPYoRJpBSUd2a-%3DCHxwLta6c%2BRKNXXRFwg%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/03b90252-e284-4bf0-8a9e-91cff8b381bfn%40googlegroups.com.

Re: Should django-admin allow specifying hidden directories for --template?

[laym...@gmail.com]

Finally got around to create a ticket for this: 
https://code.djangoproject.com/ticket/32309

I've also created a PoC with a new --directory option: 
https://github.com/django/django/pull/13827

Sage

On Thursday, 1 October 2020 at 21:14:51 UTC+7 re...@fleschenberg.net wrote:

> Hi,
>
> On 01.10.20 15:56, laym...@gmail.com wrote:
> > Thanks for the feedback! From my observations, Django does not ignore 
> > hidden /files/,
> > it only ignores hidden /directories/. So, the files that you listed 
> > should work fine.
>
> Ah, my bad, sorry.
>
> > As for the built-in exclusion list, I'm not sure if we should add that. 
> > I think ignoring .git
> > by default is fine, but we shouldn't assume that people would like to 
> > ignore .coverage.
>
> Hmmm, you mean because other tools besides 
> https://pypi.org/project/coverage/ might use that path? I guess that 
> could happen, yup.
>
> > Regarding exclusion vs inclusion... I'm not sure what the best option 
> > is, though! :)
>
> I think I prefer explicit exclusion by the user (except for obvious 
> cases like .git and __pycache__) because it's less surprising.
>
> 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/1985ff35-48b6-4fa4-8c5d-d085eb3c7b86n%40googlegroups.com.

Re: Feature Request: Provide an option to disable static files caching during development

[laym...@gmail.com]

I'm +1 on this.

In my experience teaching Django at university, this always confuses 
students: "why are my changes not reflected in the browser?"

Having static files caching disabled when DEBUG=True would be very useful. 
Thanks for bringing this up!

Sage

On Monday, 27 September 2021 at 20:17:35 UTC+7 Bharat Chauhan wrote:

> Hello,
>
> I recently opened a ticket (#33148 
> ) but it was closed as 
> duplicate of (#32891 ) which 
> itself is marked "wontfix".
>
> The reasoning provided by Carlton Gibson for this is:
>
> > *I don't think this is the right approach. As far as I can see the 
> browser behaviour is correct and as desired, s**erving static assets from 
> the browser cache when possible.*
>
> At least while DEBUG is True, I see no harm in setting `Cache-Control: 
> max-age=0` header.
>
> This will allow browsers to cache the files while forcing them to 
> revalidate cache using the If-Modified-Since header. This way, Django can 
> serve updated files if they get modified or return a 304 response in which 
> case browsers will use the cached file (conforming to Carlton's comment 
> about using browser cache when possible).
>
> This will aid in development as we now have to open the browser's network 
> tab and disable the cache to refresh static files. In Mobile, disabling 
> cache is not possible, so we have to test in Incognito Mode. It's a 
> frustrating development experience.
>
> 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 view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/f84a796f-f2be-4846-bd35-e9640c77e550n%40googlegroups.com.

Re: Add warning or prohibit module level queries?

[laym...@gmail.com]

+1, I've had people raising issues that were caused by this. They were 
using a query to provide a model field's default value.

On Sunday, 26 September 2021 at 02:06:21 UTC+7 Adam Johnson wrote:

> I noticed I've continued to encounter this problem in code review 
> relatively frequently, so I made a ticket: 
> https://groups.google.com/g/django-developers/c/7JwWatLfP44/ . Tim then 
> pointed me back to this discussion.
>
> I'm happy to implement Tim's suggestion of a RuntimeWarning followed by 
> deprecation if it doesn't cause many problems. Just checking here if anyone 
> would be against the idea.
>
> On Thursday, February 25, 2016 at 10:42:07 PM UTC cur...@tinbrain.net 
> wrote:
>
>> +1 
>>
>> At the very least we need to provide better feedback or errors to help 
>> isolate _where_ this is happening. 
>>
>> I've helped quite a number of people on IRC with this problem... 
>> firstly, people aren't understanding _what_ the problem is, but also 
>> discerning where it's happening is often quite difficult, even with a 
>> full traceback. 
>>
>> -- 
>> C 
>>
>>
>> On 26/02/16 04:29, Tim Graham wrote: 
>> > Simon proposed [0]: "I wonder if we should prevent django.db from 
>> > executing queries until django.apps.apps.ready or at least issue a 
>> > RuntimeWarning. We would have to go through deprecation but I'm pretty 
>> > sure this would uncover a lot of existing application bugs and prevent 
>> > future ones. This is related to #25454 
>> >  [1] and probably a large 
>> > number of closed tickets." 
>> > 
>> > 
>> > We have this restriction in some places, for example: "Executing 
>> > database queries with the ORM at import time in models modules will 
>> also 
>> > trigger this exception. The ORM cannot function properly until all 
>> > models are available." 
>> > 
>> > We also have a warning about using the ORM in AppConfig.ready(): 
>> > "Although you can access model classes as described above, avoid 
>> > interacting with the database in your |ready()| implementation. This 
>> > includes model methods that execute queries (|save()|, |delete()|, 
>> > manager methods etc.), and also raw SQL queries via 
>> > |django.db.connection|. Your |ready()| method will run during startup 
>> of 
>> > every management command. For example, even though the test database 
>> > configuration is separate from the production settings, |manage.py 
>> test| 
>> > would still execute some queries against your *production* database!" 
>> > 
>> > There's also a warning in the testing docs: "Finding data from your 
>> > production database when running tests? If your code attempts to access 
>> > the database when its modules are compiled, this will occur /before/ 
>> the 
>> > test database is set up, with potentially unexpected results. For 
>> > example, if you have a database query in module-level code and a real 
>> > database exists, production data could pollute your tests. /It is a bad 
>> > idea to have such import-time database queries in your code/ anyway - 
>> > rewrite your code so that it doesn’t do this. This also applies to 
>> > customized implementations of |ready()|." 
>> > 
>> > What do you think? Prohibiting such queries might be too strict at this 
>> > point as I guess some users might rely on them. I suppose warnings 
>> could 
>> > be selectively silenced as/if needed. We could start with a warning and 
>> > ask users to let us know if they believe they have a legitimate usage. 
>> > If we don't hear anything, we could proceed with the deprecation. 
>> > 
>> > Related tickets: 
>> > 
>> > [0] https://code.djangoproject.com/ticket/26273 
>> > [1] https://code.djangoproject.com/ticket/25454 
>> > 
>> > -- 
>> > 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-develop...@googlegroups.com 
>> > . 
>> > To post to this group, send email to django-d...@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/7f41ba58-09ed-4f78-b5ce-be6d7d5a6fc7%40googlegroups.com
>>  
>> > <
>> https://groups.google.com/d/msgid/django-developers/7f41ba58-09ed-4f78-b5ce-be6d7d5a6fc7%40googlegroups.com?utm_medium=email&utm_source=footer>.
>>  
>>
>> > 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 view this discussion on the web visit 
https://groups.google.com/d/m