Re: Fellow Reports - November 2022

[Mariusz Felisiak]

Week ending November 13, 2022 

*Triaged: *
   https://code.djangoproject.com/ticket/34143 - Multiple file upload docs 
(invalid) 
   https://code.djangoproject.com/ticket/34131 - Postgres AutoField change 
from serial to identity (invalid) 
   https://code.djangoproject.com/ticket/34144 - Casting a string inside a 
JSONField into an integer does not work on PostgreSQL (invalid) 
   https://code.djangoproject.com/ticket/34147 - Add aall() for related 
managers. (created) 
   https://code.djangoproject.com/ticket/34150 - Add "View on site" links 
to generic common model URL and also to common url for app. (wontfix) 
   https://code.djangoproject.com/ticket/34151 - Adding explicit primary 
key with different type doesn't update related ManyToManyFields. (accepted) 
   https://code.djangoproject.com/ticket/34153 - Set uuidField as 
DEFAULT_AUTO_FIELD (duplicate) 

*Reviewed/committed: *
   https://github.com/django/django/pull/16255 - Fixed #34088 -- Fixed 
Sitemap.get_latest_lastmod() crash with empty items. 
   https://github.com/django/django/pull/16260 - Fixed #34137 -- Made 
Model.refresh_from_db() clear cached generic relations. 
   https://github.com/django/django/pull/16267 - Refs #27849 -- Fixed 
filtered aggregates crash on filters that match everything. 
   https://github.com/django/django/pull/16258 - Fixed #31331 -- Switched 
MySQL to group by selected primary keys. 
   https://github.com/django/django/pull/16264 - Refs #33308 -- Improved 
adapting DecimalField values to decimal. 
   https://github.com/django/django/pull/16266 - Refs #33374 -- Adjusted 
full match condition handling. 
   https://github.com/django/django/pull/16256 - Fixed #34139 -- Fixed 
acreate(), aget_or_create(), and aupdate_or_create() methods for related 
managers. 
   https://github.com/django/django/pull/16243 - Fixed #10070 -- Added 
support for pyformat style parameters on SQLite. 
   https://github.com/django/django/pull/16270 - Used 
super().execute/executemany() in SQLiteCursorWrapper. 
   https://github.com/django/django/pull/16252 - Fixed #34135 -- Added 
async-compatible interface to related managers. 
   https://github.com/django/django/pull/16263 - Fixed #28477 -- Stripped 
unused annotations on aggregation. 
   https://github.com/django/django/pull/16278 - Fixed #34149 -- Allowed 
adding deferrable conditional exclusion constraints on PostgreSQL. 
   https://github.com/django/django/pull/16246 - Improved readability of 
string interpolation in frequently used examples in docs. 
   https://github.com/django/django/pull/16257 - Updated documentation and 
comments for RFC updates. 
   https://github.com/django/django/pull/16282 - Refs #34110 -- Reorganized 
django.core.files.storage into a separate module. 
   https://github.com/django/django/pull/16277 - Refs #28477 -- Reduced 
complexity of aggregation over qualify queries.

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/921d8d86-46d4-484c-ad7e-adf13bfa5864n%40googlegroups.com.

Re: [Technical Board?] Project Ideas, and beginning GSoC 2023.

[Florian Apolloner]

I do have ideas but no idea about how viable they are in a GSoC context. 
Nevertheless I will put write them down here, maybe we can find smaller 
scopes if needed and if not, it still serves as a list of things that I'd 
think to be interesting:

 * Probably my number one since it kinda is a blocker for me: We need a 
