Django bugfix releases: 2.2.6, 2.1.13, and 1.11.25

[Carlton Gibson]

Details are available on the Django project weblog:

https://www.djangoproject.com/weblog/2019/oct/01/bugfix-releases/

-- 
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/94382ACE-5E45-4BE5-BE4E-9AA900B425E2%40gmail.com.

Re: Logging in management commands

[charettes]

Hello Christian,

I don't have an exact answer for you but there's open tickets about making 
management
commands use logging instead of custom output wrappers that might interest 
you.

Simon

[0] https://code.djangoproject.com/ticket/21429
[1] https://code.djangoproject.com/ticket/27877

Le samedi 28 septembre 2019 19:13:01 UTC+2, Christian González a écrit :
>
> Hi, 
>
> i just stumbled upon logging in management commands I saw that there is 
> an own system of logging. 
>
> When creating custom mgmt cmds, you have to write logging output to 
>
> if options["verbosity"] >= 2: 
> sys.stdout.write(message) 
>
> this is a little inconvenient, and much less DRY as e.g. 
>
> logger.info(message) 
>
> But logger does not really work as intended in commands. 
>
> Was this a good choice? Yes, log levels can be changed using settings.py. 
>
> But: wouldn't it be convenient to use the system logger for that too in 
> Django? 
>
>
> My background is: I have made a plugin system, and I would have to add 
> the "verbosity" parameter to every plugin hook that is ought to print 
> out some logging strings. It would be a lot easier to use logger.warning 
> e.g. for that. 
>
> Could the 4 verbosity levels just be tied to debug,info, warning, error 
> of python's logging module as default? 
>
> Thanks, 
> Christian 
>
>

-- 
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/2da9ef10-178c-4173-bd82-061acf8733ca%40googlegroups.com.

Re: Feature idea: bulk_associate: Add ManyToMany relationships in bulk

[Tom Forbes]

Hey David,
I like this idea, while I don’t think the use case is common there have been a 
few times where I’ve needed this and got around it by creating/modifying the 
through model in bulk. Having a method that does this would be good IMO.

Unless anyone has strong opinions against this then can you make a ticket? 

Tom

