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

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

Re: Disabling dark / light mode UI toggle

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

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

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

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

iated! 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. > > > > Ale

Re: Feedback for my draft proposal

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

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

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

Re: Filtering chosen options

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

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

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

Django security releases issued: 4.1.7, 4.0.10, and 3.2.18

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

Re: Async wrappers in contrib packages

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 fir

Re: Async wrappers in contrib packages

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

Re: Async wrappers in contrib packages

n 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

Re: Multiple instances of DjangoAdmin share the same model LogEntry

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 =

Re: Multiple instances of DjangoAdmin share the same model LogEntry

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`

Re: Multiple instances of DjangoAdmin share the same model LogEntry

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

Re: Proposal for an "Age" PostgreSQL ORM function

>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

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

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

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

t; >> (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 Mc

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

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

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

. *(*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

Re: Backport for ticket 34063?

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

Re: Backport for ticket 34063?

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

Re: Backport for ticket 34063?

he 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

Re: Backport for ticket 34063?

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 whate

Re: Backport for ticket 34063?

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 t

Re: Backport for ticket 34063?

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.

Re: Standalon Django ORM

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

Django bugfix release: 4.1.4

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

Re: Async wrappers in contrib packages

> 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

Re: Potential way forward for DATABASE_URL

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

Re: Integrate dj-database-url into Django

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

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

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

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

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 wrot

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

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

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

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

Re: Integrate dj-database-url into Django

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

Re: Integrate dj-database-url into Django

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-

Re: Async wrappers in contrib packages

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

Re: Integrate dj-database-url into Django

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

Re: Set a reasonable default for EMAIL_TIMEOUT

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

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

Thanks Florian To you and all :) — casting the net wide right now is a good way forward I think. We can scope down for GSoC with some ideas on the table. (Don't be shy folks. :) Kind Regards, Carlton On Wed, 16 Nov 2022 at 19:52, Florian Apolloner wrote: > I do have ideas but no idea about

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

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

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

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

Re: Proposal: Clarify individual members page

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

Re: Proposal: Clarify individual members page

gt; - 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 inclu

Re: Proposal: Clarify individual members page

gt;>>> 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 mor

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

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 &

Re: Proposal: cacheif template tag

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

Re: Proposal: Clarify individual members page

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

Re: Proposal: Clarify individual members page

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

Adjusting DEP 10 "How Django is released" section.

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

Re: Creating internal/admin pages without Models

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

Re: Changing the role of the Technical Board

*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

Re: Model-level validation

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

Re: Making max_length argument optional

t 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

Django security releases issued: 4.1.2, 4.0.8, and 3.2.16

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

Re: Optional URL parameters in django.urls.path

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

Re: Proposal: cacheif template tag

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

Re: Proposal: Add utility class "ClassList"

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

Re: Model-level validation

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

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

uss 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

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. Given that — and the alternative re_path() approach being available — unless there was a particularly

Re: Add support for IDNA 2008

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.

Re: Add support for IDNA 2008

Codepoint('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

Re: Check constraint validation with NULLs

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

Re: Need help on solving an issue

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

Re: Add support for IDNA 2008

Hey Julien. Thanks, OK...  The Python docs have it : > If you need the IDNA 2008 standard from *RFC 5891* and *RFC 5895* , use the

Re: Add support for IDNA 2008

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

Re: Add support for IDNA 2008

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

Re: Make timeout property for PasswordResetTokenGenerator

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

Re: #21978 include production-ready web server

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

Re: #21978 include production-ready web server

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

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

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

Re: Make timeout property for PasswordResetTokenGenerator

ator 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

Re: Make timeout property for PasswordResetTokenGenerator

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

Re: transaction.on_commit() proposal

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 >

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

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

Re: More user friendly delete confirmation template

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

Re: More user friendly delete confirmation template

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

Re: More user friendly delete confirmation template

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

Django 4.1 released

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

Django security releases issued: 4.0.7 and 3.2.15.

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

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

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

Re: Switching to PEP 621 project metadata

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

Re: Switching to PEP 621 project metadata

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

Django 4.1 release candidate 1 released

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

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

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

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

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

Re: JsonResponse have a DEFAULT_JSON_ENCODER setting

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

Django 4.1 beta 1 released

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

Re: Decision on a 2FA PR

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

Re: Feature Idea: Allow setting session cookie name dynamically

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

Django bugfix release: 4.0.5

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

Re: Django 4.1 alpha 1 released

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

Django 4.1 alpha 1 released

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

Re: Performance does not scale when increasing file upload sizes

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

Re: Status of 4.1 pre-release.

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.

Re: Status of 4.1 pre-release.

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

Status of 4.1 pre-release.

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

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

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

  1   2   3   4   5   6   7   8   >