connection pool in Django for async to work. That said connection pools are 
hard to get right ( 
https://github.com/brettwooldridge/HikariCP/blob/dev/documents/Welcome-To-The-Jungle.md
 
and https://www.psycopg.org/articles/2021/01/17/pool-design/ ).
 * Production ready webserver 
(https://groups.google.com/g/django-developers/c/q20_Cxske88). Maybe only 
focus on a smaller part first, like reading env variables / config files.
 * Depending on how far we get with `request.data` in the meantime, maybe 
put the second steps (adjustable parsers etc) in as GSoC project?
 * I haven't talked with anyone about this one yet, so it might be 
completely bonkers: I think openid connect is here to stay for a while and 
I'd love to see first class support in core for it. I am looking at this 
from an enterprise perspective though; I do not expect a user to choose 
where to login out of many options but rather provide a replacement for the 
default username/password login in an enterprise environment. Most 
solutions there support openid connect. Please note that I am not 
suggesting to support generic OAuth2/SAML and whatnot -- there are great 
3rd party packages for that already (which also include support for openid 
connect). I'd just love to be able to install arbitrary Django projects and 
point them to the central authentication server.

I hope this provides some ideas to get more ideas rolling :)

Cheers,
Florian 


On Tuesday, November 15, 2022 at 10:11:45 AM UTC+1 carlton...@gmail.com 
wrote:

> Hi all. 
>
> Google Summer of Code (GSoC) for 2023 has just been announced. 
>
> https://opensource.googleblog.com/2022/11/get-ready-for-google-summer-of-code-2023.html
>
> Django has participated many times, and it's been a real boon. Recent 
> successes include: 
>
> * The django-stubs mypy plugin. 
> * The cross-db JSON field. 
> * The Redis cache backend. 
> * Per model-class (field instance) custom lookups
> * Setup of the django-asv benchmarking project. 
> * ... 
>
> Application deadline for Orgs is February 7. I'll begin working on it 
> after the New Year. 
>
> Main bit is an ideas list for projects. The GSoC guide has a Writing a 
> Good Ideas List
> section. 
>
> > Projects should take ~175 hours or ~350 hours for GSoC contributors to 
> complete. 
>
> i.e. "short" or "long" projects. 
> https://google.github.io/gsocguides/mentor/defining-a-project-ideas-list
>
> I'm writing here *to solicit input on project ideas*. 
>
> I put "Technical Board?" in the subject because we're short a list of 
> project
> ideas for the technical direction of Django going forward, and maybe 
> thinking
> in terms of GSoC could be a way of bootstrapping that. The "?" is because 
> that's not 
> meant to exclude other input.
>
> Here's last year's list for reference: 
> https://code.djangoproject.com/wiki/SummerOfCode2022
>
> - Some of those were done: benchmarking (but that could be built on) and 
> per-instance 
>   field lookups.
>
> - Rate-limiting is a no-go I think: we couldn't come to any decent 
> agreement on scope, 
>   so it's better to live as a third-party package. 
>
> - I've tried to include folks from the wider ecosystem in previous years. 
> Two years ago 
>   we had both Wagtail and django-stubs projects. Wagtail then (last year)
>   applied in their own right, to great success. I'd like to offer that help
>   again to e.g. Jazzband or other established projects, assuming 
> maintainers
>   feel they have the capacity to mentor. (It's a minor increment to my 
> effort
>   for a good return I think.)
>
>
> No urgency but, can I ask you to put your grey cells into action? 🙂
>
>
> Thanks. 
>
> Kind Regards,
>
> Carlton
>

-- 
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/2b3650c6-d340-4464-96f2-e6722a8e415an%40googlegroups.com.

Re: [Technical Board?] Project Ideas, and beginning GSoC 2023.

[Carlton Gibson]

Thanks Florian

To you and all :) — casting the net wide right now is a good way forward I
think.
We can scope down for GSoC with some ideas on the table.

