At Florian's suggestion in another thread, I propose that we move further
discussion of the settings refactor to the forum:
https://forum.djangoproject.com/t/settings-refactor/17352
On Wednesday, November 2, 2022 at 2:58:29 PM UTC-4 f.apo...@gmail.com wrote:
> The speckenv example highlights
I started a forum thread on the settings refactor here:
https://forum.djangoproject.com/t/settings-refactor/17352
Regarding the original topic of this thread (
https://code.djangoproject.com/ticket/28236), are we ready to close this as
wontfix? I'm okay not proceeding with it (dj-database-url,
I'd personally like to see better support for safe / N-1 compatible
migrations within Django itself, currently if you do CD / blue-green tower
/ etc. deployments you need to be very careful about the migration
operations that you introduce version-to-version, although I'm not sure
what that
Alright, I'm writing up a review aid that tries to re-explain the actual
changes in the PR I opened before. This document should go over all of the
actual API changes that are exposed to users as well. I believe the API
_is_ correct, and that future settings improvements could rely
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
> 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 Dj
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
> (
(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
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
Big +1 from me, I love the forum. It’s a lot more discoverable and powerful.
On Mon, 28 Nov 2022 at 15:22, '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
I don’t think it’s worth adding support for “instance”. The name “instance”
is used in generic mode view classes because they work with any kind of
object. Since the password change view knows it has a user, it can use the
more specific variable name.
You can add an “instance” property in your
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
I am not sure the db level defaults PR is suitable for a GSoC project at
this point - it’s pretty well developed. I think it could do with some
review and testing form those who are interested.
On Mon, 28 Nov 2022 at 17:10, 'st...@jigsawtech.co.uk' via Django
developers (Contributions to Django
+1 from me
And +1 to using the forum in future
On Tue, 29 Nov 2022 at 00:23, charettes wrote:
> +1 from me as well.
>
> Le lundi 28 novembre 2022 à 08:32:01 UTC-5, carlton...@gmail.com a écrit :
>
>> Hi All.
>>
>> Tom Forbes is currently unable to post to the Google Group here, due to
>>
+1 from me as well.
Le lundi 28 novembre 2022 à 08:32:01 UTC-5, carlton...@gmail.com a écrit :
> 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
eatures.
On Tue, 29 Nov 2022, at 09: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-environmen
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
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
+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
I'd like to see database-level defaults supported in models and migrations:
https://code.djangoproject.com/ticket/470
There's currently a PR open, which replaces an earlier 2020 PR
https://github.com/django/django/pull/16092
It would be a large benefit to those of us practicing continuous
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
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
Hello,
unfortunately, the emails sent by the forum have long prefixes in the subject
lines, e.g.
[Django Forum] [Django Internals/ORM] Multiple Database Switching
That makes the messages easy to filter by mail client software, but comes at
the cost of much visual clutter that is hard to
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
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
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
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
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
Just a small spinoff idea from Adam's suggestion on django-stubs. There is
another package, django-types that started as a fork of django-stubs and
was originally intended to be merged back into it. It removes the need to
use any mypy plugins, making it possible to use type checkers other than
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
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 nicenes
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
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/djan
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
Am 27.11.22 um 13:51 schrieb Raphael G:
So my ask here: how do people feel about moving forward with this
limited scope? Previous discussions talked about wanting a larger scope
for it to get merged into core. I believe that instead targetting a
smaller scope means we can at least provide 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 prop
Thank you, Adam.
I really appreciate your help.
Best
On Saturday, November 26, 2022 at 10:16:45 PM UTC+3 Adam Johnson wrote:
> Hi!
>
> I think you've found the wrong mailing list for this post. This mailing
> list is for discussing the development of Django itself, not for support
> using
Hi Simon,
In addition to what's documented, that's another way annotate() gives the
wrong result.
There are a lot of duplicates of #10060, and there are a lot of people who
run into this issue.
Given the age of the ticket and the lack of a simple backward compatible
solution, what would be
Hi Adam, thanks for the reply. I'll open a ticket and start work on a PR.
Mark
On Sunday, November 27, 2022 at 10:47:01 AM UTC Adam Johnson wrote:
> Your proposal seems reasonable - if actually saving, we should save the
> m2m fields too.
>
> I think the best next step would be to file a
Your proposal seems reasonable - if actually saving, we should save the m2m
fields too.
I think the best next step would be to file a ticket and work on a PR. The
first step would be to add a test case reproducing the issue.
On Wed, Nov 23, 2022 at 4:59 PM Mark Gensler wrote:
> Hello all!
>
>
Hi!
I think you've found the wrong mailing list for this post. This mailing
list is for discussing the development of Django itself, not for support
using Django. This means the discussions of bugs and features in Django
itself, rather than in your code using it. People on this list are unlikely
Hi,
Adding to the above, I have two migration-related ideas.
The first is quite down-to-earth: Support for moving models between
apps. This is a long-standing problem, esp. in enterprise-y or just
long-running projects. I have expressed my dissatisfaction with the
current state of things a
On Fri, Nov 25, 2022 at 2:32 PM 'Adam Johnson' via Django developers 1.
CORS in core
>
> django-cors-headers’ implementation is a bit janky, for example it uses a
> regex to filter paths. It also lacks the key ability to set up different
> CORS policies per path. Both of these could be done with
nd-in-hand with Florian’s suggestion of using
> OpenID Connect.
>
>
>
> *From:* django-developers@googlegroups.com <
> django-developers@googlegroups.com> *On Behalf Of *Carlton Gibson
> *Sent:* Wednesday, November 16, 2022 12:58 PM
> *To:* django-developers@googleg
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
Hi David!
Thanks for double checking my work. Yes, I also see those errors in the
admin. I was guessing that those were related to the primary key issue.
-
Gagan Deep
On Tuesday, November 22, 2022 at 12:03:28 PM UTC+5:30
shang.xia...@gmail.com wrote:
> Hi Gagan,
>
> Interesting quirk
Hi Gagan,
Interesting quirk you've found there, it's possible it could be a bug
though further digging may be required.
A couple of interesting notes I found while fiddling with your example code:
- If you press "Save and continue editing" there are unspecified form
errors
- Setting
Hi there,
yes I can add EMAIL_TIMEOUT in my applications and I am already doing that.
The reason I wanted to bring this up here is that I care about Django.
This behavior goes against a well known concept of the Unix Philosophy
which is to "Write programs which fail in a way that is easy to
Week ending November 20, 2022
*Triaged: *
https://code.djangoproject.com/ticket/34152 - Add the ability to store
logs in a table (wontfix)
https://code.djangoproject.com/ticket/34155 -
ModelAdmin.render_change_form does not lowercase the app_label when setting
template directories
Hi Mariusz,
> Op 17 nov. 2022, om 18:18 heeft Mariusz Felisiak
> het volgende geschreven:
>
> "Why is there no default for EMAIL_TIMEOUT?"
> The Django's SMTP backend is a wrapper around smtplib.SMTP/SMTP_SSL and we
> only pass the "timeout" parameter to the smtplib API, so I'd first ask why
*"Why is there no default for EMAIL_TIMEOUT?"*
The Django's SMTP backend is a wrapper around smtplib.SMTP/SMTP_SSL and we
only pass the "timeout" parameter to the smtplib API, so I'd first ask why
there is no default value for a timeout parameter in smtplib.
Best,
Mariusz
--
You received this
> (Why is "Just give it a value in your settings" not OK? 樂)
I'm guessing the issue here is that it's currently an unknown-unknown to
most/all newbies.
At the very least, it should probably be addressed in the documentation on
deployment.
Regards,
Arthur Pemberton
On Thu, 17 Nov 2022 at 11:16,
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
Christian - did you end up making a docs PR here?
I’m afraid I don’t really know why fields aren’t localized by default. If
you have a proposal to change this in a backwards-compatible, low
disruption way, that could be easier to discuss.
On Mon, Sep 5, 2022 at 9:23 PM Christian González <
I do like this suggestion. I also find the current behaviour surprising.
Do you have a plan for implementation? I guess this would have to go
through the regular deprecation pathway?
On Tue, Oct 4, 2022 at 4:32 PM אורי wrote:
> Hi Shai,
>
> Actually, I think this issue is very similar to
Thank you!
On Wed, Nov 16, 2022 at 9:04 PM Mariusz Felisiak
wrote:
> Week ending November 13, 2022
>
> *Triaged: *
>https://code.djangoproject.com/ticket/34143 - Multiple file upload
> docs (invalid)
>https://code.djangoproject.com/ticket/34131 - Postgres AutoField
> change from serial
I finally had some time to do some work on this and have submitted a patch
at https://github.com/django/django/pull/16302 in case anyone is interested.
On Wednesday, October 5, 2022 at 2:24:35 PM UTC+2 carlton...@gmail.com
wrote:
> Hi Adrian.
>
> Nothing has been done, no.
>
> There seem
and just have a username field?
Of course, this may go hand-in-hand with Florian’s suggestion of using OpenID
Connect.
From: django-developers@googlegroups.com
On Behalf Of Carlton Gibson
Sent: Wednesday, November 16, 2022 12:58 PM
To: django-developers@googlegroups.com
Subject: Re: [Technical
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
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
Week ending November 13, 2022
*Triaged: *
https://code.djangoproject.com/ticket/34143 - Multiple file upload docs
(invalid)
https://code.djangoproject.com/ticket/34131 - Postgres AutoField change
from serial to identity (invalid)
https://code.djangoproject.com/ticket/34144 - Casting
I also agree with raising a UnsupportedMediaType and having custom handlers
for 400, 415 is always useful IMO
On Saturday, 12 November 2022 at 12:24:45 UTC Adam Johnson wrote:
> I would have a slight preference for raising an UnsupportedMediaType as
>> well and letting that percolate to a 415
>
> I would have a slight preference for raising an UnsupportedMediaType as
> well and letting that percolate to a 415 as it seems more correct from a
> content negotiation perspective.
Thinking about it again I think I have a slight preference too.
I guess this would warrant adding a urlconf
I like that idea, Tim. A few things came up, so I'll open this PR next week.
Thanks,
Andrew
On Friday, November 11, 2022 at 12:21:43 PM UTC-5 schill...@gmail.com wrote:
> Hi folks!
>
> Andrew (Mshar) how do you feel about reworking:
>
> > If you know someone who you think should be considered
Hi folks!
Andrew (Mshar) how do you feel about reworking:
> If you know someone who you think should be considered for Individual
Membership or would like to nominate yourself, please fill out this form
> DRF’s behaviour feels more correct to me, since it allows terser views
that don’t check the content type explicitly. But it’s less backwards
compatible. I’m not sure which I prefer.
Given the .data attribute would be a new feature of the request object I
assume we don't have any backward
This first-step solution is good with me. It will allow everyone to switch
to request.data (etc.). And there’d be a clear way to use your own logic to
set request.data if needed: write a middleware (or view decorator, view
class, etc.).
What should request.data be/do in the case of an unsupported
Hi,
On Thu, Nov 10, 2022 at 9:40 AM Jacob Rief wrote:
> How about ditching the JS based datepicker altogether and replace it
> against the built-in datepicker offered by modern browsers? This would also
> help users of mobile devices because they already have good internal
> implementations to
How about ditching the JS based datepicker altogether and replace it
against the built-in datepicker offered by modern browsers? This would also
help users of mobile devices because they already have good internal
implementations to select a date. I agree that on desktop browsers the
built-in
Hello Carlton,
This is not an area of the code base I'm heavily involved with but the
increment approach you are proposing over this lack of feature support for
basic content negotiation seems like a sane approach to gradually make the
landscape better in this area without trying to get
Just want to pop in and say these are great ideas - feel free to copy me in
on any PR if you want extra opinions!
On Tuesday, November 8, 2022 at 8:26:28 AM UTC-7 Carlton Gibson wrote:
> Great, Thanks Andrew. No urgency
>
> On Tue, 8 Nov 2022 at 16:16, Andrew Mshar wrote:
>
>> Will do,
Great, Thanks Andrew. No urgency
On Tue, 8 Nov 2022 at 16:16, Andrew Mshar wrote:
> Will do, Carlton.
>
> Tim and Cory, thanks for the suggestions. I'll incorporate those in the PR
> and post here when it's ready. Probably not today, but I should be able to
> open it before the end of the
Will do, Carlton.
Tim and Cory, thanks for the suggestions. I'll incorporate those in the PR
and post here when it's ready. Probably not today, but I should be able to
open it before the end of the week.
Thanks,
Andrew
On Tuesday, November 8, 2022 at 10:10:51 AM UTC-5 carlton...@gmail.com
Hey Andrew.
I had thought this was a Flatpage (stored in the database) but it's not.
The source is here:
https://github.com/django/djangoproject.com/blob/main/djangoproject/templates/members/individualmember_list.html
If you wanted to open a PR suggesting your changes, that would be amazing 朗
Hey Tim!
> I'm of the opinion that if you care enough about Django to investigate
becoming a member of the DSF, that's enough of a qualification...
OK, so this is the point about whether or not we need another membership
level... — DSF membership has been "The DSF appoints individual Members in
I'm of the opinion that if you care enough about Django to investigate
becoming a member of the DSF, that's enough of a qualification - it is just
challenging to formalize that into proper text for the website. Maybe two
changes to encourage people to join:
- We could tweak *"Running
Looking at the code Carlton provided sounds like it meets what was being
requested, but it fails "There should be one-- and preferably only one
--obvious way to do it." in that it wasn't immediately obvious, but adding
the cacheif tag would lead to more than one way. Therefore I'm suggesting
that
Hey Andrew,
Thanks for drafting this language and I think it looks great. As someone
who only recently applied after hearing it discussed on an episode of
Django Chat[1], I'm all for the goals of making it more encouraging and
accessible and think this is a great step in that direction.
Here are
Suggested new language:
The following are Individual Members of the Django Software Foundation.
Individual Members are appointed by the DSF in recognition of their service
to the Django community.
Service to the Django community takes many forms. Here are some examples
(non-exhaustive) of
django-developers is not a support channel. Email support requests to
*only* django-users.
On Sat, Nov 5, 2022 at 7:34 AM Nishant Sagar wrote:
> Hi all,
>
> I deployed the django project to AWS ec2 instance using nginx and gunicorn
> but the static file is not loading at all.
>
> Can someone
Hi David,
While I understand the ease of use that ListFilter bring in, my issues are
1. If there are multiple filters with multiple options, the user cannot at
a glance see all the filters active / available without scrolling
2. when using multiple filters, the page is refreshed on each filter
Hi Vasanth,
What advantages does a dropdown have over simply placing the options there
though? Typically these sorts of things have horrendous accessibility and
make the code more complex.
--
David
On Fri, 4 Nov 2022 at 02:17, Vasanth Mohan wrote:
> Hello,
>
> When there are multiple filters
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
>
> But it is not possible unless we directly override the
> password_validation classes and this is an extra and dirty work.
I don't think this work is dirty!
We generally prefer to avoid extra settings (and sub-settings) where
possible. The settings file should be clear, and not do what code
This can currently be achieved with:
qs.annotate(lowername=Lower("name")).filter(lowername__in=['text'])
You’re free to add “iin” to your projects, but I'm not sure it's valuable
enough to add to Django.
Some years ago, there was an idea to allow python expressions to generate
ORM filters, that
The speckenv example highlights the problems when using `literal_eval`:
A=[] will parse as list but A=[a] will parse as string again (if I read the
code correctly). This ambiguity makes it really hard to explain. When using
`literal_eval` one imo has to be consistent and don't fall back to a
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
On Tue, Nov 1, 2022 at 10:34 AM Florian Apolloner
wrote:
> Right, that would work. I am wondering though if we want to go all in on a
> typed config object like that or in a first step only have a simple API
> like `config.get('DEBUG', cast=bool)`.
>
>
I found a neat trick in a 12factor library
config.get is how python-decouple works which is what I use for config and
deployment settings.
On Tuesday, 1 November 2022 at 09:34:15 UTC f.apo...@gmail.com wrote:
> Right, that would work. I am wondering though if we want to go all in on a
> typed config object like that or in a first step
On Tue, Nov 1, 2022, at 6:54 AM, C. Kirby wrote:
> Having run the elections for the current technical board I agree with
> Andrew's assessment that a more open requirement to run is a good idea. It
> may create a bit more work on candidate verification for the DSF Board and
> Fellows, but
Having run the elections for the current technical board I agree with
Andrew's assessment that a more open requirement to run is a good idea. It
may create a bit more work on candidate verification for the DSF Board and
Fellows, but anything that can work to encourage new blood in the
Right, that would work. I am wondering though if we want to go all in on a
typed config object like that or in a first step only have a simple API
like `config.get('DEBUG', cast=bool)`.
On Tuesday, November 1, 2022 at 3:35:46 AM UTC+1 pe...@lincolnloop.com
wrote:
> On Mon, Oct 31, 2022 at
On Mon, Oct 31, 2022 at 11:52 AM Florian Apolloner
wrote:
> On Monday, October 31, 2022 at 5:27:02 PM UTC+1 pe...@lincolnloop.com
> wrote:
>
>> In my ideal scenario, the default is a hard-coded settings file for the
>> project (deprecating DJANGO_SETTINGS_MODULE env var) and we have
>>
On Monday, October 31, 2022 at 5:27:02 PM UTC+1 pe...@lincolnloop.com wrote:
> In my ideal scenario, the default is a hard-coded settings file for the
> project (deprecating DJANGO_SETTINGS_MODULE env var) and we have
> CONFIG_LOADERS defined in the settings that could do env, toml, etc.
>
On Sun, Oct 30, 2022 at 7:57 AM Florian Apolloner
wrote:
> Hi Peter,
>
> On Saturday, October 29, 2022 at 6:07:16 PM UTC+2 pe...@lincolnloop.com
> wrote:
>
>> Since you asked for feedback, I'll tell you what I'd do differently (and
>>> this is also a sign that production environment vary
rst try and
>>>>>>>> just result in frustration.
>>>>>>>>
>>>>>>>> It seems like part of the challenge here is reaching parity with the
>>>>>>>> current runserver command, but
Hi!
I think you've found the wrong mailing list for this post. This mailing
list is for discussing the development of Django itself, not for support
using Django. This means the discussions of bugs and features in Django
itself, rather than in your code using it. People on this list are unlikely
Week ending October 30, 2022
*Triaged: *
https://code.djangoproject.com/ticket/34112 - Add async interface to
Model (accepted)
https://code.djangoproject.com/ticket/34113 - max() arg is an empty
sequence (duplicate)
https://code.djangoproject.com/ticket/34114 - loaddata doesn't
On Sun, Oct 30, 2022, at 10:42 PM, James Bennett wrote:
> On Wed, Oct 26, 2022 at 4:34 PM Andrew Godwin wrote:
>> __
>>
>> I have copied in the DSF Members mailing list as it is a governance-related
>> DEP, but if we could keep all discussion on the thread in the Django
>> Developers mailing
On Wed, Oct 26, 2022 at 4:34 PM Andrew Godwin wrote:
> I have copied in the DSF Members mailing list as it is a
> governance-related DEP, but if we could keep all discussion on the thread
> in the Django Developers mailing list, as per DEP 0001, that would be great.
>
My main concern remains
501 - 600 of 43592 matches
Mail list logo