>> On 30 Sep 2019, at 02:14, David Foster  wrote:
> 
> Here is another API variation I might suggest:
> 
> M1.m2_set.add_pairs(*[(m1, m2), ...], assert_no_collisions=False)
> # --- OR ---
> M1.m2_set.add_pair_ids(*[(m1_id, m2_id), ...], assert_no_collisions=False)
> 
> This has the advantages of being more similar to the existing add() API and 
> not requiring a special function import.
> 
> For bulk_disassociate() the analogous API would be:
> 
> M1.m2_set.remove_pairs(*[(m1, m2), ...])
> # --- OR ---
> M1.m2_set.remove_pair_ids(*[(m1_id, m2_id), ...])
> 
> - David
> 
>> On Thursday, September 26, 2019 at 10:45:45 AM UTC-7, David Foster wrote:
>> Given the following example model:
>> 
>> class M1(models.Model):
>> m2_set = models.ManyToManyField('M2')
>> 
>> It is already possible to associate one M1 with many M2s with a single DB 
>> query:
>> 
>> m1.m2_set.add(*m2s)
>> 
>> However it's more difficult to associate many M1s with many M2s, 
>> particularly if you want to skip associations that already exist.
>> 
>> # NOTE: Does NOT skip associations that already exist!
>> m1_and_m2_id_tuples = [(m1_id, m2_id), ...]
>> M1_M2 = M1.m2_set.through
>> M1_M2.objects.bulk_create([
>> M1_M2(m1_id=m1_id, m2_id=m2_id)
>> for (m1_id, m2_id) in
>> m1_and_m2_id_tuples
>> ])
>> 
>> What if we could do something like the following instead:
>> 
>> bulk_associate(M1.m2_set, [(m1, m2), ...])
>> # --- OR ---
>> bulk_associate_ids(M1.m2_set, [(m1_id, m2_id), ...])
>> 
>> I propose to write and add a bulk_associate() method to Django. I also 
>> propose to add a paired bulk_disassociate() method.
>> 
>> 1. Does this sound like a good idea in general?
>> 
>> 
>> In more detail, I propose adding the specific APIs, importable from 
>> django.db:
>> 
>> M1 = TypeVar('M1', bound=Model)  # M1 extends Model
>> M2 = TypeVar('M2', bound=Model)  # M2 extends Model
>> 
>> def bulk_associate(
>> M1_m2_set: ManyToManyDescriptor,
>> m1_m2_tuples: 'List[Tuple[M1, M2]]',
>> *, assert_no_collisions: bool=True) -> None:
>> """
>> Creates many (M1, M2) associations with O(1) database queries.
>> 
>> If any requested associations already exist, then they will be left 
>> alone.
>> 
>> If you assert that none of the requested associations already exist,
>> you can pass assert_no_collisions=True to save 1 database query.
>> """
>> pass
>> 
>> def bulk_associate_ids(
>> M1_m2_set: ManyToManyDescriptor,
>> m1_m2_id_tuples: 'List[Tuple[Any, Any]]',
>> *, assert_no_collisions: bool=True) -> None:
>> pass
>> 
>> If assert_no_collisions is False then (1 filter) query and (1 bulk_create) 
>> query will be performed.
>> If assert_no_collisions is True then only (1 bulk_create) will be performed.
>> 
>> def bulk_disassociate(
>> M1_m2_set: ManyToManyDescriptor,
>> m1_m2_tuples: 'List[Tuple[M1, M2]]') -> None:
>> """
>> Deletes many (M1, M2) associations with O(1) database queries.
>> """
>> pass
>> 
>> def bulk_disassociate_ids(
>> M1_m2_set: ManyToManyDescriptor,
>> m1_m2_id_tuples: 'List[Tuple[Any, Any]]') -> None:
>> pass
>> 
>> The database connection corresponding to the M1_M2 through-table will be 
>> used.
>> 
>> 2. Any comments on the specific API or capabilities?
>> 
>> 
>> If this sounds good I'd be happy to open an item on Trac and submit a PR.
> 
> -- 
> 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/49b45d05-836f-4512-91b8-8e4dbb55f6a4%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/A1F23375-5004-40D1-9B77-775E337CB53F%40tomforb.es.

Suggestions on where to contribute

[Fredrik Malmfors]

Hello everyone!


As part of a university course, where the goal is to contribute to a large 
open source project, I chose django. I’m currently in the process of 
studying the structure of the source code.


Anyway, if anyone has a* suggestion for a django component* to study more 
in depth (perhaps where the most work is needed), let me know. I’d also 
love to get suggestions for suitable accepted *tickets* to start looking 
into.


I do understand that django is a pretty mature project already, but I’d 
like to at least attempt to contribute. It doesn’t have to be code, it 
could as well be documentation. 


Kind regards,

Fredrik

-- 
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/aca46f0d-535d-4934-8ae8-ffc1175b47d5%40googlegroups.com.

Re: Suggestions on where to contribute

[Kye Russell]

The ORM! Good luck!

> On 1 Oct 2019, at 4:20 pm, Fredrik Malmfors  wrote:
> 
> Hello everyone!
> 
> 
> 
> As part of a university course, where the goal is to contribute to a large 
> open source project, I chose django. I’m currently in the process of studying 
> the structure of the source code.
> 
> 
> 
> Anyway, if anyone has a suggestion for a django component to study more in 
> depth (perhaps where the most work is needed), let me know. I’d also love to 
> get suggestions for suitable accepted tickets to start looking into.
> 
> 
> 
> I do understand that django is a pretty mature project already, but I’d like 
> to at least attempt to contribute. It doesn’t have to be code, it could as 
> well be documentation. 
> 
> 
> 
> Kind regards,
> 
> Fredrik
> 
> 
> -- 
> 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/aca46f0d-535d-4934-8ae8-ffc1175b47d5%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/4CA62A9B-3F9F-4041-A239-92356F2FA0D8%40kye.id.au.

How to assign issue to self

[keshav kumar]

Hii...I want to contribute to django. But I am not getting how to assign 
issue ticket to self. Can you tell me the step to assign issue.

-- 
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/0b39ba38-1464-4866-a0c7-d959cbf3fff7%40googlegroups.com.

Re: Suggestions on where to contribute

