Dear Djangonauts,
The ticket sales for DjangoCon Europe 2019 have opened, and the Call for
Participation is closing in 3 days (rumor: we might extend it by a few
days).
In case you've just seen this: Sorry for the late notice!
DjangoCon is a conference by the community and for the community.
Hi all!
Here-by announcing that in the days after our first ever Danish Django
conference (DjangoCPH Day 2018), we'll host a sprint. It's free to attend,
as long as you sign up on the website.And you are of course encouraged to
participate in the event on Friday as well *wink wink* :)
Markus
As a big fan of GCBVs, this got me out of the chair :) I am -1 for removing
GCBVs for authentication.
My reasons:
1) Security improvements also happen over time, finding a security hole in
a component is not a reason to point the finger at the architecture. If you
entirely remove something,
Hi guys!
As an external user of Django, relying on its stability, I'd like to
comment In general, I think this is possibly a good improvement.. but
possibly also a very dangerous one...
On Monday, December 8, 2014 12:38:18 AM UTC+1, Russell Keith-Magee wrote:
>
>
> On Sun, Dec 7, 2014 at
Hello again!
> What you have suggested here **is** an invasive change, because it
> requires changes to existing code paths.
I think the way to measure "invasive" is by means of backwards
compatibility. We do not change required arguments, return value or
model fields... The view normally
> > As a maintainer of many Django sites, I would often like to see a very
> > small feature implemented, that could make life a lot easier for me:
> > To force my users to set their own password.
>
> First, to me, this is not obviously a 'very small feature'.
>
> Second, is there any reason it
Dear all,
As a maintainer of many Django sites, I would often like to see a very
small feature implemented, that could make life a lot easier for me:
To force my users to set their own password.
I know this could lead to a long debate about password strength, SSL,
password reminders, secret
