How to Start for GSOC 2020 in Django org.

[Priyanshu Panwar]

Hello Everyone.
Please help me. How do I start for gsoc 2020, though I have a good 
background in Python and Django as a freelancer.
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/3d87d5a8-ab76-45a7-ab28-b8a6501fce7d%40googlegroups.com.

Re: Fellow Reports - January 2020

[Mariusz Felisiak]

Week ending January 12, 2020.

*Triaged:*
https://code.djangoproject.com/ticket/31140 - Caching of dict containing 
SafeText objects fails with bmemcached. (invalid)
https://code.djangoproject.com/ticket/31141 - translation.E004 shouldn't be 
raised on sublanguages when a base language is available. (accepted)
https://code.djangoproject.com/ticket/31143 - Variable attribute resolution 
priority in templates. (wontfix)
https://code.djangoproject.com/ticket/31144 - MySQL unique constraints 
incorrectly limited to 255 char when it should be 1000. (wontfix)
https://code.djangoproject.com/ticket/31145 - Session cookie has always the 
"SameSite=Lax" header. (invalid)
https://code.djangoproject.com/ticket/31146 - ManyToManyField with a 
through table are not updated on save in admin when using inlines. (invalid)
https://code.djangoproject.com/ticket/31148 - Raise a descriptive error on 
update()/delete() operations following QuerySet.union(), intersection(), 
and difference(). (accepted)
https://code.djangoproject.com/ticket/31149 - Django Documentation needed 
for 1.9.7. (invalid)
https://code.djangoproject.com/ticket/31152 - Annotating ArrayAgg and 
Subquery crashes with values(). (duplicate)
https://code.djangoproject.com/ticket/31153 - Fix "common" user creation on 
Oracle 12c+. (invalid)
https://code.djangoproject.com/ticket/31154 - Enumeration Types are not 
usable in templates. (accepted)
https://code.djangoproject.com/ticket/31142 - MakeValid() polygon to 
multi-polygon raises error in GEOS C function "GEOSGetNumInteriorRings_r". 
(accepted)
https://code.djangoproject.com/ticket/30274 - Segfault on iteration of GEOS 
Polygons/LinearRings. (accepted)
https://code.djangoproject.com/ticket/31155 - Named groups in choices are 
not properly validated in case of non str typed values. (accepted)
https://code.djangoproject.com/ticket/31158 - 
_password_validators_help_text_html() returns HTML block level element. 
(wontfix)

*Reviewed/committed:*
https://github.com/django/django/pull/11893 - Fixed #11385 -- Made 
forms.DateTimeField accept ISO 8601 date inputs.
https://github.com/django/django/pull/12230 - Fixed #31103 -- Improved 
pagination topic documentation.
https://github.com/django/django/pull/12275 - Fixed #15982 -- Added 
DATE_INPUT_FORMATS to forms.DateTimeField default input formats.
https://github.com/django/django/pull/12276 - Fixed #31118 -- Made 
FileInput to avoid the required attribute when initial data exists.
https://github.com/django/django/pull/12055 - Fixed #21238 -- Fixed 
restoring attributes when pickling FileField and ImageField.
https://github.com/django/django/pull/12299 - Fixed #31148 -- Added error 
messages on update()/delete() operations following union(), intersection(), 
and difference().
https://github.com/django/django/pull/12121 - Fixed #30995 -- Allowed 
converter.to_url() to raise ValueError to indicate no match.
https://github.com/django/django/pull/12304 - Fixed #31154 -- Added support 
for using enumeration types in templates.
https://github.com/django/django/pull/12300 - Fixed #23004 -- Added 
request.META filtering to SafeExceptionReporterFilter.
https://github.com/django/django/pull/12281 - Fixed #30980 -- Improved 
error message when checking uniqueness of admin actions' __name__.
https://github.com/django/django/pull/12302 - Removed unused 
ExceptionReporterFilter class.

*Authored:*
https://github.com/django/django/pull/12283 - Fixed timezones tests for 
PyYAML 5.3+.
https://github.com/django/django/pull/12286 - Fixed #31141 -- Relaxed 
system check of translation settings for sublanguages.
https://github.com/django/django/pull/12306 - Fixed #31155 -- Fixed a 
system check for the longest choice when a named group contains only 
non-string values.

