Hi all,
As per the DEP process, I have merged DEP 8, Formatting Code With Black,
into the DEP repo as a draft. This doesn't mean it's decided yet - any DEP
that meets quality requirements gets merged as a draft - but it means that
we're one step closer to doing so.
What follows is further
>From my read this also looks like it would make the auto-reloader able to
work a lot better with an async-capable server, so I would be in favour
given that is likely in the future as well.
Andrew
On Tue, Apr 23, 2019 at 9:33 PM Ramiro Morales wrote:
> Hi all,
>
> I had a stab at a somewhat
So, it looks like most of the comments on this PR have happened and been
resolved - unless anyone has any objections, I will merge it in after a
couple more days (just in time for PyCon US).
Andrew
On Wed, Apr 24, 2019 at 1:50 PM Andrew Godwin wrote:
> Hi everyone,
>
> Just wante
On Tue, Apr 30, 2019 at 11:34 PM Mariusz Felisiak <
felisiak.mari...@gmail.com> wrote:
> Thanks for this patch. Can you add a trac ticket? also Can you give me &
> Carlton few days for review? I should be able to do this somewhere in the
> next week.
>
I can indeed. I wasn't sure if you wanted
where people might input. There’s
>> massive interest.
>>
>> Great work as ever Andrew. Thank you so much!
>>
>> C.
>>
>> On Wed, 1 May 2019 at 08:46, Andrew Godwin wrote:
>>
>>>
>>>
>>> On Tue, Apr 30, 2019 at 11:34 PM Mariu
My impression reading over the problem a little yesterday was that we could
work to provide a common "get me a resource" abstraction in Django that
papers over the couple of different ways it has to work, though I haven't
looked super far into things that require directory listing (e.g.
x there because the
> project controls the "resource" directories and could sprinkle in the
> necessary __init__.py files. I filed an issue to start the discussion
> there as well, https://bugs.launchpad.net/pytz/+bug/1834363
>
> On Thu, Jun 27, 2019 at 2:40 PM Andrew Godwi
Hi everyone,
Just wanted to drop a note and say that the first pull request in the
series needed to enable async in Django is now ready for review:
https://github.com/django/django/pull/11209
This is a very minimal amount of work to get Django async-safe and
understanding ASGI as an application
s looking like?
>
> CB
>
> On Friday, 12 April 2019 07:33:35 UTC+1, Shaggy wrote:
>>
>> and how it is going ?
>> is there some interest from django devs?
>>
>> On Monday, 4 June 2018 15:18:23 UTC+2, Andrew Godwin wrote:
>>>
>>> Hello eve
, 2019 at 10:10 PM Andrew Godwin wrote:
> I agree James - forums tend to age slightly worse than mailing lists for
> archival content, but I'm hoping the improved experience in the moment
> makes up for it.
>
> Plus, our current mailing list archive depends on a service from Google
On Sat, Aug 10, 2019 at 3:30 AM Carlton Gibson
wrote:
> What does it need from Ops? (Is there a `docker run-my-service`? Could we
> leverage djangoproject.com (and GitHub) logins, or are they always going
> to be separate?)
>
Markus has done more investigation on how to run it, though my
On Fri, Aug 9, 2019 at 10:16 PM אורי wrote:
> Every Google Group also has an online forum:
> https://groups.google.com/forum/#!forum/django-developers
>
Indeed, I am aware of this, I usually use it when I link threads on Twitter.
However, it is not really a forum in the sense I am
I agree James - forums tend to age slightly worse than mailing lists for
archival content, but I'm hoping the improved experience in the moment
makes up for it.
Plus, our current mailing list archive depends on a service from Google,
and I trust those less these days (though I hope Google
Hi all,
If you recall, last month I brought up the idea of a Django Forum (
https://groups.google.com/forum/#!topic/django-developers/HGAHQqKp7rs) -
we're now ready to launch this forum in a test phase!
You can find it at https://forum.djangoproject.com
Like our Trac, it's tied into GitHub
We actually discussed this a little at the PyCon AU sprints and the
consensus was that GitHub issues would be great *if only they were a bit
more featureful*.
The problems I feel are specifically an issue:
- Ticket states; this is not easily replicated with labels, while
components etc. are
Unfortunately, from my perspective, websocket support is tricky enough that
it's at least not on the short-term plan to bake into Django; it's used by
only a small fraction of our users, and the Channels project is an official
Django project, so it's as close as we can get so far. Future Django
I agree too. Let's change it.
Andrew
On Sat, Jul 27, 2019 at 4:03 AM Markus Holtermann
wrote:
> Easy: +1 from me as well for reasons state before.
>
> /Markus
>
> On Sat, Jul 27, 2019, at 6:15 PM, Adam Johnson wrote:
> > +1 from me too for the reasons that Aymeric states.
> >
> > Another small
Hi everyone,
This might be slightly controversial, but I would like to propose that we
have a forum for discussing Django development (and potentially user
support), alongside the mailing list and maybe, eventually replacing it.
My full reasoning is below, but in short, it would be more
Andrew
On Sat, Jun 8, 2019 at 9:14 AM Andrew Godwin wrote:
>
>
> On Sat, Jun 8, 2019 at 3:14 AM Pascal Chambon
> wrote:
>
>> Hello,
>>
>> There is something a little scary for me, in changing all the core of
>> Django to async, when this really helps only,
, Jul 21, 2019 at 1:02 PM Andrew Godwin wrote:
> I'll ask permission and then summarise the points raised back out here!
>
> Andrew
>
> On Sun, Jul 21, 2019 at 1:01 PM Jacob Kaplan-Moss
> wrote:
>
>> Congratulations, and great news!
>>
>> I hope the TB will co
uot;; I'll bet there's a bunch the broader community could
> learn from the specifics.
>
> Jacob
>
> On Sun, Jul 21, 2019 at 3:54 PM Andrew Godwin wrote:
>
>> Hi everyone,
>>
>> After a long and involved vote, I can announce that the Technical Board
>> has vot
On Sun, Jul 21, 2019 at 1:11 PM Ehigie Aito wrote:
> Django 3.0?
>
Django follows time-based releases; what's in Django 3.0 will depend on
when we can get it landed. At the moment I am optimistic something will
make it in, but I make no promises!
Andrew
--
You received this message because
it would come
> in handy for the TB's direction guidance...)
>
> Kind Regards,
>
> Carlton
>
>
> On Tuesday, 10 December 2019 19:14:51 UTC+1, Andrew Godwin wrote:
>>
>> I agree that 2FA could be a good choice - some of the async support work
>> would also have bee
I agree that 2FA could be a good choice - some of the async support work
would also have been good, had I made more progress in the latter half of
this year.
A couple of other ideas for big projects:
* A secrets manager abstraction and built-in support for Vault, KMS, and
other common ones
* A
I agree - we need to communicate that ASGI support does *not *mean you can
start writing async def views. I think we should put a big disclaimer to
that effect next to it in the release notes and say it should be coming
next release.
Andrew
On Mon, Oct 14, 2019 at 5:45 PM Josh Smeaton wrote:
>
I am particularly excited for native async support arriving - that's
something I'd love to have and ship support for from our side when it's
done. The rest looks quite sensible too.
Andrew
On Wed, Mar 11, 2020 at 3:39 AM Jure Erznožnik
wrote:
> His proposed changes look awesome to me!
>
>
I am a little mixed on this change - the behaviour during the initial
development was indeed to concatenate names like this, albeit only for
adding fields or models; I thought it looked unwieldy, which is why I added
the "auto" name.
That said, the number is the only part that actually matters,
I definitely think this is worth pursuing - the reason I didn't do it back
in the day was that squashing the entire project involved solving some
rather nasty dependency graph issues if there were any cycles of apps
depending on models from other apps.
If we can overcome that, though, and squash
I also vote in favour of Claude becoming a Merger!
Andrew
On Tuesday, April 21, 2020 at 4:28:41 AM UTC-6, Markus Holtermann wrote:
>
> I vote in favor of Claude becoming a MERGER.
>
> Cheers,
>
> Markus
>
> On Thu, Apr 16, 2020, at 10:31 PM, charettes wrote:
> > I cast my vote in favor of
Yeah, I'm not quite sure what this is, but I just ran get_event_loop() a
thousand times and it gave me the same thing every time and didn't even budge
the number of file descriptors.
Can you replicate this behaviour in a brand new Django project? That's what I'd
need to help debug it further.
te how possible it is to offer
>>> > all of them and if everything can be made to work regardless of what mode
>>> > (sync or async) it's in
>>>
>>> In terms of the package or the other built-in backends or just everything
>>> in general like the ORM? If
Agreed - there's no work on caching inside Django yet, since the ORM is my next
focus, but I would definitely suggest writing a new pluggable third-party
backend that somehow provides async versions of the methods.
The main work to do here is to work how quite how possible it is to offer all
I suspect the reason for this might be to undo circular references of
ForeignKeys between apps - in this situation, you have to first have a
migration that removes one FK, then in the other app remove the model, then in
the first app remove the model.
I can't quite remember though - but that
While I agree with some of the author's points, I think a critical piece of
context is that Django migrations are designed for the 90% case - i.e., people
who just want something to work on a small scale and don't need to worry about
many aspects of the database yet.
Like all parts of Django,
Yup, I'm seeing if we can get asgiref fixed today, otherwise I'll revert the
change that broke Django and issue 3.2.9.
Andrew
On Tue, Jun 16, 2020, at 2:48 AM, Florian Apolloner wrote:
> Ok, so rebasing PRs to current master will fix this (leaving this here as
> note for others who run into
I've definitely in favour of fixing all of the problematic word usage - after
all, we eliminated master/slave from the database documentation years ago,
we've just been a bit negligent at fixing the others.
Agreed with Adam, though, about seeing what GitHub builds - they announced
they're
to
>>> import an mbox:
>>> https://github.com/discourse/discourse/blob/master/script/import_scripts/mbox.rb
>>>
>>> I’m running the box importer script now and it appears to work fine. While
>>> some people might have historical mbox files, it might be better
script to mash the APIs over HTTP)
Andrew
On Sun, Nov 8, 2020, at 2:36 PM, Andrew Godwin wrote:
> I have been moving house this week (plus, yknow, the election) so I haven't
> got anything done, but hope to poke at it early next week!
>
> Andrew
>
> On Sun, Nov 8, 2020, at 4:34
I agree we should not be quite so beholden to our existing Python version
policy - that was mostly to get us out of the early 3.x era. Now things are
more stable, I'd support a policy that is much more like "any stable version of
Python currently out there and supported".
Andrew
--
You
I'd be more than happy to assist a trial of moving things to the forum;
we've had it running for over a year now, and I feel it's a much easier way
to run a community.
Among other things, we can:
- Move posts to the right forum when they post in the wrong one (rather
than emailing back and
Migration squashing was always meant to be something that was useful in a rapid
development environment where you can't control all the installs (since it was
a feature developed alongside a CMS run by many clients at the time).
If you have control of all the places your project is installed
As the note in that section explains, that is for custom *classes*, not for
custom *fields*. Your observation is correct when applied to field
deconstruction methods, but not for the system talked about there which lets
you do it for arbitrary classes (as part of the values in field
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
belief in the need for
visible, servant leaders in OSS communities rather than trying to embrace a
flat hierarchy with mechanical checks and balances - but that is for another
day.
Andrew
On Mon, Oct 24, 2022, at 4:26 PM, James Bennett wrote:
> On Mon, Oct 24, 2022 at 2:24 PM Andrew Godw
On Tue, Oct 25, 2022, at 12:12 AM, James Bennett wrote:
>
> My first reaction to this is: if having a DEP that says the Technical Board
> is supposed to take the lead in gathering feature proposals didn't get them
> to do it, it doesn't feel like another DEP saying they're responsible for
>
I agree the Technical Board has not followed the letter of DEP 10, and I think
the things you have highlighted are all valid failings, but I want to focus on
- what should we do to remedy them?
Given the lack of candidates we already have, if we ditch the current Board and
try to elect a new
Hi Paolo,
I do like the overall idea - a few thoughts below.
My first concern for this, which somewhat echoes James, is that trying to
organise an additional in-person event that a large number of contributors are
expected to go to is difficult. Funding considerations are one concern - we
DEP shortly so it's more clear exactly
what I want to change at a written-rules level - I suspect feedback on a more
concrete proposal will help us talk about it more clearly.
Andrew
On Wed, Oct 26, 2022, at 4:55 PM, James Bennett wrote:
> On Wed, Oct 26, 2022 at 12:02 PM Andrew Godwin wr
Hi all,
As a followup to my previous post about potential changes to the Technical
Board - for which I thank you all for the feedback - I have taken the process
to the next step and written a draft DEP:
https://github.com/django/deps/pull/75/files
(If you wish to see the DEP with styling, it
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 Dj
Hi everyone,
I want to start a conversation about the Technical Board and its role in
Django, and how I'd like to change it, including its name.
Since its inception, the Technical Board has effectively only functioned as a
backstop vote for large features that require DEPs, of which there have
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
Yes, I agree we can use the forum in future since it's less tied to Google.
Provided the current +5 vote carries through to the end of the voting period, I
will be suggesting that the Technical Board triggers the DEP 10 mechanism where
we move this to the membership for a vote once the DSF
Hi everyone,
I am pleased to report that we've completed the extended approval process for
DEP 12, which was needed since it was a governance change. Both the Technical
Board and the DSF Board voted to not require a vote from the membership on the
change, so it is now officially adopted and I
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 -
concluded and a result reached.
Andrew
On Wed, Nov 30, 2022, at 10:44 AM, Andrew Godwin wrote:
> Yes, I agree we can use the forum in future since it's less tied to Google.
>
> Provided the current +5 vote carries through to the end of the voting period,
> I will be suggesting that the Tec
Hi all,
As it seems discussion on DEP 12 has reached its end, and we received generally
positive feedback, I am requesting a vote from the technical board on the
following:
"Shall we accept DEP 12 and send it to the DSF Board for further approval?"
Note that as this is a governance change, it
hu, 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 mo
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,
401 - 459 of 459 matches
Mail list logo