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
The thread that Carlton refers to is
https://groups.google.com/g/django-developers/c/q20_Cxske88 -- don't be
deterred by the title of it, it really talks about handling settings as
well :)
I kinda agree with James. I'd like to have a proper answer for handling
settings rather then go setting
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
(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
I recently did a bit of an audit of "settings types" whilst preparing for an
overhaul of django-classy-settings.
I found you could cover a majority of the common config types if you could
somehow parse from an environ string the following (which closely aligns with
django-environ):
+ str
+
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.
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
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 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
>
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
29 matches
Mail list logo