Best regards,
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/72f0-5f2c-432f-8591-3ff26d4fd78b%40googlegroups.com.

Re: How to Start for GSOC 2020 in Django org.

[Carlton Gibson]

Hi. 

I created a Wiki page for GSoC 2020 
https://code.djangoproject.com/wiki/SummerOfCode2020

Check it out. Read over the Project Ideas and the notes for students.
Then I suggest getting involved — now's a great time. :)

Kind Regards,

Carlton


On Monday, 13 January 2020 13:56:13 UTC+1, Priyanshu Panwar wrote:
>
> Hello Everyone.
> Please help me. How do I start for gsoc 2020, though I have a good 
> background in Python and Django as a freelancer.
> 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/4f12a52f-90fb-48e1-9af2-7a39402863a8%40googlegroups.com.

Re: How to Start for GSOC 2020 in Django org.

[Ahmad A. Hussein]

Hi Priyanshu,

I'm a fellow GSoC aspirer. What helped me a lot is checking out the
contributing guide posted on the Django website.

Here is the link:
https://docs.djangoproject.com/en/dev/internals/contributing/

It'll make things a lot easier for you if you've never used Git before and
never tracked tickets in an open-source environment.

You should also try to start contributing as soon as possible to get a feel
for Django's internal codebase.

If you have any other questions, don't hesitate to ask on here. Everyone
here replies promptly.

In the future, try to search for your question before posting a new thread
because this question was asked in three different threads before I
believe.

On Mon, Jan 13, 2020 at 2:56 PM Priyanshu Panwar 
wrote:

> Hello Everyone.
> Please help me. How do I start for gsoc 2020, though I have a good
> background in Python and Django as a freelancer.
> 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/3d87d5a8-ab76-45a7-ab28-b8a6501fce7d%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/CAJNa-uPs-_eoH3e1r0hDuja7VFyG-j4%3DC4CtcEwDKQMd%3DYY5NQ%40mail.gmail.com.

[Feature Request] Allow a Field/DeferredAttribute object everywhere a field name as a string is currently expected

[Matt del Valle]

Hiya,

The title says it all. It would be dead useful if you could always use 
fields rather than the string name of a field, for example in a QuerySet 
order_by(), or in the BaseModelAdmin.ordering class attribute (and probably 
many more locations).

