Re: Technical Board vote on DEP 0012: The Steering Council

[Mariusz Felisiak]

Thanks!

Reminder: according to DEP 10 voting will end on *December 2nd, 2022* *AoE* 
(members of the Technical Board may change their votes at any time prior to 
closing of the final voting period).

-- 
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/8215786d-0ccf-48af-8220-21e23178e4d9n%40googlegroups.com.

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

['Adam Johnson' via Django developers (Contributions to Django itself)]

Four ideas from myself:

1. CORS in core

django-cors-headers’ implementation is a bit janky, for example it uses a
regex to filter paths. It also lacks the key ability to set up different
CORS policies per path. Both of these could be done with a decorator.

I’d like to see a form of CORS support in Django that more closely follows
the design of the CSRF/clickjacking protection.

2. django-stubs strict mode.

The stubs do not currently pass Mypy’s strict mode. Doing so would enable
users to always use strict mode with them, improving type safety. I think
the other maintainers of django-stubs are also interested in this.

3. Better DatabaseCache

Setting up a shared cache backend is nearly always required, as many third
party packages assume the cache works like this (unlike the default
locmemcache which is per process). DatabaseCache is the easiest such cache
backend, not requiring any extra infra and working on shared hosts without
a filesystem. But it could be better.

Django-Mysql has had a much better DB cache backend implementation since
2015:
https://adamj.eu/tech/2015/05/17/building-a-better-databasecache-for-django-on-mysql/
. I’ve never got around to adapting this for postgres/sqlite but it should
be fairly straightforward, mostly some translation of SQL to different
dialects.

It would also be nice to hook the database cache tables into migrations
somehow rather than the current hacky duck typing approach (
https://github.com/django/django/blob/64b3c413da011f55469165256261f406a277e822/django/core/cache/backends/db.py#L12-L28
).

4. Auto-importing shell

One of the most popular features of django-extensions is shell_plus, which
is like 'shell' but auto-imports your models for you. This behaviour would
be great to have in core, with a way to define extra things to import
(perhaps a documented path of subclassing the management command and
overriding a method).

On Wed, Nov 16, 2022 at 7:13 PM Matthew Pava  wrote:

> 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 <
> 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 
> 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
> 

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

[James Bennett]

On Fri, Nov 25, 2022 at 2:32 PM 'Adam Johnson' via Django developers 1.
CORS in core

>
> django-cors-headers’ implementation is a bit janky, for example it uses a
> regex to filter paths. It also lacks the key ability to set up different
> CORS policies per path. Both of these could be done with a decorator.
>
> I’d like to see a form of CORS support in Django that more closely follows
> the design of the CSRF/clickjacking protection.
>
>> Another option: Content Security Policy support in core. The current
django-csp third-party app isn't necessarily bad, but I'd love to see more
good security tools in Django by default.

(some of this gets back to an old proposal for a consolidated top-level
SECURITY setting that could expand to cover all the tools, but that's
likely out of scope for a GSoC project)

-- 
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/CAL13Cg8zZZizDRvQCKfe4KS_tPS1zOyW-%3DZSQmj0MkZ7EGnGQA%40mail.gmail.com.