Re: How do you set the python path for django-admin?

[Carlton Gibson]

Hi tobias.

The django-admin command has a `--pythonpath` option for this (docs

).

So, for example in a 3rd party package using the src layout (example
) where the module itself is
installed in the venv, but the tests module is at the package root, you can
run the tests like:

django-admin test --settings=tests.settings --pythonpath=.

HTH.

Kind Regards,

Carlton

On Wed, 8 Nov 2023 at 20:18, Tobias Bengfort 
wrote:

> Hi everyone,
>
> https://docs.djangoproject.com/en/4.2/ref/django-admin/ claims that
> manage.py, django-admin and python -m django are practically
> interchangable. However, I noticed that they behave differently when it
> comes to the python path (the path you can import modules from). I used
> `CMD shell -c 'import sys; print(sys.path[0])' to check each one:
>
> - `manage.py` adds its own location to the python path. That is fine
> because `django-admin startproject` puts it right next to the project
> directory.
>
> - `django-admin` also adds its own location to the python path. That is
> less fine because that is usualy something like /some/venv/bin/, so the
> project package is not importable. Simply running `django-admin
> runserver --settings=example.settings` fails with `ModuleNotFoundError:
> No module named 'example'`.
>
> - `python -m django` uses the current directory, which is slightly less
> useful than manage.py, but quite intuitive.
>
> Of course you can circumvent all of this by setting PYTHONPATH explicitly.
>
> I personally was burned by this because I use `pip install -e` to add
> the folder containing the project directory to the python path. However,
> when switching to PEP 517 based packaging, the behavior changed and some
> modules could no longer be imported.
>
> is there any official recommendation about this? My impression was
> always that manage.py is meant for development and django-admin is meant
> for production. But how are you supposed to set the python path in that
> case? Is this assumption even correct? I could not find anything about
> it in the docs.
>
> In any case, I think the docs need an update because currently, all
> examples use `django-admin`, which does not work out of the box in my
> experience.
>
> thanks,
> tobias
>
> --
> 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/2b27a633-f658-4fe8-ab41-d553890b03c6%40posteo.de
> .
>

-- 
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/CAJwKpyT2onzVkQ3MdGQR83uPxs_7GG5Zb%2BsZtzwy7gR1-6-aHA%40mail.gmail.com.

Re: Disabling dark / light mode UI toggle

[Carlton Gibson]

Quite likely not, but such a niche feature isn’t worth the extra API
surface area, I’d likely think.

On Wednesday, 9 August 2023, Niccolò Mineo  wrote:

> Yes, not pretty, though, right?
>
> Il giorno martedì 8 agosto 2023 alle 07:33:12 UTC+2 Adam Johnson ha
> scritto:
>
>> You should be able to disable the button by creating an empty
>> admin/color_theme_toggle.html template in your project.
>>
>> On Mon, Aug 7, 2023 at 10:28 PM Niccolò Mineo 
>> wrote:
>>
>>> * I haven't found a convenient way, that is.
>>>
>>> Il giorno lunedì 7 agosto 2023 alle 23:26:11 UTC+2 Niccolò Mineo ha
>>> scritto:
>>>
 There is a specific situation in which I wouldn't want the user to be
 able to toggle between dark and light mode for the admin theme, and that is
 if I heavily customized it. I haven't found a way to disable that specific
 toggle, so I suggest that an *AdminSite.ui_toggle* (or the like)
 boolean be added. What do you think?
>>>
>>> --
>>> 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/7f09013b-02db-40bf-928f-
>>> 83a737dec069n%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/47774b6a-a783-47cf-8229-
> 299f891c1b32n%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/CAJwKpySuGR1vOEdSfeu2Kbu-YzKfFOfTXRBfM%3D8DjMWJvnojYg%40mail.gmail.com.

Re: Proposing the removal of Oracle from the Django supported backend databases

[Carlton Gibson]

Thanks for raising this Paolo. It's good to discuss, even if we maintain
the status quo.

I think this will come to a head when Mariusz steps away. It's been him
that's kept it going the last few years, and I'm not at all sure that we
have another currently active contributor that's an Oracle expert. (Perhaps
we do... 🤔)

It's good to see Chris' comment that Oracle wish to contribute themselves,
but if that doesn't materialise, we're going to need to claim *force
majeure*.

Q: Are we sure we can maintain Oracle without Mariusz? What does that look
like? If not, we need to make plans for something else.


FWIW: If possible I'd like to keep Oracle support if we can — it's good for
the ORM.
(If we could see a way of it being maintainable, I'd have us add SQL Server
in core too — but I don't think that is feasible given the state of play
today).


The difference with Windows (of course) is that we have lots of
contributors using it.


Kind Regards,

Carlton

On Fri, 4 Aug 2023 at 15:19, Paolo Melchiorre  wrote:

> Hi Mariusz,
>
> On Thu, Aug 3, 2023 at 8:47 PM Mariusz Felisiak
>  wrote:
> > I'm quite surprised that you've started a new thread for something that
> was already discussed, you could always add a comment to the existing
> thread e.g.
> https://groups.google.com/g/django-developers/c/dg8BUVHKOo4/m/5uFVmdWCAwAJ
>
> I was not aware of this thread, thanks for linking it.
>
> >> I wanted to share the frustration of seeing yet another great new ORM
> feature blocked due to Oracle compatibility:
> https://github.com/django/django/pull/16417
> > I'm not sure how you reached this conclusion. This is not blocked due
> because of Oracle compatibility. I will review it and try to merge it
> before the Django 5.0 feature freeze. You have to be patient, it has
> nothing to do with Oracle
>
> It was not my intention to push you into reviewing this PR given how
> much you already do. But it seems to me that without Oracle
> compatibility this functionality would have been ready for a long
> time. However, this reflection of mine was born after seeing the
> difficulty of the original contributor to add support to Oracle, at
> the same time I also watch again Carlton's keynote at PyCon Italia
> 2023 because the videos have recently been published. Lastly, while
> volunteering at the DSF booth at EuroPython 2023, I happened to meet
> an Oracle Django developer for the first time, who admitted that he
> had never contributed to the Oracle backend itself.
>
> >> Over the last few months, I've tried to encourage newcomers and young
> users to contribute to Django and they almost always ran into the need to
> provide compatibility to Oracle, so much so that they eventually gave up
> contributing.
> > Really? Django is not only the ORM. It is easy to demonize Oracle. I'm
> working with contributors on daily basis, and  don't remember anyone who
> would resign because we have builtin Oracle backend. We don't have much
> more open tickets in the Oracle backend then in others. The number of
> unsupported features is similar to SQLite or MySQL.
>
> In my personal experience, the people I collaborate with at work or
> meet in the local communities where I go to talk about Django all have
> experience with Open Source databases and none have ever worked with
> Oracle, which makes it very difficult for them to try to contribute in
> Django's ORM why should they ensure compatibility for this DB without
> ever having seen it.
>
> >> The point is that I think Oracle is a historical anomaly among the
> database backends supported by Django because it is the only one that is
> not Open Source, it has irrelevant usage numbers
> > It's not an anomaly. Oracle support was a conscious decision, keeping
> the ORM features Oracle-compatible is a good battlefield, that helps
> keeping the ORM friendly for 3rd-party database backends as we have more
> feature flags and hooks for custom behaviors.
>
> I think this would be the same if the Oracle backend was a third-party
> package, perhaps maintained by the same company
>
> >> ... and the company that earns from it does not contribute in any way
> to its maintenance or support
> > Should be also drop support for Windows for exactly the same reason?
> (rhetorical question)
>
> I don't know, I haven't used Windows since 2000 :-)
>
> Anyway, tornado to talk about Database, SQL Server is a third-party package
>
> >> I, therefore, suggest that we start a discussion on removing Oracle
> from supported databases.
> > This was already discussed. I'm still strongly against it.
>
> Thank you for your point of view, and also for all the extra work you
> do to help Django contributors who are having trouble making their
> functionality compatible with Oracle.
>
> I reiterate that my only intention was to understand if I were the
> only one to have this point of view without wanting to criticize
> anyone's work or past choices, things simply change in the field of
> information technology and choices could

Re: Can we move the activity on this list to the Forum now?

[Carlton Gibson]

Hey Curtis.

The notifications settings are very flexible, and allow good filtering (to
your inbox) if that's how you want them.

For example, I'm able to get notifications for the Django Internals
category, and the Async subcategory of Using Django (and then I'm able to
keep up with the rest just by glancing at the latest tab.)

The water is nice  😅
C.


On Thu, 4 May 2023 at 07:29, Curtis Maloney  wrote:

> Does the Forum allow me to get email notifications / summaries?
>
> If not, it will mean I disconnect with that part of the community.
>
> --
> Curtis
>
> On Thu, 4 May 2023, at 15:19, Arthur Rio wrote:
>
> Yes please!
>
>
>
> On May 3, 2023 at 11:19:12 PM, jure.erznoz...@gmail.com (
> jure.erznoz...@gmail.com) wrote:
>
>
> +1
>
>
>
> *From:* django-developers@googlegroups.com <
> django-developers@googlegroups.com> *On Behalf Of *natali...@gmail.com
> *Sent:* sreda, 03. maj 2023 20:10
> *To:* Django developers (Contributions to Django itself) <
> django-developers@googlegroups.com>
> *Subject:* Re: Can we move the activity on this list to the Forum now?
>
>
>
> Hello everyone!
>
>
>
> I was wondering if we could make a decision about this topic. On the one
> hand, and as far as I understand, the forum is the preferred channel of
> communication. On the other hand, having multiple channels of communication
> can spread important discussions too thin, making it difficult to have
> productive conversations in one place.
>
>
>
> As a newcomer to the contributing community, I can attest that the current
> situation causes some confusion. IMHO, the same applies to the chat
> options: there is IRC and the Discord server (though perhaps I should start
> a new forum topic about that in order to keep decisions separated).
>
>
>
> In summary, I'm +1 to "move on-mass (all few of us :) over there"!
>
>
>
> Thank you!
>
> Natalia.
>
> On Thursday, January 26, 2023 at 10:07:36 AM UTC-3 Alex Krupp wrote:
>
> I just submitted a proposal to create a Discourse plugin to improve the
> accuracy of their inbound email parsing. This would enable two things:
>
>- Folks who prefer to live in their inbox could continue to do so and
>contribute by just replying to emails. Discourse currently has
>reply-by-email, but it often mangles formatting and/or entirely deletes
>text. Once these issues are fixed, folks who like the current experience
>would be able to just pretend the forum doesn't exist and continue having
>the same experience as they currently have with Google Groups.
>- Right now importing the archives from Google Groups into Discourse
>isn't realistic for the same reasons; some messages will import correctly,
>but others will be mangled or missing text. This would also be made
>possible.
>
> If this is something you care about (positively or negatively), here is
> the exploratory proposal:
>
>
>
>
> https://meta.discourse.org/t/proposed-plugin-to-improve-reply-by-email-accuracy/252944
>
>
>
> Any feedback and/or testing would be much appreciated! Right now Discourse
> recognizes that this is a problem and is interested in solving it, but
> getting it prioritized will require folks to A) speak up saying they want
> it done B) test the underlying API to verify that it actually solves the
> problem.
>
>
>
> Alex
>
>
>
> On Fri, Jan 20, 2023 at 2:24 AM Carlton Gibson 
> wrote:
>
> OK, I've updated the Trac wiki page to point to the forum too. (We use
> this as a wiki-link in responses to guide folk onwards.)
>
>
>
> The docs have a `|django-developers|` shortcut used in quite a few places
> so that needs a moment more to review and adjust.
>
> (I'll look at it soon-ish... — if no-one beats me to it :)
>
>
>
> Thanks.
>
> C
>
>
>
> On Thu, 19 Jan 2023 at 18:15, Andrew Godwin  wrote:
>
> We should at least update those Trac and Triage Workflow docs to point to
> both, maybe with the Forum first?
>
>
>
> Andrew
>
>
>
> On Thu, Jan 19, 2023, at 12:30 AM, Carlton Gibson wrote:
>
> I'm trying to begin new conversations there where I can.
>
>
>
> The main issue is that we're still pointing people here from Trac and the
> Triage Workflow docs — so if there's a rough "Yeah, let's do it" we can
> adjust practice there.
>
>
>
> I expect there will always be the "How do I start?" posts. The Forum at
> least has a pinned post for that. ...
>
>
>
> On Thu, 19 Jan 2023 at 01:04, 'Kye Russell' via Django developers
> (Contributions to Django itself)  wro

Re: Feedback for my draft proposal

[Carlton Gibson]

Hi Jayant. 

This sounds like a good idea for an ecosystem package, but I think it's the 
kind of thing that's out-of-scope for a GSoC project I'm afraid. 😬

Kind Regards,

Carlton



On Tuesday, 28 March 2023 at 20:27:47 UTC+2 jayant khanna wrote:

> Hello everyone,
> I have started this conversation to obtain input for my suggestion for a 
> project not on the list: *Automating early steps in Django*. I have used 
> the framework for the past two years but I have never contributed to any of 
> the official Django projects. In this discussion, I'd like to offer a 
> high-level overview of what I'm doing and how it can be done; any input you 
> could offer or resources you might recommend for a more in-depth and 
> understandable look at the project would be very welcomed.
> What I have in mind to do is as follows: 
>
>1. Make a simple API where users can send JSON data. 
>2. Users can pass the Project name and App name
>3. They can pass the type of database they want to use(Will be giving 
>multiple options but for now my focus will be on SQLite, PostgreSQL, 
> MySQL, 
>and MongoDB).
>4. Whether their application will be a Simple Django template-based 
>application or will they use Django-Rest-Framework
>5. Any particular python module they want in their requirements.txt
>6. Option to declare Models, their fields, and their types
>7. I will also be building a simple frontend using React to make it 
>easier for users
>8. Auto-set Static files, templates(if using HTML, CSS, and JS files 
>in the project), and media settings in Settings.py
>9. Auto-set base URLs
>10. There will be an option to define multiple apps too.
>11. Write import statements that are used widely and are not written 
>by default for example `from .models import ABC` and so on
>
> Here is a link to my draft proposal: 
> https://docs.google.com/document/d/17b7YKkAk_KMuyUma8yoR17JLe6LNKib7jN2CrHjBF_o/edit?
>  
> 
>
> I understand that the Django community has a lot of experience and 
> expertise, and I would value your input on my proposal. Specifically, I 
> would be grateful for any feedback you have on the feasibility, scope, and 
> potential impact of the 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/53fa3a79-2e58-4be3-baf8-338186a33435n%40googlegroups.com.

Re: GSOC 2023 Discussion and Feedback: Database-level Cascades

[Carlton Gibson]

Hey David. 

Nice example! 

I've done this, again just PostgreSQL, overriding the schema 
editor's sql_create_fk and sql_create_column_inline_fk to add to the 
necessary ON DELETE (for an FK subclass), but doing it with a constraint is 
a lovely touch. (I shall play with that 😜)

I didn't look at all at making it work for each backend (but it should no? 
🤔)

My need-to-double-check-but… thought on #21961 was that a new kwarg (such 
as, say) db_on_delete, which would error if used with on_delete, and set 
that to DO_NOTHING, responsible for controlling the generated SQL would be 
the way forward here. 

That was all before constraints, though, so thoughts from Simon/Mariusz/... 
on best way forward would be good. 

For me, it would be **great** (and akin with various other changes in 
recent versions) to be able to push this responsibility into the DB in a 
recommended/supported way. 

Kind Regards,

Carlton

On Monday, 27 March 2023 at 18:16:37 UTC+2 David Sanders wrote:

> Hi Akash,
>
> Database-level cascading deletes is a topic that has been discussed often 
> since, well probably the dawn of Django 😁  From recollection the main 
> issue isn't the implementation, it's getting it to play nicely with 
> Django's cascading emulation.
>
> There are other tickets, but I believe this is the main ticket to refer 
> to: https://code.djangoproject.com/ticket/21961  There are also plenty of 
> threads on this group I'm sure you could dig up.
>
> Note that with the introduction of constraints a while back, there's 
> nothing stopping people from adding their own custom foreign keys that adds 
> the necessary `ON DELETE` clauses. Here's a demonstration of that:  
> https://github.com/shangxiao/stupid-django-tricks/tree/master/abusing_constraints#database-level-cascading-deletes
>
> The gist is:
>
>1. Set your fks to "do nothing" (I haven't tested with other options - 
>seems like there could be some conflicts there though)
>2. Define your own fk by extending BaseConstraint and add the 
>necessary ON DELETE/ON UPDATE clauses
>3. Add this new fk to your meta's constraints attribute
>
> Check out the tests in that link above for confirmation (only tested on 
> Postgres).
>
> Anyway, best of luck!
> David
>
>
> On Tue, 28 Mar 2023 at 00:57, Akash Sen  wrote:
>
>> Hello everyone,
>> I’ve started this discussion to get feedback for my proposal for the 
>> project: Database-level Cascades Functionality to Django ORM. I have never 
>> contributed to any of the official Django projects earlier but I have 
>> experience using the framework for last 2 years. In this discussion I would 
>> like to propose a high level view of how this can be implemented, any kind 
>> of feedback and reference to resources for a more detailed and clear 
>> perspective about the project from your side would be very much appreciated,
>>
>> Based on my study it seems quite straightforward and simple to implement.
>>
>>1. Conduct thorough research and gain an understanding of the 
>>existing discussions, pull requests, and issues associated with adding 
>>support for database-level cascading options in the Django web framework.
>>2. Specify the requirements for the new feature, including its name 
>>and behavior, and determine whether it should be a new option 
>>(on_delete_db) or a modification of the existing one (on_delete).
>>3. Develop a ForeignKey subclass that sets a flag indicating that the 
>>database should manage the cascading options.
>>4. Modify the DatabaseSchemaEditor’s add_field() and sql_create_fk() 
>>methods to recognize the flag and generate SQL accordingly for the 
>> specific 
>>database backend.
>>5. Ensure that the implementation performs as intended when tested 
>>for a single database backend. Then, generalize the implementation so 
>> that 
>>it works for all supported database backends, generating appropriate SQL 
>>for each.
>>6. Integrate the implementation with the Django migrations framework 
>>to ensure proper handling of database-level cascading options during 
>> schema 
>>migrations.
>>7. Write tests to verify that the new feature functions correctly and 
>>does not interfere with existing functionality.
>>8. Submit one or more pull requests containing the changes, and 
>>collaborate with the Django community to address any feedback or issues 
>>that may arise.
>>
>> Here is a link to my proposal : Database-level Cascades Proposal - GSoC 
>> '23 - Google Docs 5 
>> 
>>
>> Due to my beginner level understanding of the codebase there is a lot of 
>> scope room for improvement. Your suggestions will be of great help.
>>
>> -- 
>> 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 st

Re: Filtering chosen options

[Carlton Gibson]

This was added 
in 
https://github.com/django/django/commit/be63c78760924e1335603c36babd0ad6cfaea3c4
 
and will be part of Django 4.2, which is currently at release candidate 
stage, for final release around 2023-04-03. 

On Friday, 24 March 2023 at 03:20:41 UTC+1 Marty wrote:

> Hi,
>
> Is there a reason why there is a filter only at available options but not 
> at chosen options in this multiple select widget 
> ?
>
> I would appreciate filtering even chosen options. 🙂
>
> Thanks.

-- 
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/0e8ff9c5-2061-498a-92d4-cc1464c24364n%40googlegroups.com.

Re: GSOC 2023 Proposal Feedback on Security: Bring CORS and CSP into core

[Carlton Gibson]

Hi Anvesh.

I replied to your forum post:
https://forum.djangoproject.com/t/gsoc-2023-discussion-on-security-bring-cors-and-csp-into-core/18932/7
— let's keep the discussion in one place please. Thanks.

On Tue, 7 Mar 2023 at 17:59, Anvesh Mishra  wrote:

> I created a draft proposal GSOC Proposal [Security: Bring CORS and CSP
> into core] - Google Docs 3
> 
>  I
> would be glad if you could review it once [image: :smile:]
> Some key notes on the proposal:
>
>1. CSP is to be added to SecurityMiddleware as suggested by @timgraham
> in his closing notes on
>PR-5776
>. I
>will be following the design of Referrer Policy and implementing some extra
>features such as nonce context processor.
>2. A doubt that I had is since CSP consists of a number of directives
>so will creating settings attributes for each one of them be a valid option
>or we can stick to the proposed way of declaring it in a single comma
>separated string as done with Referrer Policy.
>3. Currently this proposal proposes CORS to be implemented via the
>addition of CORSMiddleware but I was thinking if implementing CORS
>into SecurityMiddleware would be the right way or not?
>4. Also since I propose to add CSP to SecurityMiddleware we would have
>to create SecurityMiddleware._make_nonce(request), I don’t know if
>this breaks the design of SecurityMiddleware. The mock implementation
>of CSP in SecurityMiddleware can be seen here CSP mock implementation
>
> 
> .
>5. Decorators will be added to both CORS and CSP with CORS having 3
>decorators and CSP having 4 decorators.
>
>
> --
> 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/03a6602d-9f95-46be-9dc0-39f841bcd9bcn%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/CAJwKpySjRD0miatiC%2BpSFAUGRnjtiHyNwfm5wsF2vY6eLMCK%3DA%40mail.gmail.com.

Django security releases issued: 4.1.7, 4.0.10, and 3.2.18

[Carlton Gibson]

Details are available on the Django project weblog:

https://www.djangoproject.com/weblog/2023/feb/14/security-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/CAJwKpyS86ByXMTh3sodVbkOXS3Gn%2BMtK33ei6b7jMd6jsPTqHQ%40mail.gmail.com.

Re: Async wrappers in contrib packages

[Carlton Gibson]

Great. Thanks Jon. I will follow up there next week.

On Saturday, 11 February 2023, Jon Janzen  wrote:

> Hey Carlton,
>
> Sorry I skipped over the suggestion in one of your earlier messages to
> post on the Forum.
>
> I’ve done so now: https://forum.djangoproject.com/t/
> asyncifying-django-contrib-auth-and-signals-and-maybe-sessions/18770
>
> I think we can consider this thread deprecated in favor of the above Forum
> thread.
>
> Cheers,
>
> Jon
>
> On Feb 10, 2023, at 03:54, Carlton Gibson 
> wrote:
>
> No plan ever survives first contact with the enemy :) but, this seems
> reasonable to me Jon, yes.
>
> Can I suggest we move further discussion on details to the Forum's async
> category? It's nicer, better contained, and we more likely to catch
> interested eyes.
>
> Thanks for pursuing this! 🎁
>
> On Thu, 9 Feb 2023 at 23:38, Jon Janzen  wrote:
>
>> Hey Carlton,
>>
>> Thanks for your thoughtful comments, a few things come to mind:
>>
>> A. It sounds like we’re in agreement about the utility and severability
>> of Phase 1 (just creating an async_to_sync-based wrapper around the auth
>> interface). I want to make sure I don’t cause extra work on the bug
>> tracker, so does this sound like it’s ready to be filed as a ticket there?
>> I can file the ticket and get started on writing tests/docs if so!
>>
>> B. In reply to your "Is there a best order here, or can we just chip
>> away bit-by-bit? 🤔” comment, I think there is a reasonable order: we
>> mirror the dependencies between django internals. By that I mean I think we
>> should asyncify the necessary parts of sessions or signals before
>> asyncifying the parts of auth that depend on them. That reduces the need to
>> insert “temporary” sync/async boundaries and reduces churn.
>>
>> C. Based on your responses and my own thoughts in (2) I think it’s
>> reasonable to revise the overall order into this:
>>
>> 1. In any order: asyncify the auth API (Phase 1), asyncify signals
>> (ticket 32172), and asyncify sessions (TODO: discussion/ticket)
>> 2. After all 3 parts to (1), asyncify auth backends and internals of the
>> auth API (Phase 2)
>> 3. Resolve ticket 31920
>> 4. Asyncify the auth middleware (Phase 3)
>>
>> D. I’m admittedly very new to Django and contributing code to it, but
>> Phase 1 is certainly within my area of expertise considering the 2 PRs that
>> I have contributed 😉:
>>
>> https://github.com/django/django/pull/16256
>> https://github.com/django/django/pull/16252
>>
>> After that, I’d be interested in helping nudge this along over time. I’d
>> like to build my experience beyond just adding async wrappers 😛, so maybe
>> I can pick up https://github.com/django/django/pull/13651 and hack away
>> at your idea about categorizing during registration. If that all goes well
>> I can start a discussion around asyncifying sessions (which, on first
>> glance seems like a LARGE project of its own)
>>
>> Thanks,
>>
>> Jon
>>
>>
>> On Feb 7, 2023, at 09:25, Carlton Gibson 
>> wrote:
>>
>> Hi Jon.
>>
>> Thanks for this.
>>
>> I think your use-case is reasonable, and that you're basically on the
>> right track.
>> If you were to add test cases to your PoC, there's certainly a case for
>> looking seriously at it.
>> It should be reasonable to keep pushing the interfaces down one layer at
>> a time. (See comment on Sessions below.)
>>
>> I'm not sure a priori how Phase 2 plays out in advance. It's likely
>> something we have to think about as we go.
>> Targeted posts to the Async category of the Forum might help drive
>> discussion.
>> https://forum.djangoproject.com/c/users/async-channels/23
>>
>> Let me inline some quick thoughts on your …
>>
>> ## Open Questions
>>
>> Based on my stab at the above PoC implementation I came away with several
>> questions:
>>
>> 1. Are there proven strategies for reducing code duplication between sync
>> and async versions of functionality in Django or in Python broadly? I’m not
>> aware of any guidance here but I’m eager for resources to consider. The
>> implementation is verbose (doubles file size in some cases) and fragile
>> (what if a bug fix is only applied to the sync version and not the async
>> version?) right now.
>>
>> Yes… you end up writing it twice... 🤔 Maybe in some ideal end state we
>> end up with an async core with a thin sync wrapper around that, but we are
>> a long way from there: I'

Re: Async wrappers in contrib packages

[Carlton Gibson]

No plan ever survives first contact with the enemy :) but, this seems
reasonable to me Jon, yes.

Can I suggest we move further discussion on details to the Forum's async
category? It's nicer, better contained, and we more likely to catch
interested eyes.

Thanks for pursuing this! 🎁

On Thu, 9 Feb 2023 at 23:38, Jon Janzen  wrote:

> Hey Carlton,
>
> Thanks for your thoughtful comments, a few things come to mind:
>
> A. It sounds like we’re in agreement about the utility and severability of
> Phase 1 (just creating an async_to_sync-based wrapper around the auth
> interface). I want to make sure I don’t cause extra work on the bug
> tracker, so does this sound like it’s ready to be filed as a ticket there?
> I can file the ticket and get started on writing tests/docs if so!
>
> B. In reply to your "Is there a best order here, or can we just chip away
> bit-by-bit? 🤔” comment, I think there is a reasonable order: we mirror the
> dependencies between django internals. By that I mean I think we should
> asyncify the necessary parts of sessions or signals before asyncifying the
> parts of auth that depend on them. That reduces the need to
> insert “temporary” sync/async boundaries and reduces churn.
>
> C. Based on your responses and my own thoughts in (2) I think it’s
> reasonable to revise the overall order into this:
>
> 1. In any order: asyncify the auth API (Phase 1), asyncify signals
> (ticket 32172), and asyncify sessions (TODO: discussion/ticket)
> 2. After all 3 parts to (1), asyncify auth backends and internals of the
> auth API (Phase 2)
> 3. Resolve ticket 31920
> 4. Asyncify the auth middleware (Phase 3)
>
> D. I’m admittedly very new to Django and contributing code to it, but
> Phase 1 is certainly within my area of expertise considering the 2 PRs that
> I have contributed 😉:
>
> https://github.com/django/django/pull/16256
> https://github.com/django/django/pull/16252
>
> After that, I’d be interested in helping nudge this along over time. I’d
> like to build my experience beyond just adding async wrappers 😛, so maybe
> I can pick up https://github.com/django/django/pull/13651 and hack away
> at your idea about categorizing during registration. If that all goes well
> I can start a discussion around asyncifying sessions (which, on first
> glance seems like a LARGE project of its own)
>
> Thanks,
>
> Jon
>
>
> On Feb 7, 2023, at 09:25, Carlton Gibson  wrote:
>
> Hi Jon.
>
> Thanks for this.
>
> I think your use-case is reasonable, and that you're basically on the
> right track.
> If you were to add test cases to your PoC, there's certainly a case for
> looking seriously at it.
> It should be reasonable to keep pushing the interfaces down one layer at a
> time. (See comment on Sessions below.)
>
> I'm not sure a priori how Phase 2 plays out in advance. It's likely
> something we have to think about as we go.
> Targeted posts to the Async category of the Forum might help drive
> discussion.
> https://forum.djangoproject.com/c/users/async-channels/23
>
> Let me inline some quick thoughts on your …
>
> ## Open Questions
>
> Based on my stab at the above PoC implementation I came away with several
> questions:
>
> 1. Are there proven strategies for reducing code duplication between sync
> and async versions of functionality in Django or in Python broadly? I’m not
> aware of any guidance here but I’m eager for resources to consider. The
> implementation is verbose (doubles file size in some cases) and fragile
> (what if a bug fix is only applied to the sync version and not the async
> version?) right now.
>
> Yes… you end up writing it twice... 🤔 Maybe in some ideal end state we
> end up with an async core with a thin sync wrapper around that, but we are
> a long way from there: I'm not sure it bears thinking about.
>
> Part of the task on the decorators work is to try not to duplicate
> everything. e.g. a process_request only middleware doesn't necessarily need
> to consume the `get_response()` callable, so often times can make use of
> `markcoroutinefunction()` rather than needed to duplicate the whole
> middleware function. (And so on.) — But those patterns aren't 100% clear
> just yet — we'll find them as we go through in this next phase.
>
>
> 2. The auth app obviously fires several signals, and Django signals
> currently has a sync-only interface. I see there is an issue on the bug
> tracker (https://code.djangoproject.com/ticket/32172) but it is currently
> blocked for performance reasons. Is it fine to just add more sync_to_async
> wrappers here? (I did so in the above PoC implementation). Another idea is
> to just add a async wrapper around th

Re: Async wrappers in contrib packages

[Carlton Gibson]

but I think it warrants consideration so we
> don’t write ourselves into a corner.
>
>
> ## Naive Implementation
> I’ve taken the time to rough-out a rather simple implementation of the
> above plan: https://github.com/bigfootjon/django/pull/1 (note this is a
> PR from my fork _to_ my fork, not a PR against the main django GitHub repo)
>
> This branch just exists to illustrate this proposal, not as code ready for
> checkin. It’s missing tests and docs and… a well-considered implementation.
> There’s duplicated code all over the place and I didn’t even bother running
> the code to see if it works. I just wanted to get a feel for how this would
> work and though I might as well publish my hacked-up PoC to show my work.
>
>
> ## Open Questions
>
> Based on my stab at the above PoC implementation I came away with several
> questions:
>
> 1. Are there proven strategies for reducing code duplication between sync
> and async versions of functionality in Django or in Python broadly? I’m not
> aware of any guidance here but I’m eager for resources to consider. The
> implementation is verbose (doubles file size in some cases) and fragile
> (what if a bug fix is only applied to the sync version and not the async
> version?) right now.
>
> 2. The auth app obviously fires several signals, and Django signals
> currently has a sync-only interface. I see there is an issue on the bug
> tracker (https://code.djangoproject.com/ticket/32172) but it is currently
> blocked for performance reasons. Is it fine to just add more sync_to_async
> wrappers here? (I did so in the above PoC implementation). Another idea is
> to just add a async wrapper around the `send` method and defer the rest of
> that ticket until the perf question can be resolved.
>
> 3. The sessions app seems to only have a synchronous interface, which
> would cause a lot of friction during Phase 2. I couldn’t find any tickets
> covering this topic (just some tangential discussion in
> https://groups.google.com/u/1/g/django-developers/c/D2Cm25yFzdI/m/bo_Ae_kgBQAJ),
> perhaps it would be a good idea for me to dig into this area first and
> think about asyncifying `sessions` instead of sprinkling lots of
> `sync_to_async` calls around `sessions` callsites in `auth`? I’d appreciate
> some other opinions/guidance here.
>
> 4. I’ve intentionally not considered the auth decorators as that seems
> like an orthogonal issue while https://code.djangoproject.com/ticket/31949 is
> pending, am I missing something here? Do I need to consider decorators in
> this proposal?
>
> ## Summary
>
> I think without guidance my gut tells me that doing just Phase 1 would be
> “fine” and mirrors a lot of other work around the django codebase to add
> async _interfaces_ without pushing those down to natively-async
> _implementations_ (yet). Each phase in my proposal seems severable to me,
> so stopping after Phase 1 seems acceptable.
>
> I think after Phase 1 the next step would be analyzing and adding an async
> interface (and, hopefully, implementation) for `sessions` before turning to
> Phase 2/3.
>
> I’m well aware I dug really deep into a rabbit hole without asking if I
> was digging in the right spot, so please let me know where I’ve gone wrong
> in my analysis/approach/etiquette. I’m not invested in this plan, just in
> the core idea of asyncifying more of django. If the idea itself is not
> acceptable then I’ll be a little disappointed but I can understand the need
> to minimize complexity in a project like Django, so I won’t be that
> disappointed.
>
> Thanks for reading this novella,
>
> Jon
>
>
> On Dec 2, 2022, at 03:39, Carlton Gibson  wrote:
>
> > But I can file a ticket just to track this one?
>
> TBH I'd prefer it if you pondered the design here without opening a ticket
> until such a point (if ever) that you have a concrete plan. (We'd likely
> just close it as wontfix unless there's a specific idea on the table
> anyway, so it's just noise at that point.)
>
> I hope that makes sense.
>
> Kind Regards,
>
> Carlton
>
> On Mon, 28 Nov 2022 at 16:53, Jon Janzen  wrote:
>
>> Hey Carlton,
>>
>> There's: https://code.djangoproject.com/ticket/31949 "Allow builtin view
>>> decorators to be applied directly to async views."
>>> I think this is likely the next step.
>>>
>>> There's a PR for that, which I think took a too complex approach (see
>>> discussion). A simpler (more inline) take be good to see.
>>>
>>
>> Thanks, I saw this ticket but it didn't look relevant when I was skimming
>> the tracker. I'll take a closer look.
>>
>> > My personal interest in this is 

Re: Multiple instances of DjangoAdmin share the same model LogEntry

[Carlton Gibson]

Hey Jacob.

I had in mind literally **just** adding the content-types so that the line
in that render call would be:

# this could be via a proposed context["site_content_types"] or via a
map from
# "available_apps"
site_content_types: [ContentType] = ...
entries = LogEntry.objects.filter(
user__pk=user_id,
content_type__in=site_content_types
)

This I can sort of see: OK, folks use multiple AdminSites, and having
non-registered models show up is a cause of uncertainty, plausibly, yes.

You want more than that thought right? (I'm still not certain I've grasped
exactly what use-case you have in mind.)

Passing in a callable seems an extra step of complexity up.
(IDK, maybe it's not, but I'm not seeing it, although I'm known to be slow
at times.)

It would be undocumented magic.
I think I'd lean towards suggesting a custom template and tag in that case.

(But maybe that's just me.)

A diff of what you actually have in mind would likely help (to at least be
clear).


C.



On Thu, 26 Jan 2023 at 15:26, Jacob Rief  wrote:

> Hi Carlton,
> that proposal makes a lot of sense.
>
> This means that one could for instance add a custom function to that
> context which, if set, would be called
> by the AdminLogNode.render method and then overrides the
> context[self.varname].
> How would you name that extra context variable, maybe "render_log_entries"?
> Another approach would be to move the functionality of method render into
> the class AdminSite. This would
> allow Django implementers to override the way, log entries are rendered.
>
> This would be a minimalistic change to the existing code base but would
> allow to change the rendering
> of log entries in a much more flexible way.
>
> Shall I create a ticket and a proof of concept?
>
> – Jacob
>
> --
> 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/e50bce39-d1dd-44b5-9fae-fc1bc8c9c864n%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/CAJwKpyQqW6wLUCHFQiFvReF-67_Ker8XoFHhFDvg4tnkwFLd_w%40mail.gmail.com.

Re: Multiple instances of DjangoAdmin share the same model LogEntry

[Carlton Gibson]

Thanks for clarifying Jacob, great.

So, the registered content_types are in the available_apps key to the
context passed to that tag. (Currently that needs reconstructing in a
filter/comprehension, but it could feasibly be added to the
`AdminSite.each_context` method.) Adding the matching `__in` lookup to the
filter call there should allow retricting to only registered models no?

I'm personally sceptical that a "I added the same model to multiple
AdminSites and need to see only actions for each model from the AdminSite
that it occurred on" use-case is one we should cover. That's pretty niche
I'd say.

Kind Regards,

Carlton

On Thu, 26 Jan 2023 at 10:01, Jacob Rief  wrote:

> Hi Carlton,
>
> As I understand it, separate admin sites may register different models,
> but I'm only going to see the History for instances that are visible to the
> current admin no?
>
> The Django admin interface uses a templatetag named get_admin_log. It
> renders the content of all entries of model LogEntry filtered by the
> current user.
> Check here for details:
> https://github.com/django/django/blob/34b328814976a2e2f7907361a494202763649f3f/django/contrib/admin/templatetags/log.py#L14
> If you instantiate more than one Django-Admin interface, the logged in
> user therefore sees all his actions, regardless of the chosen admin
> instance.
>
> My proposal would be to add another column to LogLevel containing the name
> of the admin interface. That column then shall be used as an additional
> filter.
> It should also be possible to swap that model against a compatible
> implementation, for instance if someone separates the admin interface
> because he also
> separated the underlying databases.
>
> Maybe you mean the Recent actions > My actions bit of the index page? (I
> didn't check but, if not already, could that list be filtered by the
> content type of registered models for the current admin? 🤔)
>
> Yes, that's what I wrote and intended.
>
> – Jacob
>
> --
> 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/bfcd58e8-bbf1-42bc-a7dc-25a788e47b1en%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/CAJwKpyT0yGSrZGrRcH%2ByRk2vhpKgBjANo_xuDuTe5p60m-BuPw%40mail.gmail.com.

Re: Multiple instances of DjangoAdmin share the same model LogEntry

[Carlton Gibson]

Hi Jacob.

Can I ask you to explain your use-case a little more please?
As I understand it, separate admin sites may register different models, but
I'm only going to see the History for instances that are visible to the
current admin no?
Maybe you mean the Recent actions > My actions bit of the index page? (I
didn't check but, if not already, could that list be filtered by the
content type of registered models for the current admin? 🤔)

C.

On Tue, 24 Jan 2023 at 14:35, Jacob Rief  wrote:

> If someone uses two or more instances of the Django Admin interface,
> the sidebar on the right containing the "Recent actions", shares the same
> information for all instances of the Django Admin interface.
> This is because the model LogEntry is a singleton and shared across all
> instances of the Django Admin interface.
> As a consequence this may be confusing to some users, since they might
> expect that the log entries are bound to the current user interface.
>
> I had a look at the code and although it is possible to create separate
> entries
> for those logs, this is really complicated and requires a lot of work.
> Therefore
> I wanted to ask, if it would make sense to allow each instance of a Django
> Admin to specify its own model used to log entries? The default would of
> course be to fall back on the current behaviour.
>
> I have some ideas on how to achieve this. An instantiation
> of a Django Admin could specify its own model similar to LogEntry
> which itself should inherit from a class named AbstractLogEntry (which
> doesn't yet exist). This would also allow integrators to extend this class
> with
> additional columns for extra log entries.
>
> – Jacob
>
> --
> 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/38c055d3-58ef-4a73-9784-be6877e31b2cn%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/CAJwKpyS17Kx8FaHx1CG1GE2wYpgqSq89u%3DLxeqth23vJkRPPrg%40mail.gmail.com.

Re: Proposal for an "Age" PostgreSQL ORM function

[Carlton Gibson]

>From the maintenance perspective, it's not that any one individual function 
is too hard to maintain — it's clearly not. 

Rather it's about not adding a million of them — which would add up — and 
in so doing essentially duplicating the entire API offered by databases. 

* Each one we add makes the docs longer, and less fun to read. Every user 
has to answer (for each one) "What's this?" and "Is it relevant to me?"
* Once you get beyond the core functions they impose that cost with less 
and less likelihood of being relevant. 
* And the function wrappers are in the main really quite trivial to add to 
your own project if you want them. 

Previous discussions have more or less pointed to the core cases being 
covered, and not adding a whole lot more. 
(There's always the possibility that one extra **is** worth adding, but …) 

One question:

> the function wrappers are in the main really quite trivial to add to your 
own project if you want them. 

Can we make the docs point this out more clearly? 

Like custom fields, custom functions shouldn't be something folks shy away 
from. 🤔

Kind Regards,

Carlton





On Friday, 20 January 2023 at 13:44:57 UTC+1 j.bre...@netzkolchose.de wrote:

>
>
> Am 19.01.23 um 21:14 schrieb Jason Johns:
> > the AGE function takes in two timestamps and returns an interval.  You 
> > can do this in python by subtracting two date/datetime objects and 
> > getting a timedelta.  what would the difference be to kick this out to 
> > the db?
>
> I'd say thats mainly about performance - the DB can almost almost always 
> calculate things much more efficiently, eg. for AGE with table data:
> - less datapoints to be moved to client side (should run ~2x faster 
> here, if the mangling of datetime and range type is equally expensive)
> - Ideally the db has a fast impl for the function, thus the calculation 
> loop would also run faster than in python / on django side.
>
> Since I have not benchmarked AGE this is all speculative (TM), but there 
> is a good chance to get at least a 2x faster processing.
>
> Furthermore this is also about SQL realms vs. client roundtrips & 
> deduplication - a value calculated on python side cannot be used in SQL 
> directly anymore, you either need another python roundtrip to calc the 
> values and put it back to DB side or some data duplication on a table 
> (eww, now you've violated the normalization rules).
>
> Still all that is not yet a good indicator, whether AGE should be 
> supported natively, as there is more to it from ORM perspective:
> - Is AGE a vivid use case, does it help django users to get things done?
> - Whats the testing/maintenance burden of AGE?
> - How about other DB vendors?
>
> Now to the downsides of AGE in postgres itself - it creates a "symbolic" 
> range string in years|months|days, rather than in postgres' standard 
> interval repr. This might create frictions at the interval to timedelta 
> translation in psycopg*, at least needs extensive testing for edge 
> cases, that might occur in that weird "symbolic" notation. That 
> uncertainty is a very bad startpoint for an ORM to get reliable 
> functionality and def. raises the test/maintenance needs just for that 
> AGE function.
>
> An in-depth analysis of all these points might reveal, that its more 
> reliable to just use datetime substraction at SQL level. Which is 
> already easy doable and prolly also works with many other DB vendors. 
> Which again somewhat questions the idea for native postgres AGE support.
>
> In summary - I am not against an ORM age thingy, still think that a more 
> general impl covering other vendors as well might be more helpful.
>
> Cheers,
> Jerch
>
>
> [*] Again speculative (TM) - I know that Daniele Varrazzo does a really 
> great job in maintaining psycopg and it prolly will just work as 
> expected. It still creates a dependency on a less often used/tested code 
> path, so needs more caution on ORM side.
>

-- 
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/a46517dd-a03f-47e6-bdd6-4a052e6bdaecn%40googlegroups.com.

Re: Can we move the activity on this list to the Forum now?

[Carlton Gibson]

OK, I've updated the Trac wiki page to point to the forum too. (We use this
as a wiki-link in responses to guide folk onwards.)

The docs have a `|django-developers|` shortcut used in quite a few places
so that needs a moment more to review and adjust.
(I'll look at it soon-ish... — if no-one beats me to it :)

Thanks.
C

On Thu, 19 Jan 2023 at 18:15, Andrew Godwin  wrote:

> We should at least update those Trac and Triage Workflow docs to point to
> both, maybe with the Forum first?
>
> Andrew
>
> On Thu, Jan 19, 2023, at 12:30 AM, Carlton Gibson wrote:
>
> I'm trying to begin new conversations there where I can.
>
> The main issue is that we're still pointing people here from Trac and the
> Triage Workflow docs — so if there's a rough "Yeah, let's do it" we can
> adjust practice there.
>
> I expect there will always be the "How do I start?" posts. The Forum at
> least has a pinned post for that. ...
>
> On Thu, 19 Jan 2023 at 01:04, 'Kye Russell' via Django developers
> (Contributions to Django itself) 
> wrote:
>
> Hi all,
>
> I find that the signal-to-noise ratio on this mailing list is (by my
> determination) quite bad around this time of year.
>
> Is a move to the forum still on the cards?
>
> Kye
> On 6 Dec 2022 at 7:16 AM +0800, Andrew Godwin ,
> wrote:
>
> I did some investigation of moving django-users and django-developers to
> the Forum right after DjangoCon; I wanted to see if we could import all the
> old posts too, which we probably could, but I'm not entirely sure of the
> utility of that.
>
> I will say that the forum is a lot easier to moderate - the ability to
> moderate after a post has gone out, rather than gating all posts behind
> approval if they're untrusted, is a big step in itself, not to mention the
> ability to remove sensitive or offensive content once it's posted.
>
> Andrew
>
> On Monday, November 28, 2022 at 10:01:17 PM UTC-7 m...@kye.id.au wrote:
>
> IMO django-announce and django-updates serve a very different purpose and
> I would be against moving them if it were suggested.
>
> I am incredibly strongly in favour of moving django-developers and
> django-users to the forums. IMO being able to more easily trap people
> misusing this list as a tech support channel is itself reason enough to
> move. Beyond that, I’d argue that the plentiful UX issues with Google
> Groups, and mailing lists in general, certainly don’t do the community any
> favours in terms of getting more people on board.
>
> Kye
>
> On 28 Nov 2022 at 11:40 PM +0800, 'Tobias McNulty' via Django developers
> (Contributions to Django itself) , wrote:
>
> As someone who only just joined the forum -- I'm +1:
>
>- The forum has seen great adoption from what I can tell (nearly half
>the number of posts as django-developers during the same time period, not
>bad given the mailing list's head start in subscribers).
>- It seems beneficial to house future conversations in a single place,
>e.g., so members don't need to subscribe to both the mailing list and forum
>to get the full picture of current active development, set up two different
>sets of mail filters to tag things appropriately, etc...
>
> Would the plan be to switch django-users as well? I think similar
> arguments could be made for consolidating those...
>
> (On the other hand, I see little value in switching django-announce and
> django-updates, but I'm not necessarily opposed to it either, especially if
> there's a way to import the subscribers to those lists...)
>
> Cheers,
>
>
> *Tobias McNulty*Chief Executive Officer
>
> tob...@caktusgroup.com
> www.caktusgroup.com
>
>
>
> On Mon, Nov 28, 2022 at 9:05 AM Carlton Gibson 
> wrote:
>
> Hey Roger,
>
> Indeed it does. You can set up Email Mode (that may not be the actual
> name) and it’ll work just like a mailing list.
>
> You can also subscribe to just a particular category, so the Internals one
> would map to the discussion on this list.
>
>
>
> On Monday, 28 November 2022, Roger Gammans 
> wrote:
>
> Hi
>
> I can't speak for others, but I personally STRONGLY value the fact that
> this discussion happens in my inbox, not on yet another website.
>
> But perhaps the forum still supports this reading mode?
>
> On Mon, 2022-11-28 at 05:38 -0800, Carlton Gibson wrote:
>
> Hi all.
>
> Given the issues with Tom's access to the mailing list here, and the fact
> that the Forum has been active for a few years now, and is a great success,
> I'd like to revisit whether we can move on-mass (all few of us :) over
> the

Re: Can we move the activity on this list to the Forum now?

[Carlton Gibson]

I'm trying to begin new conversations there where I can.

The main issue is that we're still pointing people here from Trac and the
Triage Workflow docs — so if there's a rough "Yeah, let's do it" we can
adjust practice there.

I expect there will always be the "How do I start?" posts. The Forum at
least has a pinned post for that. ...

On Thu, 19 Jan 2023 at 01:04, 'Kye Russell' via Django developers
(Contributions to Django itself)  wrote:

> Hi all,
>
> I find that the signal-to-noise ratio on this mailing list is (by my
> determination) quite bad around this time of year.
>
> Is a move to the forum still on the cards?
>
> Kye
> On 6 Dec 2022 at 7:16 AM +0800, Andrew Godwin ,
> wrote:
>
> I did some investigation of moving django-users and django-developers to
> the Forum right after DjangoCon; I wanted to see if we could import all the
> old posts too, which we probably could, but I'm not entirely sure of the
> utility of that.
>
> I will say that the forum is a lot easier to moderate - the ability to
> moderate after a post has gone out, rather than gating all posts behind
> approval if they're untrusted, is a big step in itself, not to mention the
> ability to remove sensitive or offensive content once it's posted.
>
> Andrew
>
> On Monday, November 28, 2022 at 10:01:17 PM UTC-7 m...@kye.id.au wrote:
>
>> IMO django-announce and django-updates serve a very different purpose and
>> I would be against moving them if it were suggested.
>>
>> I am incredibly strongly in favour of moving django-developers and
>> django-users to the forums. IMO being able to more easily trap people
>> misusing this list as a tech support channel is itself reason enough to
>> move. Beyond that, I’d argue that the plentiful UX issues with Google
>> Groups, and mailing lists in general, certainly don’t do the community any
>> favours in terms of getting more people on board.
>>
>> Kye
>> On 28 Nov 2022 at 11:40 PM +0800, 'Tobias McNulty' via Django developers
>> (Contributions to Django itself) , wrote:
>>
>> As someone who only just joined the forum -- I'm +1:
>>
>>- The forum has seen great adoption from what I can tell (nearly half
>>the number of posts as django-developers during the same time period, not
>>bad given the mailing list's head start in subscribers).
>>- It seems beneficial to house future conversations in a single
>>place, e.g., so members don't need to subscribe to both the mailing list
>>and forum to get the full picture of current active development, set up 
>> two
>>different sets of mail filters to tag things appropriately, etc...
>>
>> Would the plan be to switch django-users as well? I think similar
>> arguments could be made for consolidating those...
>>
>> (On the other hand, I see little value in switching django-announce and
>> django-updates, but I'm not necessarily opposed to it either, especially if
>> there's a way to import the subscribers to those lists...)
>>
>> Cheers,
>>
>>
>> *Tobias McNulty*Chief Executive Officer
>>
>> tob...@caktusgroup.com
>> www.caktusgroup.com
>>
>>
>> On Mon, Nov 28, 2022 at 9:05 AM Carlton Gibson 
>> wrote:
>>
>>> Hey Roger,
>>>
>>> Indeed it does. You can set up Email Mode (that may not be the actual
>>> name) and it’ll work just like a mailing list.
>>>
>>> You can also subscribe to just a particular category, so the Internals
>>> one would map to the discussion on this list.
>>>
>>>
>>>
>>> On Monday, 28 November 2022, Roger Gammans 
>>> wrote:
>>>
>>>> Hi
>>>>
>>>> I can't speak for others, but I personally STRONGLY value the fact that
>>>> this discussion happens in my inbox, not on yet another website.
>>>>
>>>> But perhaps the forum still supports this reading mode?
>>>>
>>>> On Mon, 2022-11-28 at 05:38 -0800, Carlton Gibson wrote:
>>>>
>>>> Hi all.
>>>>
>>>> Given the issues with Tom's access to the mailing list here, and the
>>>> fact that the Forum has been active for a few years now, and is a great
>>>> success, I'd like to revisit whether we can move on-mass (all few of us :)
>>>> over there?
>>>>
>>>> We'd enjoy the benefits of a much nicer system. We'd not have issues
>>>> such as the current, and we'd be one less item in the pocket

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

[Carlton Gibson]

Hi Manav. Great, thanks! 👍

On Tue, 17 Jan 2023 at 22:26, Manav Agarwal  wrote:

> Hii All!
>
> I am a Google Summer of Code 2021 Student and have contributed to
> The schema editor project.
> I would be happy to mentor a project this year.
>
> On Tue, Jan 17, 2023 at 8:23 PM Carlton Gibson 
> wrote:
>
>> Hi All!
>>
>> Thanks for your earlier replies, comments and ideas!
>>
>> The organisation application period for GSoC begins next week, so I've
>> pulled them together to begin the ideas page:
>>
>> https://code.djangoproject.com/wiki/SummerOfCode2023
>>
>> It's not 100% — not least I need to go over the WIKI formatting, and make
>> it consistent (but ignore that, or make clean ups :)
>> *Please have a look *— see if the descriptions make sense.
>> (I want to add a few more links and such, and tweak the descriptions —
>> again, happy to take edits :)
>>
>> If you suggested an idea I put you as a *Possible Mentor*.
>> That doesn't mean you're committed to anything — but equally we do need
>> mentors… :)
>> What's involved? Not too much: being available to comment on a PR on your
>> project is the main bit.
>> If you know you're not happy to mentor, you can remove yourself: if
>> you're the only person, please put me instead.
>> *(*If you *didn't* suggest an idea but might like mentoring do feel free
>> to do the opposite :)
>>
>> It's Google *Summer *of Code — so there's ages before anything much else
>> happens.
>>
>> Thanks again.
>>
>> Kind Regards,
>>
>> Carlton
>>
>> On Tuesday, 15 November 2022 at 10:11:45 UTC+1 Carlton Gibson 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
>> "Djan

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

[Carlton Gibson]

Hi All! 

Thanks for your earlier replies, comments and ideas!

The organisation application period for GSoC begins next week, so I've 
pulled them together to begin the ideas page: 

https://code.djangoproject.com/wiki/SummerOfCode2023

It's not 100% — not least I need to go over the WIKI formatting, and make 
it consistent (but ignore that, or make clean ups :) 
*Please have a look *— see if the descriptions make sense. 
(I want to add a few more links and such, and tweak the descriptions — 
again, happy to take edits :) 

If you suggested an idea I put you as a *Possible Mentor*. 
That doesn't mean you're committed to anything — but equally we do need 
mentors… :)
What's involved? Not too much: being available to comment on a PR on your 
project is the main bit. 
If you know you're not happy to mentor, you can remove yourself: if you're 
the only person, please put me instead. 
*(*If you *didn't* suggest an idea but might like mentoring do feel free to 
do the opposite :) 

It's Google *Summer *of Code — so there's ages before anything much else 
happens. 

Thanks again. 

Kind Regards,

Carlton

On Tuesday, 15 November 2022 at 10:11:45 UTC+1 Carlton Gibson 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/58bf890d-28be-49b2-827e-a7cbe1f9587en%40googlegroups.com.

Re: Backport for ticket 34063?

[Carlton Gibson]

Just to clarify this point, which I think has been glossed over:

> But unless I'm misunderstanding the nature of the bug, this seems like it
basically makes async views un-testable ...

This isn't correct.

Under normal circumstances you just use the sync Client, as you've always
done. `response = client.get(`/my-async-view/`)`.
Django handles that the **view** is async for you.

It's only if you need to write an actual **async test**, i.e. an `async
def` test case that you need the async client and factory.

The factory can use the suggested `request.body` workaround if needed.
Where you need async def tests, dropping down to the request factory is
available. An example might be testing a middleware for async
support in isolation, which fits the request factory model directly.

The `AsyncClient` is affected, yes. The question is whether that justifies
a backport at this very late hour.





On Fri, 30 Dec 2022 at 23:59, Kevin Grinberg 
wrote:

> I'll say upfront that I haven't hit this particular issue, but it's mostly
> because I've avoided the Django async stack after some challenging
> experiences on the old(er) channels/daphne/etc. stack and its evolution.
> I've personally been in the "let's see how this develops" camp, which
> admittedly isn't the most community-focused. I'll resolve to do better in
> the new year.
>
> This does sort of get at one aspect of this issue though - there's less
> usage of the async stuff as it's being rolled out slowly across multiple
> releases (which it itself an experiment of sorts), in part because [at
> least] some people don't trust it to actually be stable and are waiting to
> see the whole story before committing projects more fully.
>
> So from the perspective of "how many users are impacted", I agree the
> impact is probably low. But unless I'm misunderstanding the nature of the
> bug, this seems like it basically makes async views un-testable without a
> pretty annoying workaround (assuming it's more than a handful of views)?
> Plus the fact that it's not easily discoverable.
>
> FWIW (I'm an n of 1 obviously), but I go LTS-to-LTS for most projects,
> just given uncertainty in when I'll be upgrading any particular project,
> and wanting to be certain I never fall out of support for at least security
> releases. So for my own personal needs, fair enough - by the time I migrate
> my 3.2 projects to 4.2, this will be fixed, and it's unlikely that I'll
> personally be experimenting with async views in the next 3 months or so.
> But that doesn't really seem like the sort of behavior we want to
> encourage, if we're trying to actually get people to use async, get some
> real-world usage, and signal that Django has a good async story.
>
> I'm very cognizant of maintenance burden and feel sheepish advocating for
> someone else to do work, but if this thread is asking for opinions, I do
> think it's important to backport this issue. I can't literally equate it to
> a data loss bug (the specific example in the policy), but I'd argue that
> the gradual nature of the async rollout and its importance in moving Django
> forward mitigates for an exception to the backport policy.
>
> Cheers,
> Kevin
>
>
> On Friday, December 30, 2022 at 5:24:51 PM UTC-5 timog...@gmail.com wrote:
>
>> As perfectionists, it's always hard to say (and hear) "no" when this sort
>> of request comes up. I'm unconvinced it's a serious issue that requires a
>> break from normal policy. (Unreported for 2 years in 4 major releases;
>> simple workaround present.)
>>
>> Incidentally, escalating an issue to the steering council after less than
>> 24 hours (during a holiday week, no less) probably isn't something we want
>> to model as a best practice in forming consensus.
>> On Friday, December 30, 2022 at 12:48:47 PM UTC-5 James Bennett wrote:
>>
>>> I have put it to the Steering Council:
>>>
>>>
>>> https://forum.djangoproject.com/t/request-for-technical-board-steering-council-vote-requested-backport-ticket-34063/17920/1
>>>
>> --
> 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/f9fc0dad-fb09-4c5b-8c68-a83375f42d2en%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/CAJwKpySNy2CgG-uEPtJSH5d2bJbUK0WtF-Hgo1u2KF

Re: Backport for ticket 34063?

[Carlton Gibson]

> Even if it will not be fixed for older versions, Django 4.1 ought to be
eligible for a backport.

What you're suggesting is a change to the backport policy. That may be the
right thing to do, but it would be quite a significant change.
These issues — where a bug report/fix comes outside the backport period —
are quite common. It's always a bit frustrating that we can't backport, but
the stability of released versions has been taken (for years, by the whole
community — by the folks hitting the particular non-backported issue this
time :) as correct on balance.

> But this response to it is eroding my trust in Django, and I hope you
know that is not something I say lightly.

Since I'm the only person who's responded thus far, I can't help but read
that as saying it erodes your trust in me. That's sad. Especially since all
I've done is not agree with you. :)
Nonetheless you can invoke the Steering Council if no-one else responds,
and you feel it's as bad as all that.

> ...a critical time when Django is facing stiff competition...

Django's USP is stability and ease of update, not async. The backport,
stability, and supported versions policies are the cornerstone of that, I
believe. It's not something we should endanger.
Other frameworks move faster, but they don't have extended LTS lifetimes to
consider.

I see the success of FastAPI in particular. Super.
But I don't see it as any different to Flask, say, in the previous period.
May a thousand flowers bloom.
I don't see it as an existential threat to Django. Quite the contrary: What
a rich and wonderful time it is for the Python web framework ecosystem as
whole.
(This ecosystem is itself under threat from JavaScript, I'm constantly
told, which will not survive Rust, I hear, ... and so on.)

My view is that Django's async support is maturing nicely, slowly, but
nicely and it's grows every release. That will continue for a few more
cycles yet. Bug fixes in new features should be backported within the
policy yes, but not beyond that. Better guidance in the asynchronous
support docs saying, "hey, do update, this stuff is still growing" may well
be in order. I have this in the Channels 4.0 release notes
<https://channels.readthedocs.io/en/latest/releases/4.0.0.html#updated-python-and-django-support>:
"The async support in both Python and Django continues to evolve rapidly.
We advise you to always upgrade to the latest versions in order to avoid
issues in older versions if you’re building an async application." — I
don't think similar in Django would hurt. /my view.

> ...as unwilling to support ...

Following the backport policy is not being unwilling to support.

Sorry (again) that I don't share your view. Sorry that undermines your
faith (in me) — I assume we still think there's room for rational
disagreement on how to weigh competing concerns in these kinds of cases.

I'm going to mute this thread until after the new year now.
Enjoy the festivities.

Kind Regards,

Carlton

On Fri, 30 Dec 2022 at 11:34, James Bennett  wrote:

>
>
> On Fri, Dec 30, 2022 at 2:04 AM Carlton Gibson 
> wrote:
>
>> No it's not. It's a bug in AsyncClient and AsyncRequestFactory, that
>> means if you're using those on older versions of Django, you'll need to
>> work around.
>> This is no different than any of a thousand other cases where there's
>> been a bug in an older version that folks have needed to account for.
>>
>
> I believe it is very different and have explained why repeatedly.
>
> But if it is to be left unfixed, what is the plan for how to communicate
> the workaround to people who will be running into this bug until at least
> April of 2024? And what is the plan for communicating to them that Django
> is aware async testing is broken and the official policy is to knowingly
> leave it broken in every currently-released version of the framework? Even
> if it will not be fixed for older versions, Django 4.1 ought to be eligible
> for a backport. And I strongly urge allowing a backport to 4.0 and 3.2,
> though I do not know what could convince you at this point.
>
> This bug is bad. But this response to it is eroding my trust in Django,
> and I hope you know that is not something I say lightly. I think it also is
> going to erode the trust of other people when they find out about it, and
> is going to do so at a critical time when Django is facing stiff
> competition in the async space and cannot afford to lose more ground or be
> seen as unwilling to support its own claimed async features.
>
>> --
> 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 r

Re: Backport for ticket 34063?

[Carlton Gibson]

James,

I think the backport policy has proven itself over the years, no?

"Django lied" — that's a bit melodramatic don't you think?.
Django introduced a new feature, as it is wont to do.
There was a bug in that new feature, as there are wont to be.
Unfortunately that bug was not discovered during the timeframe in which it
would qualify for a backport.
However it's fixed in the upcoming version, which will be in pre-release in
just a couple of weeks.
Sorry for the inconvenience, but backport and supported versions policy is
the foundation of the stability and ease of update you've come to
appreciate in Django over all these years.

> This is a showstopper of a bug...

No it's not. It's a bug in AsyncClient and AsyncRequestFactory, that means
if you're using those on older versions of Django, you'll need to work
around.
This is no different than any of a thousand other cases where there's been
a bug in an older version that folks have needed to account for.

> Unless another major bug gets found...

I'm *quite certain* there are plenty more of these to be found.
The journey is still really only just beginning.
I'd guess I'd say we're entering a new phase, but the async support is
neither complete nor mature.
There will be bugs.

I'm -1 on making an exception to the backport policy in this case. (Sorry I
don't agree with you.)


Kind Regards,

Carlton




On Fri, 30 Dec 2022 at 10:38, James Bennett  wrote:

> On Fri, Dec 30, 2022 at 1:27 AM Carlton Gibson 
> wrote:
> > It's frustrating when this happens, but the backport policy has proven
> its worth time and again.
> > I **really** don't see the case for making an exception here.
> > (The policy has more value than the inconvenience in any of these cases,
> or even all of them summed.)
>
> I don't see the value here.
>
> If it's left as-is, the message is, effectively, that Django lied
> about its async support for years, but suddenly *now* is asking people
> to trust the claims of async support. Unless another major bug gets
> found, in which case "well, *now* you can trust Django on async" will
> get kicked down the road again.
>
> This is a showstopper of a bug, and just leaving it deliberately
> unfixed in *every released version of Django* because "policy said no"
> has the potential to do a lot of damage to Django's reputation.
>
> > Adding the support here is difficult and slow enough. Backporting fixes
> to discovered bugs, outside the established policy, is making an
> unrealistic burden for ourselves.
>
> I'm not saying every bug found with async needs a backport. But one
> that literally prevents the built-in testing tool from working with a
> huge swathe of views and middlewares (including potentially some built
> in to Django itself), *when that tool is documented and Django claims
> to officially support it*, is just unacceptable. I'll work up the
> patches myself if that's what it takes.
>
> --
> 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/CAL13Cg-tMbTXN3WwqjqjgiLj1rrMO6K8YhRHnci6Qzw2d52Y-w%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/CAJwKpyQdcKve7rx2fwscf-WTY5c2SzgtaCJeOC66hAbTiMd3dw%40mail.gmail.com.

Re: Backport for ticket 34063?

[Carlton Gibson]

OK, yes, that's probably right.

Had #34063 been reported during the 3.1 cycle it would have been a release
blocker.
As it was, it wasn't reported until 4.0 (when main was already 4.1) so two
cycles later.
As such it no longer qualifies for a backport.

It's frustrating when this happens, but the backport policy has proven its
worth time and again.
I **really** don't see the case for making an exception here.
(The policy has more value than the inconvenience in any of these cases, or
even all of them summed.)

> As it was, it wasn't reported until 4.0 ...

I think the bottomline is people are only starting to use this stuff now.
It's still experimental, for whatever that means, and there simply are and
will be rough edges.
I'd be very happy to think about how we should message that better — a big
sign saying "Still in development: if you want to use async, be on the
latest versions" would be fine in my opinion.
I think we've been pretty upfront that that's the case.
Adding the support here is difficult and slow enough. Backporting fixes to
discovered bugs, outside the established policy, is making an unrealistic
burden for ourselves.

On Fri, 30 Dec 2022 at 10:13, James Bennett  wrote:

> On Fri, Dec 30, 2022 at 1:09 AM Carlton Gibson 
> wrote:
> > All you're talking about is adding this to your test cases right?
> >
> > # Work around Django #34063 until 4.2.
> > request.body
>
> As far as I can tell it needs to go in whatever code will *read*
> request.POST, not the code that generates the request. So that means a
> no-op "request.body" in every view and every middleware that might
> read request.POST. And that includes Django's own built-in views
> (including generic views) and any built-in async-supporting
> middlewares, if they have the misfortune to get called on the async
> path from an AsyncClient-initiated request.
>
> --
> 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/CAL13Cg_1MMt2DbcC%2B4Vfzi83g_U-bBNj2-J92Y1NWTvAS9c1Ww%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/CAJwKpyTCeMvXsxHwENYf0pEw2ySBXOadBEe_EXC04SndSk%3D6bQ%40mail.gmail.com.

Re: Backport for ticket 34063?

[Carlton Gibson]

James,

All you're talking about is adding this to your test cases right?

# Work around Django #34063 until 4.2.
request.body

# ... continue


C.

On Fri, 30 Dec 2022 at 10:04, James Bennett  wrote:

> On Fri, Dec 30, 2022 at 12:01 AM Carlton Gibson
>  wrote:
> > When I looked at the trace you posted in IRC yesterday, my first thought
> was "3.2?". I think supporting Django 3.2 at this point isn't worth the
> effort.
>
> It's also broken in 4.0 and 4.1. I just posted the first trace I got
> back from my test matrix, which happened to be a Django 3.2 run.
>
> > Yes, sure it's not EOL for another year or so but if folks want to use
> async they should be on the latest version.
>
> I strongly disagree with this -- Django has been claiming support for
> async views/middlewares, and for testing them with AsyncClient, since
> 3.1. Telling people that actually it was badly broken to the point of
> almost unusability until 4.2 and thus not to use any of those versions
> that claimed to have the support is... suboptimal. Especially given,
> as I noted, the difficulty for Django novices of even figuring out
> what the heck is going on when they try to test an async view and get
> a weird exception.
>
> Or to put it another way: if I submitted patches against the 3.2, 4.0,
> and 4.1 branches for docs/topics/testing/tools.txt that put a big
> "WARNING! BROKEN! DO NOT USE!" on all mentions of AsyncClient, I doubt
> those patches would be well-received. But that's basically what those
> releases of Django *need* at this point. It's intolerably misleading
> to end users of the framework to have docs for those versions claiming
> that you can write async code and test it with the AsyncClient when...
> well, you can't, really, unless you know the precise way that it's
> broken and put explicit workarounds for the brokenness in all your
> views and middlewares.
>
> > You're wanting to add async support to your third-party library: super;
> just say it's 4.2+ and move on.
>
> And telling library authors not to even think about doing async
> support until Django 4.2 comes out (approximately two and a half years
> after Django itself claimed to officially support this stuff), and
> that they have to cut off all older versions of Django when they do so
> *despite those versions officially claiming to support async* just
> seems like a recipe for those authors deciding not to trust or waste
> their time on Django.
>
> So I *really* think this one needs an exception to the backports
> policy. Async is too important, and Django's reputation is too
> important, to leave 3.2, 4.0, and 4.1 as badly broken as they
> currently are.
>
> --
> 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/CAL13Cg8ZjzR%3Dzd4PwY%2Bmg1pUMXzPDUx_0ZPetCam5xEM7xqS1w%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/CAJwKpyQzd%2BUBKWECbHwZvZ37zRRwYh4w9LAMsZFMzqLPvTM5cA%40mail.gmail.com.

Re: Backport for ticket 34063?

[Carlton Gibson]

Hey James.

Grrr. 😬

I don't think this justifies an exception to the backport policy. It's not
significantly different from any of any number of other fixes that folks
ask for a backport for and we say no. Fielding "but you backported that
one" isn't an extra task that's going to be helpful.

When I looked at the trace you posted in IRC yesterday, my first thought
was "3.2?". I think supporting Django 3.2 at this point isn't worth
the effort.
Yes, sure it's not EOL for another year or so but if folks want to use
async they should be on the latest version.
There's significant changes still in each version, and sticking on the old
LTS is asking for trouble. (I certainly don't see making exceptions to the
backport policy to help out such to be a good idea. The old LTS is for
frozen apps, not new development.)
You're wanting to add async support to your third-party library: super;
just say it's 4.2+ and move on.
Folks who aren't on the LTS will be updating shortly enough anyway. A
little-bit of carrot never hurt.

Kind Regards,

Carlton

On Fri, 30 Dec 2022 at 01:44, James Bennett  wrote:

> https://code.djangoproject.com/ticket/34063
>
> The short summary of that ticket is that there was a significant
> behavioral difference between django.test.Client and
> django.test.AsyncClient: with AsyncClient, any view or middleware
> which attempted to access request.POST without first accessing
> request.body would raise an exception with an obscure message about
> trying to read too much data from the request body. This was fixed
> last month:
>
>
> https://github.com/django/django/commit/c4eaa67e2b880db778c9fe6d9854fbdfcc16ecd2
>
> However, it does not explicitly fall under any of the criteria for
> backporting to older releases
> (
> https://docs.djangoproject.com/en/dev/internals/release-process/#supported-versions
> )
> so at the moment, the fix will only be available from Django 4.2
> onward, and no previous Django versions will receive a backported
> version of the fix (though the bug is present back to at least Django
> 3.2, and I suspect but haven't confirmed all the way back to the
> introduction of AsyncClient in Django 3.1).
>
> I'd like to argue for an exception to the normal backport policy, and
> for #34063 to be backported to Django 4.1, 4.0, and 3.2 LTS.
>
> My reasoning here is that async support is an incredibly important
> part of the Python web ecosystem right now, and there is no good
> alternative to django.test.AsyncClient for testing some kinds of async
> code -- although the normal django.test.Client can hit URLs served by
> async views, it does not always trigger async code paths inside Django
> when doing so. For example, I came across #34063 while trying to test
> a middleware that supports both sync and async usage; only AsyncClient
> reliably exercises the async code path of such a middleware, but that
> triggers the bug unless I add throwaway accesses of request.body.
>
> Especially for authors of reusable applications/libraries that try to
> support a broad range of Django versions, many of whom (like me!) are
> finally getting around to async support, this is an unpleasant
> situation, since it will require the request.body workaround to be
> left in place in all such code for at least another 16 months or so
> (which is when Django 3.2 LTS will finally drop out of upstream
> support). And that's presuming such authors even know to put in the
> workaround -- it took me quite a bit of debugging and following up on
> irrelevant search results before I finally found #34063, and that's as
> someone who has deep familiarity with Django -- someone less
> experienced at delving into Django's internals to figure out root
> causes and likely search terms would probably have had an even worse
> time of it.
>
> Finally, if it had been discovered prior to any of the releases in
> which AsyncClient has been present, this would have been a clear
> release blocker; it's quite a serious bug that seems to have gone
> unnoticed for so long largely by accident (and, ironically, by
> under-testing of the testing tools).
>
> So I think the right thing to do, to help with Django's transition
> into async support and to avoid imposing unnecessary burdens of
> debugging on application and library authors, is to backport the fix
> from #34063 to the full set of currently-supported Django releases:
> 4.1, 4.0, and 3.2 LTS.
>
> --
> 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/CAL13Cg-Pexnfd7ynnOWEoLkmfM5gYhcMfHgkYzOG7nH8sWA9sQ%40mail.gmail.com
> .
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" group.
To 

Re: Standalon Django ORM

[Carlton Gibson]

I think we already have this no?

See https://docs.djangoproject.com/en/4.1/ref/databases/#s-third-party-notes
for a list of 3rd party DB backends.

On Tue, 13 Dec 2022 at 10:31, Vasanth Mohan  wrote:

> I second Jörg about better maintainability with tighter integrations.
>
> However, for the fun of stirring the pot, what's the opinion on letting
> Django define an API for the ORM and letting a library deal with the
> DB-specific implementation that generates the SQL for query?  Django could
> have a list of officially supported DBs ('django.db.postgres') to be
> included in the INSTALLED_APPS to select the DB to be used.
>
> Meanwhile, the community can come up with support for other DBs like
> CockroachDB, Mongo etc. (just an idea borrowed off the rust community). It
> can even allow adding additional filters/commands specific to the DB.
>
> Vaz
>
> On Monday, 12 December 2022 at 13:07:50 UTC+1 j.bre...@netzkolchose.de
> wrote:
>
>> I tend to believe the opposite is true. Django was/is a successor in its
>> field, because it offers an "out-of-the-box" or "batteries included"
>> experience. Subsequently parts were shaped as needed for that bigger
>> picture, e.g. the ORM became what it is today.
>>
>> Does anyone still remember django versions with external south
>> migrations? Was much more tricky to get done right, ppl would just
>> forget it, do it in wrong order, whatsoever. Got basically fixed by the
>> tighter integration with typical django project lifecycling.
>>
>> By making the ORM an external lib with its own progression and
>> versioning you'd reintroduce all that fuzz again, plus frictions from
>> API changes, that seem logical from a db maintainer viewpoint, but make
>> life harder at consumer end (would be django here). By keeping it in one
>> place those tiny viewpoint differences can be leveled out upfront.
>>
>> Ofc mammoths move slower, but they are also more resilient against
>> disturbance. In terms of good long term maintainability the more
>> granular/agile approach as seen in the JS-world still has to prove
>> itself. Projects there need a lot more care&love of their dependency
>> lists, and typically wont run anymore after 1-2 years without manually
>> fixing this or that, because package xy of 100+ dependencies turned its
>> API upside-down for no good reason.
>>
>> So no, outsourcing things is not always a good idea.
>> All imho, ofc.
>>
>> Cheers,
>> Jörg
>>
> --
> 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/d405433e-3ce4-4737-9539-47012a405b9en%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/CAJwKpyRrS%2BMztj%3DY57g%2BKcf%3D9%2B94PKDHtq7EimvSzxSvbdgVPA%40mail.gmail.com.

Django bugfix release: 4.1.4

[Carlton Gibson]

Details are available on the Django project weblog:

https://www.djangoproject.com/weblog/2022/dec/06/bugfix-release/

-- 
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/CAJwKpyQF7r1B4jwv%3D-idgJ2fEsgwHJvJU66qrJ-pCmQ_uHVrqg%40mail.gmail.com.

Re: Async wrappers in contrib packages

[Carlton Gibson]

> But I can file a ticket just to track this one?

TBH I'd prefer it if you pondered the design here without opening a ticket
until such a point (if ever) that you have a concrete plan. (We'd likely
just close it as wontfix unless there's a specific idea on the table
anyway, so it's just noise at that point.)

I hope that makes sense.

Kind Regards,

Carlton

On Mon, 28 Nov 2022 at 16:53, Jon Janzen  wrote:

> Hey Carlton,
>
> There's: https://code.djangoproject.com/ticket/31949 "Allow builtin view
>> decorators to be applied directly to async views."
>> I think this is likely the next step.
>>
>> There's a PR for that, which I think took a too complex approach (see
>> discussion). A simpler (more inline) take be good to see.
>>
>
> Thanks, I saw this ticket but it didn't look relevant when I was skimming
> the tracker. I'll take a closer look.
>
> > My personal interest in this is about django.contrib.auth (login,
>> authenticate, etc.)
>>
>> This was missing from the PR on #31949, so if you wanted to pick it up...
>> 😜
>>
>
> I'll take a closer look, I think I might be able to do that :D
>
>
>>
>> (Not sure about the value of rewriting the built-in views though if
>> that's what you're thinking of 🤔)
>>
>> > ...and django.contrib.syndication (views.Feed)
>>
>> Not sure what you have in mind here. Perhaps explaining that in
>> more detail would help?
>> (I'm not immediately sure I see the benefit of async for the feed views?
>> 🤔)
>>
>
> Not for the view itself, but for individual fields that compose the Feed.
>
> I want to define an async "item_categories" method when I subclass Feed
> due to an async-only permissions system I have that is out-of-scope here,
> but that isn't possible right now so I pre-compute each of these values and
> pass in a composite object with the source object and item_categories
> precomputed.
>
> I would rather just declare an async function and let the framework figure
> out how to resolve the values reasonably efficiently for me. I don't want
> to pay the cost of async_to_sync for each item in the feed :/
>
> I'm fine with setting this one aside, as I said I already have a
> workaround. But I can file a ticket just to track this one?
>
>  - Jon
>
> --
> 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/CAP1wFiCp_y%3DVygQxmat-JVR2cr_LjGTKDyQ7rXtg3ERrzdfXXw%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/CAJwKpyRp5OLrEB%3DRD4zONCsChZMcBSEpqyiSCmoR9XB83Y6w5w%40mail.gmail.com.

Re: Potential way forward for DATABASE_URL

[Carlton Gibson]

Hey Raphael.

My only query is as we sure the API is correct going forward?
The answer could be yes there, but I didn't (as yet get to) review the
history in depth.

We **can** deprecate things, but we get an awful lot of complaints and
pushback, even changes that are clearly for the good.
I'd rather measure twice and cut once is all.
The whole point of the "Do it in a third-party app" approach is that we get
to make sure the APIs are right, without adding churn to Django,
and without being tied to the long-release cycle fixing the unforeseen
issues that arise.

Kind Regards,

Carlton

On Tue, 29 Nov 2022 at 06:45, Raphael G  wrote:

> (I'm very sorry about the threading going on here, I originally replied to
> the very old mailing thread and then realized it had not generated
> consensus, so am going to try and make this thread a more focused
> discussion regarding concensus)
>
> In the other thread people are discussing more generalized setting
> helpers. I am trying to avoid this, most because I think this work doesn't
> exclude that work. But also I don't want to introduce more magic
> personally, nor do the work involved in the settings magic personally.
> os.environ is straightforward IMO.
>
> Carlton posted the following comment:
>
> > Given that it's a single import I might still lean towards seeing it as
> an external package, at least for a cycle, so unknowns that come up can be
> resolved, and folks on an older LTS can opt-in early, etc.
> (But that's not a point of religion.)
>
> I am OK with putting in work to have it as a separate package for a cycle.
> The glib comment would be that dj-database-url was that package for many
> cycles, but this is not very true in practice. This is introducing extra
> things not originally present for cache configuration, and has this concept
> of the database backends holding the parsing logic. And of course there's
> an extremely valid underlying point here: the API really needs to be
> "right". Personally I believe that Django's very good deprecation strategy
> means that big mess-ups are fortunately fixable, but it's work for everyone
> (and likely would involve either some weird hack in the intermediate
> steps).
>
> I would like to offer an alternative narrative to the background here,
> that I think more strongly justifies introducing this into Django proper.
> It is not the real narrative, but it is a narrative.
>
> URL-based configuration conventions exist for database backends and cache
> backends in various libraries. This lets us pass in credentials as one
> string rather than a bunch of components to be assembled. But each backend
> will handle things like configuration options within those URLs
> differently. Overall URL parsing logic is all very similar, with important
> differences coming from how the database name might get passed in, how
> certain connection options get passed in, etc.
>
> So it would be helpful to provide both a method on DatabaseWrapper that
> does basic URL parsing (to pull out the host/username/password), and for
> Django's supported DB backends to override this URL parsing method based on
> whatever convention is being applied by other libraries (or from
> backend-specific tooling). Same thing for caches.
>
> Because this is ultimately a bit backend-specific, having this logic close
> to the actual backend connection logic (so on these classes themselves) is
> the most natural, more so than having separate dictionaries with mappings
> to backends. New configuration option? Would be good to make sure it's
> handled in the URL parser as well, somehow.
>
> Rambling a bit, but really am open to any(?) way forward that leads to "I
> will not need to install an extra package to handle this, nor am I
> personally parsing the URL with urllib.parse", and am ready to do the
> legwork.
>
> Speaking to that, if we have consensus on the principle, what would be the
> right step forward? An actual DEP?
>
> Raphael
>
> On Tuesday, November 29, 2022 at 1:47:24 PM UTC+9 Adam Johnson wrote:
>
>> I’m happy with this approach, it’s a little step forwards towards
>> maintainable settings files.
>>
>> On Sun, 27 Nov 2022 at 20:37, 'Tobias McNulty' via Django developers
>> (Contributions to Django itself)  wrote:
>>
>>> Hi Raphael,
>>>
>>> Thanks for taking this on.
>>>
>>> Starting with a limited scope seems like a good idea to me.
>>>
>>> A couple other things I like about this approach:
>>>
>>> - It tackles cache URLs at the same time (it makes sense for them to
>>> mirror one another, IMO).
>>> - No implicit usage of DATABASE_URL, but as you said it still supplies
>>> an easily searchable answer for "Django DATABASE_URL."
>>>
>>> Cheers,
>>> Tobias
>>>
>>>
>>> On Sun, Nov 27, 2022, 2:40 PM Raphael G  wrote:
>>>
 Some base industry background. It's a pretty common convention to share
 credentials in environment variables. For many PaaS, it's common to use
 connection URLs to do so. So DATABASE_URL will have a URL like
 postg

Re: Integrate dj-database-url into Django

[Carlton Gibson]

This must be do-able now.

There was some discussion of something along these lines a couple of years
ago, with the idea of doing it for GSoC.
There was much back-and-forth but no consensus.

It has then come up again with Peter's suggestions about making it easier
to get to a deployment ready state.
The discussion with Florian there touches on this exact point.

It looks like there's two sides to it:
* A user-facing API, perhaps like ...get("key" default) 🤔
* A pluggable backend API for that, so folks can use things like Vault and
temporary secrets files as well as the environment.

If I followed correctly, it would be OK to ship an environment backend with
Django (perhaps with some simpler ones for development/testing) leaving
more advanced options open.
I think Florian has ideas here.


On Mon, 28 Nov 2022 at 23:20, James Bennett  wrote:

> It feels like this needs to be a broader conversation about not just
> changing DATABASES to accept a URL, or integrating a particular
> database-settings project, but to re-think how Django does
> settings-from-environment as a whole.
>
> When I'm setting up new Django-based projects, django-environ
> (https://pypi.org/project/django-environ/) is now one of the first
> packages I reach for, and it has a much more comprehensive set of
> helpers for configuring Django from environment variables and doing
> appropriate parsing and type casts.
>
> There also is Pydantic's settings model
> (https://pydantic-docs.helpmanual.io/usage/settings/) which uses type
> annotations to drive parsing/validation/type-casting and defaults to
> reading from environment variables.
>
> I'd rather see some sort of comprehensive "make settings-from-env
> easier" in Django than one-off pieces like a database URL.
>
> --
> 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/CAL13Cg-cqJi1JanmhN0S3rf1MYME9qH4XJsCEjLdB5wFXEQeAA%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/CAJwKpyRXH5BgJDXVrDXJqfLYWjdDJ3Mf0rZyRPDgo3VrRdbf0Q%40mail.gmail.com.

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

[Carlton Gibson]

On this vein I'd also like to see DB Cascades implemented
https://code.djangoproject.com/ticket/21961


On Mon, 28 Nov 2022 at 18:10, 'st...@jigsawtech.co.uk' via Django
developers (Contributions to Django itself) <
django-developers@googlegroups.com> wrote:

> +1 from me on DB defaults (constraints too). I've worked on many systems
> where Django isn't the only place putting records into DBs and having DB
> level defaults and constraints fixes a lot of common issues with that.
> Currently I create an empty migrations to then add them in manually when
> required
>
> On Monday, 28 November 2022 at 16:59:48 UTC John Whitlock wrote:
>
>> I'd like to see database-level defaults supported in models and
>> migrations:
>>
>> https://code.djangoproject.com/ticket/470
>>
>

-- 
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/CAJwKpyTqhMv6GATZ_wjMpv2YS%3D0aUV%3DNViAZRoi1KBRpePnwBg%40mail.gmail.com.

Re: Can we move the activity on this list to the Forum now?

[Carlton Gibson]

Hey Roger,

Indeed it does. You can set up Email Mode (that may not be the actual name)
and it’ll work just like a mailing list.

You can also subscribe to just a particular category, so the Internals one
would map to the discussion on this list.



On Monday, 28 November 2022, Roger Gammans 
wrote:

> Hi
>
> I can't speak for others, but I personally STRONGLY value the fact that
> this discussion happens in my inbox, not on yet another website.
>
> But perhaps the forum still supports this reading mode?
>
> On Mon, 2022-11-28 at 05:38 -0800, Carlton Gibson wrote:
>
> Hi all.
>
> Given the issues with Tom's access to the mailing list here, and the fact
> that the Forum has been active for a few years now, and is a great success,
> I'd like to revisit whether we can move on-mass (all few of us :) over
> there?
>
> We'd enjoy the benefits of a much nicer system. We'd not have issues such
> as the current, and we'd be one less item in the pocket of a mega-corp.
> (You can rank those as you will :)
>
> Initially when this can up (a long time ago) Andrew and Tom discussed
> whether we could import the history here into the forum. I think that's
> unnecessary. We can still access the history here (until such a day as
> Google takes it away) at worst -- but, rather, if we can get an archive we
> could import it into read-only Datasette instance[0] — and that would
> likely be good enough.
>
> Can we move now?
>
> Thanks.
>
> Kind Regards,
>
> Carlton
>
>
> [0]: I'd happily do this.
>
> --
> 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/101f4e6d-9b83-47ab-bb1b-
> b571402e037dn%40googlegroups.com
> <https://groups.google.com/d/msgid/django-developers/101f4e6d-9b83-47ab-bb1b-b571402e037dn%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/4a329eadd5606c2f94aa5638e079800f1914d0d7.camel%
> 40gammascience.co.uk
> <https://groups.google.com/d/msgid/django-developers/4a329eadd5606c2f94aa5638e079800f1914d0d7.camel%40gammascience.co.uk?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/CAJwKpyTSfF51C6ejog0xMd_6s-DofOUT4yaTeWmoc5SEiTY8jQ%40mail.gmail.com.

Can we move the activity on this list to the Forum now?

[Carlton Gibson]

Hi all. 

Given the issues with Tom's access to the mailing list here, and the fact 
that the Forum has been active for a few years now, and is a great success, 
I'd like to revisit whether we can move on-mass (all few of us :) over 
there? 

We'd enjoy the benefits of a much nicer system. We'd not have issues such 
as the current, and we'd be one less item in the pocket of a mega-corp. 
(You can rank those as you will :) 

Initially when this can up (a long time ago) Andrew and Tom discussed 
whether we could import the history here into the forum. I think that's 
unnecessary. We can still access the history here (until such a day as 
Google takes it away) at worst -- but, rather, if we can get an archive we 
could import it into read-only Datasette instance[0] — and that would 
likely be good enough. 

Can we move now? 

Thanks. 

Kind Regards,

Carlton


[0]: I'd happily do this. 

-- 
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/101f4e6d-9b83-47ab-bb1b-b571402e037dn%40googlegroups.com.

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

[Carlton Gibson]

Hi All. 

Tom Forbes is currently unable to post to the Google Group here, due to 
Currently Undiagnosed Google Account Weirdness™. 

For the record he's asked me to say that his vote is +1 in support of the 
change, but I feel we should probably move voting to the forum because of 
this. 


Kind Regards,

Carlton


On Monday, 28 November 2022 at 09:52:35 UTC+1 f.apo...@gmail.com wrote:

> Hi,
>
> +1 from me, but I'd like to ask the wider community (ie DSF members) 
> whether they support this change.
>
> While there has been some opposition on whether a change likes this will 
> actually change things, I think that given the overall good reception of 
> the proposal it is at least worth to try it.
>
> Cheers,
> Florian
> On Friday, November 25, 2022 at 10:04:36 AM UTC+1 Mariusz Felisiak wrote:
>
>> 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/a2f62728-33b0-43e7-8fcc-696b7e6fac82n%40googlegroups.com.

Re: Integrate dj-database-url into Django

[Carlton Gibson]

Hey Tobias.

> Could you (or others) provide some examples of the needs this solution
doesn't address (not necessarily complete, just to give an idea)?

I hadn't seen the other thread this morning when replying to this one. It
looks like some of the issues are indeed addressed *but *I was only able to
give the historical discussion a quick read — I can't if it's Job Done™ — I
kind of feel that review falls to the proposal.

>From my glance, all positive points:

* The register functions for a backend look quite flexible.
* The cache case was covered.
* The need to wire-up the configure functions looked to resolve somes
concerns too.

Given that it's a single import I might still lean towards seeing it as an
external package, at least for a cycle, so unknowns that come up can be
resolved, and folks on an older LTS can opt-in early, etc.
(But that's not a point of religion.)

Kind Regards,

Carlton

On Mon, 28 Nov 2022 at 14:03, 'Tobias McNulty' via Django developers
(Contributions to Django itself)  wrote:

> Hi Carlton,
>
> Responses inline below:
>
> On Mon, Nov 28, 2022, 2:40 AM Carlton Gibson 
> wrote:
>
>> Hi Raphael, thanks for picking this up.
>>
>> Looking at the history here, particularly the discussion here
>> https://groups.google.com/g/django-developers/c/UQjpzB39JN0/m/XGqdV8nbBwAJ
>> but there are others, the reason this hasn't already happened is that if
>> we're going to merge this into core it would be nice (required?) to handle
>> extra cases than (to paraphrase) "just what Heroku expects".
>>
>> It doesn't look like anyone has sat down to spec out exactly what that
>> means, but there seem to be plenty of thoughts in the discussion.  ... 🤔
>>
>> JKM's comment on the thread there is representative of the general
>> thought:
>>
>> > I suspect this is a "good enough is good enough" situation. Something
>> like what
>> Raffaele is talking about, or dsnparse, or whatever would probably be
>> ideal. And
>> for something to be merged into core, I think it'd need to be a more full
>> solution than just dj-database-url.
>>
>
> Isn't this already a more full solution insofar as it supports setting
> CACHES as well? This may or may not be correct, but I read the history a
> little differently, more that "life happens" and no one quite found the
> energy to push the current solution over the finish line (I empathize
> completely!).
>
> The trouble with merging a suboptimal solution is that once it's in, it's 
> *very
>> hard* to change. We have the whole API stability policy to contend with
>> (and rightly so).
>> We bring in a half-baked solution; likely "recommend" it (for some value
>> of that) and then face a long stream of difficult adjustments whilst we try
>> and accommodate the necessary adjustments.
>>
>
> I agree 100%, and I feel like we can and will take this into consideration
> sufficiently as we refine the current solution, if we continue down this
> path.
>
>  Given that dj-database-url is stable, a single line install, and (most
>> importantly) not being developed to try and accommodate the issues that
>> stopped it just being merged into core already, I think it should continue
>> to live as a third-party package.
>>
>> The place for the development to happen is in dj-database-url or a
>> successor package. (The first step would be a Roadmap drawn from the
>> historical discussion.)
>> Once (if) that gets to the point where it clearly addresses the 90% of
>> needs, then there's a case for adding it to core. I don't think we can just
>> push forward given that nothing changed in the last few years.
>>
>
> Could you (or others) provide some examples of the needs this solution
> doesn't address (not necessarily complete, just to give an idea)?
>
> Many thanks,
> Tobias
>
> --
> 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/CAMGFDKQg8ikr%2BVh9ZXm2UXJidbz%2BpUr-GvZa%2BKoGz%2BBfRyZggg%40mail.gmail.com
> <https://groups.google.com/d/msgid/django-developers/CAMGFDKQg8ikr%2BVh9ZXm2UXJidbz%2BpUr-GvZa%2BKoGz%2BBfRyZggg%40mail.gmail.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/CAJwKpyQE%2BCGB0YtFF_%3DKbSwDt-AbvNQO4CHTdBBA5XUaHECTOA%40mail.gmail.com.

Re: Integrate dj-database-url into Django

[Carlton Gibson]

I see you posted afresh in the other thread, addressing some of the points
here. C.


On Mon, 28 Nov 2022 at 08:39, Carlton Gibson 
wrote:

> Hi Raphael, thanks for picking this up.
>
> Looking at the history here, particularly the discussion here
> https://groups.google.com/g/django-developers/c/UQjpzB39JN0/m/XGqdV8nbBwAJ
> but there are others, the reason this hasn't already happened is that if
> we're going to merge this into core it would be nice (required?) to handle
> extra cases than (to paraphrase) "just what Heroku expects".
>
> It doesn't look like anyone has sat down to spec out exactly what that
> means, but there seem to be plenty of thoughts in the discussion.  ... 🤔
>
> JKM's comment on the thread there is representative of the general
> thought:
>
> > I suspect this is a "good enough is good enough" situation. Something
> like what
> Raffaele is talking about, or dsnparse, or whatever would probably be
> ideal. And
> for something to be merged into core, I think it'd need to be a more full
> solution than just dj-database-url.
>
> The trouble with merging a suboptimal solution is that once it's in, it's 
> *very
> hard* to change. We have the whole API stability policy to contend with
> (and rightly so).
> We bring in a half-baked solution; likely "recommend" it (for some value
> of that) and then face a long stream of difficult adjustments whilst we try
> and accommodate the necessary adjustments.
>
> Given that dj-database-url is stable, a single line install, and (most
> importantly) not being developed to try and accommodate the issues that
> stopped it just being merged into core already, I think it should continue
> to live as a third-party package.
>
> The place for the development to happen is in dj-database-url or a
> successor package. (The first step would be a Roadmap drawn from the
> historical discussion.)
> Once (if) that gets to the point where it clearly addresses the 90% of
> needs, then there's a case for adding it to core. I don't think we can just
> push forward given that nothing changed in the last few years.
>
> Kind Regards,
>
> Carlton
>
>
>
> On Sun, 27 Nov 2022 at 20:40, Raphael G  wrote:
>
>> Alright, I tried to revive Tom Forbe's work on this in
>> https://github.com/django/django/pull/16331
>>
>> My honest feeling here is that if Django existed just for me, I would
>> really just want to get this pulled in as an option, and trying to increase
>> the scope beyond "given a URL, get a dictionary of settings" is a tarpit
>> that is not worth venturing into in a first merge. Though it's definitely a
>> tarpit worth venturing into as a future step!
>>
>> So my strategy here was to try and get this as close to mergeable as
>> possible, with as few points of discussion needed as possible. I tried to
>> document what Tom did, more or less disregarded the idea of providing DSN
>> support in settings, and for memcache avoided blessing an "official"
>> backend. The main thing should be that if people google Django DATABASE_URL
>> there should be a good answer in the docs, IMO.
>>
>> As someone who's dealt with custom backends in various parts of Django,
>> and with libs, I think Tom's simple registry pattern for custom protocols
>> is more than sufficient for library writers.
>>
>> Documentation is minimal, but exists. While I basically expect people
>> writing custom DB backends or cache backends to directly look at the
>> source, at the very least we are pointing to the existence of functions for
>> registration in the docs in this PR.
>>
>> I'm sure we all have these simple projects that really don't need to do
>> much, we all have been pulling in dj_database_url on the side to get this
>> and feeling a bit off about it, so let's try and get that use case handled
>> in a way that doesn't prevent further niceness in the future!
>>
>> Raphael
>> On Monday, December 24, 2018 at 7:01:23 AM UTC+9 Raffaele Salmaso wrote:
>>
>>> Hi all,
>>> I'm working on https://github.com/django/django/pull/10786 (which is a
>>> port of https://pypi.org/project/django-service-urls/ , which is a
>>> 'fork/rewrite' of Tom PR).
>>> I need to (re)read all these emails to find ideas to improve the
>>> PR/package.
>>>
>>> On Sat, Jul 28, 2018 at 9:44 PM Tom Forbes  wrote:
>>>
>>>> So in the PR I proposed I only bits I took verbatim from
>>>> dj-database-url are the tests. The rest is re-implemented. I 

Re: Async wrappers in contrib packages

[Carlton Gibson]

Hi Jon.

There's: https://code.djangoproject.com/ticket/31949 "Allow builtin view
decorators to be applied directly to async views."
I think this is likely the next step.

There's a PR for that, which I think took a too complex approach (see
discussion). A simpler (more inline) take be good to see.

> My personal interest in this is about django.contrib.auth (login,
authenticate, etc.)

This was missing from the PR on #31949, so if you wanted to pick it up... 😜

(Not sure about the value of rewriting the built-in views though if that's
what you're thinking of 🤔)

> ...and django.contrib.syndication (views.Feed)

Not sure what you have in mind here. Perhaps explaining that in more detail
would help?
(I'm not immediately sure I see the benefit of async for the feed views? 🤔)

Kind Regards,

Carlton


On Sun, 27 Nov 2022 at 23:02, Jon Janzen  wrote:

> Hey everyone,
>
> Sorry if I'm not following correct protocol on this or if this has already
> been discussed elsewhere, but is there any consensus about (or needed for)
> creating async versions of contrib packages?
>
> My personal interest in this is about django.contrib.auth (login,
> authenticate, etc.) and django.contrib.syndication (views.Feed) but I would
> guess this sort of work would fall under a general policy.
>
> I read DEP009
>  and
> didn't see any discussion of this topic, nor could I find any discussions
> on the ticket tracker (my skills using the tracker are limited). I could
> only find 2 files mentioning "async" in django/contrib/ (git grep "async"
> django/contrib | grep "\.py:"):
>
> * django/contrib/contenttypes/fields.py (added by me recently
> ,
> a bug fix )
> * django/contrib/staticfiles/handlers.py (added as part of standing up
> async support
> 
> )
>
> Has there been any consensus about this? If I'm interested in async
> versions of functions/features in contrib packages should I just file
> tickets, or is this something that might need a DEP first?
>
> Again, sorry if I'm barking up the wrong tree. It's not my intention to
> waste anyone's time!
>
> --
> 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/70e80f26-e1fa-4aa9-a3a8-0d7dc38752c3n%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/CAJwKpyRdOHcNymeAoQceMeiog%2Bum8cUJVKsXB6uyhTajmbbwxA%40mail.gmail.com.

Re: Integrate dj-database-url into Django

[Carlton Gibson]

Hi Raphael, thanks for picking this up.

Looking at the history here, particularly the discussion here
https://groups.google.com/g/django-developers/c/UQjpzB39JN0/m/XGqdV8nbBwAJ
but there are others, the reason this hasn't already happened is that if
we're going to merge this into core it would be nice (required?) to handle
extra cases than (to paraphrase) "just what Heroku expects".

It doesn't look like anyone has sat down to spec out exactly what that
means, but there seem to be plenty of thoughts in the discussion.  ... 🤔

JKM's comment on the thread there is representative of the general thought:

> I suspect this is a "good enough is good enough" situation. Something
like what
Raffaele is talking about, or dsnparse, or whatever would probably be
ideal. And
for something to be merged into core, I think it'd need to be a more full
solution than just dj-database-url.

The trouble with merging a suboptimal solution is that once it's in, it's *very
hard* to change. We have the whole API stability policy to contend with
(and rightly so).
We bring in a half-baked solution; likely "recommend" it (for some value of
that) and then face a long stream of difficult adjustments whilst we try
and accommodate the necessary adjustments.

Given that dj-database-url is stable, a single line install, and (most
importantly) not being developed to try and accommodate the issues that
stopped it just being merged into core already, I think it should continue
to live as a third-party package.

The place for the development to happen is in dj-database-url or a
successor package. (The first step would be a Roadmap drawn from the
historical discussion.)
Once (if) that gets to the point where it clearly addresses the 90% of
needs, then there's a case for adding it to core. I don't think we can just
push forward given that nothing changed in the last few years.

Kind Regards,

Carlton



On Sun, 27 Nov 2022 at 20:40, Raphael G  wrote:

> Alright, I tried to revive Tom Forbe's work on this in
> https://github.com/django/django/pull/16331
>
> My honest feeling here is that if Django existed just for me, I would
> really just want to get this pulled in as an option, and trying to increase
> the scope beyond "given a URL, get a dictionary of settings" is a tarpit
> that is not worth venturing into in a first merge. Though it's definitely a
> tarpit worth venturing into as a future step!
>
> So my strategy here was to try and get this as close to mergeable as
> possible, with as few points of discussion needed as possible. I tried to
> document what Tom did, more or less disregarded the idea of providing DSN
> support in settings, and for memcache avoided blessing an "official"
> backend. The main thing should be that if people google Django DATABASE_URL
> there should be a good answer in the docs, IMO.
>
> As someone who's dealt with custom backends in various parts of Django,
> and with libs, I think Tom's simple registry pattern for custom protocols
> is more than sufficient for library writers.
>
> Documentation is minimal, but exists. While I basically expect people
> writing custom DB backends or cache backends to directly look at the
> source, at the very least we are pointing to the existence of functions for
> registration in the docs in this PR.
>
> I'm sure we all have these simple projects that really don't need to do
> much, we all have been pulling in dj_database_url on the side to get this
> and feeling a bit off about it, so let's try and get that use case handled
> in a way that doesn't prevent further niceness in the future!
>
> Raphael
> On Monday, December 24, 2018 at 7:01:23 AM UTC+9 Raffaele Salmaso wrote:
>
>> Hi all,
>> I'm working on https://github.com/django/django/pull/10786 (which is a
>> port of https://pypi.org/project/django-service-urls/ , which is a
>> 'fork/rewrite' of Tom PR).
>> I need to (re)read all these emails to find ideas to improve the
>> PR/package.
>>
>> On Sat, Jul 28, 2018 at 9:44 PM Tom Forbes  wrote:
>>
>>> So in the PR I proposed I only bits I took verbatim from dj-database-url
>>> are the tests. The rest is re-implemented. I think it's a pretty good POC
>>> but I haven't touched it in a while.
>>>
>>> In any case we have to implement our own parsing for backends that do
>>> not support passing in a URL to the connection library.
>>>
>>> Making postgres skip our parsing step and passing it in directly is an
>>> implementation detail and there are much more important questions around
>>> the API design to answer before this has any chance of being included.
>>>
>>> On Sat, 28 Jul 2018, 12:57 Maciej Urbański,  wrote:
>>>
 I would agree that DSN support seems like a nicer alternative to just
 copying dj-database-url, because it not only focuses on 12factor
 configuration in enviroment variables, but also enables some additional
 flexibility for the database connection option passing.

 As for 12factor, I think https://gist.github.com/telent/9742059 is a
 good r

Re: Set a reasonable default for EMAIL_TIMEOUT

[Carlton Gibson]

Hi Federico.

Maybe if we were starting from scratch having a default would be the right
course — "maybe", I didn't think it through yet, or look at why the
original decision went the way it did — but I don't think changing it is
worth the disruption, or the difficulty of going through the deprecation
process.

(Why is "Just give it a value in your settings" not OK? 🤔)

Around core.mail, there's a cluster of tickets that I'm hoping to pull into
a project idea for this year's GSoC — see...

- [Add Settings EMAIL_FQDN by Jrief · Pull Request #13728 · Django/Django](
https://github.com/django/django/pull/13728)

- [Ui/Django-post_office: A Django App That Allows You to Send Email
Asynchronously in Django. Supports HTML Email, Database Backed Templates
and Logging.](https://github.com/ui/django-post_office)

- [Proposal on How Add Configuration Options to Email Backends](
https://groups.google.com/g/django-developers/c/R8ebGynQjK0)


... and linked threads.


... and linked threads.

One result of that (if all comes to pass) should hopefully be better
customizability of your email backends, so you'd be free to set a default
in your own backend, without the BC concerns for others.

So that's not a, yes, let's change it, but hopefully it doesn't leave you
without optimism 🙂

Kind Regards,

Carlton

On Thu, 17 Nov 2022 at 16:33, Federico Capoano 
wrote:

> Hi all,
>
> Why is there no default for EMAIL_TIMEOUT?
>
> Applications built in Django can potentially stall indefinitely if email
> sending starts to hang (eg: if the SMTP server is overloaded), when this
> happens, since there's no timeout, there's also no error being logged, so
> it's very hard and time consuming to debug.
>
> Wouldn't it be better to set a timeout? Some high value like 2 minutes
> which wouldn't really make sense to wait any longer, so at least if and
> when this happens, developers will find error traces in the logs and
> quickly understand where the problem is coming from, instead of spending
> hours to debug it like I did in the past week.
>
> Alternatively, we could set a default timeout only if
> "socket.getdefaulttimeout()" returns None, just to avoid applications
> stalling indefinitely, which is something that has been happening to me
> lately.
>
> Best regards
> Federico Capoano
>
> --
> 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/CAERYH6Vs6%2BWnJMsw95Uc_b006PZ2N_Pr%3DNgx4ztPDkgjVbkivA%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/CAJwKpyRt%3D3AfDF3ygyn2XY9X7OtqzbWJ8U0VwH0KhwW-KJwzQg%40mail.gmail.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

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

[Carlton Gibson]

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/194b43ff-98cf-4736-8360-3d79e9b62402n%40googlegroups.com.

Advancing the "content negotiation" and "modernising request object" proposals.

[Carlton Gibson]

Hi all.

I'm looking for a high-level sanity check if you would. 

I've been trying to see a way forward through a nest of issues around two 
concrete proposals:

1. Adding "content negotiation" to the request object, allowing automatical 
parsing of different content types, such as JSON, as well as allowing that 
to work for all request methods, rather than just POST. 

2. Modernising the API for the request object, adding attributes such as 
`request.data`, and `request.query_params`, etc., rather than the uppercase 
POST, GET, and so on.

The first is a major stepping stone towards having (JSON or other) API 
support in core — the "merge DRF into core" request that comes up 
frequently. (The other main side of that would be a review of serialization 
and forms, in light of developments such as Pydantic, attrs/cattrs, and 
django-readers, but that is **not** on topic here.) This was first 
suggested in 2011, but has made little progress in that time. [0][1]

[0]: https://groups.google.com/g/django-developers/c/4c4xT3ULNLk
[1]: https://code.djangoproject.com/ticket/21442

The second Adam Johnson proposed 2020, and was nearly merged bar Mariusz
**blinking** at the size of the distruption, particularly for documentation
throughout the community, for no change in behaviour. [2][3]

There was an inconclusive discussion about whether we right there[4] but, 
at the time I linked the modernisation to the content negotiation issue, as 
the feature needed to pay for the change. 

[2]: 
https://groups.google.com/g/django-developers/c/Kx8BfU-z4_E/m/lFXTF0IMCQAJ
[3]: https://code.djangoproject.com/ticket/32259
[4]: 
https://forum.djangoproject.com/t/technical-board-vote-on-ticket-32259-modernize-request-attribute-names/10255

Digging further into the history, with a mind to move these issues forward, 
having **not** merged Adam's patch first time gives us the needed pathway 
forward, I hope.

I think there have been two reasons the content negotiation suggestion has 
not progressed:

1. It's been all or nothing. Numerous times it's been requested to **just** 
add JSON handling, but that's been bounced back to the full proposal, 
adding customisable parsers and so on, which has then stalled.[5][6]

[5]: https://code.djangoproject.com/ticket/27415
[6]: https://code.djangoproject.com/ticket/32646

2. There's a backwards compatibility concern, particularly with multipart 
request bodies, where currently you'd get a string, which you'd then try to 
parse yourself, not expecting an already parsed dictionary, for example.[7]

[7]: https://code.djangoproject.com/ticket/28678

The way around the backwards compatibility concern is to introduce a new 
code
pathway at `request.data` that handles things in the new way, whilst
deprecating `request.POST`, which could either be removed or become an 
alias to
`request.data` at the end of the deprecation period. (Given the behaviour
change, and django-upgrade ongoing development, I'd lean now toward 
removal, I
think.)

In order to get this done, I'd like to introduce this **without also 
solving the pluggable parsers issue** in the first version. 

That is, I would like to add `request.data` to provide parsed data from the 
request body, for all request methods, together with `application/json` 
content type handling (and multipart parsing for `application/json` parts 
as well) **but** I would like to leave the configurable parsers step for a 
later iteration. 

I think this would give most of the benefit, and allow us to (finally) make 
forward steps here. My hope it that this is addressable before the 4.2 
feature freeze in January, but if not, OK, it hits 5.0 — at least it's in. 

Folks needing other content types can parse request.body as they'd need to 
do now. 
Having a list of request.parsers, configurable in e.g. View.setup(), or a 
middleware, or even a custom request class — essentially at any point 
before accessing request.data — would be the follow-up. Clearly, this would 
be good to have, but I feel like we've blocked on it so long, finding a way 
forward that allows it to be deferred would be sensible. (Prefetch 
evolved...)

Matching ``request.data``, if Adam will pick it up, the modernised request 
API would be
delightful. (The schedule leaves room for the code changes to come before 
the
documentation updates if needed.) 


Does this seem like a reasonable plan? 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/3bbd42d0-982b-485b-ba5b-3f1aa408ff0an%40googlegroups.com.

Re: Proposal: Clarify individual members page

[Carlton Gibson]

ge. The goals of rubrics in terms of increasing objectivity and
>>>> reducing bias are great, but as applied to the already-squishy definition
>>>> of "service to the community" it doesn't seem like a good fit here.
>>>>
>>>> Finally, this is wildly out of scope, but it may make sense to (either
>>>> here or separately) attempt to create a bit more content about what it
>>>> means to be an individual member of the DSF. That information is also
>>>> somewhat lacking, and having it somewhere may encourage more people to
>>>> apply. One possibility could be to link to one of the recent conference
>>>> talks[2][3] on the DSF. But wouldn't want that discussion/information to
>>>> slow down this change.
>>>>
>>>> cheers,
>>>> Cory
>>>>
>>>> [1] https://djangochat.com/episodes/read-the-docs-eric-holscher
>>>> [2] https://www.youtube.com/watch?v=Z_e-QoeZwEM
>>>> [3] https://www.youtube.com/watch?v=uJnaEZkoVTg
>>>>
>>>>
>>>>> On Thursday, October 27, 2022 at 10:03:48 AM UTC-4
>>>>> carlton...@gmail.com wrote:
>>>>>
>>>>>> That would be awesome, yes. Fresh eyes likely see more clearly :)
>>>>>>
>>>>>> And equally. :)
>>>>>>
>>>>>> Thanks.
>>>>>> C.
>>>>>>
>>>>>> On Thursday, 27 October 2022 at 15:28:09 UTC+2 acm...@gmail.com
>>>>>> wrote:
>>>>>>
>>>>>>> Regarding Carlton's points, that does clarify, and I agree about the
>>>>>>> open ended qualifiers. I also agree with Tim's points. I'm not sure we 
>>>>>>> need
>>>>>>> another membership level (I'm not opposed, though). Rather, I think 
>>>>>>> making
>>>>>>> the current page more transparent will help more folks feel welcome and
>>>>>>> hopefully get more folks (who do fit the criteria) to apply.
>>>>>>>
>>>>>>> If someone wants to draft new language, that would be great. If not,
>>>>>>> I may have some time next week to try.
>>>>>>>
>>>>>>> Thanks,
>>>>>>> Andrew
>>>>>>>
>>>>>>> P.S. Great meeting both of you at Djangocon last week!
>>>>>>> On Thursday, October 27, 2022 at 7:41:15 AM UTC-4
>>>>>>> schill...@gmail.com wrote:
>>>>>>>
>>>>>>>> Hi Carlton,
>>>>>>>>
>>>>>>>> I think I might have been one of those people mentioning the lack
>>>>>>>> of definition around the membership requirements. It has held me back 
>>>>>>>> from
>>>>>>>> applying (finally sent one in yesterday). Given the process's obscurity
>>>>>>>> (see below), it's daunting to hit submit.
>>>>>>>>
>>>>>>>>- The number of potential qualifiers is open ended.
>>>>>>>>   - This should remain, unaltered. It makes the application
>>>>>>>>   more daunting, but it's also encouraging in that any 
>>>>>>>> contribution is valid.
>>>>>>>>   - The degree of involvement per qualifier is not defined.
>>>>>>>>   - This seems like something that could be done. The review
>>>>>>>>   process must have a rubric of some sort.
>>>>>>>>   - There is a valid argument to be made that making
>>>>>>>>   statements about minimum levels of requirement could lead to a 
>>>>>>>> person
>>>>>>>>   disputing a rejection.
>>>>>>>>   - The review process is not included on the form.
>>>>>>>>   - Some people will appreciate having more information on how
>>>>>>>>   the process works.
>>>>>>>>   - The people who will see this application are not included
>>>>>>>>on the form.
>>>>>>>>   - I know the DSF Board is doing at least part of the
>>>>>>>>   approvals (I see it in the minutes), but I'm still unsure of who 
>>>>>>>> will see
>>>>>

Re: Proposal: Clarify individual members page

[Carlton Gibson]

ould be awesome, yes. Fresh eyes likely see more clearly :)
>>>>
>>>> And equally. :)
>>>>
>>>> Thanks.
>>>> C.
>>>>
>>>> On Thursday, 27 October 2022 at 15:28:09 UTC+2 acm...@gmail.com wrote:
>>>>
>>>>> Regarding Carlton's points, that does clarify, and I agree about the
>>>>> open ended qualifiers. I also agree with Tim's points. I'm not sure we 
>>>>> need
>>>>> another membership level (I'm not opposed, though). Rather, I think making
>>>>> the current page more transparent will help more folks feel welcome and
>>>>> hopefully get more folks (who do fit the criteria) to apply.
>>>>>
>>>>> If someone wants to draft new language, that would be great. If not, I
>>>>> may have some time next week to try.
>>>>>
>>>>> Thanks,
>>>>> Andrew
>>>>>
>>>>> P.S. Great meeting both of you at Djangocon last week!
>>>>> On Thursday, October 27, 2022 at 7:41:15 AM UTC-4 schill...@gmail.com
>>>>> wrote:
>>>>>
>>>>>> Hi Carlton,
>>>>>>
>>>>>> I think I might have been one of those people mentioning the lack of
>>>>>> definition around the membership requirements. It has held me back from
>>>>>> applying (finally sent one in yesterday). Given the process's obscurity
>>>>>> (see below), it's daunting to hit submit.
>>>>>>
>>>>>>- The number of potential qualifiers is open ended.
>>>>>>   - This should remain, unaltered. It makes the application more
>>>>>>   daunting, but it's also encouraging in that any contribution is 
>>>>>> valid.
>>>>>>   - The degree of involvement per qualifier is not defined.
>>>>>>   - This seems like something that could be done. The review
>>>>>>   process must have a rubric of some sort.
>>>>>>   - There is a valid argument to be made that making statements
>>>>>>   about minimum levels of requirement could lead to a person 
>>>>>> disputing a
>>>>>>   rejection.
>>>>>>   - The review process is not included on the form.
>>>>>>   - Some people will appreciate having more information on how
>>>>>>   the process works.
>>>>>>   - The people who will see this application are not included on
>>>>>>the form.
>>>>>>   - I know the DSF Board is doing at least part of the approvals
>>>>>>   (I see it in the minutes), but I'm still unsure of who will see the
>>>>>>   application itself. If it's the broader DSF membership, it's 
>>>>>> uncomfortable
>>>>>>   to send all of you an advertisement about my involvement in 
>>>>>> your/our
>>>>>>   community.
>>>>>>   - There's nothing to help a person decide how to make the
>>>>>>decision to put yourself out there.
>>>>>>   - Until San Diego I did not have a personal relationship with
>>>>>>   any DSF member, which meant I never sent a DM to an existing DSF 
>>>>>> member to
>>>>>>   ask what the process was like for them or if I was qualified.
>>>>>>
>>>>>>
>>>>>> I think if the form itself were a bit more transparent people will
>>>>>> feel more comfortable sending in an application.
>>>>>>
>>>>>> Thanks,
>>>>>> Tim
>>>>>>
>>>>>> On Thu, Oct 27, 2022 at 2:19 AM Carlton Gibson 
>>>>>> wrote:
>>>>>>
>>>>>>> Hi Andrew.
>>>>>>>
>>>>>>> Yes. Good question. I'm not immediately sure if there is a better
>>>>>>> description of DSF membership around. 🤔
>>>>>>>
>>>>>>> It's meant to be a recognition of contribution to the community, be
>>>>>>> that to the code in django/django, maintaining a  third-party
>>>>>>> package, organising a DjangoCon or community meetup, mentoring, ... — 
>>>>>>> the
>>>>>>> dots there a

Re: Proposal: Clarify individual members page

[Carlton Gibson]

ne of the recent conference
>> talks[2][3] on the DSF. But wouldn't want that discussion/information to
>> slow down this change.
>>
>> cheers,
>> Cory
>>
>> [1] https://djangochat.com/episodes/read-the-docs-eric-holscher
>> [2] https://www.youtube.com/watch?v=Z_e-QoeZwEM
>> [3] https://www.youtube.com/watch?v=uJnaEZkoVTg
>>
>>
>>> On Thursday, October 27, 2022 at 10:03:48 AM UTC-4 carlton...@gmail.com
>>> wrote:
>>>
>>>> That would be awesome, yes. Fresh eyes likely see more clearly :)
>>>>
>>>> And equally. :)
>>>>
>>>> Thanks.
>>>> C.
>>>>
>>>> On Thursday, 27 October 2022 at 15:28:09 UTC+2 acm...@gmail.com wrote:
>>>>
>>>>> Regarding Carlton's points, that does clarify, and I agree about the
>>>>> open ended qualifiers. I also agree with Tim's points. I'm not sure we 
>>>>> need
>>>>> another membership level (I'm not opposed, though). Rather, I think making
>>>>> the current page more transparent will help more folks feel welcome and
>>>>> hopefully get more folks (who do fit the criteria) to apply.
>>>>>
>>>>> If someone wants to draft new language, that would be great. If not, I
>>>>> may have some time next week to try.
>>>>>
>>>>> Thanks,
>>>>> Andrew
>>>>>
>>>>> P.S. Great meeting both of you at Djangocon last week!
>>>>> On Thursday, October 27, 2022 at 7:41:15 AM UTC-4 schill...@gmail.com
>>>>> wrote:
>>>>>
>>>>>> Hi Carlton,
>>>>>>
>>>>>> I think I might have been one of those people mentioning the lack of
>>>>>> definition around the membership requirements. It has held me back from
>>>>>> applying (finally sent one in yesterday). Given the process's obscurity
>>>>>> (see below), it's daunting to hit submit.
>>>>>>
>>>>>>- The number of potential qualifiers is open ended.
>>>>>>   - This should remain, unaltered. It makes the application more
>>>>>>   daunting, but it's also encouraging in that any contribution is 
>>>>>> valid.
>>>>>>   - The degree of involvement per qualifier is not defined.
>>>>>>   - This seems like something that could be done. The review
>>>>>>   process must have a rubric of some sort.
>>>>>>   - There is a valid argument to be made that making statements
>>>>>>   about minimum levels of requirement could lead to a person 
>>>>>> disputing a
>>>>>>   rejection.
>>>>>>   - The review process is not included on the form.
>>>>>>   - Some people will appreciate having more information on how
>>>>>>   the process works.
>>>>>>   - The people who will see this application are not included on
>>>>>>the form.
>>>>>>   - I know the DSF Board is doing at least part of the approvals
>>>>>>   (I see it in the minutes), but I'm still unsure of who will see the
>>>>>>   application itself. If it's the broader DSF membership, it's 
>>>>>> uncomfortable
>>>>>>   to send all of you an advertisement about my involvement in 
>>>>>> your/our
>>>>>>   community.
>>>>>>   - There's nothing to help a person decide how to make the
>>>>>>decision to put yourself out there.
>>>>>>   - Until San Diego I did not have a personal relationship with
>>>>>>   any DSF member, which meant I never sent a DM to an existing DSF 
>>>>>> member to
>>>>>>   ask what the process was like for them or if I was qualified.
>>>>>>
>>>>>>
>>>>>> I think if the form itself were a bit more transparent people will
>>>>>> feel more comfortable sending in an application.
>>>>>>
>>>>>> Thanks,
>>>>>> Tim
>>>>>>
>>>>>> On Thu, Oct 27, 2022 at 2:19 AM Carlton Gibson 
>>>>>> wrote:
>>>>>>
>>>>>>> Hi Andrew.
>>>>>>>
>>>>>>> Yes. Good q

Re: Adjusting DEP 10 "How Django is released" section.

[Carlton Gibson]

Hi All. 

I've drafted up a DEP for this adjustment here: 

https://github.com/django/deps/pull/76

Please have a look if you're interested. 

I've initially asked for review from the Technical Board and from James, as 
the author of DEP 10, but any other input appreciated. 

To simplify the remaining discussions, I'd like to move this forward to a 
Technical Board vote sooner rather than later. 

Thanks. 

Kind Regards,

Carlton

On Thursday, 27 October 2022 at 08:56:25 UTC+2 Carlton Gibson wrote:

> Hi all, 
>
> Almost scared to say it but, the discussion on the TB renaming and 
> election eligibility changes highlights the inappropriateness of the How 
> Django is released section of DEP 10. 
>
> It currently reads: 
>
> How Django is released 
> <https://github.com/django/deps/tree/main/accepted#id20>
>
> No later than one week after the release of each Feature Release of 
> Django, the Technical Board SHALL determine and publish a schedule for the 
> following Feature Release. Bugfix Releases for each supported Feature 
> Release SHALL be scheduled to occur on a monthly basis.
>
> Releases of Django will occur as follows:
>
>1. When the scheduled date of a Feature Release, of an 
>alpha/beta/candidate package for a Feature Release, or of a Bugfix Release 
>is less than one week away, the Technical Board MAY, by vote, request that 
>the Releasers not issue the release on the scheduled date. In the event 
>that the Technical Board does make such a request, the Releasers MUST NOT 
>issue the release until such time as they receive an update from the 
>Technical Board granting permission for the release. If the Technical 
> Board 
>requests that a release not be issued, they SHALL provide public notice, 
> on 
>the django-developers mailing list or the Django Forum, of their 
> reasoning, 
>and SHALL provide timely updates regarding the status of the release.
>2. At any time, the Django Security Team MAY ask a Releaser to issue 
>one or more Security Releases of Django, regardless of prior schedule, in 
>order to handle a security issue under Django's security process. When the 
>Django Security Team makes such a request, the Releaser MUST issue the 
>requested release(s) at or as close as is practicable to the time of 
>release requested by the Django Security Team. The Technical Board MUST 
> NOT 
>attempt to prevent such release(s) from occurring; if the Technical Board 
>feels such release(s) are or were inappropriate, the Technical Board may 
>take action after the release(s).
>
>
> Src: 
> https://github.com/django/deps/blob/main/accepted/0010-new-governance.rst#how-django-is-released
>
> Django has a fixed eight monthly release schedule — Apr - Dec - Aug, and 
> back to Apr over a 24month period. This is entirely mechanical. It's one of 
> Django's great strengths. Any change to that would be significant and 
> require a DEP itself; nobody took DEP10 to be trying to change that, we'd 
> agree I presume. 
>
> The opening paragraph should mention the eight month cycle and say a 
> Releaser SHALL determine and publish a schedule for the following Feature 
> Release. The reality is this falls to one of the Fellows, who by convention 
> alternate the release manager role for each major version. The TB/SC SHOULD 
> (and DO, and HAVE) acted to review the proposed schedule to suggest tweaks, 
> for example Adam noticed a suggested Apr 1 final release which we avoided.
>
> Then, requiring a vote to allow the release in point 1 should be removed. 
> The release goes ahead unless there's a reason not to. The TB/SC of course 
> should have that oversight, but the release should be automatic unless 
> there's a proposal to stop it. There's no benefit to having a release 
> potentially delayed because a vote wasn't held. There's no benefit to 
> organising a vote that merely rubber stamps an automatic, long-standing 
> process. (It's no surprise this vote hasn't been happening, as it doesn't 
> map to the actual workflow. The conflict is an issue with the DEP, not the 
> workflow.) 
>
> Point 2 is fine. We've done such once during my time as Fellow. I've also 
> though had to make one release due to a packaging error, so we should 
> probably have something along the lines of, "In exceptional 
> circumstances...", which I would have had "hot" security releases under if 
> it wasn't there already. 
>
> To James' wider point about supposedly discarding DEP 10, I don't see that 
> at all. Rather, the most of it is great. It was written in abstract though, 
> so it's to be 

Re: Proposal: cacheif template tag

[Carlton Gibson]

Hi Igor, 

The sort of thing I had in mind was: 

{% with cache_timeout=request.user.is_authenticated|yesno:"0,500" %}
  {% cache cache_timeout sidebar %}

...

  {% endcache %}
{% endwith %}

Kind Regards,

Carlton

On Wednesday, 12 October 2022 at 17:17:57 UTC+2 des...@gmail.com wrote:

> Hey Carlton,
> I am not sure I got your idea.
> The point of proposal is not in user.is_authenticated. 
> user.is_authenticated is just a boolean. Conditional caching for non logged 
> in user is just very simple and common use case when `cacheif` could be 
> used. 
>
> пʼятниця, 30 вересня 2022 р. о 09:09:53 UTC+2 carlton...@gmail.com пише:
>
>> Hey Igor, 
>>
>> I wonder if you can achieve the same varying the timeout parameter based 
>> in user.is_authenticated?
>>
>> Kind Regards,
>>
>> Carlton
>>
>> On Sat, 24 Sept 2022 at 15:35, Igor Margitich  wrote:
>>
>>> Hi django-developers,
>>>
>>> I would like to propose new template tag `cacheif`. Could be useful when 
>>> you need to cache part of html and it depends on some condition. Template 
>>> tag is similar to built-in `cache` tag but accepts extra boolean parameter. 
>>> See example:
>>>
>>> {% cacheif user.is_anonymous 10 homepage %}
>>>   
>>>  .
>>>   
>>> {% endcacheif %}
>>>
>>>
>>> -- 
>>> 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/bcf8ffee-6497-4a55-ba40-913446d15b06n%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/476159b3-7f5f-4264-994b-1b62b8adaf8fn%40googlegroups.com.

Re: Proposal: Clarify individual members page

[Carlton Gibson]

That would be awesome, yes. Fresh eyes likely see more clearly :) 

And equally. :) 

Thanks. 
C. 

On Thursday, 27 October 2022 at 15:28:09 UTC+2 acm...@gmail.com wrote:

> Regarding Carlton's points, that does clarify, and I agree about the open 
> ended qualifiers. I also agree with Tim's points. I'm not sure we need 
> another membership level (I'm not opposed, though). Rather, I think making 
> the current page more transparent will help more folks feel welcome and 
> hopefully get more folks (who do fit the criteria) to apply.
>
> If someone wants to draft new language, that would be great. If not, I may 
> have some time next week to try.
>
> Thanks,
> Andrew
>
> P.S. Great meeting both of you at Djangocon last week!
> On Thursday, October 27, 2022 at 7:41:15 AM UTC-4 schill...@gmail.com 
> wrote:
>
>> Hi Carlton,
>>
>> I think I might have been one of those people mentioning the lack of 
>> definition around the membership requirements. It has held me back from 
>> applying (finally sent one in yesterday). Given the process's obscurity 
>> (see below), it's daunting to hit submit.
>>
>>- The number of potential qualifiers is open ended.
>>   - This should remain, unaltered. It makes the application more 
>>   daunting, but it's also encouraging in that any contribution is valid.
>>   - The degree of involvement per qualifier is not defined.
>>   - This seems like something that could be done. The review process 
>>   must have a rubric of some sort.
>>   - There is a valid argument to be made that making statements 
>>   about minimum levels of requirement could lead to a person disputing a 
>>   rejection.
>>   - The review process is not included on the form.
>>   - Some people will appreciate having more information on how the 
>>   process works.
>>   - The people who will see this application are not included on the 
>>form.
>>   - I know the DSF Board is doing at least part of the approvals (I 
>>   see it in the minutes), but I'm still unsure of who will see the 
>>   application itself. If it's the broader DSF membership, it's 
>> uncomfortable 
>>   to send all of you an advertisement about my involvement in your/our 
>>   community.
>>   - There's nothing to help a person decide how to make the decision 
>>to put yourself out there.
>>   - Until San Diego I did not have a personal relationship with any 
>>   DSF member, which meant I never sent a DM to an existing DSF member to 
>> ask 
>>   what the process was like for them or if I was qualified.
>>
>>
>> I think if the form itself were a bit more transparent people will feel 
>> more comfortable sending in an application.
>>
>> Thanks,
>> Tim
>>
>> On Thu, Oct 27, 2022 at 2:19 AM Carlton Gibson  
>> wrote:
>>
>>> Hi Andrew. 
>>>
>>> Yes. Good question. I'm not immediately sure if there is a better 
>>> description of DSF membership around. 🤔
>>>
>>> It's meant to be a recognition of contribution to the community, be that 
>>> to the code in django/django, maintaining a  third-party package, 
>>> organising a DjangoCon or community meetup, mentoring, ... — the dots there 
>>> are that the list incompletable, not simply because I'm too lazy to type, 
>>> if that makes sense 😜 
>>> (These tie roughly to the suggested points for eligibility for being on 
>>> the Steering Committee in Andrew's proposal 
>>> <https://github.com/django/deps/pull/75/files> except without the "and 
>>> you're still engaged" requirement that's also there — once earned, it's 
>>> yours.) 
>>>
>>> There was some discussion of this at both recent DjangoCons... — there's 
>>> a bit of a gap for people, perhaps like yourself, first getting involved. 
>>> One idea was a more open membership level that anyone interested could take 
>>> up, that would allow easier communication if nothing else. I don't know how 
>>> those discussions will turn out, but stay tuned 🙂
>>>
>>> I hope that clarifies a litte? 
>>>
>>> In any case, Welcome aboard! ⛵️ :) Please reach out if you need any 
>>> help. 
>>>
>>> Kind Regards,
>>>
>>> Carlton
>>>
>>> On Wed, 26 Oct 2022 at 15:48, Andrew Mshar  wrote:
>>>
>>>> Along the lines of discussions about redefining 

Re: Proposal: Clarify individual members page

[Carlton Gibson]

Hi Andrew.

Yes. Good question. I'm not immediately sure if there is a better
description of DSF membership around. 🤔

It's meant to be a recognition of contribution to the community, be that to
the code in django/django, maintaining a  third-party package,
organising a DjangoCon or community meetup, mentoring, ... — the dots there
are that the list incompletable, not simply because I'm too lazy to type,
if that makes sense 😜
(These tie roughly to the suggested points for eligibility for being on the
Steering Committee in Andrew's proposal
 except without the "and
you're still engaged" requirement that's also there — once earned, it's
yours.)

There was some discussion of this at both recent DjangoCons... — there's a
bit of a gap for people, perhaps like yourself, first getting involved. One
idea was a more open membership level that anyone interested could take up,
that would allow easier communication if nothing else. I don't know how
those discussions will turn out, but stay tuned 🙂

I hope that clarifies a litte?

In any case, Welcome aboard! ⛵️ :) Please reach out if you need any help.

Kind Regards,

Carlton

On Wed, 26 Oct 2022 at 15:48, Andrew Mshar  wrote:

> Along the lines of discussions about redefining requirements for board
> seats (e.g. https://groups.google.com/g/django-developers/c/FbNaAq3rz6c),
> I think it would be helpful to clarify what we want from individual members
> of the DSF here:
>
> https://www.djangoproject.com/foundation/individual-members/
>
> As a non-member who recently made my first contribution to Django, I
> looked at that page and thought: is that enough for me to be a member? I'm
> not particularly concerned about my own membership, but rather, this made
> me realize that the lack of clarity may prevent others from joining who
> otherwise should.
>
> Is there anywhere that we have a more clear outline of what we expect from
> members both before they join and after? If not, could we have that
> discussion here to clarify for future members?
>
> Thanks,
> Andrew
>
> --
> 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/824f1e56-64f1-44e4-9612-dc121c5d3efcn%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/CAJwKpySfQfgtpoLnCYcwfsaL7g1kgOZU%2BPvKyvggm0UT%3DLpiWg%40mail.gmail.com.

Adjusting DEP 10 "How Django is released" section.

[Carlton Gibson]

Hi all,

Almost scared to say it but, the discussion on the TB renaming and election
eligibility changes highlights the inappropriateness of the How Django is
released section of DEP 10.

It currently reads:

How Django is released


No later than one week after the release of each Feature Release of Django,
the Technical Board SHALL determine and publish a schedule for the
following Feature Release. Bugfix Releases for each supported Feature
Release SHALL be scheduled to occur on a monthly basis.

Releases of Django will occur as follows:

   1. When the scheduled date of a Feature Release, of an
   alpha/beta/candidate package for a Feature Release, or of a Bugfix Release
   is less than one week away, the Technical Board MAY, by vote, request that
   the Releasers not issue the release on the scheduled date. In the event
   that the Technical Board does make such a request, the Releasers MUST NOT
   issue the release until such time as they receive an update from the
   Technical Board granting permission for the release. If the Technical Board
   requests that a release not be issued, they SHALL provide public notice, on
   the django-developers mailing list or the Django Forum, of their reasoning,
   and SHALL provide timely updates regarding the status of the release.
   2. At any time, the Django Security Team MAY ask a Releaser to issue one
   or more Security Releases of Django, regardless of prior schedule, in order
   to handle a security issue under Django's security process. When the Django
   Security Team makes such a request, the Releaser MUST issue the requested
   release(s) at or as close as is practicable to the time of release
   requested by the Django Security Team. The Technical Board MUST NOT attempt
   to prevent such release(s) from occurring; if the Technical Board feels
   such release(s) are or were inappropriate, the Technical Board may take
   action after the release(s).


Src:
https://github.com/django/deps/blob/main/accepted/0010-new-governance.rst#how-django-is-released

Django has a fixed eight monthly release schedule — Apr - Dec - Aug, and
back to Apr over a 24month period. This is entirely mechanical. It's one of
Django's great strengths. Any change to that would be significant and
require a DEP itself; nobody took DEP10 to be trying to change that, we'd
agree I presume.

The opening paragraph should mention the eight month cycle and say a
Releaser SHALL determine and publish a schedule for the following Feature
Release. The reality is this falls to one of the Fellows, who by convention
alternate the release manager role for each major version. The TB/SC SHOULD
(and DO, and HAVE) acted to review the proposed schedule to suggest tweaks,
for example Adam noticed a suggested Apr 1 final release which we avoided.

Then, requiring a vote to allow the release in point 1 should be removed.
The release goes ahead unless there's a reason not to. The TB/SC of course
should have that oversight, but the release should be automatic unless
there's a proposal to stop it. There's no benefit to having a release
potentially delayed because a vote wasn't held. There's no benefit to
organising a vote that merely rubber stamps an automatic, long-standing
process. (It's no surprise this vote hasn't been happening, as it doesn't
map to the actual workflow. The conflict is an issue with the DEP, not the
workflow.)

Point 2 is fine. We've done such once during my time as Fellow. I've also
though had to make one release due to a packaging error, so we should
probably have something along the lines of, "In exceptional
circumstances...", which I would have had "hot" security releases under if
it wasn't there already.

To James' wider point about supposedly discarding DEP 10, I don't see that
at all. Rather, the most of it is great. It was written in abstract though,
so it's to be expected that we would revise given experience of how it
applies in practice.

I will create the draft DEP to fulfil the formalities here, and ask for a
TB vote next week.

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/CAJwKpyThHVDAjYEY8_kh%3DD__3yGopt-cn-uE10eQXQ2qUSqB8Q%40mail.gmail.com.

Re: Creating internal/admin pages without Models

[Carlton Gibson]

Check out Django-admin-views

https://github.com/frankwiles/django-admin-views

I think it needs a bit of an update for recent versions of Django (but I
suspect those are minor) and o tho knit does what you’re after (or close)

On Tuesday, 25 October 2022, Vasanth Mohan  wrote:

> Hi Igor,
>
> Most of my cases are for internal tools and grouping together unrelated
> tables as you just summarised. Some examples are,
>
> - Writing text that can need to send out to clients by triggering a
> predefined email templates
> - Creating internal forms that should be saved to multiple tables or throw
> an error
> - Custom templates for showing unrelated & unrelated data
>
> While these can be done normally with templates, the key difference is
> these are internal pages and do not need to be super stylised. Performance
> is far more important than the UI. A minimal stylisation would be good
> enough is most cases.
>
> Being able to leverage admin widgets would improve task turnaround time
> and reduce frontend work to only client-facing logic.
>
>
> Vasanth MOHAN
>
>
> On Tue, 25 Oct 2022 at 14:10, Igor Margitich  wrote:
>
>> Hi Vasanth,
>>
>> Can you ptovide an example when do you need generic admin view? I have
>> case where I need gather some information from different not directly
>> related tables. I have used https://pypi.org/project/
>> django-nonrelated-inlines/. Can't say it is exactly what I need but
>> seems it does the job.
>> Also sometimes I need action's intermediate page which is more then just
>> simple template. This is the case where would be nice to have CBV. Watch
>> this presentation to get some ideas about CBV actions
>> https://youtu.be/HJfPkbzcCJQ?t=1817.
>>
>> Best regards,
>> Ihor
>>
>> вт, 25 окт. 2022 г. в 11:22, Vasanth Mohan :
>>
>>> Hello,
>>>
>>> I'd like to gauge the general opinion of more experienced devs before
>>> starting on a project.
>>>
>>> I personally love the sheer flexibility that the django admin provides
>>> me to get started on the DB and manage the backend. I can add actions,
>>> filters and charts with just a few third-party apps. On top of that,
>>> permissions to control user access to everything.
>>>
>>> However, I find myself having to build a separate set of templates and
>>> view for internal use often as the admin is tightly tied to the DB. I find
>>> myself not being able to expose the admin as it requires too much
>>> customisation to be useful to tech & non-tech teams at the same time.
>>> Moreover, DB structure is not as intuitive to non-tech users.
>>>
>>> So I'd like to build a generic admin view that is not tied to the DB but
>>> can still leverage the widgets (tables, inputs, messages etc.) that Django
>>> offers. A set of tools to design custom pages like django-etc and design
>>> easy-to-customise top/sidebars
>>>
>>> My question to the reader is quite simple, is this something feasible ?
>>> Are all widgets tightly coupled and expect models to function ? Anything
>>> you believe that might trip me up?
>>>
>>> Thanks,
>>> Vaz
>>>
>>> --
>>> 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/d6146414-c423-4f2a-b482-
>>> 5eccb971f16cn%40googlegroups.com
>>> 
>>> .
>>>
>> --
>> You received this message because you are subscribed to a topic in the
>> Google Groups "Django developers (Contributions to Django itself)" group.
>> To unsubscribe from this topic, visit https://groups.google.com/d/
>> topic/django-developers/yFJz4GPTJPo/unsubscribe.
>> To unsubscribe from this group and all its topics, 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/CAHi_fyv7QrWwpNOdyv8ZvOg%
>> 2B84mzTLKvrc-iYHjee8SQ6gPd%2Bg%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/CAOAVv_NQpKDOsEEYoGe13DyKWkb9Hm-
> VidrcLv%2BKrwbVQ30v1A%40mail.gmail.com
> 

Re: Changing the role of the Technical Board

[Carlton Gibson]

*Loosening eligibility is fine, though I agree it's going to be very
difficult to write down in an enforceable way -- the DEP 10 language and
process was intended primarily to prevent trolls and other bad-faith actors
from being able to run effectively for the Technical Board, and there's a
balance where the more you loosen it up, the more you also open the door
for those kinds of people.*

I think it’s very easy for us to overplay this difficulty by thinking that
we *ex ante* need to define what contributions would qualify someone to
stand for the Steering Council.

In reality it’s usually entirely clear in any given case whether someone
has been *contributing* to Django or not.

The issue here (I take it) is that we both want and need to widen the
notion of contributing so that it’s not so tightly focused on current,
active, engagement with the development on django/django. I thought the
wording in DEP 10 was good, but, two elections in, it’s already clear that
it doesn’t produce a large enough candidate pool, or one that’s
representative of the Django community, or the DSF members.

Rather than struggling with too much precision, I believe we’d be better
suited with something deliberately vague — *a history of contributing to
Django*, say — and then including a list of exemplars of that…

Such contributions may include, but are not limited to:

   - Code contributions to django/django
  - Organising Django community events
  - …
  (I leave this in sketch format deliberately.)

Thinking of all the recent discussions on what *contributing to Django*
means — I have Kojo Idrissa’s keynote from DjangoCon Europe, and Jeff
Tripplet’s comments during the panel at DjangoCon US in mind that would
be/will be accessible to all via YouTube, and which are both on-topic —
it’s likely that there’s *nothing* that we can pick out as uniting
everything that we’d call *contributing*.

Still, it remains clear-as-day in most cases. Frank, who replied already
here: clearly yes. Some troll off the internet we never heard of: clearly
no. There will be (likely few) difficult cases in the middle, sure — that’s
universal — but it’s unlikely to be significant which way we decide in such
a case.

Practically, let anyone stand, but also let anyone ask for a review of any
one standing. If so asked, let the Board, who are organising the election,
judge, perhaps asking around, if this person is really a legitimate member
of the community. Let the judgement of the Board be final.

I think the Steering Council should — as per the suggestion — pick up the
proposal side of it. That this hasn’t happened already is, I think, a
slight side-issue. (Surviving the ongoing pandemic has kept everyone busy.
Having a pool of candidates can but help.)

+1 to the proposal.

Kind Regards,

Carlton

p.s. That a current Merger cannot also on the TB has proven correct: to
have a fallback is essential for Merger sanity, e.g. the typing proposal,
for which it’s not reasonable for the set of Mergers to make such a
decision. (This is independent of oversight, which we’d all agree is
necessary to have, even in we assume Mergers always to be benign. 🙂)


On Mon, 24 Oct 2022 at 23:24, Andrew Godwin  wrote:

> These are some great points, James - let me try to tackle them roughly in
> order.
>
> Proposing features - this is already in DEP 10, so I more just want to get
> that aspect of the Board actually going (and, as a side-effect, have
> something to aid fundraising). I am talking with the current Board
> separately on an internal thread, where the current stance (not everyone
> has responded) is that I am personally happy to take on all the work here
> for now - but I want to make sure it's not just me in the long run, be that
> merely proving that the idea works or attracting board members who want to
> specifically mediate such discussions and interaction with the wider
> community.
>
> Engagement - It's not about "lack of engagement", and I think any issues
> there are deeper problems with OSS communities and the fact that we have to
> learn to sustainably work with the people we have rather than throwing
> everything at trying to recruit fresh, new people. I have ideas around this
> topic specifically, but they will not be solved in terms of the Board alone.
>
> Loosening eligibility - If you're up for it I would very much value your
> help here in terms of refining wording once I have a first draft. My
> initial direction was to still require the 18 month history of
> contributions, but widen it from "technical" to more kinds of work
> (obviously the discussion part is in there too, but I think in general we
> can do a bit more of an OR rather than an AND on the current requirements,
> keeping a minimum time of contribution to prevent bad actors)
>
> Serving on the DSF Board - you are of course right, I misread the DEP last
> week.
>
> Overall, if all we do is change the name and start actually doing calls
> for features as outlined in DEP 10,

Re: Model-level validation

[Carlton Gibson]

> ... the duplication I was referring to is having both Forms and
Serializers do validation.

That's a separate issue.

Can we merge various aspects of DRF into Django, so that it better handles
building JSON APIs? Yes, clearly. One step of that is better content type
handling, another is serializers. (There are others).
On the serializer front, it would be a question of making django.forms
better able to handle list-like (possibly do-able with FormSet) and nested
data, and so on.
Not a small project, but with things like django-readers, and Pydantic (and
django-ninja), and attrs/cattrs showing new ideas, re-thinking about
serialization in Django is about due.

But the issue is here:

> ... I also don't relish the thought of needing to use a Form or
Serializer every time I alter a Model's data.

I'm like literally, "¿Qué? 😳" - Every single time you get data from an
untrusted source you simply **must** validate it before use. ("Filter
input, escape output", I was drilled.) That applies exactly the same to a
CSV file as it does to HTTP request data. (That your CSV is malformed is
axiomatic no? :)

If you want to enforce validation, with a single call, write a method (on a
manager likely) that encapsulates your update logic (and runs the
validation before save). Then always use that in your code. (That's long
been a recommended pattern
.) But don't
skip the validation layer on your incoming data.

I would be -1 to `validate` kwarg to `save()` — that's every user ever
wondering *should I use it? *every time. (Same for a setting.)
Rather — is this a docs issue? — we should re-emphasise the importance of
the validation layer.
Then if folks want a convenience API to do both tasks, they're free to
write that for their models. (This is what Uri has done for Speedy Net.
It's not a bad pattern.)






On Fri, 7 Oct 2022 at 04:34, Aaron Smith  wrote:

> James - to clarify, the duplication I was referring to is having both
> Forms and Serializers do validation. I often work with web apps where data
> for the same model can arrive via user input, serializer, or created in
> some backend process e.g. Celery. If forms/serializers are your validation
> layer, you need to duplicate it and worry about how to keep them from
> diverging over time as there's no single source of truth. I also don't
> relish the thought of needing to use a Form or Serializer every time I
> alter a Model's data.
>
> Perhaps we think about validation differently. I consider it to be
> critical to maintain complex systems with any kind of confidence, any time
> data is being created or changed, regardless of where that change comes
> from. Bugs can happen anywhere and validation is the best (only?) option to
> prevent data-related bugs.
> On Thursday, October 6, 2022 at 12:03:28 PM UTC-7 James Bennett wrote:
>
>> On Thu, Oct 6, 2022 at 9:00 AM Aaron Smith  wrote:
>>
>>> James - The problem with moving validation up the stack, i.e. to logical
>>> branches from Model (Form, Serializer) is that you must duplicate
>>> validation logic if your data comes from multiple sources or domains (web
>>> forms *and* API endpoints *and* CSVs polled from S3. Duplication leads
>>> to divergence leads to horrible data integrity bugs and no amount of test
>>> coverage can guarantee safety. Even if you consider Django to be "only a
>>> web framework" I would still argue that validation should be centralized in
>>> the data storage layer. Validity is a core property of data. Serialization
>>> and conversion changes between sources and is a different concern than
>>> validation.
>>>
>>
>> I would flip this around and point out that the duplication comes from
>> seeing the existing data conversion/validation layer and deciding not to
>> use it.
>>
>> There's nothing that requires you to pass in an HttpRequest instance to
>> use a form or a serializer -- you can throw a dict of data from any source
>> into one and have it convert/validate for you.  Those APIs are also
>> designed to be easy to check and easy to return useful error messages from
>> on failed validation, while a model's save() has no option other than to
>> throw an exception at you and demand you parse the details out of it
>> (because it was designed as part of an overall web framework that already
>> had the validation layer elsewhere).
>>
>> So I would argue, once again, that the solution to your problem is to use
>> the existing data conversion/validation utilities (forms or serializers)
>> regardless of the source of the data. If you refuse to, I don't think
>> that's Django's problem to solve.
>>
>>> --
> 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.co

Re: Making max_length argument optional

[Carlton Gibson]

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
<https://github.com/jacobian/django-postgres-unlimited-varchar/blob/master/django_postgres_unlimited_varchar.py>

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
>>>> <https://github.com/jacobian/django-postgres-unlimited-varchar>, 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 tha

Django security releases issued: 4.1.2, 4.0.8, and 3.2.16

[Carlton Gibson]

Details are available on the Django weblog:

https://www.djangoproject.com/weblog/2022/oct/04/security-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/CAJwKpyRtN15r_RvqVDMcG2hjxaE7660chHQt7JkZkjReFn62LQ%40mail.gmail.com.

Re: Optional URL parameters in django.urls.path

[Carlton Gibson]

Hi.

Re-reading again, I'm still not sure (personally) of the need/motivation
given either of the "use two entries" or "use re_path()" options.
Maybe it would be a nice-to-have but I'm not seeing the benefit as
outweighing the complexity (remembering docs, and tests, and related
functionality such as reverse() that would also need updating.)

(IRL I've rarely needed this pattern. I've used both the options above
without issue)

So, I'd probably be -1 at this point.

Kind regards
Carlton


On Sun, 2 Oct 2022 at 08:16, Meiyer  wrote:

> Is there any interest in implementing this feature? If yes, what would be
> the syntax for the path components that would follow the optional parameter
> (only if it is present)? I thought about something along the lines of
>  with the characters after the second colon having to
> appear literally in the URL.
> For example:
> path(format_lazy('{org}/',
> org=pgettext_lazy('URL', 'event/organizers/')), OrganizersView.as_vew())
> would match both
> /üritus/korraldajad/perekonnanimi/ and
> /üritus/korraldajad/FI/perekonnanimi/ (in Estonian).
> On Monday, September 19, 2022 at 4:07:26 PM UTC+2 matthew.pava wrote:
>
>> I wonder if maybe you should look at the APPEND_SLASH setting.
>>
>> https://docs.djangoproject.com/en/4.1/ref/settings/#append-slash
>>
>>
>>
>>
>>
>> *From:* django-d...@googlegroups.com  *On
>> Behalf Of *Meiyer
>> *Sent:* Monday, September 19, 2022 8:59 AM
>> *To:* Django developers (Contributions to Django itself) <
>> django-d...@googlegroups.com>
>> *Subject:* Re: Optional URL parameters in django.urls.path
>>
>>
>>
>> > One approach is to route two patterns (one with the parameter and one
>> without) to the same URL. Some duplication but (perhaps) easier to read at
>> a glance than either an optional `?` operator.
>>
>>
>>
>> I thought about that, but it won't work if I want both cases to be named
>> similarly (via the `name` parameter). It also feels as duplicating the same
>> line.
>>
>>
>>
>> > Given that — and the alternative re_path() approach being available —
>>  unless there was a particularly simple implementation on display I'd
>> likely be sceptical about an addition here… 🤔
>>
>>
>>
>> I did a bit of digging in the Django code and in fact it might be quite
>> easy (it is also possible I am missing the elephant). django.urls.resolvers
>> defines the syntax for the path parameters on line 245 [1] and converts the
>> matches to regular expressions on line 290 [2]. Looks like an addition of
>> the '?' to the regex after the closing bracket would do it..?
>>
>>
>>
>>
>>
>> [1]
>> https://github.com/django/django/blob/baf9604ed8fed3e6e7ddfaca2d83c377c81399ae/django/urls/resolvers.py#L245
>>
>> [2]
>> https://github.com/django/django/blob/baf9604ed8fed3e6e7ddfaca2d83c377c81399ae/django/urls/resolvers.py#L290
>>
>> --
>>
>> 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/9e0828d7-6434-4fd1-b605-8113342fcba9n%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/43b40cdf-2f3d-4a28-9208-af16dd68ede0n%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/CAJwKpyQRwLrfhFVLzxMuw3_ycqt0eaDaKHD7habPKPnhRAAJHQ%40mail.gmail.com.

Re: Proposal: cacheif template tag

[Carlton Gibson]

Hey Igor,

I wonder if you can achieve the same varying the timeout parameter based in
user.is_authenticated?

Kind Regards,

Carlton

On Sat, 24 Sept 2022 at 15:35, Igor Margitich  wrote:

> Hi django-developers,
>
> I would like to propose new template tag `cacheif`. Could be useful when
> you need to cache part of html and it depends on some condition. Template
> tag is similar to built-in `cache` tag but accepts extra boolean parameter.
> See example:
>
> {% cacheif user.is_anonymous 10 homepage %}
>   
>  .
>   
> {% endcacheif %}
>
>
> --
> 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/bcf8ffee-6497-4a55-ba40-913446d15b06n%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/CAJwKpyS%3DYeGUCnbOr47BfU5SDKdCs83%3DvULAMa2E2rmPvNZBig%40mail.gmail.com.

Re: Proposal: Add utility class "ClassList"

[Carlton Gibson]

Hey Jacob. Thanks for this. 

Can I ask you to give a few examples of potential usages in Django, and 
showing the gain over use a set in these cases? 

I'm trying to imagine exactly what you have in mind, but I'm not entirely 
clear. 

Thanks again. 
Carlton

On Friday, 23 September 2022 at 11:14:27 UTC+2 Jacob Rief wrote:

> In JavaScript each HTMLElement has a property named classList 
> . 
> This actually is a set allowing to *add* a single CSS class string, 
> *remove* it
> and/or *toggle* it.
>
> If we would reimplement this as a Python class, methods such as
> css_classes 
> 
>  
> could be implemented as a one-liner. This would also be beneficial
> for future uses of similar methods in Django and 3rd party libraries, 
> because it is a quite
> common use case that one has to change the list of CSS classes as an 
> element
> attribute.
>
> – Jacob
>

-- 
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/d63a27a1-6a67-403e-9ecd-f03b19e8660dn%40googlegroups.com.

Re: Model-level validation

[Carlton Gibson]

Hi. 

I have to ask, did you search the history at all here? This has been 
discussed *several times* over the years. 

> Bringing View-level concepts such as forms down into celery tasks and 
management commands breaks separation of concerns...

I think it's an error to think of forms (please read "or serializers" 
throughout) as "view-level". 
A view's job is to turn requests into responses. 
It may use other layers of Django, such as the ORM to do that, but that 
doesn't make said layers part of the view. (The ORM is not "view-level".)

Forms are such another level. Their role is to validate (and transform) 
incoming data, and they provide an opportunity to present user-friendly 
validation errors back up to the client code. 
You should definitely be using them in all places that you process incoming 
data, and that includes celery tasks. 

On Thursday, 29 September 2022 at 06:29:30 UTC+2 aa...@aaronsmith.co wrote:

> Why doesn't Django validate Models on save()?
>
> I am aware that full_clean() is called when using ModelForms. But most web 
> app development these days, and every django app I've ever worked with, are 
> headless APIs. The default behavior is dangerous for the naive developer.
>
> Bringing View-level concepts such as forms or serializers down into celery 
> tasks and management commands breaks separation of concerns, and having 
> multiple validation implementations at different layers in the app is 
> fraught with divergence and unexpected behavior.
>
> It's not right. The data store layer should protect the validity of the 
> data.
>

-- 
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/566b4706-4075-485b-9122-eca24d3b67fcn%40googlegroups.com.

Re: Revisiting multiline template tags in Django Templates (again)

[Carlton Gibson]

Hey Thibaud.

Thanks for following up! Yes — happy to sheppard.

(My other comment was to make sure the Rationale was sufficiently
clear/compelling, but I know you're on that 😉)
C.

On Wed, 28 Sept 2022 at 12:24, Thibaud Colas  wrote:

> Just wanted to follow up that I got to discuss this in person with Carlton
> Gibson at the DjangoCon Europe sprints in Porto, who provisionally offered
> to act as a shepherd for this proposed DEP. This is on the condition that I
> find an implementation team as well.
>
> On Saturday, 24 September 2022 at 08:37:52 UTC+1 Thibaud Colas wrote:
>
>> 👋 Hi django-developers, I would like to revisit a very old feature
>> request: ticket #8652 Multiline tags and tag escape tags
>> <https://code.djangoproject.com/ticket/8652>, proposed DEP Multiline
>> Template Tags <https://github.com/django/deps/pull/3>, and maling list
>> thread Revisiting multiline tags
>> <https://groups.google.com/g/django-developers/c/wRKgnMIhl6g/m/hMRHPIz4CgAJ>
>> .
>>
>> There have been a lot of cases made against and for multiline template
>> tags across many threads. I’m raising this on the mailing list not
>> necessarily to revisit those arguments but to ask:
>>
>>1. Is a DEP indeed the best way forward for this at this point in
>>time? If so I will volunteer to author it (co-authors welcome!).
>>2. The last DEP got blocked due to the lack of an implementation team
>>and shepherd. If we made a new (proposed) DEP – is anyone here interested
>>in helping in either positions?
>>
>>
>> --
> 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/ddc74d02-63df-479a-968c-2ee44b696bd2n%40googlegroups.com
> <https://groups.google.com/d/msgid/django-developers/ddc74d02-63df-479a-968c-2ee44b696bd2n%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/CAJwKpySuOV37RcngoV2TopXsayMOw_WRACgy-_WoHVTwebDjPw%40mail.gmail.com.

Re: Optional URL parameters in django.urls.path

[Carlton Gibson]

One approach is to route two patterns (one with the parameter and one
without) to the same URL. Some duplication but (perhaps) easier to read at
a glance than either an optional `?` operator.

Given that — and the alternative re_path() approach being available —
 unless there was a particularly simple implementation on display I'd
likely be sceptical about an addition here… 🤔

On Mon, 19 Sept 2022 at 14:07, Meiyer  wrote:

> Hi,
>
> I feel there is a use case that the `path()` function does not address and
> thus requires to switch over to `re_path()` which immediately adds a lot of
> additional and error-prone syntax.
>
> Often there is a need to capture a URL parameter which can be optional
> into the view’s kwargs. In terms of path() syntax, this could be
> accomplished by simply allowing, e.g., . However, I am not sure
> how to handle the forward slash that would usually appear after the
> parameter, and I don’t know how difficult it would be to amend the current
> implementation to support this feature.
>
> By the way, if there was a discussion about this before, I couldn’t find
> it. Please point me to it if there was.
>
> --
> 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/818f30d8-308b-4860-b861-7c7dde9b7aaan%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/CAJwKpyTxa291LBc17H7%3DhpdHy3F_sSj2yPz76ncphMa7Mf4qZQ%40mail.gmail.com.

Re: Add support for IDNA 2008

[Carlton Gibson]

OK, great, thanks.

I'll await your PR. Let's continue on GitHub for the moment then
Good hustle 👍

On Wed, 14 Sept 2022 at 15:54, 'Julien Bernard' via Django developers
(Contributions to Django itself)  wrote:

> Hi Carlton,
>
> Le mardi 13 septembre 2022 à 07:17:31 UTC-4, carlton...@gmail.com a
> écrit :
>
>> Hi Julien.
>>
>> I didn't get a canonical answer from the security team yet, but it may be
>> that we can make the idna an optional dependency quite easily. I already
>> have it installed in my dev environment, for instance, coming from selenium
>> and requests.
>>
>> From the package docs: https://pypi.org/project/idna/
>>
>>You may use the codec encoding and decoding methods using
>> the idna.codec module:
>>>>> import idna.codec
>>>>> print('домен.испытание'.encode('idna'))
>>b'xn--d1acufc.xn--80akhbyknj4f'
>>
>> So "use if installed" (catching the ImportError if not) would look
>> feasible. (The usage in the punycode helper is just `domain.encode("idna")`
>> which matches this example already.)
>>
>
> That's great news! Thanks.
>
>
>>
>> Would you fancy looking a PR around that?
>>
>
> Yes, no problem.
>
>
>>
>> We'd need *some* tests for both the installed and not-installed cases,
>> ideally showing the difference. I didn't immediately have success with your
>> https://fuss.standcore.com/ example:
>>
>> % python
>> Python 3.10.6 (v3.10.6:9c7b4bd164, Aug  1 2022, 17:13:48) [Clang
>> 13.0.0 (clang-1300.0.29.30)] on darwin
>> Type "help", "copyright", "credits" or "license" for more information.
>> >>> print('https://fuß.standcore.com/'.encode('idna')
>> <https://fuss.standcore.com/'.encode('idna')>)
>> b'https://fuss.standcore.com/'
>> >>> import idna.codec
>> >>> print('https://fuß.standcore.com/'.encode('idna')
>> <https://fuss.standcore.com/'.encode('idna')>)
>> b'https://fuss.standcore.com/'  # Was expecting
>> https://xn--fu-hia.standcore.com/ from discussion 🤔
>> >>> import idna
>> >>> idna.encode('https://fuß.standcore.com/
>> <https://fuss.standcore.com/>')
>> Traceback (most recent call last):
>>   File "", line 1, in 
>>   File
>> "/Users/carlton/Envs/django/lib/python3.10/site-packages/idna/core.py",
>> line 357, in encode
>> s = alabel(label)
>>   File
>> "/Users/carlton/Envs/django/lib/python3.10/site-packages/idna/core.py",
>> line 269, in alabel
>> check_label(label)
>>   File
>> "/Users/carlton/Envs/django/lib/python3.10/site-packages/idna/core.py",
>> line 250, in check_label
>> raise InvalidCodepoint('Codepoint {} at position {} of {} not
>> allowed'.format(_unot(cp_value), pos+1, repr(label)))
>> idna.core.InvalidCodepoint: Codepoint U+003A at position 6 of '
>> https://fuß <https://fuss>' not allowed
>>
>
> I was not able to get .encode('idna') to work either. I reported this
> issue https://github.com/kjd/idna/issues/128 to check why this is not
> working as expected.
>
> For the last part, idna works with labels or domains, so you would have to
> provide only the domain to the encode method:
>
> % python
> Python 3.10.7 (main, Sep  6 2022, 21:22:27) [GCC 12.2.0] on linux
> Type "help", "copyright", "credits" or "license" for more information.
> >>> import idna
> >>> idna.encode('fuß.standcore.com <http://fuss.standcore.com>')
> b'xn--fu-hia.standcore.com'
>
> Best regards,
> Julien
>
>
>>
>> Possibly there's some objection to such a change, but I'm struggling to
>> imagine it short of concrete cases...
>>
>> Thanks!
>>
>> Kind Regards,
>>
>> Carlton
>>
>>
>>
>> On Wednesday, 7 September 2022 at 08:18:13 UTC+2 Carlton Gibson wrote:
>>
>>> Hey Julien.
>>>
>>> Thanks, OK... 📖
>>>
>>> The Python docs have it
>>> <https://docs.python.org/3.10/library/codecs.html#python-specific-encodings>
>>> :
>>>
>>> > If you need the IDNA 2008 standard from *RFC 5891*
>>> <https://tool

Re: Add support for IDNA 2008

[Carlton Gibson]

Hi Julien. 

I didn't get a canonical answer from the security team yet, but it may be 
that we can make the idna an optional dependency quite easily. I already 
have it installed in my dev environment, for instance, coming from selenium 
and requests. 

>From the package docs: https://pypi.org/project/idna/

   You may use the codec encoding and decoding methods using 
the idna.codec module:
   >>> import idna.codec 
   >>> print('домен.испытание'.encode('idna')) 
   b'xn--d1acufc.xn--80akhbyknj4f'

So "use if installed" (catching the ImportError if not) would look 
feasible. (The usage in the punycode helper is just `domain.encode("idna")` 
which matches this example already.)

Would you fancy looking a PR around that? 

We'd need *some* tests for both the installed and not-installed cases, 
ideally showing the difference. I didn't immediately have success with your 
https://fuss.standcore.com/ example: 

% python
Python 3.10.6 (v3.10.6:9c7b4bd164, Aug  1 2022, 17:13:48) [Clang 13.0.0 
(clang-1300.0.29.30)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> print('https://fuß.standcore.com/'.encode('idna'))
b'https://fuss.standcore.com/'
>>> import idna.codec
>>> print('https://fuß.standcore.com/'.encode('idna'))
b'https://fuss.standcore.com/'  # Was expecting 
https://xn--fu-hia.standcore.com/ from discussion 🤔
>>> import idna
>>> idna.encode('https://fuß.standcore.com/')
Traceback (most recent call last):
  File "", line 1, in 
  File 
"/Users/carlton/Envs/django/lib/python3.10/site-packages/idna/core.py", 
line 357, in encode
s = alabel(label)
  File 
"/Users/carlton/Envs/django/lib/python3.10/site-packages/idna/core.py", 
line 269, in alabel
check_label(label)
  File 
"/Users/carlton/Envs/django/lib/python3.10/site-packages/idna/core.py", 
line 250, in check_label
raise InvalidCodepoint('Codepoint {} at position {} of {} not 
allowed'.format(_unot(cp_value), pos+1, repr(label)))
    idna.core.InvalidCodepoint: Codepoint U+003A at position 6 of 
'https://fuß' not allowed

Possibly there's some objection to such a change, but I'm struggling to 
imagine it short of concrete cases... 

Thanks! 

Kind Regards,

Carlton



On Wednesday, 7 September 2022 at 08:18:13 UTC+2 Carlton Gibson wrote:

> Hey Julien. 
>
> Thanks, OK... 📖
>
> The Python docs have it 
> <https://docs.python.org/3.10/library/codecs.html#python-specific-encodings>
> : 
>
> > If you need the IDNA 2008 standard from *RFC 5891* 
> <https://tools.ietf.org/html/rfc5891.html> and *RFC 5895* 
> <https://tools.ietf.org/html/rfc5895.html>, use the third-party idna 
> module <https://pypi.org/project/idna/>.
>
> So the question is do we **need** the newer standard?
>
> I will have a read of the various resources here, and I'll also ask the 
> Django Security Team if they have any thoughts. 
>
> Kind Regards,
>
> Carlton
>
>
> On Tue, 6 Sept 2022 at 23:03, 'Julien Bernard' via Django developers 
> (Contributions to Django itself)  wrote:
>
>> Hi Carlton,
>>
>> IDNA 2008 made some changes in the valid or invalid IDNs and some 
>> differences in the ways some characters are transformed in Punycode 
>> compared to IDNA 2003 for multiple reasons.
>> A difference that is often used as an example is the german 'ß' 
>> character. In IDNA 2003 it is transformed into 'ss' while it is converted 
>> into Punycode in IDNA 2008.
>> It means that, depending on the standard that is implemented, you may 
>> reach totally different domains with the same IDN, which may lead to 
>> security issues.
>> For example, the URL https://fuß.standcore.com/ 
>> <https://fuss.standcore.com/> would be https://fuss.standcore.com/ with 
>> IDNA 2003 and https://xn--fu-hia.standcore.com/ with IDNA 2008.
>> This is only a very brief insight, for further quick readings, 
>> https://www.unicode.org/faq/idn.html is quite informative too.
>>
>> Best regards,
>> Julien
>>
>> Le mardi 6 septembre 2022 à 14:39:49 UTC-4, carlton...@gmail.com a 
>> écrit :
>>
>>> Hey Julian. 
>>>
>>> What's maybe missing is some concrete cases. "This conversion should be 
>>> made IDNA 2008 compliant." — OK, but what does that buy us? 
>>>
>>> Maybe the idna package is OK... It's widely depended on already — I got 
>>&g

Re: Check constraint validation with NULLs

[Carlton Gibson]

Hi David.

This is https://code.djangoproject.com/ticket/33996 I think — it's a
Release Blocker for 4.1.2
Your thoughts/review on work there would be welcome. :)

Kind Regards,

Carlton


On Thu, 8 Sept 2022 at 14:30, David Sanders 
wrote:

> Hi folks,
>
> I've noticed a difference in the way check constraint validation behaves
> compared to the way Postgres (assuming similar behaviour in other DBs)
> validates when dealing with NULLs.
>
> Given a model with a simple positive check constraint:
>
> class Test(Model):
> test = IntegerField(null=True)
>
> class Meta:
> constraints = [
>CheckConstraint(check=Q(test__gte=0), name="positive"),
> ]
>
> Then the an instance with a NULL will save but fail validation:
>
> test = Test()
> test.save()
> test.validate_constraints()
> ...
> E   django.core.exceptions.ValidationError: {'__all__':
> ['Constraint “positive” is violated.']}
>
>
> I believe this is due to the way validation is handled in the WHERE
> clause. I've trawled back through the PR discussion and original ticket
> as well as the validation code – I could see the original comment about
> moving validation to WHERE to get around issues with using SELECT but
> couldn't find any other mention about how NULLs should be handled.
>
> I wanted to check with folks here first before raising an issue. I'm not
> sure what the fix should be but I'd recommend at least adding a note in the
> docs if it's not fixable? :)
>
> Cheers,
> David
>
> --
> 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/CADyZw-4uYZnpWgjOXT-Wa2BSs%2BG1f4PNFD0YDU096bK9Uzc0tw%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/CAJwKpySQt%3DUtnDH7CfyzgQa2tsWk3eSY8fQNsEdiMa8LyZJctg%40mail.gmail.com.

Re: Need help on solving an issue

[Carlton Gibson]

Hi Arka. Welcome.

Did you see the contributing guidelines?
https://docs.djangoproject.com/en/4.1/internals/contributing/

Then make sure you're set up to run the unit tests:
https://docs.djangoproject.com/en/4.1/internals/contributing/writing-code/unit-tests/

If you can create a test-case for the issue, that shows how it fails,
that's a great start.

Then take a look at this PR, which looks related 🤔 — although that needs
confirming (and it needs a test case at least).
https://github.com/django/django/pull/15573

I hope that helps.

Kind Regards,

Carlton

On Wed, 7 Sept 2022 at 15:58, Arka Pratim Chaudhuri 
wrote:

> Hey, can anyone help me in solving #33985
>  . This is actually my first
> time & I'm totally confused of what to do.
>
> --
> 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/97e2b0e7-2574-4a14-a55a-38beff787964n%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/CAJwKpyT7OXyiE5L%2BFUOeypGnNugnwtwPJeNSGb5CqT8TZQpquA%40mail.gmail.com.

Re: Add support for IDNA 2008

[Carlton Gibson]

Hey Julien.

Thanks, OK... 📖

The Python docs have it

:

> If you need the IDNA 2008 standard from *RFC 5891*
 and *RFC 5895*
, use the third-party idna module
.

So the question is do we **need** the newer standard?

I will have a read of the various resources here, and I'll also ask the
Django Security Team if they have any thoughts.

Kind Regards,

Carlton


On Tue, 6 Sept 2022 at 23:03, 'Julien Bernard' via Django developers
(Contributions to Django itself)  wrote:

> Hi Carlton,
>
> IDNA 2008 made some changes in the valid or invalid IDNs and some
> differences in the ways some characters are transformed in Punycode
> compared to IDNA 2003 for multiple reasons.
> A difference that is often used as an example is the german 'ß' character.
> In IDNA 2003 it is transformed into 'ss' while it is converted into
> Punycode in IDNA 2008.
> It means that, depending on the standard that is implemented, you may
> reach totally different domains with the same IDN, which may lead to
> security issues.
> For example, the URL https://fuß.standcore.com/
>  would be https://fuss.standcore.com/ with
> IDNA 2003 and https://xn--fu-hia.standcore.com/ with IDNA 2008.
> This is only a very brief insight, for further quick readings,
> https://www.unicode.org/faq/idn.html is quite informative too.
>
> Best regards,
> Julien
>
> Le mardi 6 septembre 2022 à 14:39:49 UTC-4, carlton...@gmail.com a écrit :
>
>> Hey Julian.
>>
>> What's maybe missing is some concrete cases. "This conversion should be
>> made IDNA 2008 compliant." — OK, but what does that buy us?
>>
>> Maybe the idna package is OK... It's widely depended on already — I got
>> it for free yesterday installing httpx in a project — and packaging isn't
>> what it was... — but **if** we take on an extra dependency it needs to be
>> for a clear gain.
>>
>> Likely (still) a proof-of-concept at least showing what's added (as a
>> separate package? 🤔)  is the easiest way forward?
>>
>> Others may yet agree that this is something needed.
>>
>> Kind Regards,
>>
>> Carlton
>>
>> On Tue, 6 Sept 2022 at 20:23, 'Julien Bernard' via Django developers
>> (Contributions to Django itself)  wrote:
>>
>>> Thanks Carlton.
>>>
>>> This makes total sense to keep things simple and avoid bringing another
>>> dependency in the context of validation, providing that you won't prevent
>>> valid URLs to be accepted. That's where it can be tricky but it seems
>>> reasonable to think that the current domain validation  is too permissive
>>> from what I saw.
>>> But the punycode method is also used in other places where it is more
>>> "critical" than a validator:
>>>
>>>- Urlizer
>>>- CachedDnsName
>>>- email sending.
>>>
>>> The need for the idna package should be evaluated regarding those usages
>>> rather than the validation.
>>>
>>> Best regards,
>>> Julien
>>>
>>> Le dimanche 4 septembre 2022 à 05:16:19 UTC-4, carlton...@gmail.com a
>>> écrit :
>>>
 Hi Julian.

 We've had several tickets and discussions surrounding how far e.g.
 URLValidator needs to match all valid URLs. The conclusion we've come to
 (which is always provisional) is that actually we **don't** want such match
 all valid (according to the relevant RFC and such) input. Rather, we'd
 prefer a simpler implementation — that's realistically maintainable for us
 — that captures the 95% case, and then ask users to implement a custom
 validator if they need more. This seems like a happy compromise.

 I hope that makes sense.

 I agree with Adam here that a third-party package is the immediate way
 forward here. If it shows a lot of demand then it's always open to revisit
 whether that should be included in Django itself. (Taking on an extra
 dependency for a small subset of users is always going to be up for debate
 — it's not a blocker per se, but it does need weighing...)

 Kind Regards,

 Carlton

 On Fri, 2 Sept 2022 at 17:32, 'Julien Bernard' via Django developers
 (Contributions to Django itself)  wrote:

> Thanks Adam.
> The ticket was targetting EmailValidator but the punycode method is
> used at more places in Django core.
> If you look for Unicode characters support in email addresses in
> tickets you will get more than looking for IDN but indeed the demand may
> not be that much.
> This is a vicious circle, IDNs and especially EAIs are not widely used
> because of the poor support in software and the lack of compliance with 
> the
> latest version.
> Regards,
> Julien
>
>
> Le jeudi 1 septembre 2022 à 13:33:29 UTC-4, Adam Johnson a écrit :
>
>> Some data...
>>
>> The idna package has ~9M downloads a day (
>> https://py

Re: Add support for IDNA 2008

[Carlton Gibson]

Hey Julian.

What's maybe missing is some concrete cases. "This conversion should be
made IDNA 2008 compliant." — OK, but what does that buy us?

Maybe the idna package is OK... It's widely depended on already — I got it
for free yesterday installing httpx in a project — and packaging isn't what
it was... — but **if** we take on an extra dependency it needs to be for a
clear gain.

Likely (still) a proof-of-concept at least showing what's added (as a
separate package? 🤔)  is the easiest way forward?

Others may yet agree that this is something needed.

Kind Regards,

Carlton

On Tue, 6 Sept 2022 at 20:23, 'Julien Bernard' via Django developers
(Contributions to Django itself)  wrote:

> Thanks Carlton.
>
> This makes total sense to keep things simple and avoid bringing another
> dependency in the context of validation, providing that you won't prevent
> valid URLs to be accepted. That's where it can be tricky but it seems
> reasonable to think that the current domain validation  is too permissive
> from what I saw.
> But the punycode method is also used in other places where it is more
> "critical" than a validator:
>
>- Urlizer
>- CachedDnsName
>- email sending.
>
> The need for the idna package should be evaluated regarding those usages
> rather than the validation.
>
> Best regards,
> Julien
>
> Le dimanche 4 septembre 2022 à 05:16:19 UTC-4, carlton...@gmail.com a
> écrit :
>
>> Hi Julian.
>>
>> We've had several tickets and discussions surrounding how far e.g.
>> URLValidator needs to match all valid URLs. The conclusion we've come to
>> (which is always provisional) is that actually we **don't** want such match
>> all valid (according to the relevant RFC and such) input. Rather, we'd
>> prefer a simpler implementation — that's realistically maintainable for us
>> — that captures the 95% case, and then ask users to implement a custom
>> validator if they need more. This seems like a happy compromise.
>>
>> I hope that makes sense.
>>
>> I agree with Adam here that a third-party package is the immediate way
>> forward here. If it shows a lot of demand then it's always open to revisit
>> whether that should be included in Django itself. (Taking on an extra
>> dependency for a small subset of users is always going to be up for debate
>> — it's not a blocker per se, but it does need weighing...)
>>
>> Kind Regards,
>>
>> Carlton
>>
>> On Fri, 2 Sept 2022 at 17:32, 'Julien Bernard' via Django developers
>> (Contributions to Django itself)  wrote:
>>
>>> Thanks Adam.
>>> The ticket was targetting EmailValidator but the punycode method is used
>>> at more places in Django core.
>>> If you look for Unicode characters support in email addresses in tickets
>>> you will get more than looking for IDN but indeed the demand may not be
>>> that much.
>>> This is a vicious circle, IDNs and especially EAIs are not widely used
>>> because of the poor support in software and the lack of compliance with the
>>> latest version.
>>> Regards,
>>> Julien
>>>
>>>
>>> Le jeudi 1 septembre 2022 à 13:33:29 UTC-4, Adam Johnson a écrit :
>>>
 Some data...

 The idna package has ~9M downloads a day (
 https://pypistats.org/packages/idna ) compared with Django's ~350k (
 https://pypistats.org/packages/django ).

 However it has 191 GitHub stars ( https://github.com/kjd/idna )
 compared to Django's 66k ( https://github.com/django/django ).

 I imagine most idna installs are from popular packages depending on it:
 at least requests, and twisted do. Most people probably don't care about
 complete domain validation (until they do). To me, it seems like a
 reasonable dependency for Django to adopt, given so much of the ecosystem
 uses it.

 But I don't think there's much evidence of demand. I found one other
 ticket mentioning idna, and this was with an extended regex, not the
 package ( https://code.djangoproject.com/ticket/18119 , seems stale,
 maybe closeable? ).

 I'd suggest at this point: implement idna validators in a third party
 package, do some advocacy for why projects would need it, and show some
 adoption. This would make the case for Django itself stronger.

 On Thu, Sep 1, 2022 at 4:18 PM 'Julien Bernard' via Django developers
 (Contributions to Django itself)  wrote:

> Hi,
> I'm starting this discussion following ticket #33968
>  recommendation in
> comment.
> Currently the punycode
> 
> method is converting domain names from Unicode to ASCII using the
> deprecated IDNA 2003 standard.
> As suggested in the ticket, the method should use the idna
>  package that is fully compliant with
> the latest IDNA 2008 standard.
> Ticket comment points that adding a new dependency is pr

Re: Add support for IDNA 2008

[Carlton Gibson]

Hi Julian.

We've had several tickets and discussions surrounding how far e.g.
URLValidator needs to match all valid URLs. The conclusion we've come to
(which is always provisional) is that actually we **don't** want such match
all valid (according to the relevant RFC and such) input. Rather, we'd
prefer a simpler implementation — that's realistically maintainable for us
— that captures the 95% case, and then ask users to implement a custom
validator if they need more. This seems like a happy compromise.

I hope that makes sense.

I agree with Adam here that a third-party package is the immediate way
forward here. If it shows a lot of demand then it's always open to revisit
whether that should be included in Django itself. (Taking on an extra
dependency for a small subset of users is always going to be up for debate
— it's not a blocker per se, but it does need weighing...)

Kind Regards,

Carlton

On Fri, 2 Sept 2022 at 17:32, 'Julien Bernard' via Django developers
(Contributions to Django itself)  wrote:

> Thanks Adam.
> The ticket was targetting EmailValidator but the punycode method is used
> at more places in Django core.
> If you look for Unicode characters support in email addresses in tickets
> you will get more than looking for IDN but indeed the demand may not be
> that much.
> This is a vicious circle, IDNs and especially EAIs are not widely used
> because of the poor support in software and the lack of compliance with the
> latest version.
> Regards,
> Julien
>
>
> Le jeudi 1 septembre 2022 à 13:33:29 UTC-4, Adam Johnson a écrit :
>
>> Some data...
>>
>> The idna package has ~9M downloads a day (
>> https://pypistats.org/packages/idna ) compared with Django's ~350k (
>> https://pypistats.org/packages/django ).
>>
>> However it has 191 GitHub stars ( https://github.com/kjd/idna ) compared
>> to Django's 66k ( https://github.com/django/django ).
>>
>> I imagine most idna installs are from popular packages depending on it:
>> at least requests, and twisted do. Most people probably don't care about
>> complete domain validation (until they do). To me, it seems like a
>> reasonable dependency for Django to adopt, given so much of the ecosystem
>> uses it.
>>
>> But I don't think there's much evidence of demand. I found one other
>> ticket mentioning idna, and this was with an extended regex, not the
>> package ( https://code.djangoproject.com/ticket/18119 , seems stale,
>> maybe closeable? ).
>>
>> I'd suggest at this point: implement idna validators in a third party
>> package, do some advocacy for why projects would need it, and show some
>> adoption. This would make the case for Django itself stronger.
>>
>> On Thu, Sep 1, 2022 at 4:18 PM 'Julien Bernard' via Django developers
>> (Contributions to Django itself)  wrote:
>>
>>> Hi,
>>> I'm starting this discussion following ticket #33968
>>>  recommendation in comment.
>>> Currently the punycode
>>> 
>>> method is converting domain names from Unicode to ASCII using the
>>> deprecated IDNA 2003 standard.
>>> As suggested in the ticket, the method should use the idna
>>>  package that is fully compliant with
>>> the latest IDNA 2008 standard.
>>> Ticket comment points that adding a new dependency is problematic,
>>> however, in most case, someone using Django will end up with this
>>> dependency anyway as it is widely used. Django GeoIP2 contrib uses it for
>>> instance.
>>> Best regards,
>>> Julien
>>>
>>> --
>>> 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/d4331b21-d9e8-4647-aa1f-357b00fb0125n%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/90f58142-7808-4136-a06d-8ba1352857c7n%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, 

Re: Make timeout property for PasswordResetTokenGenerator

[Carlton Gibson]

Hey Robert.

> ... the argument here is "we don't want to", but the reasoning behind
that is unclear ...

For me, the reasoning would be that we get several security reports against
Django pretty much every week, and the extent to which we make security
sensitive areas **generic** for the sake of only a subset of users
increases the attack surface, which makes these harder to contain and deal
with. (**Every** hook adds a maintenance cost, no matter how small. The
question is always whether it's worth it.)

The diff on django/contrib/auth/tokens.py is small:
https://github.com/django/django/pull/11302/files

I'm not sure we want to make PasswordResetTokenGenerator usable as a
generic token generator. (Use the signing tools to create your own no?)

Perhaps others will say that yes this is worth it (and then we come to a
consensus, or not) — but my original reply was attempting to expand the
reason for the original decision to turn it down.

C.










On Wed, 24 Aug 2022 at 15:53, 'Robert Musił' via Django developers
(Contributions to Django itself)  wrote:

> Hey Carlton,
>
> I'm reading through the replies and I feel like I'm missing point
> completely.
>
> First some background - `PasswordResetTokenGenerator` is heavily
> referenced over the web (or more accurately - the `default_token_genrator`)
> when it comes to account activation. I personally believe the solution is
> pretty genius for this particular use case, simplifies the flow without
> relying on the persistence layer. The implementation is also well-contained
> within the class so makes using it super simple.
> When I use `default_token_generator` I'm however limited by two things -
> the fields that make up the hash (user.pk, user.password, login_timestamp
> and current timestamp) - which I can EASILY overwrite with
> `_make_hash_value` and `PASSWORD_RESET_TIMEOUT_DAYS` which is NOT easily
> overwritten, due to the method `check_token` having too many
> responsibilities.
>
> So the use case is definitely there, but the argument here is "we don't
> want to", but the reasoning behind that is unclear - is it not worth to
> maintain this piece of code because it's deprecated? This would be flagged
> then, no? Or do you feel like it's already a concrete implementation given
> its name ("PasswordResetTokenGenerator") - would the solution then be
> abstracting the parts of it to a base class, would that be acceptable?
>
>
>
>
>
>
> On Tuesday, 23 August 2022 at 13:47:45 UTC+2 carlton...@gmail.com wrote:
>
>> Yes, likely.
>>
>> My point was (merely) that we **don't** want to add
>> additional extension points to PasswordResetTokenGenerator.
>>
>> On Tue, 23 Aug 2022 at 12:58, Roger Gammans 
>> wrote:
>>
>>> Hi
>>>
>>> If it's intended as a reference implementation, then I would expect
>>> PasswordResetTokenGenerator  to use Signer or TimestampSigner internally
>>> , but I was surprised to discover that it didn't use either.
>>>
>>> Isn't those entry points the better API to advise for use rather than
>>> the direct use of hmac based algorithms?
>>>
>>> On Tue, 2022-08-23 at 12:45 +0200, Carlton Gibson wrote:
>>>
>>> Hi Alexander.
>>>
>>> I think the point from ticket #30423 is that we don't want to complicate
>>> PasswordResetTokenGenerator in order to make it into a more general
>>> purpose token generator.
>>> Much better is for you to take inspiration from it to implement what you
>>> need in your project. (It's the underlying signing code that you really
>>> want to lean on Django for.)
>>>
>>> Kind Regards,
>>>
>>> Carlton
>>>
>>> On Mon, 22 Aug 2022 at 17:26, Alexander Voloshchenko <
>>> voloshchen...@gmail.com> wrote:
>>>
>>> During project development our team needs to create several types of
>>> tokens. One of them will be used in case of account reset password. The
>>> second one is for account activation. Django itself has a good class for
>>> token generation called PasswordResetTokenGenerator. And now for
>>> account activation, we are using our own class called
>>> ActivationTokenGenerator, a subclass of PasswordResetTokenGenerator with
>>> overridden _make_hash_value method. And it works, but there is one
>>> problem. And this problem is called "timeout". For now, every token created
>>> with PasswordResetTokenGenerator will have timeout from
>>> settings.PASSWORD_RESET_TIMEOUT variable and can be changed only by
>>> chang

Re: #21978 include production-ready web server

[Carlton Gibson]

Hey Pete.

Yes, there can be a lot of steps... (and trouble is every one has a
different opinion once you get to specifics :)

django-webserver looks good — in a similar ballpark to what I had in mind,
yes, but I'd probably not want to bundle the options for each server
myself, as that seems a lot to maintain over time... (Better to outsource
to the individual projects no?)

Have you seen what Eric Matthes is doing with django-simple-deploy?

https://github.com/ehmatthes/django-simple-deploy

I really like the idea: in an opinionated way, it applies the project
changes you need to deploy (and it's plugable so folks could provide a
*template* for their own flavour of deployment if they wanted, which is
kind of important given the number of options in the landscape, even if you
only to *ship* a beginner option.)

Tim Allen also recently raised improving the Django project template, which
I think is related here. (That's on my list too: async this QTR, then
hoping to take on Adam's proposal to modernise the Request object for the
end of year, then 🤞 swinging back here for "OK, what does it look like,
what can we do?" after that: there's a bunch of related tickets around
#21978 that it would be very sweet if we could clear up...)

I think all these thoughts are really pursuable outside of core in the very
short run, even if the goal is to merge them — it's much easier to
experiment that way, and then say, "This worked".

Anyhow, other than a "I've been thinking along these lines", and a
generally positive emote, I don't have too much more concrete at this
stage.
👍
C.

On Tue, 23 Aug 2022 at 19:00, Peter Baumgartner 
wrote:

> Thanks for the additional background Carlton! I like the idea of
> having some sort of protocol that folks can follow to make
> ready-to-use Django server packages (django-webserver [1] is in the
> same vein), but I'd strive for more. pip install + INSTALLED_APPS is
> great, but getting to production with that approach can feel like
> death by a thousand paper cuts. Do that with gunicorn, whitenoise,
> dj-database-url, etc. and it ends up being a laundry list of things
> that, in my experience, people rarely get right on the first try and
> just result in frustration.
>
> It seems like part of the challenge here is reaching parity with the
> current runserver command, but is that necessary? Running `runserver
> --dev` locally and getting dev features like autoreloading and then
> having `runserver` use a different server for a deployed app doesn't
> seem unreasonable.
>
> [1] https://github.com/lincolnloop/django-webserver
>
> On Tue, Aug 23, 2022 at 10:14 AM Carlton Gibson
>  wrote:
> >
> > Hey Pete.
> >
> > Yes... this is a good one.
> >
> > It's difficult to see how we can even have an ASGI runserver in core,
> simply because there's no SimpleServer equivalent as there is for WSGI, and
> it's not clear one is on the card. (HTTP is getting **more** complex, and I
> can't see  Python bringing such into the standard library.)
> > So we have to use a third-party dependency for that.
> >
> > For the Channels v4 update (in progress now) I'm moving the runserver
> command to the Daphne package. This was because folks wanted to use
> Channels without the Daphne/Twisted dependency.
> >
> > See: https://github.com/django/daphne/pull/429
> >
> > tl;dr — it came out pretty clean TBH. You pip install daphne, then add
> "daphne" at the top of INSTALLED_APPS. (There's a system check to make sure
> you're not fighting staticfiles.)
> >
> > On the back of that I don't see why servers (any servers) can't provide
> a runserver command (or a django-* mini-package to go with it) and offer
> what they offer in development as well as production. (Obviously that all
> needs writing but it's just a management command.)
> >
> > Related is strategising the reloader.
> https://code.djangoproject.com/ticket/30213
> >
> > We could then host *Protocols* — "Your runserver should do this",
> "Implement this for your reloader", and so on — and (maybe) (slowly)
> replace built-in options here with either optional dependencies (pip
> install django["daphne"]) or recommendations to get going. (pip install
> django["starter"] maybe). — I don't know — we seem a long way from that. (I
> don't suppose wsgiref is going anywhere too soon is it?)
> >
> > But to cut back to your point, I don't know that we need to **include**
> a server — just make it easy to get going. These days pip install + a line
> in INSTALLED_APPS doesn't seem too much to ask (I think.)
> >
> > Was it r

Re: #21978 include production-ready web server

[Carlton Gibson]

Hey Pete.

Yes... this is a good one.

It's difficult to see how we can even have an ASGI runserver in core,
simply because there's no SimpleServer equivalent as there is for WSGI, and
it's not clear one is on the card. (HTTP is getting **more** complex, and I
can't see  Python bringing such into the standard library.)
So we have to use a third-party dependency for that.

For the Channels v4 update (in progress now) I'm moving the runserver
command to the Daphne package. This was because folks wanted to use
Channels without the Daphne/Twisted dependency.

See: https://github.com/django/daphne/pull/429

tl;dr — it came out pretty clean TBH. You pip install daphne, then add
"daphne" at the top of INSTALLED_APPS. (There's a system check to make sure
you're not fighting staticfiles.)

On the back of that I don't see why servers (any servers) can't provide a
runserver command (or a django-* mini-package to go with it) and offer what
they offer in development as well as production. (Obviously that all needs
writing but it's just a management command.)

Related is strategising the reloader.
https://code.djangoproject.com/ticket/30213

We could then host *Protocols* — "Your runserver should do this",
"Implement this for your reloader", and so on — and (maybe) (slowly)
replace built-in options here with either optional dependencies (pip
install django["daphne"]) or recommendations to get going. (pip install
django["starter"] maybe). — I don't know — we seem a long way from that. (I
don't suppose wsgiref is going anywhere too soon is it?)

But to cut back to your point, I don't know that we need to **include** a
server — just make it easy to get going. These days pip install + a line in
INSTALLED_APPS doesn't seem too much to ask (I think.)

Was it really 4 years ago Tom left that comment on #21978
 😳 (We'd finally close this
as wontfix: Django doesn't ship a webserver.)

Does that fit in your view, or would that scenario not be good enough?

Kind Regards,

Carlton

On Tue, 23 Aug 2022 at 16:56, Peter Baumgartner 
wrote:

> Hi all! I'd like to re-open the discussion around
> https://code.djangoproject.com/ticket/21978
>
> As a "batteries included" framework, Django kind of leaves people to
> fend for themselves when it comes to deployment. This makes it harder
> than necessary for a developer to go from works-on-my-laptop to
> works-on-the-internet. The docs here are great, but also daunting to a
> newcomer https://docs.djangoproject.com/en/4.1/howto/deployment/
>
> I'd love to see Django provide some sane defaults that people can use
> to deploy a site without having to make a bunch of decisions they
> don't totally understand.
>
> I have two thoughts on how it could be handled:
>
> 1. Similar to the template backends. You get Django's template system
> by default, but you're welcome to swap in Jinja2. I don't believe
> there is a one-size-fits-all webserver, but probably a
> one-size-fits-most.
> 2. Similar to cache/database backends. You define the backend you want
> to use and Django makes some sane choices for you and allows you to
> serve the site via some common `manage.py` command.
>
> For the first option, Gunicorn is a popular choice, but afaik it does
> not work on Windows. Waitress [1] is an interesting option for WSGI
> serving and daphne exists for ASGI. Whitenoise is a reasonable choice
> for serving static files. It doesn't yet support ASGI, but there has
> been some activity on that front [2].
>
> Thanks!
>
> [1] https://pypi.org/project/waitress/
> [2] https://github.com/evansd/whitenoise/pull/359
>
> --
> 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/CAC6K9zk5PmcxYWXRdvco1pWXnO%2BHoYoYHf0pg5Mw%3DgmdefZArg%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/CAJwKpyTSGPJW%2BmdUADW8eBYaXakesHG9H9dkSzhLxWnCpBdH6A%40mail.gmail.com.

Re: About #33904, Many-To-Many field is deleted/ignored from internal JavaScript “filter” interface

[Carlton Gibson]

Hi Carsten,

Mariusz marked that as a duplicate

The fix was applied to stable/4.1.x here:
https://github.com/django/django/commit/82e9e19ebe6bc920f1cfffc42d86648644fd4a78

It'll be part of the next release.
https://docs.djangoproject.com/en/4.1/releases/4.1.1/

Can you give stable/4.1.x a try and confirm it fixes your problem? If it
doesn't work please reopen the ticket with a comment to that effect.

Thanks!

On Tue, 23 Aug 2022 at 14:16, Carsten Fuchs  wrote:

> Dear group,
>
> ticket https://code.djangoproject.com/ticket/33904 was closed with
> https://code.djangoproject.com/changeset/0756c61f2ada56e4ae625589099c0141a77737eb/
>
> However, it seems that that commit has a fix for #33893, not for #33904 ?
>
> Best regards,
> Carsten
>
> --
> 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/82eabdca-b66a-6c70-8156-c664969bfffa%40cafu.de
> .
>

-- 
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/CAJwKpySaOMo4EKGbhpOhR%3DQN_zSnJuYD%3DTe3Bbc2G_chffcA%3Dw%40mail.gmail.com.

Re: Make timeout property for PasswordResetTokenGenerator

[Carlton Gibson]

Yes, likely.

My point was (merely) that we **don't** want to add
additional extension points to PasswordResetTokenGenerator.

On Tue, 23 Aug 2022 at 12:58, Roger Gammans 
wrote:

> Hi
>
> If it's intended as a reference implementation, then I would expect
> PasswordResetTokenGenerator  to use Signer or TimestampSigner internally
> , but I was surprised to discover that it didn't use either.
>
> Isn't those entry points the better API to advise for use rather than the
> direct use of hmac based algorithms?
>
> On Tue, 2022-08-23 at 12:45 +0200, Carlton Gibson wrote:
>
> Hi Alexander.
>
> I think the point from ticket #30423 is that we don't want to complicate
> PasswordResetTokenGenerator in order to make it into a more general
> purpose token generator.
> Much better is for you to take inspiration from it to implement what you
> need in your project. (It's the underlying signing code that you really
> want to lean on Django for.)
>
> Kind Regards,
>
> Carlton
>
> On Mon, 22 Aug 2022 at 17:26, Alexander Voloshchenko <
> voloshchenkoalexan...@gmail.com> wrote:
>
> During project development our team needs to create several types of
> tokens. One of them will be used in case of account reset password. The
> second one is for account activation. Django itself has a good class for
> token generation called PasswordResetTokenGenerator. And now for account
> activation, we are using our own class called ActivationTokenGenerator, a
> subclass of PasswordResetTokenGenerator with overridden _make_hash_value 
> method.
> And it works, but there is one problem. And this problem is called
> "timeout". For now, every token created with PasswordResetTokenGenerator will
> have timeout from settings.PASSWORD_RESET_TIMEOUT variable and can be
> changed only by changing this variable value. But what if we need different
> timeouts for different tokens? And I don't think we want changing timeout
> for *activation* token using a variable which is screaming about *password
> reset* (PASSWORD_RESET_TIMEOUT), we would like to use smth called
> ACTIVATION_TOKEN_TIMEOUT
> So there is a solution: why not create a timeout property for
> PasswordResetTokenGenerator class? Almost in the same way as it was done
> with _secret and algorithm fields.So our development team come up with an
> idea to create a PR which will add this functionality to the Django
> project. But before this we decided to search similar solutions in django
> PRs. And we found them! Ticket 30423
> https://code.djangoproject.com/ticket/30423 sounds good enough, but it
> was closed with wontfix label.So the question is: why not to add this
> fine feature to the PasswordResetTokenGenerator ? And if people find this
> useful - why not to merge one o the existing PRs?
>
> --
> 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/6458aad7056857164d976b1c7ce46bcd0249d292.camel%40gammascience.co.uk
> <https://groups.google.com/d/msgid/django-developers/6458aad7056857164d976b1c7ce46bcd0249d292.camel%40gammascience.co.uk?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/CAJwKpyTL8n2wDqcA0TY33uZ_F3iro-NYw8vj_Mp4Y_htDqfHvw%40mail.gmail.com.

Re: Make timeout property for PasswordResetTokenGenerator

[Carlton Gibson]

Hi Alexander.

I think the point from ticket #30423 is that we don't want to complicate
PasswordResetTokenGenerator in order to make it into a more general
purpose token generator.
Much better is for you to take inspiration from it to implement what you
need in your project. (It's the underlying signing code that you really
want to lean on Django for.)

Kind Regards,

Carlton

On Mon, 22 Aug 2022 at 17:26, Alexander Voloshchenko <
voloshchenkoalexan...@gmail.com> wrote:

> During project development our team needs to create several types of
> tokens. One of them will be used in case of account reset password. The
> second one is for account activation. Django itself has a good class for
> token generation called PasswordResetTokenGenerator. And now for account
> activation, we are using our own class called ActivationTokenGenerator, a
> subclass of PasswordResetTokenGenerator with overridden _make_hash_value 
> method.
> And it works, but there is one problem. And this problem is called
> "timeout". For now, every token created with PasswordResetTokenGenerator will
> have timeout from settings.PASSWORD_RESET_TIMEOUT variable and can be
> changed only by changing this variable value. But what if we need different
> timeouts for different tokens? And I don't think we want changing timeout
> for *activation* token using a variable which is screaming about *password
> reset* (PASSWORD_RESET_TIMEOUT), we would like to use smth called
> ACTIVATION_TOKEN_TIMEOUT
> So there is a solution: why not create a timeout property for
> PasswordResetTokenGenerator class? Almost in the same way as it was done
> with _secret and algorithm fields.So our development team come up with an
> idea to create a PR which will add this functionality to the Django
> project. But before this we decided to search similar solutions in django
> PRs. And we found them! Ticket 30423
> https://code.djangoproject.com/ticket/30423 sounds good enough, but it
> was closed with wontfix label.So the question is: why not to add this
> fine feature to the PasswordResetTokenGenerator ? And if people find this
> useful - why not to merge one o the existing PRs?
>
> --
> 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/4f810acc-f2b4-4931-a84e-a59332a825f1n%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/CAJwKpyTkzLNe9sWNVGKfMBvGwxCOKEDzr4EVHhHySo9ddXzXNw%40mail.gmail.com.

Re: transaction.on_commit() proposal

[Carlton Gibson]

Related ticket from this weekend, suggesting a docs change:
https://code.djangoproject.com/ticket/33939

On Mon, 22 Aug 2022 at 14:11, 'Adam Johnson' via Django developers
(Contributions to Django itself)  wrote:

> Hi
>
> I just wrote a blog post on a late-binding bug that can occur with using
> transaction.on_commit() with a function or lambda within a loop. THe post
> shows how using functools.partial() solves this. See the post here:
> https://adamj.eu/tech/2022/08/22/use-partial-with-djangos-transaction-on-commit/
>
> I propose that transaction.on_commit() be modified to take args and kwargs
> to pass to the callback function. This would mean it effectively constructs
> a partial() "under the hood":
>
> transaction.on_commit(send_mail, subject=f"...",
> recipient_list=[user.email], ...)
>
> I think this would be simpler than asking developers to beware of the
> late-binding problem and use partial(), always or when appropriate.
>
> This change would make transaction.on_commit() similar to Python's
> atexit.register(), which also takes a callback to run at a later point, and
> optional args/kwargs to pass it:
> https://docs.python.org/3.10/library/atexit.html#atexit.register
>
> The only backwards-compatibility concern I can see is the `using`
> argument, which would not be passed to the underlying function. I don't see
> this as a huge concern, since it would be the only argument that isn't
> passed through, and there doesn't seem to be any reason to add further
> arguments. Users who need to pass a kwarg called 'using' could always
> construct a partial() themselves.
>
> Thoughts?
>
> 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/CAMyDDM2OQoj3mV4pHuo8OB%2BLM6xpZdLQdSTyaGR%2B1m5oPg-C7Q%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/CAJwKpyTBmLTR8cLbOMWFmm-y47jH1Jki48BF57cvM%3DKPpjNGHw%40mail.gmail.com.

Re: Feature Request: get_default_backend() in django.template.Engine

[Carlton Gibson]

Hi Peter. 

I agree with you that the documentation isn't that clear here. *"Why are 
there two template classes?", "Why does one take a dict and the other a 
Context?"* — that comes up. 🙂

I don't think your suggestion itself it that unreasonable, but I'm wary 
about expanding the API here, at least before exploring other options. 

The current get_default() behaviour was only added to allow folks manually 
creating `Template("My String")` instances to continue to operate with 
multiple Django backends defined (#27359 
) — the initial assumption 
there was that anonymous backend usage wouldn't be supported, i.e. that 
folks would do `engines["django"]` to get a specific backend.  Could you 
use that? 

If you've got a traditional Template (expecting a Context) can't you just 
provide one, via the make_context helper if needed? 
You already know here that you want a DjangoTemplate backend, we know we 
get that, so why the need for backend-neutral dict-taking Template? 
(It doesn't look like we need that?)

I guess, can you explain more about how the use-case comes up here? #27359 
was a while back now so we might exposing a new hook to have come up more 
quickly. 

Thanks. 

Kind Regards,

Carlton



On Thursday, 11 August 2022 at 20:44:06 UTC+2 homa...@gmail.com wrote:

> Hi,
>
> We're trying to create a template from string using 
> DjangoTemplates.from_string() of the default template backend, which wraps 
> the result of Engine.from_string() to construct an instance of the Template 
> class defined in the backend definition file: 
> django/template/backends/django.py#30
>
> This Template class differs from the Engine-delivered Template in that it 
> accepts a dictionary as the context, see 
> https://docs.djangoproject.com/en/4.0/topics/templates/#django.template.backends.base.Template.render
> .
>
> The default backend's engine is easily retrieved via 
> django.template.Engine.get_default(). This function identifies the first 
> configured DjangoTemplates backend, and then returns its .engine attribute. 
> As a result, when from_string() is called, it will be called on the engine 
> and not on the backend, thus the wrapping Template() call is missing.
>
> I would like to propose adding a get_default_backend() function to 
> django.template.Engine, which is like get_default(), but returns the 
> backend itself (and not its .engine attribute). get_default() can then be 
> adjusted to simply return get_default_backend().engine.
>
> While trying to solve the issue (context argument type mismatch: dict vs 
> Context), I found the docs not very helpful, as they are not very accurate 
> in the distinction between a backend and its engine. I've also added a 
> commit that clarifies that language.
>
> I have submitted a patch here: https://github.com/django/django/pull/15944
>
>
> FWIW, the problem can also be solved on the application layer, like:
>
> def get_default_template_backend():
> # Ad-hoc implementation of https://github.com/django/django/pull/15944
> from django.template import engines
> for backend in engines.all():
> if isinstance(backend, DjangoTemplates):
> return backend
> raise ImproperlyConfigured("No DjangoTemplates backend is configured.")
>
> However and IMHO, this needlessly duplicates the logic from get_default() 
> and adds undue complication to the app (like having to know about and 
> looping over the .all() iterable; raising the exception), whereas that 
> complexity already is in the core.
>
>
> Please let me know what you think!
>
> Thanks,
> Peter
>
> -- 
> https://desec.io/
>

-- 
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/815e0c04-ae16-4502-8792-6a3551d7d260n%40googlegroups.com.

Re: More user friendly delete confirmation template

[Carlton Gibson]

Sounds good.

(You mentioned adding an additional template block. You could put that in a
commit to look at as well if you think it's of value to you.)

On Wed, 17 Aug 2022 at 08:14, Jacob Rief  wrote:

> On Wednesday, August 17, 2022 at 7:23:35 AM UTC+2 Carlton Gibson wrote:
>
>> > Can we at least agree to put an id="..." onto the  element
>> wrapping that list.
>>
>> That seems pretty minimal. 🙂  Do you want to open a PR so we can have a
>> look?
>>
>
> Okay, will do that.
> Any suggestions for a name? My proposal is id="deleted-objects".
>
> – Jacob
>
>
> --
> 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/5dd47fd5-adcb-4a28-934f-8d132c3c540cn%40googlegroups.com
> <https://groups.google.com/d/msgid/django-developers/5dd47fd5-adcb-4a28-934f-8d132c3c540cn%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/CAJwKpyQJVyeTP-Z%3D%3DEGM0t%3D%2BW2%3D0xLVM5fGs%3DL9S%3D%2BTpfFTrZw%40mail.gmail.com.

Re: More user friendly delete confirmation template

[Carlton Gibson]

> Can we at least agree to put an id="..." onto the  element wrapping
that list.

That seems pretty minimal. 🙂  Do you want to open a PR so we can have a
look?

On Tue, 16 Aug 2022 at 21:58, Jacob Rief  wrote:

> Can we at least agree to put an id="..." onto the  element wrapping
> that list.
> That would help me to add some JS and CSS to the overwritten
> delete_selected_confirmation template without
> having to copy a huge block of HTML code from that template.
>
> – Jacob
>
> --
> 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/1bbb2f37-765d-4bcf-83d6-7ddc04dd5edcn%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/CAJwKpySp2t%2BCwMJ5Cea7Br8fE%2B9fBk7h7cEUh_cEme96ceF4ww%40mail.gmail.com.

Re: More user friendly delete confirmation template

[Carlton Gibson]

These kinds of UI features are quite "maintenance-heavy" — they're hard to
test, and fragile — and so can consume a lot of time in review, perhaps
disproportionate, perhaps not. That on-top of Adam's points mean I'd lean
to -1 to begin. Maybe that's not the final answer, but I'd look for another
way first. (The particular change here isn't likely too difficult, but
that's the opening bias)

Then as Maxim points out, this is already possible with overriding the
template.

*But we don't really show how to do that*.
(I'm looking forward to Maxim's DjangoCon talk,
 partly for
this reason.)

I wonder if a *HowTo* in the docs on patterns for customising the admin,
beginning with the "The Admin is not your app" reminder, but showing how
you might override a template or two, or add a rich JS widget to a form, or
... (there are a few *kinds* of use-cases that come up I think)... — would
be a useful resource?
I've always had to search for a while each time I've wanted to do this in
the past.

To me this would seem like something we could add without needing to expand
the built-in functionality too much.

Kind regards,
Carlton


On Tue, 16 Aug 2022 at 15:54, 'Adam Johnson' via Django developers
(Contributions to Django itself)  wrote:

> The admin interface is not designed for such mass deletions. When deleting
> millions of objects, it can be necessary to paginate the deletion to avoid
> exhausting the resources of your database server. I don't think it's
> suitable for a view to try and do this.
>
> Btw in the case of sessions, use the 'clearsessions' management command:
> https://docs.djangoproject.com/en/4.1/ref/django-admin/#clearsessions .
> In the case of admin logs, I would use 'shell' with the ORM.
>
>
>
> On Tue, Aug 16, 2022 at 2:42 PM Danilov Maxim  wrote:
>
>> >> Collapsing the list of to-be-deleted objects could also lead to cases
>> of accidental removal of related objects. I think it's better to err on the
>> side of overwhelming than hiding information.
>>
>>
>>
>> But sometimes It is very painful to delete whole list of sessions (
>> database-backed
>> 
>> sessions) (4mlo) or Django admin logs (66mlo).
>>
>>
>>
>>
>>
>> Mit freundlichen Grüßen,
>>
>> DI Mag. Maxim Danilov
>>
>>
>>
>> +43(681)207 447 76 <+43(681)207%20447%2076>
>>
>> ma...@wpsoft.at
>>
>>
>>
>> *From:* 'Adam Johnson' via Django developers (Contributions to Django
>> itself) [mailto:django-developers@googlegroups.com]
>> *Sent:* Tuesday, August 16, 2022 2:55 PM
>> *To:* Django developers (Contributions to Django itself) <
>> django-developers@googlegroups.com>
>> *Subject:* Re: More user friendly delete confirmation template
>>
>>
>>
>> If the object to be deleted contains many relations, the user
>> is overwhelmed with a list of other objects to be deleted together with the
>> current object. Often those objects are just internal relations the user
>> never heard of, and this may be unsettling.
>>
>>
>>
>> I would argue that if the list of objects is "overwhelming" /
>> "unsettling", then this is perhaps an indicator that the admin interface is
>> being used beyond its intended scope. The admin is designed for site
>> administrators, mostly developers. Yes, most projects seem to push it
>> beyond that, but we can't make it something for all people.
>>
>>
>>
>> Collapsing the list of to-be-deleted objects could also lead to cases of
>> accidental removal of related objects. I think it's better to err on the
>> side of overwhelming than hiding information.
>>
>>
>>
>> On Tue, Aug 16, 2022 at 1:22 PM Danilov Maxim  wrote:
>>
>> Hi Jacob.
>>
>> On the one side - you can override this delete_confirmation.html and
>> delete_selected_confirmation.html I do it since dj 1.4
>>
>>
>>
>> On the other side I am agree with Jacob - it can be in Django by default.
>> – We can add “collapsed” div to wrap  with every objects list, or we
>> can add details/summary for that.
>>
>>
>>
>> Mit freundlichen Grüßen,
>>
>> DI Mag. Maxim Danilov
>>
>>
>>
>> +43(681)207 447 76 <+43(681)207%20447%2076>
>>
>> ma...@wpsoft.at
>>
>>
>>
>> *From:* django-developers@googlegroups.com [mailto:
>> django-developers@googlegroups.com] *On Behalf Of *Jacob Rief
>> *Sent:* Tuesday, August 16, 2022 1:57 PM
>> *To:* Django developers (Contributions to Django itself) <
>> django-developers@googlegroups.com>
>> *Subject:* More user friendly delete confirmation template
>>
>>
>>
>> Whenever a user attempts to delete an object inside the Django admin,
>>
>> a delete confirmation page is shown. If the object to be deleted contains
>>
>> many relations, the user is overwhelmed with a list of other objects to be
>>
>> deleted together with the current object. Often those objects are just
>>
>> internal relations the user never heard of, and this may be unsettling.
>>
>>
>>
>> I therefore propose to hide those related objects beh

Django 4.1 released

[Carlton Gibson]

Details are available on the Django project weblog:

https://www.djangoproject.com/weblog/2022/aug/03/django-41-released/

-- 
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/CAJwKpyR3GRReA1qdshq-eNERRTQUHMHznCiLeBntVNoLZ6_kiQ%40mail.gmail.com.

Django security releases issued: 4.0.7 and 3.2.15.

[Carlton Gibson]

Details are available on the Django project weblog:

https://www.djangoproject.com/weblog/2022/aug/03/security-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/CAJwKpyRZNynRNTqRnE7HCUpNk0Yh1DRg8UUyDZ%2BzFc0pzpcg9g%40mail.gmail.com.

Re: timesince and timeuntil - should we use python-dateutil?

[Carlton Gibson]

Hey Uri.

Historically, taking on extra dependencies isn't something we've done
lightly.
The packaging situation is a lot better these days than it was in
earlier years, but with the concerns about supply chain security I think
maintaining that position is worthwhile.
If we were to take on python-dateutil as a required dependency there would
be folks needing to go through an additional security audit in order to get
permission to upgrade Django. I wouldn't think two template tags justifies
that.

So then, it would need to be optional.
But then it could just live in a third-party package.
(I don't think we really document it, but one could shadow/override the
built-in tags with the improved versions if your app was installed, I
guess...)

Or that would be my initial thought. 🤔

Kind Regards,

Carlton


‪On Tue, 2 Aug 2022 at 03:27, ‫אורי‬‎  wrote:‬

> Hi,
>
> Lately I discovered some inaccuracy bugs in timesince (and timeuntil), and
> I created a ticket (#33879 ).
> In short, the problems are when calculating a year minus one week, 2 weeks,
> one day etc. and also 2 years minus one or 2 days. In all such cases,
> Django's implementation of timesince is inaccurate, in some cases resulting
> in "1 year, 12 months" (for 2 years minus one or 2 days) or adding a week
> (for a year minus one or 2 weeks). I read the code of Django's timesince
> implementation and it's quite long, and I searched and found
> that python-dateutil already have such methods, which is possible to
> calculate exactly the number of days between two dates like this:
>
>
>
>
>
>
>
>
> *from dateutil.relativedelta import relativedeltadiff =
> relativedelta(date2, date1)years = diff.yearsmonths = diff.monthsweeks =
> diff.days // 7days = diff.days - weeks * 7 # ("**diff.days % 7" will also
> work here)*
>
> This calculates exactly the number of years, months, weeks and days and
> not an approximation like Django's implementation. And python-dateutil is
> stable and I think exists even before Django. I recently started using
> Django's timesince function in my own website, and I like the way it's
> translated (currently only to English and Hebrew). Do you think it's worth
> using python-dateutil in the Django implementation of timesince and
> timeuntil?
>
> Of course, I can also implement my own version of timesince which
> uses python-dateutil and doesn't use Django. But since timesince and
> timeuntil are built-in tags in Django, I guess many websites are using
> them. Isn't it better to use a more precise implementation and avoid
> something like "1 year, 12 months"?
>
> Thanks,
> Uri Rodberg, Speedy Net
> אורי
> u...@speedy.net
>
> --
> 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/CABD5YeEC_o%2BwQVF8pj3Kat57MXfX071LT0rZAq2XipFFCK%3DFBQ%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/CAJwKpyTwuAQvq%2BwB3Pv_HfSBHiZLf2gq3nCPmYGVrvyCY2GfmA%40mail.gmail.com.

Re: Switching to PEP 621 project metadata

[Carlton Gibson]

Hey Ofek.

On Mon, 25 Jul 2022 at 17:04, Ofek Lev  wrote:

> > I'd much rather let the bulk of smaller projects adopt, and iron out the
> details, and then update when it's a better beaten track.
>
> Can we please quantify such heuristics? I want something concrete to write
> in my OSS to-do list :)
>

Well, I guess A decent number™ of projects in the Django eco-system, would
do. (No I'm not saying how many :)

But if you were to offer updating Jazzband projects, and that all went
smooth, then that would directly feed into people here knowing more about
the state of play.

Also, I'd be happy to look at this for the Channels Trio
(Channels/Daphne/Channels Redis. I'm working on updates for all of those
now.
I did have Flit in mind... so my first question would be why Hatch rather
than that? — But if you were prepared to discuss that I'd be appreciative
of the contribution.

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/CAJwKpyS252oFWvDzo3-FtR8Qk6AFuKnKD-5CaNZt3ULTdakA4g%40mail.gmail.com.

Re: Switching to PEP 621 project metadata

[Carlton Gibson]

I think we need to be very cautious. Anecdotally, I've seen folks hitting
issues trying to adopt the new methods, and I don't see any upside to
Django being an earlier adopter here.

We were slow adopting PEP 517 and still had regressions reported:

https://github.com/django/django/pull/12013
https://github.com/django/django/pull/13994

I'd much rather let the bulk of smaller projects adopt, and iron out the
details, and then update when it's a better beaten track.

On the particulars, I'm sure Hatchling is great, but it's not at all clear
(from here — to me) that it's mature enough to trust Django with. It seems
the packaging options are emerging very quickly (which is great) but I'd
like the current (evolutionarily) explosive period to settle some, so we
can see the long-term survivors going forward before we jump.

With setup.py, I think for a project like Django, there's a certain value
in being second-to-last off the boat.

Kind regards,
Carlton


On Sun, 24 Jul 2022 at 22:39, James Bennett  wrote:

> On Sun, Jul 24, 2022 at 1:34 PM Ofek Lev  wrote:
>
>> > My initial reaction is "no", and that this request kind of rubs me the
>> wrong way. In the pull request you say [...] But the blog post you quote is
>> just saying to run "python -m build" instead of "python setup.py"
>>
>> This issue is that the `python -m build`/PEP 517 way does not support the
>> deprecated RPM logic. I tried to articulate that as best as I could; I'm
>> sorry if it wasn't clear!
>
>
> We can run `python -m build` pretty much as-is using setuptools as the
> build backend, though, and that suffices for Django's packaging needs.
>
> I'm not familiar with what happened with black but I think you might be
>> referencing how the recommended style was in flux for a time.
>>
>
> I am referring to the multiple occasions on which black's approach to
> packaging caused installation of the package, via pip, to fail in often
> mysterious ways.
>
> This is something that's documented in the history of their issue tracker,
> and that the maintainers have since apologized for and adopted policies to
> try to prevent in the future.
>
>> --
> 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/CAL13Cg_F1JxY5ANKw53LvEYc8_JjJGb_%2BSs-dZ2YxWr_tRw1Vw%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/CAJwKpyTvKDGEnO2RQM3yhB9UJ_YLhaZJYmwdLmjBhd5MFPDW-w%40mail.gmail.com.

Django 4.1 release candidate 1 released

[Carlton Gibson]

Details are available on the Django project weblog:

https://www.djangoproject.com/weblog/2022/jul/19/django-41-rc1/

-- 
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/CAJwKpyQLcPLJa-0qxbmhcM55OPaoz74F7fL%2BE2mwqs9crG0pJg%40mail.gmail.com.

Re: (Circa end of 2021) Localization issues with input type=date?

[Carlton Gibson]

Thanks Denny.

I'll follow-up on the PR. Let's see what folks have to say.
👍

Kind Regards,

Carlton

On Wed, 29 Jun 2022 at 22:20, Denny Biasiolli 
wrote:

> Hi Carlton,
>
> Here we go: https://github.com/django/django/pull/15806
> Just a draft for now, tried on a local Django project with a test model
> using Date, Time and DateTime fields.
>
> I'm thinking to backward compatibility for custom admin templates, any
> thoughts?
>
> Thanks
>
> Denny
> On Wednesday, June 29, 2022 at 10:20:43 AM UTC+2 carlton...@gmail.com
> wrote:
>
>> Hey Denny.
>>
>> Thanks for looking at this!
>>
>> > My idea was to change...
>>
>> Can I get you to put that into a (draft) PR on GitHub? It's much easier
>> to think about with code in hand. :)
>>
>> Kind Regards,
>>
>> Carlton
>>
>> On Tuesday, 28 June 2022 at 18:47:57 UTC+2 denny.b...@gmail.com wrote:
>>
>>> Hi everyone,
>>>
>>> I just arrived on this topic searching for ideas about improving the
>>> admin datetime format.
>>> I noticed that datetime values are passed between to/from the admin form
>>> using the format defined in settings, but as you mentioned, this could be a
>>> problem when users from different timezones are using the admin interface.
>>>
>>> I'd like to contribute to this, and I can suggest to use an iso format
>>> (used in input type "date", "datetime-local" and "time") to pass data, so
>>> all formatting problems can be avoided.
>>>
>>> My idea was to change the `localize_input` function to return
>>> `value.isoformat()` when `isinstance(value, (datetime.datetime,
>>> datetime.date, datetime.time))`.
>>> After this we can customize the attrs of `AdminDateWidget`,
>>> `AdminTimeWidget` (and eventually add a `AdminDateTimeWidget`)
>>> passing the correct input type (`date`, `time` or `datetime-local`).
>>>
>>> Any other idea?
>>> On Tuesday, October 12, 2021 at 3:22:41 PM UTC+2 carlton...@gmail.com
>>> wrote:
>>>
 Thank you all, yes — there's some good points there. (Some others
 raised on the PR and the ticket too.)

 It's looks like there are still some caveats, and describing those
 succinctly remains to do.
 👍

 Kind Regards,

 Carlton


 On Wednesday, 29 September 2021 at 21:13:51 UTC+2 Tobias Bengfort wrote:

> > Back then there were various issues with localisation when **not**
> using type=text.
>
> As https://code.djangoproject.com/ticket/16630#comment:11 states: the
> inputs only accept a special format. To make it work I had to
> explicitly
> set the format: `DateInput(format='%Y-%m-%d', attrs={'type': 'date'}`.
>
> Another thing to be aware of: The native date picker UI uses the
> system/browser locale, not the one that is used on the page. (See also
> https://bugs.chromium.org/p/chromium/issues/detail?id=263320)
>
> Hope that helps
>
> tobias
>
 --
> 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/59eeae49-9670-4276-8543-fa93e85a86b0n%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/CAJwKpyTUW2FRafwTWA1ms0r3bkAwmqytShivMBbFVUa_cseNUQ%40mail.gmail.com.

Re: (Circa end of 2021) Localization issues with input type=date?

[Carlton Gibson]

Hey Denny. 

Thanks for looking at this! 

> My idea was to change...

Can I get you to put that into a (draft) PR on GitHub? It's much easier to 
think about with code in hand. :) 

Kind Regards,

Carlton

On Tuesday, 28 June 2022 at 18:47:57 UTC+2 denny.b...@gmail.com wrote:

> Hi everyone,
>
> I just arrived on this topic searching for ideas about improving the admin 
> datetime format.
> I noticed that datetime values are passed between to/from the admin form 
> using the format defined in settings, but as you mentioned, this could be a 
> problem when users from different timezones are using the admin interface.
>
> I'd like to contribute to this, and I can suggest to use an iso format 
> (used in input type "date", "datetime-local" and "time") to pass data, so 
> all formatting problems can be avoided.
>
> My idea was to change the `localize_input` function to return 
> `value.isoformat()` when `isinstance(value, (datetime.datetime, 
> datetime.date, datetime.time))`.
> After this we can customize the attrs of `AdminDateWidget`, 
> `AdminTimeWidget` (and eventually add a `AdminDateTimeWidget`)
> passing the correct input type (`date`, `time` or `datetime-local`).
>
> Any other idea?
> On Tuesday, October 12, 2021 at 3:22:41 PM UTC+2 carlton...@gmail.com 
> wrote:
>
>> Thank you all, yes — there's some good points there. (Some others raised 
>> on the PR and the ticket too.) 
>>
>> It's looks like there are still some caveats, and describing those 
>> succinctly remains to do. 
>> 👍
>>
>> Kind Regards,
>>
>> Carlton
>>
>>
>> On Wednesday, 29 September 2021 at 21:13:51 UTC+2 Tobias Bengfort wrote:
>>
>>> > Back then there were various issues with localisation when **not** 
>>> using type=text. 
>>>
>>> As https://code.djangoproject.com/ticket/16630#comment:11 states: the 
>>> inputs only accept a special format. To make it work I had to explicitly 
>>> set the format: `DateInput(format='%Y-%m-%d', attrs={'type': 'date'}`. 
>>>
>>> Another thing to be aware of: The native date picker UI uses the 
>>> system/browser locale, not the one that is used on the page. (See also 
>>> https://bugs.chromium.org/p/chromium/issues/detail?id=263320) 
>>>
>>> Hope that helps 
>>>
>>> tobias 
>>>
>>

-- 
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/3ae9b51d-f731-44c2-a90b-7fc2092e3b78n%40googlegroups.com.

Re: JsonResponse have a DEFAULT_JSON_ENCODER setting

[Carlton Gibson]

This is talking about HTTP responses, rather than fields, but I agree with
Adam here: you should be able to encapsulate overriding the default encoder
in a single location. It doesn't need a setting.

On Thu, 23 Jun 2022 at 23:57, 'Adam Johnson' via Django developers
(Contributions to Django itself)  wrote:

> I don't think that's necessary, you can create a subclass of JSONField
> with the encoder you want, or even faster use functools.partial() as I
> blogged about here:
> https://adamj.eu/tech/2021/05/05/3-uses-for-functools-partial-in-django/#making-reusable-fields-without-subclassing
>
> On Thu, Jun 23, 2022 at 9:11 PM Steve Jorgensen 
> wrote:
>
>> I think that seems like a good thing to be able to configure.
>>
>> On Thursday, June 23, 2022 at 7:54:56 AM UTC-7 Fab wrote:
>>
>>> Hey,
>>>
>>> With JsonResponse instead of the encoder defaulting to DjangoJSONEncoder
>>> I was thinking it would be nice to have a setting like DEFAULT_JSON_ENCODER
>>> so I can set another one if needed without having to change all my usages
>>> already set.
>>>
>>>
>>> https://github.com/django/django/blob/0dd29209091280ccf34e07c9468746c396b7778e/django/http/response.py#L676
>>>
>>> Is there any reason not to do this? Feels like it wont break backwards
>>> compatibility.
>>>
>>> Regards,
>>>
>>> Fab
>>>
>> --
>> 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/0eff9638-f455-4a64-a507-b47c6bd2cff0n%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/CAMyDDM2DzWneRNCHk0psdinCehJmvw71PSw1Fh5RBfYcsZktww%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/CAJwKpyQq9Ou5n%3D%2BvgWZEeBLjBysuyN-ONFAvrNzkU57kJffUSQ%40mail.gmail.com.

Django 4.1 beta 1 released

[Carlton Gibson]

Details are available on the Django project weblog:

https://www.djangoproject.com/weblog/2022/jun/21/django-41-beta-1-released/

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

Re: Decision on a 2FA PR

[Carlton Gibson]

Hi Yonas. 

Thanks for your input here. 

Two points:  

   - I *think* one reason Django doesn't already have 2fa itself is that 
   available methods have (up to now) each been problematic in their own way. 
   The trouble with adding a sub-optimal approach into Django is that we're 
   essentially stuck with it forever. We can't realistically add an option, 
   have it widely adopted and then say, "Oh, actually, we're deprecating this, 
   use New Hotness™ instead" — that's not what folks use Django for. So, when 
   this has come up before, the answer has generally been to keep 
   implementations in third-party packages, of which there are several 
   options. 
   - It *looks* like WebAuthn (and the whole Fido Alliance grouping 
   ) is the way forward now. Per-device keys, 
   stored in secure enclaves, with biometric authentication, and OS-level and 
   password manager app-level integrations, etc. **This** is what we should be 
   integrating no? (This is a solution, finally we can agree is robust enough 
   no?)

Maybe either of those points are wrong but, I'd rather see effort going 
into "What does WebAuthn in Django look like?" — answering that would be a 
major contribution. 

Kind Regards,

Carlton



On Sunday, 5 June 2022 at 19:48:22 UTC+2 Yonas wrote:

> Hi,
>
> In light of what happened to the ctx package, this is a good time to get a 
> conclusion on the following topic.
>
> I opened a PR  based on an 
> accepted ticket  and a 
> discussion . 
> The PR implements 2fa but excludes WebAuthn, leaving it out as an 
> alternative to Django password-based auth. But an idea on GitHub was 
> forwarded that the PR won’t be accepted without at least supporting 
> WebAuthn.
>
> While 2fa is one use case of WebAuthn, the primary use case, in my 
> opinion, is providing an alternative to or a replacement for password-based 
> authentication. Regardless of its use case, the implementation of WebAuthn 
> does not have a lot in common with the opened PR. 
>
> Instead of taking the all-or-nothing approach, doesn’t it make more sense 
> to work on the opened PR--making Django more secure--and support WebAuthn 
> when someone in the future opens a PR for either or both of the use cases?
>
> Thanks!
>

-- 
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/898b0499-d201-47a7-8bfd-4d026aeeafbbn%40googlegroups.com.

Re: Feature Idea: Allow setting session cookie name dynamically

[Carlton Gibson]

Hey Dan.

Thanks for following up here.

Just to recap, my reasoning on the ticket was that it's quite a niche
use-case. For me, just use the custom SessionMiddleware, or put that in a
third-party package for multi-tenancy folks to maintain together. (Or so
would be my opening thought... -- interested to see others' thoughts.)

Kind regards,
Carlton

Aside: Searching, there are lots of disparate resources for multi-tenant
deploys; slightly orthogonal to your exact suggestion here, I imagine
there's good work to be done corralling the interested parties and
patterns. Maybe one of the existing resources already does this... 🤔




On Thu, 2 Jun 2022 at 14:47, Dan Strokirk  wrote:

> Hi,
>
> Currently it's only possible to use a single session cookie, but it can be
> useful in a multi-tenant application to use multiple session cookies. To
> solve this we currently use our own, slightly modified SessionMiddleware
> class that we keep in sync with the official implementation and re-apply
> the patch during each Django upgrade.
>
>
> Proposal: Adding a new get_cookie_name or get_cookie_params method to
> the SessionMiddleware class might be one way to implement this, which means
> that you can then then use your own subclassed middleware to easily
> override it. It would take the request and response objects as arguments.
>
> If this seems like a reasonable feature to add I'd be glad to supply a
> patch.
>
> (I've previously submitted a WONTFIX ticket for this, perhaps a little
> over-eager :) https://code.djangoproject.com/ticket/33760)
>
> Best regards,
> Dan
>
> --
> 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/879fbda1-c8f6-4995-a3d0-7b2cbe5bc282n%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/CAJwKpyROabEZPD2N%2BgQfJxGWh4TW%2BiZe1w5O0P8C4aKdS9nHwA%40mail.gmail.com.

Django bugfix release: 4.0.5

[Carlton Gibson]

Details are available on the Django project weblog:

https://www.djangoproject.com/weblog/2022/jun/01/bugfix-release/

-- 
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/CAJwKpyQhY%3DkMzHX-ALZSdUMW8mrxfnCQoY7tX73XTEuBEj5FEQ%40mail.gmail.com.

Re: Django 4.1 alpha 1 released

[Carlton Gibson]

Hi Uri,

Good spot. The docs have `The optional exclude argument lets you provide a
list of field names to exclude from validation.` for `clean_fields()` so
expecting a list seems reasonable. 🤔

This was changed in
https://github.com/django/django/commit/1ea7e3157d1f9b4db71e768d75ea57e47dbd49f9
— it looks like your use-case isn't covered by the existing tests.
Can I ask you to open a ticket on Trac, with a minimal test and we can have
a look?

Thanks! 👍

Kind Regards,

Carlton

‪On Thu, 19 May 2022 at 05:50, ‫אורי‬‎  wrote:‬

> Hi,
>
> In my code there is clean_fields with exclude as an optional argument:
>
> def clean_fields(self, exclude=None):
> """
> Allows to have different slug and username validators for Entity
> and User.
> """
> if (exclude is None):
> exclude = []
>
> Is it still optional and should I define it as a set if it's None? Or is
> it not optional any more?
>
> I see in Django 4.1 alpha this is the code now:
> def clean_fields(self, exclude=None):
> """
> Clean all fields and raise a ValidationError containing a dict
> of all validation errors if any occur.
> """
>     if exclude is None:
> exclude = set()
>
>
>
> אורי
> u...@speedy.net
>
>
> On Wed, May 18, 2022 at 9:09 AM Carlton Gibson 
> wrote:
>
>> Details are available on the Django project weblog:
>>
>>
>> https://www.djangoproject.com/weblog/2022/may/18/django-41-alpha-1-released/
>>
>>
>> --
>> 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/CAJwKpyQmCB6q__p167GcmaH8dBT%3D-jSbtr2LLb_E63E9QRQUXQ%40mail.gmail.com
>> <https://groups.google.com/d/msgid/django-developers/CAJwKpyQmCB6q__p167GcmaH8dBT%3D-jSbtr2LLb_E63E9QRQUXQ%40mail.gmail.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/CABD5YeG9RYV2%2BqKN1_XT%2Bn0%3DJ6W2G0t-OWFBB-pLWQQFvEVJDQ%40mail.gmail.com
> <https://groups.google.com/d/msgid/django-developers/CABD5YeG9RYV2%2BqKN1_XT%2Bn0%3DJ6W2G0t-OWFBB-pLWQQFvEVJDQ%40mail.gmail.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/CAJwKpyTTsPFQWBcnJJTgYzdGTk4Qxt5ef%3Dw%3DdRr%3DQD8Dhnjb%3Dg%40mail.gmail.com.

Django 4.1 alpha 1 released

[Carlton Gibson]

Details are available on the Django project weblog:

https://www.djangoproject.com/weblog/2022/may/18/django-41-alpha-1-released/

-- 
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/CAJwKpyQmCB6q__p167GcmaH8dBT%3D-jSbtr2LLb_E63E9QRQUXQ%40mail.gmail.com.

Re: Performance does not scale when increasing file upload sizes

[Carlton Gibson]

Hi Noxx.

This is interesting, thanks for the write-up.

As a bit of history, initially ASGIRequests would read the whole body into
memory, which was fine for an initial version, but led quickly enough to
resource concerns. Andrew followed up with the SpooledTemporaryFile
approach, as a nice next-step improvement on that. There **was** at the
time some initial work on wrapping the receive queue to consume the body
on-demand, but with the temp-file solution in hand that never got pushed
through. I can very well imagine folks in ASGI-land have had time to get
that right now. (So exciting to look at!)

I'd very much want to dig into a dependency before deciding to take one on.
I suspect it's not **that** complex, so it's likely something we'd want to
re-implement to fit our needs exactly. (But we can see on review...)

Please do open a PR when you're ready.

Kind regards,
Carlton

On Tue, 17 May 2022 at 15:20, 'Noxx' via Django developers (Contributions
to Django itself)  wrote:

> Hi all,
>
> I've played around a bit and would like to give you a heads up:
>
> WSGI and ASGI have only differences in how they parse incoming requests.
> As WSGI is synchronous the body is already provided as a ByteIO stream
> which is set directly on the HTTPRequest (wrapped as a LazyStream).
>
> On ASGI the body is sent in chunks. As the base of HTTPRequest - and this
> includes how to parse the body, POST, FILES etc. - is the same for ASGI and
> WSGI, those chunks need to be joined together prior to any other processing.
> to do this, all chunks are currently written into the SpooledTemporaryFile
> mentioned in my previous post and this file is then provided as a stream to
> the HTTPRequest.
> As already written, this workaround to get all chunks into one stream is
> very slow for requests which are bigger in their size as the temporary file
> is spooled to disc in the worst case.
>
> To workaround this issue, I've tried to delay the reading of the ASGI
> queue to get the next chunk (called "message" in ASGI) until the
> HTTPRequest really needs it.
> As the HTTPRequest/MultiFileParser works on a stream to read and parse its
> body, the idea is to use the ASGI queue as a stream-like object and to
> directly read it.
> This would eliminate the need to create a temporary file as a "proxy".
>
> When I was in the process of implementing this interface, I've recognized
> that the package a2wsgi already handles such use-case:
> https://github.com/abersheeran/a2wsgi/blob/master/a2wsgi/wsgi.py
>
> I've added a2wsgi as a dependency and change the ASGI handler a little bit.
> The changes can be reviewed on my fork:
> https://github.com/Flauschbaellchen/django/commit/006bf2d5c0b82092524ee9b65ef919637165ee01
>
> Timings:
> In my test environment, the timing went from 4s (sending)/16s (waiting) to
> 6s/5s.
> Sending is a bit slower. This is because prior to the change the chunks
> have been read directly into the temporary file and now the parser is doing
> its business between reading new chunks.
> However, those chunks are directly parsed and feed into the upload
> handlers which dramatically improves the performance on the server side.
> Using gunicorn+uvicorn the waiting time went down to ~600ms. I don't know
> why runserver/daphne is so slow. I'll check this within the next days.
>
> I've attached a new flame graph representing my changes.
> The right-most block can be ignored - this is already the next GET request
> of the admin panel after saving the object.
>
> What's next?
> I would appreciate any feedback on my changes.
> Is this the right direction?
> What about the newly introduced dependency? - It would also be possible to
> implement/copy the code on the Django side to eliminate this dependency.
> However, on my opinion, doing things twice is never a good idea...
> Can anyone test against other environments/ASGI servers? Maybe I've
> overlooked some edge cases.
>
> The current changes depends on the version 4.0.4 of Django as on the main
> branch small changes happend to the ASGI handler.
> I'll rebase my changes prior to submitting a PR.
>
> With kind regards :)
>
> On Wednesday, May 11, 2022 at 7:47:10 PM UTC+2 Adam Johnson wrote:
>
>> Ferran - No, this is the right place. Noxx is suggesting a change to
>> Django.
>>
>> Noxx - it seems reasonable to improve Django here. You mentioned ASGI -
>> did you check what the WSGI paths do? It may be that the newer ASGI code is
>> simply less optimal.
>>
>> Would it be possible to reduce the workflow to a single write call?
>>>
>>
>> This is indeed the question. Could you investigate further and perhaps
>> come up with a patch? You're likely "the world expert" on this part of
>> Django at this point, after all the profiling you've done.
>>
>>
>> On Wed, May 11, 2022 at 5:44 PM Ferran Jovell  wrote:
>>
>>> This is still the wrong place. Try django-users mailing list.
>>>
>>> El dc., 11 de maig 2022, 17:53, 'Noxx' via Django developers
>>> (Contributions to Django itself)  va
>>> escriu

Re: Status of 4.1 pre-release.

[Carlton Gibson]

On Wed, 11 May 2022 at 13:53, thinkwel...@gmail.com <
thinkwelldesi...@gmail.com> wrote:

> Will the psycopg3 backend 
> land in time for the 4.1 release?  I'm looking forward to it, as it should
> support PyPy much better than psycopg2 does.
>

No. It's not been worked on recently as far as I know. Next step would be
someone to pick the preliminary work up and push it forward. (A major
feature like that isn't something we'd add to the roster the week before
the feature freeze: we'd likely see it coming the whole release cycle.)

-- 
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/CAJwKpyT5ABcmuSHGbFBqeAcGO4U0McCTTq_%3DySkTa9Pvx4%3D1wQ%40mail.gmail.com.

Re: Status of 4.1 pre-release.

[Carlton Gibson]

Hi Jacob.

I've always taken it that the person reviewing will do the marking. (I.e. I
don't read it as saying, "Find someone to review it and then mark it RFC
yourself", which would contradict the note in the FAQ yes.)

#32559 is on my list. IIRC it was there bar a few last tweaks, so I wanted
(want) to get it resolved.
C.

On Wed, 11 May 2022 at 09:04, Jacob Rief  wrote:

> Hi Carlton,
> there is somehow a contradiction:
> In https://code.djangoproject.com/wiki/Version4.1Roadmap it's written:
>
> Better yet, find someone to review your patch and mark the ticket as
>> "Ready for checkin".
>>
>
> but
> https://docs.djangoproject.com/en/4.0/faq/contributing/#i-m-sure-my-ticket-is-absolutely-100-perfect-can-i-mark-it-as-ready-for-checkin-myself
> states:
>
>
>> ’m sure my ticket is absolutely 100% perfect, can I mark it as “Ready For
>> Checkin” myself?
>>
>> Sorry, no. It’s always better to get another set of eyes on a ticket. If
>> you’re having trouble getting that second set of eyes, see questions above.
>>
>
> I'm actually asking, because of this I left one of my tickets
>  on "Accepted".
>
> Kind Regards,
> Jacob
>
> --
> 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/b4e386d5-b8be-4880-aa29-0c923c986518n%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/CAJwKpyRhcYUPUsd47-N8Prrob%3DbjYo6fDVK%3DsHmVzEMuYk%3DOVA%40mail.gmail.com.

Status of 4.1 pre-release.

[Carlton Gibson]

Hi all. 

Time to begin release process for the next major release, Django 4.1!

It's been an incredible cycle with (again) a staggering number of 
contributions. Thank you everyone! 

The 4.1 feature freeze is scheduled (according to 
https://code.djangoproject.com/wiki/Version4.1Roadmap) for Tuesday May 17. 
I'd 
like to release the alpha that day, but it may be Wednesday or Thursday. 

There have been a number of changes improving the accessibility of the 
default
form rendering (tickets #32338 and #32229) for which there's a deprecation 
and
docs changes pending to round-off. 

We want to get as far as we can on that. It's being worked on here: 
https://github.com/django/django/pull/15665

We also have a couple of release blockers that we'd like to resolve this 
week 
so that we can release clean. 

Both Mariusz and I have a short-list of further tickets that have been
bubbling: we'll get as far as we can on those. We've both been head-down
working hard towards the feature freeze for a number of weeks. It's coming
together well, but all I can say is sorry if your particular ticket doesn't
make it this time. 

As per the roadmap, we have pre-releases through June and July, targeting 
August 3 for Django 4.1 final. 

Please test early and often. 

We will use this thread to inform you of any changes to the schedule. 

Thanks again. It wouldn't be possible without you! 🎁

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/c0c5af4f-9870-4ea3-ae0d-bbdfa66af780n%40googlegroups.com.

Re: Provide a way to pass kwargs when initializing the storage class

[Carlton Gibson]

Hi Jarosław. Thanks for picking this up. 

There seems to be enough support for the general idea here, so worth 
pressing on. 

Let's think about any required deprecations on the PR. (It's easier there 
😅). 

Kind Regards,

Carlton

On Sunday, 24 April 2022 at 01:25:28 UTC+2 jaro...@wygoda.me wrote:

>  I'd like to introduce a file storage registry similar to 
> BaseConnectionHandler (django/utils/connection.py) and EngineHandler 
> (django/template/utils.py).
>
> Example settings.py snippet:
>
> STORAGES = {  # rename to FILE_STORAGES to make it more explictit?
> 'example': {
> 'BACKEND': 'django.core.files.storage.FileSystemStorage',
> 'OPTIONS': {
> 'location': '/example',
> 'base_url': '/example/',
> },
> },
> }
>
> Changes introduced by this pr are backward compatible. Users can still use 
> existing settings to configure static and media storages.
>
> Currently storages can be retrieved from the following objects:
>
> django/core/files/storage.py:
>
> get_storage_class
> DefaultStorage
> default_storage 
>
> django/contrib/staticfiles/storage.py:
>
> ConfiguredStorage
> staticfiles_storage 
>
> What do you think about deprecating them?
>
> ​https://github.com/django/django/pull/15610
>
> FileField can be tackled in a separate pr.
>
> czwartek, 12 listopada 2015 o 11:25:57 UTC+1 ja...@tartarus.org 
> napisał(a):
>
>> On 8 Nov 2015, at 08:31, Marc Tamlyn  wrote: 
>>
>> > I'm definitely in favour of a format allowing multiple storage back 
>> ends referred to by name. For larger sites it is not unusual to manage 
>> files across multiple locations (eg several S3 buckets). The storage param 
>> to FileField would be allowed to be the key, and there would be a 
>> get_storage function like get_cache. 
>>
>> It would remove the assymetry between the default backends and per-field 
>> ones, which does feel a little odd. However I don’t think that’s a strong 
>> enough reason to go for more complicated. Ballooning dictionaries can feel 
>> overwhelming when looking at modern Django settings (for instance, the new 
>> templates configuration is more daunting than it used to be), and as 
>> pointed out, overriding is more fiddly. 
>>
>> For testing, you need to be explicit per-field no matter what, so it’s a 
>> change from an instance to a symbolic reference. The instance is probably a 
>> variable anyway by declaration of the test model, which I suspect is 
>> slightly easier to chase. 
>>
>> So I’d be slightly more in favour of the terse, tuple-based syntax. 
>>
>> J 
>>
>> -- 
>> James Aylett 
>> I make: devfort.com, spacelog.org 
>> Films: talktorex.co.uk 
>> Everything else: tartarus.org/james/ 
>>
>>

-- 
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/48fed52b-4ef4-49d2-8e8d-c3f8550a4731n%40googlegroups.com.