This has the huge advantage of avoiding string literals in your code, which 
allows static code analysis (MyPy, Pycharm's inspections, etc.) tools to 
warn you if you misspell the field name, or if you later rename the field. 
Otherwise such errors end up being hidden until that line of code happens 
to be actually run, which has the potential to slip through testing and end 
up in production. It also allows refactor/rename tools to automatically 
assist with renames in every such location across your Django project, 
saving a lot of time and effort.

It also seems really simple to implement. All you'd need would be a helper 
function that did a few if-elif checks for instances of Field or 
DeferredAttribute, and returned Field.name and DeferredAttribute.field.name 
respectively. It would return strings unchanged to preserve the current 
functionality.

The tricky part would be then tracking down everywhere within Django where 
such field name strings are expected and wrapping the input in this 
function.

Is there any chance something like this could be considered as a new 
feature?

Thanks in advance,
Matt

-- 
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/6e84d486-e2a0-47ca-b8f5-99739be3028a%40googlegroups.com.

Django3.0 / async - use cases

[Vitaliy Kucherivaiy]

Hi Everyone,


In Django 3.0  we have Asynchronous support
But where and how to have any benefit from it at this point ?
(as according to docs views/middlewares/ORM does not support it)

do you have any practical/useful example where async can benefit now ?

~Vitaliy

-- 
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/103a07ef-3d2c-4220-8bed-d97eb4438c72%40googlegroups.com.

Re: Django3.0 / async - use cases

[Adam Johnson]

Hi!

I think you've found the wrong mailing list for this post. This mailing
list is for the development of Django itself, not for support using Django.
This means the discussions of bugs and features in Django itself, rather
than in your code using it. People on this list are unlikely to answer your
support query with their limited time and energy. Read more on the mailing
lists at https://www.djangoproject.com/community/

For support, please use the NEW Django forum at
https://forum.djangoproject.com , django-users mailing list, or IRC #django
on Freenode, or a site like Stack Overflow. There are people out there
willing to help on those channels, but they might not respond if you don't
ask your question well. Stack Overflow's question guide can help you frame
it well: https://stackoverflow.com/help/how-to-ask .

Also if you haven't read it, please take a look at Django's Code of
Conduct: https://www.djangoproject.com/conduct/ . These are our "ground
rules" for working well as a community, and will help you get the most out
of Django and our fantastic community.

Thanks for your understanding,

Adam

On Mon, 13 Jan 2020 at 17:22, Vitaliy Kucherivaiy 
wrote:

> Hi Everyone,
>
>
> In Django 3.0  we have Asynchronous support
> But where and how to have any benefit from it at this point ?
> (as according to docs views/middlewares/ORM does not support it)
>
> do you have any practical/useful example where async can benefit now ?
>
> ~Vitaliy
>
> --
> 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/103a07ef-3d2c-4220-8bed-d97eb4438c72%40googlegroups.com
> 
> .
>


-- 
Adam

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

Re: [Feature Request] Allow a Field/DeferredAttribute object everywhere a field name as a string is currently expected

[Tim Graham]

If I understand correctly, currently this works:

Question.objects.order_by(Question.pub_date.field_name)

but your proposal is to avoid the need for ".field_name". I don't think I'd 
use that syntax as its more verbose and less readable (to me, anyway). 
Having more than one way to write things (string or field reference) isn't 
great for consistency. Strings would still be needed for referencing things 
like annotations.

On Monday, January 13, 2020 at 11:09:39 AM UTC-5, Matt del Valle wrote:
>
> Hiya,
>
> The title says it all. It would be dead useful if you could always use 
> fields rather than the string name of a field, for example in a QuerySet 
> order_by(), or in the BaseModelAdmin.ordering class attribute (and probably 
> many more locations).
>
> This has the huge advantage of avoiding string literals in your code, 
> which allows static code analysis (MyPy, Pycharm's inspections, etc.) tools 
> to warn you if you misspell the field name, or if you later rename the 
> field. Otherwise such errors end up being hidden until that line of code 
> happens to be actually run, which has the potential to slip through testing 
> and end up in production. It also allows refactor/rename tools to 
> automatically assist with renames in every such location across your Django 
> project, saving a lot of time and effort.
>
> It also seems really simple to implement. All you'd need would be a helper 
> function that did a few if-elif checks for instances of Field or 
> DeferredAttribute, and returned Field.name and 
> DeferredAttribute.field.name respectively. It would return strings 
> unchanged to preserve the current functionality.
>
> The tricky part would be then tracking down everywhere within Django where 
> such field name strings are expected and wrapping the input in this 
> function.
>
> Is there any chance something like this could be considered as a new 
> feature?
>
> Thanks in advance,
> Matt
>

-- 
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/5b3dba4c-2bfa-41dd-8190-bcab48616467%40googlegroups.com.

Re: GDAPS

[Christian González]

Eh, sorry if I misunderstand - but adding a "default = true" line to an
AppConfig is the same as addign default_app_config = "foo.apps.FooConfig".

A few things that came to my mind when reading the code:

* You check if there is only one AppConfig available
(https://github.com/django/django/pull/12310/commits/6a4ee2d02477cac1fa67708ceefda2ffd56bbf96#diff-239ff7e40a4b9921b462471882a575f6R111)
and if so, this one is used - that's perfect IMHO.

* But what if 2 AppConfigs have "default = true" ? Then line #139+ is
run, and silently the default app config class is used - none of the two
ones. Maybe an error message would be better. default=true should only
be valid once!

Best regards,

Christian

Am 12.01.20 um 21:42 schrieb Aymeric Augustin:
> Hello,
>
> I created a PR for this: https://github.com/django/django/pull/12310
>
> I'd love to get some feedback on the design before I polish the patch.
>
> Best regards,
>
> -- 
> Aymeric.
>
>
>
>> On 10 Jan 2020, at 14:18, Christian González
>> > > wrote:
>>
>>
>> Am 08.01.20 um 22:39 schrieb Aymeric Augustin:
>>> The original intent was to make configuration explicit by having
>>> settings.py reference directly the target AppConfig class.
>>>
>>> - When you write MIDDLEWARE = ["polls"], do you expect Django to
>>> enable "polls.middleware.PollsMiddleware"?
>>> - When you write INSTALLED_APPS = ["polls"], do you expect Django to
>>> enable "polls.apps.PollsAppConfig"?
>>>
>>> Many readers of this mailing list will answer "no" and "yes"
>>> respectively. I think the answer to both should be "no", according
>>> to Django's design philosophy
>>> .
>>> (If you're about to argue that an application can provide more than
>>> one middleware — I'm aware of this and I know you understood my
>>> point anyway.)
>> Yes, that's exactly what I wanted to state.
>>> [...]
>>>
>>> If we're reversing course, giving up on explicitness and going for
>>> magic, we could embrace that decision fully: import the "apps"
>>> submodule inside each application; if it exists and it defines
>>> exactly one AppConfig subclass, use that as the config for this app.
>>> Then app authors can stop littering their __init__.py files with
>>> default_app_config.
>>
>> That would be perfect IMHO. One could consider restricting it to the
>> same-named subclass like the app itself, so the app "foo" would need
>> to have "FooConfig" as default.
>>
>> I'm aware that this violates the 2nd "Zen of Python" principle
>> "Explicit is better than implicit". and "Special cases aren't special
>> enough to break the rules." - but the next one says: "Although
>> practicality beats purity."
>>
>> Yes, too much "magic" leads to a system where half of it uses magic,
>> and the other half not - so it's not predictable for the developer
>> what a certain line does.
>>
>> But exactly in this part I think that having a "sane default" - in
>> the sense of app loading using by using the app name only - is ok.
>>
>> I would bet that the vast majority of apps don't have two AppConfigs.
>> And to urge all devs to use the more elaborative AppConfig line in
>> INSTALLED_APPS, just to make such special cases (and THESE are the
>> special cases!) are possible, is wrong IMHO.
>>
>> Let it be easy - even the variable says INSTALLED_APPS, not
>> INSTALLED_CONFIGS. And let there be the *possibility *to declare
>> other AppConfigs on demand.
>>
>> Christian
>>
>>
>> -- 
>> Dr. Christian González
>> https://nerdocs.at
>>
>> -- 
>> You received this message because you are subscribed to the Google
>> Groups "Django developers (Contributions to Django itself)" group.
>> To unsubscribe from this group and stop receiving emails from it,
>> send an email to django-developers+unsubscr...@googlegroups.com
>> .
>> To view this discussion on the web visit
>> https://groups.google.com/d/msgid/django-developers/b37e3655-4253-75a1-b750-6c81a0f6cf26%40nerdocs.at
>> .
>
> -- 
> You received this message because you are subscribed to the Google
> Groups "Django developers (Contributions to Django itself)" group.
> To unsubscribe from this group and stop receiving emails from it, send
> an email to django-developers+unsubscr...@googlegroups.com
> .
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/django-developers/A037EBE4-78A7-4037-9E8A-29DCC604CB85%40polytechnique.org
> .

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

-- 
You received this message because you are subscribed to the Google Groups 
"Django

Re: GDAPS

[Christian González]

Oh, sorry, I just saw that this is discussed (andanswered) in the PR.

Am 13.01.20 um 23:03 schrieb Christian González:
>
> Eh, sorry if I misunderstand - but adding a "default = true" line to
> an AppConfig is the same as addign default_app_config =
> "foo.apps.FooConfig".
>
> A few things that came to my mind when reading the code:
>
> * You check if there is only one AppConfig available
> (https://github.com/django/django/pull/12310/commits/6a4ee2d02477cac1fa67708ceefda2ffd56bbf96#diff-239ff7e40a4b9921b462471882a575f6R111)
> and if so, this one is used - that's perfect IMHO.
>
> * But what if 2 AppConfigs have "default = true" ? Then line #139+ is
> run, and silently the default app config class is used - none of the
> two ones. Maybe an error message would be better. default=true should
> only be valid once!
>
> Best regards,
>
> Christian
>
> Am 12.01.20 um 21:42 schrieb Aymeric Augustin:
>> Hello,
>>
>> I created a PR for this: https://github.com/django/django/pull/12310
>>
>> I'd love to get some feedback on the design before I polish the patch.
>>
>> Best regards,
>>
>> -- 
>> Aymeric.
>>
>>
>>
>>> On 10 Jan 2020, at 14:18, Christian González
>>> >> > wrote:
>>>
>>>
>>> Am 08.01.20 um 22:39 schrieb Aymeric Augustin:
 The original intent was to make configuration explicit by having
 settings.py reference directly the target AppConfig class.

 - When you write MIDDLEWARE = ["polls"], do you expect Django to
 enable "polls.middleware.PollsMiddleware"?
 - When you write INSTALLED_APPS = ["polls"], do you expect Django
 to enable "polls.apps.PollsAppConfig"?

 Many readers of this mailing list will answer "no" and "yes"
 respectively. I think the answer to both should be "no", according
 to Django's design philosophy
 .
 (If you're about to argue that an application can provide more than
 one middleware — I'm aware of this and I know you understood my
 point anyway.)
>>> Yes, that's exactly what I wanted to state.
 [...]

 If we're reversing course, giving up on explicitness and going for
 magic, we could embrace that decision fully: import the "apps"
 submodule inside each application; if it exists and it defines
 exactly one AppConfig subclass, use that as the config for this
 app. Then app authors can stop littering their __init__.py files
 with default_app_config.
>>>
>>> That would be perfect IMHO. One could consider restricting it to the
>>> same-named subclass like the app itself, so the app "foo" would need
>>> to have "FooConfig" as default.
>>>
>>> I'm aware that this violates the 2nd "Zen of Python" principle
>>> "Explicit is better than implicit". and "Special cases aren't
>>> special enough to break the rules." - but the next one says:
>>> "Although practicality beats purity."
>>>
>>> Yes, too much "magic" leads to a system where half of it uses magic,
>>> and the other half not - so it's not predictable for the developer
>>> what a certain line does.
>>>
>>> But exactly in this part I think that having a "sane default" - in
>>> the sense of app loading using by using the app name only - is ok.
>>>
>>> I would bet that the vast majority of apps don't have two AppConfigs.
>>> And to urge all devs to use the more elaborative AppConfig line in
>>> INSTALLED_APPS, just to make such special cases (and THESE are the
>>> special cases!) are possible, is wrong IMHO.
>>>
>>> Let it be easy - even the variable says INSTALLED_APPS, not
>>> INSTALLED_CONFIGS. And let there be the *possibility *to declare
>>> other AppConfigs on demand.
>>>
>>> Christian
>>>
>>>
>>> -- 
>>> Dr. Christian González
>>> https://nerdocs.at
>>>
>>> -- 
>>> You received this message because you are subscribed to the Google
>>> Groups "Django developers (Contributions to Django itself)" group.
>>> To unsubscribe from this group and stop receiving emails from it,
>>> send an email to django-developers+unsubscr...@googlegroups.com
>>> .
>>> To view this discussion on the web visit
>>> https://groups.google.com/d/msgid/django-developers/b37e3655-4253-75a1-b750-6c81a0f6cf26%40nerdocs.at
>>> .
>>
>> -- 
>> You received this message because you are subscribed to the Google
>> Groups "Django developers (Contributions to Django itself)" group.
>> To unsubscribe from this group and stop receiving emails from it,
>> send an email to django-developers+unsubscr...@googlegroups.com
>> .
>> To view this discussion on the web visit
>> https://groups.google.com/d/msgid/django-developers/A037EBE4-78A7-4037-9E8A-29DCC604CB85%40polytechnique.org
>>