[Carlton Gibson]

Hi Fredrik 

Welcome! 

If you go to Trac, and View Tickets, you can filter by Component. 
Here's an example for the Admin 

.

It's worth spending a few minutes trying different components, and perhaps 
a few other filters to get the feel for it. 

The top three components by ticket numbers, with a comment from me about 
them are: 

1. The ORM: Certainly the hardest bit, but if you know about DBs and are 
prepared to get to get your hands dirty, it's not impossible to get a feel 
for. If you begin, you'll find plenty of people who will lend you their 
expertise to get you further. 

2. The Admin: The trick here is often testing HTML output. That together 
with that the Admin is very powerful, and so can take some time to get your 
head around. I'd say most issues here are not super-hard per se, but rather 
need time and love to get them resolved. 

3. Documentation. These can be on any part of Django. They're a great 
learning opportunity because you have to understand an issue before you can 
then write clearly about it. Again, often time, rather than difficult per 
se. 

Those would be the primary targets, but if you wanted to pick a component 
with less open tickets, you could become an expert there, and clear out the 
lot. :)

There are many opportunities to get involved there. (The are >1200 open 
accepted tickets!) 

Also there's djangoproject.com, django-people, django-snippets, 
django-packages, ... that all need love. Then there's the whole third-party 
ecosystem: most of those packages are under-maintained. I'd say "mature" 
means more surface area, rather than less. :) 

Hopefully that helps. Have a look around. Let me know if you need more 
guidance from there. 

Kind Regards,

Carlton


On Tuesday, 1 October 2019 13:13:41 UTC+2, Fredrik Malmfors wrote:
>
> Hello everyone!
>
>
> As part of a university course, where the goal is to contribute to a large 
> open source project, I chose django. I’m currently in the process of 
> studying the structure of the source code.
>
>
> Anyway, if anyone has a* suggestion for a django component* to study more 
> in depth (perhaps where the most work is needed), let me know. I’d also 
> love to get suggestions for suitable accepted *tickets* to start looking 
> into.
>
>
> I do understand that django is a pretty mature project already, but I’d 
> like to at least attempt to contribute. It doesn’t have to be code, it 
> could as well be documentation. 
>
>
> Kind regards,
>
> Fredrik
>
>

-- 
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/362f9b32-4af3-4913-877d-f2507e843546%40googlegroups.com.

Re: How to assign issue to self

[keshav kumar]

Thank you so much! I have done it.

On Tuesday, 1 October 2019 18:08:59 UTC+5:30, keshav kumar wrote:
>
> Hii...I want to contribute to django. But I am not getting how to assign 
> issue ticket to self. Can you tell me the step to assign issue.
>

-- 
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/35a64344-7a54-4799-ba30-4d046c4e71ab%40googlegroups.com.

Query Regarding Ticket : #30817 Document that Sitemap.items() can return an iterable.

[keshav kumar]

I have read all the description of this ticket but still I'm not getting 
what they wanted to do in this issue. Can you explain me more about it ?

-- 
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/e5fbae5f-62c5-45a1-9aea-850b845c1cd4%40googlegroups.com.

Re: Query Regarding Ticket : #30817 Document that Sitemap.items() can return an iterable.

[Mariusz Felisiak]

This issue is already assigned and has patch.

W dniu wtorek, 1 października 2019 21:11:47 UTC+2 użytkownik keshav kumar 
napisał:
>
> I have read all the description of this ticket but still I'm not getting 
> what they wanted to do in this issue. Can you explain me more about it ?
>

-- 
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/ddbf4e69-cbd7-4794-b61b-d519027368c9%40googlegroups.com.

Re: Feature idea: bulk_associate: Add ManyToMany relationships in bulk

[David Foster]

Trac ticket created: https://code.djangoproject.com/ticket/30828