(Don't be shy folks. :)

Kind Regards,

Carlton

On Wed, 16 Nov 2022 at 19:52, Florian Apolloner 
wrote:

> I do have ideas but no idea about how viable they are in a GSoC context.
> Nevertheless I will put write them down here, maybe we can find smaller
> scopes if needed and if not, it still serves as a list of things that I'd
> think to be interesting:
>
>  * Probably my number one since it kinda is a blocker for me: We need a
> connection pool in Django for async to work. That said connection pools are
> hard to get right (
> https://github.com/brettwooldridge/HikariCP/blob/dev/documents/Welcome-To-The-Jungle.md
> and https://www.psycopg.org/articles/2021/01/17/pool-design/ ).
>  * Production ready webserver (
> https://groups.google.com/g/django-developers/c/q20_Cxske88). Maybe only
> focus on a smaller part first, like reading env variables / config files.
>  * Depending on how far we get with `request.data` in the meantime, maybe
> put the second steps (adjustable parsers etc) in as GSoC project?
>  * I haven't talked with anyone about this one yet, so it might be
> completely bonkers: I think openid connect is here to stay for a while and
> I'd love to see first class support in core for it. I am looking at this
> from an enterprise perspective though; I do not expect a user to choose
> where to login out of many options but rather provide a replacement for the
> default username/password login in an enterprise environment. Most
> solutions there support openid connect. Please note that I am not
> suggesting to support generic OAuth2/SAML and whatnot -- there are great
> 3rd party packages for that already (which also include support for openid
> connect). I'd just love to be able to install arbitrary Django projects and
> point them to the central authentication server.
>
> I hope this provides some ideas to get more ideas rolling :)
>
> Cheers,
> Florian
>
>
> On Tuesday, November 15, 2022 at 10:11:45 AM UTC+1 carlton...@gmail.com
> wrote:
>
>> Hi all.
>>
>> Google Summer of Code (GSoC) for 2023 has just been announced.
>>
>> https://opensource.googleblog.com/2022/11/get-ready-for-google-summer-of-code-2023.html
>>
>> Django has participated many times, and it's been a real boon. Recent
>> successes include:
>>
>> * The django-stubs mypy plugin.
>> * The cross-db JSON field.
>> * The Redis cache backend.
>> * Per model-class (field instance) custom lookups
>> * Setup of the django-asv benchmarking project.
>> * ...
>>
>> Application deadline for Orgs is February 7. I'll begin working on it
>> after the New Year.
>>
>> Main bit is an ideas list for projects. The GSoC guide has a Writing a
>> Good Ideas List
>> section.
>>
>> > Projects should take ~175 hours or ~350 hours for GSoC contributors to
>> complete.
>>
>> i.e. "short" or "long" projects.
>> https://google.github.io/gsocguides/mentor/defining-a-project-ideas-list
>>
>> I'm writing here *to solicit input on project ideas*.
>>
>> I put "Technical Board?" in the subject because we're short a list of
>> project
>> ideas for the technical direction of Django going forward, and maybe
>> thinking
>> in terms of GSoC could be a way of bootstrapping that. The "?" is because
>> that's not
>> meant to exclude other input.
>>
>> Here's last year's list for reference:
>> https://code.djangoproject.com/wiki/SummerOfCode2022
>>
>> - Some of those were done: benchmarking (but that could be built on) and
>> per-instance
>>   field lookups.
>>
>> - Rate-limiting is a no-go I think: we couldn't come to any decent
>> agreement on scope,
>>   so it's better to live as a third-party package.
>>
>> - I've tried to include folks from the wider ecosystem in previous years.
>> Two years ago
>>   we had both Wagtail and django-stubs projects. Wagtail then (last year)
>>   applied in their own right, to great success. I'd like to offer that
>> help
>>   again to e.g. Jazzband or other established projects, assuming
>> maintainers
>>   feel they have the capacity to mentor. (It's a minor increment to my
>> effort
>>   for a good return I think.)
>>
>>
>> No urgency but, can I ask you to put your grey cells into action? 🙂
>>
>>
>> Thanks.
>>
>> Kind Regards,
>>
>> Carlton
>>
> --
> 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/2b3650c6-d340-4464-96f2-e6722a8e415an%40googlegroups.com
> 
> .
>

-- 
You received this message because you are subscribed to the G

RE: [Technical Board?] Project Ideas, and beginning GSoC 2023.

[Matthew Pava]

I’m not on the technical board or of any important part of the Django ecosystem 
at all, but I do have an idea. It would be nice to revamp the “name” field in 
the default user model, perhaps to have one field for the name as suggested 
here from the W3C:
https://www.w3.org/International/questions/qa-personal-names

I remember reading elsewhere that there were various important reasons that 
prevented Django from making such a change. Perhaps it would be a good time to 
review that? If there is too much controversy for having a name field at all, 
perhaps eliminating it is the way to go and just have a username field?

Of course, this may go hand-in-hand with Florian’s suggestion of using OpenID 
Connect.

From: django-developers@googlegroups.com  
On Behalf Of Carlton Gibson
Sent: Wednesday, November 16, 2022 12:58 PM
To: django-developers@googlegroups.com
Subject: Re: [Technical Board?] Project Ideas, and beginning GSoC 2023.

Thanks Florian

To you and all :) — casting the net wide right now is a good way forward I 
think.
We can scope down for GSoC with some ideas on the table.

(Don't be shy folks. :)

Kind Regards,

Carlton

On Wed, 16 Nov 2022 at 19:52, Florian Apolloner 
mailto:f.apollo...@gmail.com>> wrote:
I do have ideas but no idea about how viable they are in a GSoC context. 
Nevertheless I will put write them down here, maybe we can find smaller scopes 
if needed and if not, it still serves as a list of things that I'd think to be 
interesting:

 * Probably my number one since it kinda is a blocker for me: We need a 
connection pool in Django for async to work. That said connection pools are 
hard to get right ( 
https://github.com/brettwooldridge/HikariCP/blob/dev/documents/Welcome-To-The-Jungle.md
 and 
https://www.psycopg.org/articles/2021/01/17/pool-design/
 ).
 * Production ready webserver 
(https://groups.google.com/g/django-developers/c/q20_Cxske88).
 Maybe only focus on a smaller part first, like reading env variables / config 
files.
 * Depending on how far we get with `request.data` in the meantime, maybe put 
the second steps (adjustable parsers etc) in as GSoC project?
 * I haven't talked with anyone about this one yet, so it might be completely 
bonkers: I think openid connect is here to stay for a while and I'd love to see 
first class support in core for it. I am looking at this from an enterprise 
perspective though; I do not expect a user to choose where to login out of many 
options but rather provide a replacement for the default username/password 
login in an enterprise environment. Most solutions there support openid 
connect. Please note that I am not suggesting to support generic OAuth2/SAML 
and whatnot -- there are great 3rd party packages for that already (which also 
include support for openid connect). I'd just love to be able to install 
arbitrary Django projects and point them to the central authentication server.

I hope this provides some ideas to get more ideas rolling :)

Cheers,
Florian


On Tuesday, November 15, 2022 at 10:11:45 AM UTC+1 
carlton...@gmail.com wrote:
Hi all.

Google Summer of Code (GSoC) for 2023 has just been announced.
https://opensource.googleblog.com/2022/11/get-ready-for-google-summer-of-code-2023.html

Django has participated many times, and it's been a r

Re: Making max_length argument optional

[Adrian Torres]

I finally had some time to do some work on this and have submitted a patch 
at https://github.com/django/django/pull/16302 in case anyone is interested.

On Wednesday, October 5, 2022 at 2:24:35 PM UTC+2 carlton...@gmail.com 
wrote:

> Hi Adrian. 
>  
> Nothing has been done, no. 
>
> There seem to be a few competing options: 
>
> 1. Allow max_length=None on Postgres (using a 
> supports_unlimited_charfields, name!?, DB backend feature flag maybe 🤔)
> 2. Add an unlimited flag to CharField. 
> 3. Have a subclass in contrib.postgres, similar to JKM's version Tom 
> linked before 
> 
>
> My guess would be 1 or 3. (I'd rather 3 than 2.) So proof-of-concepts 
> implementing those would be the way forward I think. 
>
> Kind Regards,
>
> Carlton
>
>
> On Wed, 5 Oct 2022 at 12:47, Adrian Torres  wrote:
>
>> Sorry for reviving the thread but just ran into this issue again and 
>> wanted to ask, has there anything been done to address this?
>>
>> For me having max_length=None mean "unlimited varchar" for Postgres and 
>> being an error for any other database (or those that don't support 
>> unlimited varchar) is the best solution, but I'm also ok with Carlton's 
>> idea of having a subclass in contrib.postgres is an acceptable compromise.
>>
>> Cheers,
>> Adrian
>>
>> On Monday, August 17, 2020 at 11:26:39 AM UTC+2 t...@carrick.eu wrote:
>>
>>> It would work for my use-cases. It was mentioned that it's maybe not the 
>>> best as a lot of fields subclass CharField, but I don't see a compelling 
>>> argument for an unlimited email or slug field. The one problem I see is 
>>> CICharField, you might want to make that unlimited - but the CI fields are 
>>> more or less redundant on pg >= 12 once we have column collations in. So I 
>>> think it's okay for now. Only problem I can see is if we add more CharField 
>>> subclasses in the future...
>>>
>>> On Mon, 17 Aug 2020 at 11:02, Carlton Gibson  
>>> wrote:
>>>
 Would the subclass in contrib.postgres suggestion be acceptable? 

 On Mon, 17 Aug 2020 at 10:31, Tom Carrick  wrote:

> I'm not a fan of any solution either, really, even the one I suggested.
>
> I think adding a new kwarg, "unlimited" seems okay to me, though it 
> feels a little redundant.
>
> I don't like the idea of using TextField, I find them semantically 
> different. An unlimited varchar says to me "one possibly very long 
> thing", 
> whereas TextField feels more like it's free text, or a document, 
> especially 
> as the form fields are different. Subclassing CharField is an option, but 
> the methods I've seen to do this makes it annoying. I need this so often 
> that I do it all the time, but the code is so short that I don't want to 
> bring in a new package to do it. Also, the popular ways to do this are 
> not 
> great. One way is to just set the max_length extremely high, which is not 
> what I want ending up in the database, the other is something like 
> this , 
> which works well, but will stop working well once column collations are 
> in 
> as that PR adds more stuff to CharField.__init__().
>
> I think it's time we had something in Django, whatever that ends up 
> being.
>
> On Sun, 16 Aug 2020 at 20:28, Carlton Gibson  
> wrote:
>
>> Reading the history, I see an awful lot of -1s to the idea of a 
>> default. 
>>
>> I see “use a TextField” and “use a subclass” a few times, which were 
>> my immediate thoughts just on the recent emails. 
>>
>> On Sun, 16 Aug 2020 at 18:47, Tom Forbes  wrote:
>>
>>> I’m not a fan of implicit max_lengths. Is having to add a keyword 
>>> argument to a model field really that much of a burden? And we also 
>>> would 
>>> likely never be able to change the default without headaches.
>>>
>>> On 12 Aug 2020, at 13:19, t...@carrick.eu  wrote:
>>>
>>> I'd like to revive this discussion and try to come to a consensus as 
>>> it's something I find myself wishing for (for Postgres in particular).
>>>
>>> My suggestion, after reading through everything:
>>>
>>> Give CharField a default max_length that is consistent across all 
>>> vendors. It doesn't really matter what the number is other than that it 
>>> should be large enough to be useful but small enough to work 
>>> everywhere. I 
>>> think 100 or 255 are both fine options.
>>>
>>> If you set max_length=None explicitly, on Postgres this will use an 
>>> unlimited varchar, on everything else will raise an exception on 
>>> migrate.
>>>
>>> Any thoughts?
>>>
>>> Cheers,
>>> Tom
>>>
>>> On Saturday, March 5, 2016 at 2:13:14 PM UTC+1 Shai Berger wrote:
>>>
 On Saturday 

Re: Fellow Reports - November 2022

[Jerwin Montellano]

Thank you!

On Wed, Nov 16, 2022 at 9:04 PM Mariusz Felisiak 
wrote:

> Week ending November 13, 2022
>
> *Triaged: *
>https://code.djangoproject.com/ticket/34143 - Multiple file upload
> docs (invalid)
>https://code.djangoproject.com/ticket/34131 - Postgres AutoField
> change from serial to identity (invalid)
>https://code.djangoproject.com/ticket/34144 - Casting a string inside
> a JSONField into an integer does not work on PostgreSQL (invalid)
>https://code.djangoproject.com/ticket/34147 - Add aall() for related
> managers. (created)
>https://code.djangoproject.com/ticket/34150 - Add "View on site" links
> to generic common model URL and also to common url for app. (wontfix)
>https://code.djangoproject.com/ticket/34151 - Adding explicit primary
> key with different type doesn't update related ManyToManyFields. (accepted)
>https://code.djangoproject.com/ticket/34153 - Set uuidField as
> DEFAULT_AUTO_FIELD (duplicate)
>
> *Reviewed/committed: *
>https://github.com/django/django/pull/16255 - Fixed #34088 -- Fixed
> Sitemap.get_latest_lastmod() crash with empty items.
>https://github.com/django/django/pull/16260 - Fixed #34137 -- Made
> Model.refresh_from_db() clear cached generic relations.
>https://github.com/django/django/pull/16267 - Refs #27849 -- Fixed
> filtered aggregates crash on filters that match everything.
>https://github.com/django/django/pull/16258 - Fixed #31331 -- Switched
> MySQL to group by selected primary keys.
>https://github.com/django/django/pull/16264 - Refs #33308 -- Improved
> adapting DecimalField values to decimal.
>https://github.com/django/django/pull/16266 - Refs #33374 -- Adjusted
> full match condition handling.
>https://github.com/django/django/pull/16256 - Fixed #34139 -- Fixed
> acreate(), aget_or_create(), and aupdate_or_create() methods for related
> managers.
>https://github.com/django/django/pull/16243 - Fixed #10070 -- Added
> support for pyformat style parameters on SQLite.
>https://github.com/django/django/pull/16270 - Used
> super().execute/executemany() in SQLiteCursorWrapper.
>https://github.com/django/django/pull/16252 - Fixed #34135 -- Added
> async-compatible interface to related managers.
>https://github.com/django/django/pull/16263 - Fixed #28477 -- Stripped
> unused annotations on aggregation.
>https://github.com/django/django/pull/16278 - Fixed #34149 -- Allowed
> adding deferrable conditional exclusion constraints on PostgreSQL.
>https://github.com/django/django/pull/16246 - Improved readability of
> string interpolation in frequently used examples in docs.
>https://github.com/django/django/pull/16257 - Updated documentation
> and comments for RFC updates.
>https://github.com/django/django/pull/16282 - Refs #34110 --
> Reorganized django.core.files.storage into a separate module.
>https://github.com/django/django/pull/16277 - Refs #28477 -- Reduced
> complexity of aggregation over qualify queries.
>
> 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/921d8d86-46d4-484c-ad7e-adf13bfa5864n%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/CALPnNBTpjxeUHtn32thJvPOFfUyu6-dMO3rRMXL_Q3gVELqDTQ%40mail.gmail.com.