On Tuesday, October 1, 2019 at 3:02:38 AM UTC-7, Tom Forbes wrote:
>
> Hey David,
> I like this idea, while I don’t think the use case is common there have 
> been a few times where I’ve needed this and got around it by 
> creating/modifying the through model in bulk. Having a method that does 
> this would be good IMO.
>
> Unless anyone has strong opinions against this then can you make a ticket? 
>
> Tom
>
> On 30 Sep 2019, at 02:14, David Foster > 
> wrote:
>
> 
> Here is another API variation I might suggest:
>
> M1.m2_set.add_pairs(*[(m1, m2), ...], assert_no_collisions=False)
> # --- OR ---
> M1.m2_set.add_pair_ids(*[(m1_id, m2_id), ...], assert_no_collisions=False)
>
> This has the advantages of being more similar to the existing add() API 
> and not requiring a special function import.
>
> For bulk_disassociate() the analogous API would be:
>
> M1.m2_set.remove_pairs(*[(m1, m2), ...])
> # --- OR ---
> M1.m2_set.remove_pair_ids(*[(m1_id, m2_id), ...])
>
> - David
>
> On Thursday, September 26, 2019 at 10:45:45 AM UTC-7, David Foster wrote:
>>
>> Given the following example model:
>>
>> class M1(models.Model):
>> m2_set = models.ManyToManyField('M2')
>>
>> It is already possible to associate *one* M1 with *many* M2s with a 
>> single DB query:
>>
>> m1.m2_set.add(*m2s)
>>
>> However it's more difficult to associate *many* M1s with *many* M2s, 
>> particularly if you want to skip associations that already exist.
>>
>> # NOTE: Does NOT skip associations that already exist!
>> m1_and_m2_id_tuples = [(m1_id, m2_id), ...]
>> M1_M2 = M1.m2_set.through
>> M1_M2.objects.bulk_create([
>> M1_M2(m1_id=m1_id, m2_id=m2_id)
>> for (m1_id, m2_id) in
>> m1_and_m2_id_tuples
>> ])
>>
>> What if we could do something like the following instead:
>>
>> bulk_associate(M1.m2_set, [(m1, m2), ...])
>> # --- OR ---
>> bulk_associate_ids(M1.m2_set, [(m1_id, m2_id), ...])
>>
>> I propose to write and add a *bulk_associate()* method to Django. I also 
>> propose to add a paired *bulk_disassociate()* method.
>>
>> *1. Does this sound like a good idea in general?*
>>
>>
>> In more detail, I propose adding the specific APIs, importable from 
>> *django.db*:
>>
>> M1 = TypeVar('M1', bound=Model)  # M1 extends Model
>> M2 = TypeVar('M2', bound=Model)  # M2 extends Model
>>
>> def bulk_associate(
>> M1_m2_set: ManyToManyDescriptor,
>> m1_m2_tuples: 'List[Tuple[M1, M2]]',
>> *, assert_no_collisions: bool=True) -> None:
>> """
>> Creates many (M1, M2) associations with O(1) database queries.
>> 
>> If any requested associations already exist, then they will be left 
>> alone.
>> 
>> If you assert that none of the requested associations already exist,
>> you can pass assert_no_collisions=True to save 1 database query.
>> """
>> pass
>>
>> def bulk_associate_ids(
>> M1_m2_set: ManyToManyDescriptor,
>> m1_m2_id_tuples: 'List[Tuple[Any, Any]]',
>> *, assert_no_collisions: bool=True) -> None:
>> pass
>>
>> If assert_no_collisions is False then (1 filter) query and (1 
>> bulk_create) query will be performed.
>> If assert_no_collisions is True then only (1 bulk_create) will be 
>> performed.
>>
>> def bulk_disassociate(
>> M1_m2_set: ManyToManyDescriptor,
>> m1_m2_tuples: 'List[Tuple[M1, M2]]') -> None:
>> """
>> Deletes many (M1, M2) associations with O(1) database queries.
>> """
>> pass
>>
>> def bulk_disassociate_ids(
>> M1_m2_set: ManyToManyDescriptor,
>> m1_m2_id_tuples: 'List[Tuple[Any, Any]]') -> None:
>> pass
>>
>> The database connection corresponding to the M1_M2 through-table will be 
>> used.
>>
>> *2. Any comments on the specific API or capabilities?*
>>
>>
>> If this sounds good I'd be happy to open an item on Trac and submit a PR.
>>
> -- 
> 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/49b45d05-836f-4512-91b8-8e4dbb55f6a4%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/a02a1a95-9da6-4212-8e79-595c60a2fa56%40googlegroups.com.