from:"James Bennett"

Re: Add a minimal Gitignore

2023-03-09 Thread James Bennett

On Thu, Mar 9, 2023 at 10:27 AM 'Adam Johnson' via Django developers
(Contributions to Django itself)  wrote:

> The Django project has a .gitignore file:
> https://github.com/django/django/blob/main/.gitignore
>
I think this person was asking for the default ‘startproject’ template to
include a minimal .gitignore file.

-- 
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 receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CAL13Cg9ySuiTEcyUQQiPKzP_Q6qCu2JBV6jZeE-0QdEFoimYAg%40mail.gmail.com.

Re: Backport for ticket 34063?

2023-01-01 Thread James Bennett

On Sun, Jan 1, 2023 at 7:01 PM Tim Graham  wrote:
> Incidentally, I don't think it's important for the ultimate decision here, 
> but I looked at the below analysis of ticket #32189. Carlton's analysis on 
> the ticket that request.POST is empty when using 'content-type': 
> 'application/json' remains true.

The bug report specifically says:

> First due to the limitation in reading from FakePayload, in the real world 
> you can ask to read more just you would not read more i think
> I found http request was setting a high chunk size for an unrelated test and 
> failing to read from fake payload
>
> Then i notice that when trying to use a content type json not multipart 
> (default) that the post data was empty again!
> This time it seemed to be due to handling of application / json content

I read that as clearly saying that the reporter's earlier attempt(s)
*did* encounter the same bug as #34063, since otherwise why mention
the read/chunk size and the mechanics of reading from FakePayload? It
seems like a later attempt ran into the separate issue of the
application/json content type not populating request.POST. Ideally
this bug report would have been followed up with a "wait, why did it
hit that code path with the read size error" during triage, since that
is *not* what ought to be happening, even when request.POST is
inappropriately accessed on a non-form request (request.POST should
just be an empty QueryDict in that case).

So I do believe #32189 is a duplicate of #34063. It just happened that
the reporter had hit multiple issues: one was user error, but the
other was a genuine bug in Django.

> If I encountered a similar issue, I would have just worked around it and 
> moved on. Surely there are other issues like this one that don't meet the 
> current backport criteria but that could be similarly argued by someone 
> persistent enough. It would be nice if the outcome here avoided that in the 
> future.

As I keep saying: for a feature as hyped up as async, and for a bug of
this severity in the async testing support, I do not think Django can
afford such a lackadaisical "work around it yourself" policy without
incurring significant reputational harm. Nor can the response be that
people should just upgrade -- mostly because Django should have fixed
this bug two years ago, but even today Django should take
responsibility for the bug and provide a backport of the fix into all
the supported releases. And especially should do so since it *still*
is not possible, today, to "upgrade" to a released version of Django
containing the fix.

> I guess it's nice to have a strict backport policy, partly to avoid hours of 
> discussion like this

The fix could have been backported and released a dozen times over,
and the backport policy amended with language to explicitly allow
fixes like this one but not open the floodgates to anything and
everything, in the amount of time that has been devoted to trying to
prevent this from being backported.

At any rate, your remaining objections basically seem to boil down to
not liking the time and effort being spent on this. I have already
offered to do whatever work is needed to see the backports through to
release. It is not a particularly difficult patch, so far as I can
tell, and I have significant direct experience backporting and
maintaining much gnarlier bugfixes in branches of Django. So the
time/effort objection is moot.

-- 
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 receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CAL13Cg_yTXKx7GRYuzqhiUZ%3Dy%3DbJesD%3D9TGjrjei6a_4D0SLfQ%40mail.gmail.com.

Re: Backport for ticket 34063?

2023-01-01 Thread James Bennett

On Sun, Jan 1, 2023 at 12:54 PM Tim Graham  wrote:
> Older Django releases are currently maintained with minimal support that 
> allows existing projects to continue running securely. I don't think we 
> should invest resources in promoting them as a place to use experimental 
> features. A benefit of running an old LTS release like 3.2 is that any 
> release at this point is probably a very important upgrade (security or data 
> loss issue). If we start making new LTS bug fix releases to fix experimental 
> features, releases may be more frequent and less important. Of course, with 
> more changes, the risk of unrelated regressions increases, including the 
> possible bad situation in which users put off a bug fix upgrade because it 
> doesn't have any security fixes only to face issues updating to a subsequent 
> security release because of an issue in an interim bug fix release. (Maybe 
> mergers can estimate how many other async fixes would be eligible for a 
> backport based on the proposed criteria.)

The backport policy already says that Django will backport certain
things into older releases. I do not agree with your assessment of the
risk of backporting, but even if we grant it for sake of argument, the
Django project overall has already clearly endorsed -- through the
current backport policy -- the idea that some fixes are important
enough to override such concerns and to backport even into releases
that are on "minimal" support.

I happen to think that this is one such fix, for reasons that I have
laid out at length. I also think the backport policy should be amended
to prevent an issue like this from "slipping through the cracks" again
in the future. I am still considering the wording Shai proposed,
though on first read I thought it was getting at the right idea.

> James argues that this bug that went unreported for 2+ years is now very 
> important and is going to cause massive pain for many users. Only time will 
> answer this, but I'm skeptical. So far I believe we've seen two people 
> affected, James and the ticket reporter.

Well.

I had been trying to avoid bringing this up because I felt that the
backport policy and the severity of the bug were the things to focus
on, and because I was trying to avoid singling out individual mistakes
that contributed to the situation we have now. But there is at least
one other report of this bug in the Django Trac instance. It is the
first one I found when trying to diagnose the problem in my own code
(and the one I mentioned in my initial question on IRC, as anyone who
saw that can confirm), and it is one that was filed only a couple of
months after the release of Django 3.1, so well within the window of
time when the backport policy would have said to apply the fix to the
3.1 branch as well as to main. It also correctly diagnosed the source
of the bug and provided an attempt at a patch.

That ticket was #32189:

https://code.djangoproject.com/ticket/32189

But it was closed invalid as a user error. We can debate whether the
user should have been trying to access request.POST for their
particular use case, but we cannot debate whether this is the
underlying bug that user was encountering. It also was clearly not the
normal behavior one ought to see from accessing request.POST, even in
a non-POST request or supposedly non-appropriate context, and likely
either should not have been closed, or should have produced a
follow-up ticket to investigate why that specific behavior was
occurring.

As for whether anyone else is affected: my searching turned up several
references on other sites to the exact error message the bug produces,
which all seemed to receive replies along the lines of #32189: that it
was the fault of the reporter for accessing request.POST rather than
request.body.

So. I have said several times that using a strict reading of the
backport policy to avoid fixing a severe bug sends a bad message. I
will amend that now, and say that using a strict reading of the
backport policy to avoid fixing a bug, when the bug was reported to
Django within a window where the backport policy should not have
mattered, sends an even worse message.

I also do think that more people will trip over this bug as they start
using async Django, and that leaving it unfixed creates a problem of
how to communicate the need for a workaround without violating a
strict reading of the backport policy.

> This bug will be a non-issue for third-party apps with the release of Django 
> 5.0 in December if they follow the suggested Django version support policy:

I have repeatedly pointed out that I do not think Django should force
the choice of long-delayed async adoption, or fracturing of the
community, onto maintainers of third-party packages and libraries. My
objection was to waiting until Django 3.2 drops out of support, which
is in April 2024, but the objection would apply equally to saying that
a feature released in 2020 must be left in a state where it is not
reliably

Re: Backport for ticket 34063?

2022-12-31 Thread James Bennett

On Sat, Dec 31, 2022 at 2:12 AM 'Adam Johnson' via Django developers
(Contributions to Django itself) 
wrote:
> In the past I have also been frustrated at particular bug fixes not being 
> backported. But I've gradually come to appreciate just how valuable the 
> backport policy is. It keeps Django forward-facing, and prevents the fellows 
> spending much of their precious time backporting.

In the forum post, which attempted to be a single-place-to-read
summary of the argument, I pointed out the benefits of the backport
policy, and also pointed out that making exceptions to it from time to
time has happened and without ill effect. I also explained why I
believe *not* backporting this runs counter to the goals the backport
policy is theoretically supposed to achieve, and why an exception to
backport this fix is correct.

As I said above:

> So I ask that people actually read and engage with that in future replies. 
> This is the
> bare minimum of respect and good faith that can be expected of participants in
> discussions on this and other forums concerning Django and its development.

I should not have to be asking people to show that basic level of
respect and good faith. Yet here I am having to ask more than once.

> Also, I’ve learned several techniques to backport within projects when 
> required (e.g. 
> https://adamj.eu/tech/2020/07/29/backporting-a-django-orm-feature-with-database-instrumentation/
>  ). I encourage others to do the same. We could perhaps document some of 
> these techniques (one source: Paul Ganssle’s talk ”What to Do When the Bug is 
> in Someone Else’s Code ”: https://ganssle.io/talks/#upstream-bugs ).
>
> I also believe that there is no overriding reason to backport in this case. 
> Self-backporting the fix within a project is very feasible—there’s no need 
> for "the request.body workaround" (which is an understandable source of 
> frustration).

This has multiple issues.

First, merely from a technical perspective, a "self backport" for this
bug can never be as self-contained as you seem to think it would be.
Take, for example, the code I was writing when I tripped over the bug:
a middleware that accesses request.POST, and is part of an application
I distribute to others. Even if I "self backport" a working
AsyncClient into my own test suite, anyone who has my middleware
configured in their settings now has the bug, too, and now *their*
test suite must account for it. And then anyone who uses that person's
code gets "infected" by it and now has to account for it.

This leads to either:

1. Everyone must maintain their own copy of the "self backport" of
things Django shipped, or
2. Everyone relies on a centralized repository for the code.

The first case clearly is bad: it takes not many individual developers
at all needing to maintain their own "self backports" before the total
maintenance cost imposed on the community outweighs the maintenance
cost Django would have incurred by just applying the fix. And given
that this is a high-severity bug in a key part of a feature Django
wants to hype up, I think the current status quo of "not many
affected" will not last long. And the cost analysis here, it should be
noted, does *not* include the decreased trust and confidence in Django
on the part of developers who see such a high-severity bug that Django
knows about and actively refuses to apply a fix for, even when *all*
currently-released versions of Django are affected by it.

The second case is worse: the correct name for a centralized
repository of Django with bugfixes applied is... Django. If we reach
the point where people in the community are expected to maintain forks
just to get documented basic functionality like the unit-testing tools
working, we are in a truly bad place indeed.

Finally, this ignores the question I have asked several times now: if
the official recommendation of the Django project is for everyone in
the Django ecosystem to apply workarounds or "self backports" for this
bug, how exactly is that to be communicated? It cannot go into the
documentation of the affected Django versions, because the same strict
"computer says no" reading of Django's policies that is being wielded
against the idea of a backported bugfix also applies to backporting
such notes into the documentation of older releases. Which leaves this
in a state of undiscoverability -- as I noted, I am someone who is not
exactly a novice at tracking down problems in Django, and it took me
over a day of working on this to end up at ticket 34063. And if an
exception *is* to be made to backport a "how to fix it yourself" into
the documentation of older versions, roughly the same amount of effort
would suffice simply to backport the bugfix itself. Even better:
backporting the fix does not create a stream of people reading the
Django documentation, discovering "wait, there was a bug of this
severity and their solution to it is to tell me to fix it myself", and
having that affect their perception of

Re: Backport for ticket 34063?

2022-12-31 Thread James Bennett

On Fri, Dec 30, 2022 at 11:22 PM Carlton Gibson
 wrote:
> Under normal circumstances you just use the sync Client, as you've always 
> done. `response = client.get(`/my-async-view/`)`.
> Django handles that the **view** is async for you.
>
> It's only if you need to write an actual **async test**, i.e. an `async def` 
> test case that you need the async client and factory.

Well, no. And I have been over this at least once in my explanations.
But I will explain it again as succinctly as I can.

First: the Django testing documentation steers readers toward
AsyncClient for asynchronous testing, especially for a consistently
async codebase. Which is something that has become table stakes, or
perhaps even more basic than that, for any Python framework claiming
to support async. Given that Python itself imposes limitations on use
of async code in synchronous contexts (with "await" literally being a
syntax error in any but an async context), telling people to just
write sync tests with the sync client is neither an acceptable
substitute for just fixing the AsyncClient, nor is it compatible with
the fact that the documentation currently prominently advertises
AsyncClient and its ability to let you write a full async codebase,
tests and all.

Second: as I *know* I have explained, it can be difficult to predict
in advance which code path Django will choose for mixed sync/async
code, because of all the work Django does to try to make them coexist
nicely. Any developer who wants to ensure async code paths are
actually tested has no useful alternative to AsyncClient, because only
AsyncClient is natively an ASGI client and thus will reliably trigger
async code paths through Django.

> The factory can use the suggested `request.body` workaround if needed.

Again I point out that this presumes the ability to easily communicate
both the workaround and the need for it to casual readers of the
documentation. If no exception can be made to the backport policy for
fixing the async test support, then no exception should be made to
change the documentation to tell people to use the workaround. And if
an exception is to be made, the exception which causes the least
damage to Django and the least overall ongoing burden is just to *fix
the async test support*. As I have been advocating.

> The `AsyncClient` is affected, yes. The question is whether that justifies a 
> backport at this very late hour.

I remind everyone that earlier in this thread I provided some initial
longer explanations, and then over on the forum I wrote over two
thousand words explaining in detail why I believe the backport is in
fact justified, and which anticipated and addressed several arguments
now being raised here. So I ask that people actually read and engage
with that in future replies. This is the bare minimum of respect and
good faith that can be expected of participants in discussions on this
and other forums concerning Django and its development.

-- 
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 receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CAL13Cg9LYH2CW-TNi_DuJvCWZk4CZ9aS_aKVAPhqgNzndW%2B5pw%40mail.gmail.com.

Re: Backport for ticket 34063?

2022-12-30 Thread James Bennett

On Fri, Dec 30, 2022 at 2:24 PM Tim Graham  wrote:
> As perfectionists, it's always hard to say (and hear) "no" when this sort of 
> request comes up.

I wrote a 2,000-word argument explaining why I believe this warrants
backporting. I think that deserves more engagement than just a "no".

> I'm unconvinced it's a serious issue that requires a break from normal 
> policy. (Unreported for 2 years in 4 major releases; simple workaround 
> present.)

I strongly encourage you to read the linked forum post, where I have
explained at length why I think it is serious enough to warrant an
exception (and why I believe the policy should also be
revisited/revised to accommodate cases like this explicitly).

> Incidentally, escalating an issue to the steering council after less than 24 
> hours (during a holiday week, no less) probably isn't something we want to 
> model as a best practice in forming consensus.

Reducing an opposing viewpoint to "it's hard to hear 'no'" probably
falls into that category, too. And I will point out here, as I did in
the forum thread, that the discussion here seemed to be blocked on a
Merger who was not convinced and *who suggested the Steering Council
as an option*. And procedurally, one point of the SC is to serve as a
"court of appeal" if someone cannot convince the Mergers of the merits
of a minor change.

Meanwhile, I think Kevin is pointing in the direction of something
important, which is that it is very easy to wind up in a vicious cycle
where people get the impression that Django does not take its async
story seriously and so they stay away from async Django, which then is
used as an argument for not taking the async story as seriously
(because obviously async Django is not that widely used), which then
gives people the impression...

Async is hard enough without Django making it harder still. So I think
it is important for Django to make clear that the async story is
supposed to be good and that the Django project is committed to
supporting async. Right now, a developer who decides to try out async
Django, with any currently-supported release, and follows the obvious
"how to test my async code" clues in the documentation, will very
likely end up with something broken. Worse: the breakage will be hard
to diagnose, harder to find out the workaround for, and if they do
manage to find it they'll likely also be treated to one or more
threads of the Django project saying that due to the technicalities of
when the breakage was first formally reported, none of the currently
released and allegedly bugfix-supported versions of Django are
actually eligible to receive a fix.

I put it to you that this is not a good experience for the developer,
that it is not the experience the Django project should be inflicting
on the developer, that it will tend to erode the developer's trust and
confidence in Django if this is the path Django decides to take, and
that the solution to all this is comparatively easy: backport the
frankly pretty minimal fix for the async test client into the full set
of currently-supported feature releases of Django as a show of good
faith and support, and to make async support easier for the community
and the overall ecosystem.

-- 
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 receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CAL13Cg8NAXWw3nLm0TbJH68i8zzgsHGBySJW459KEW81tbY85g%40mail.gmail.com.

Re: Backport for ticket 34063?

2022-12-30 Thread James Bennett

I have put it to the Steering Council:

https://forum.djangoproject.com/t/request-for-technical-board-steering-council-vote-requested-backport-ticket-34063/17920/1

-- 
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 receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CAL13Cg9QdLJBK1K%3D-CO1%2BxvnCbw_X7sCG%2B%2BUSzFv84Jnb8khAA%40mail.gmail.com.

Re: Backport for ticket 34063?

2022-12-30 Thread James Bennett

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, you'll need to work
> around.
> This is no different than any of a thousand other cases where there's been
> a bug in an older version that folks have needed to account for.
>

I believe it is very different and have explained why repeatedly.

But if it is to be left unfixed, what is the plan for how to communicate
the workaround to people who will be running into this bug until at least
April of 2024? And what is the plan for communicating to them that Django
is aware async testing is broken and the official policy is to knowingly
leave it broken in every currently-released version of the framework? Even
if it will not be fixed for older versions, Django 4.1 ought to be eligible
for a backport. And I strongly urge allowing a backport to 4.0 and 3.2,
though I do not know what could convince you at this point.

This bug is bad. But this response to it is eroding my trust in Django, and
I hope you know that is not something I say lightly. I think it also is
going to erode the trust of other people when they find out about it, and
is going to do so at a critical time when Django is facing stiff
competition in the async space and cannot afford to lose more ground or be
seen as unwilling to support its own claimed async features.

>

-- 
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 receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CAL13Cg_5wFeiQjEbOfRYJGgZ2Hn3cQoJHoW-CSUSGD9xuNehoA%40mail.gmail.com.

Re: Backport for ticket 34063?

2022-12-30 Thread James Bennett

On Fri, Dec 30, 2022 at 1:27 AM Carlton Gibson  wrote:
> It's frustrating when this happens, but the backport policy has proven its 
> worth time and again.
> I **really** don't see the case for making an exception here.
> (The policy has more value than the inconvenience in any of these cases, or 
> even all of them summed.)

I don't see the value here.

If it's left as-is, the message is, effectively, that Django lied
about its async support for years, but suddenly *now* is asking people
to trust the claims of async support. Unless another major bug gets
found, in which case "well, *now* you can trust Django on async" will
get kicked down the road again.

This is a showstopper of a bug, and just leaving it deliberately
unfixed in *every released version of Django* because "policy said no"
has the potential to do a lot of damage to Django's reputation.

> Adding the support here is difficult and slow enough. Backporting fixes to 
> discovered bugs, outside the established policy, is making an unrealistic 
> burden for ourselves.

I'm not saying every bug found with async needs a backport. But one
that literally prevents the built-in testing tool from working with a
huge swathe of views and middlewares (including potentially some built
in to Django itself), *when that tool is documented and Django claims
to officially support it*, is just unacceptable. I'll work up the
patches myself if that's what it takes.

-- 
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 receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CAL13Cg-tMbTXN3WwqjqjgiLj1rrMO6K8YhRHnci6Qzw2d52Y-w%40mail.gmail.com.

Re: Backport for ticket 34063?

2022-12-30 Thread James Bennett

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 whatever code will *read*
request.POST, not the code that generates the request. So that means a
no-op "request.body" in every view and every middleware that might
read request.POST. And that includes Django's own built-in views
(including generic views) and any built-in async-supporting
middlewares, if they have the misfortune to get called on the async
path from an AsyncClient-initiated request.

-- 
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 receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CAL13Cg_1MMt2DbcC%2B4Vfzi83g_U-bBNj2-J92Y1NWTvAS9c1Ww%40mail.gmail.com.

Re: Backport for ticket 34063?

2022-12-30 Thread James Bennett

On Fri, Dec 30, 2022 at 12:01 AM Carlton Gibson
 wrote:
> When I looked at the trace you posted in IRC yesterday, my first thought was 
> "3.2?". I think supporting Django 3.2 at this point isn't worth the effort.

It's also broken in 4.0 and 4.1. I just posted the first trace I got
back from my test matrix, which happened to be a Django 3.2 run.

> Yes, sure it's not EOL for another year or so but if folks want to use async 
> they should be on the latest version.

I strongly disagree with this -- Django has been claiming support for
async views/middlewares, and for testing them with AsyncClient, since
3.1. Telling people that actually it was badly broken to the point of
almost unusability until 4.2 and thus not to use any of those versions
that claimed to have the support is... suboptimal. Especially given,
as I noted, the difficulty for Django novices of even figuring out
what the heck is going on when they try to test an async view and get
a weird exception.

Or to put it another way: if I submitted patches against the 3.2, 4.0,
and 4.1 branches for docs/topics/testing/tools.txt that put a big
"WARNING! BROKEN! DO NOT USE!" on all mentions of AsyncClient, I doubt
those patches would be well-received. But that's basically what those
releases of Django *need* at this point. It's intolerably misleading
to end users of the framework to have docs for those versions claiming
that you can write async code and test it with the AsyncClient when...
well, you can't, really, unless you know the precise way that it's
broken and put explicit workarounds for the brokenness in all your
views and middlewares.

> You're wanting to add async support to your third-party library: super; just 
> say it's 4.2+ and move on.

And telling library authors not to even think about doing async
support until Django 4.2 comes out (approximately two and a half years
after Django itself claimed to officially support this stuff), and
that they have to cut off all older versions of Django when they do so
*despite those versions officially claiming to support async* just
seems like a recipe for those authors deciding not to trust or waste
their time on Django.

So I *really* think this one needs an exception to the backports
policy. Async is too important, and Django's reputation is too
important, to leave 3.2, 4.0, and 4.1 as badly broken as they
currently are.

-- 
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 receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CAL13Cg8ZjzR%3Dzd4PwY%2Bmg1pUMXzPDUx_0ZPetCam5xEM7xqS1w%40mail.gmail.com.

Backport for ticket 34063?

2022-12-29 Thread James Bennett

https://code.djangoproject.com/ticket/34063

The short summary of that ticket is that there was a significant
behavioral difference between django.test.Client and
django.test.AsyncClient: with AsyncClient, any view or middleware
which attempted to access request.POST without first accessing
request.body would raise an exception with an obscure message about
trying to read too much data from the request body. This was fixed
last month:

https://github.com/django/django/commit/c4eaa67e2b880db778c9fe6d9854fbdfcc16ecd2

However, it does not explicitly fall under any of the criteria for
backporting to older releases
(https://docs.djangoproject.com/en/dev/internals/release-process/#supported-versions)
so at the moment, the fix will only be available from Django 4.2
onward, and no previous Django versions will receive a backported
version of the fix (though the bug is present back to at least Django
3.2, and I suspect but haven't confirmed all the way back to the
introduction of AsyncClient in Django 3.1).

I'd like to argue for an exception to the normal backport policy, and
for #34063 to be backported to Django 4.1, 4.0, and 3.2 LTS.

My reasoning here is that async support is an incredibly important
part of the Python web ecosystem right now, and there is no good
alternative to django.test.AsyncClient for testing some kinds of async
code -- although the normal django.test.Client can hit URLs served by
async views, it does not always trigger async code paths inside Django
when doing so. For example, I came across #34063 while trying to test
a middleware that supports both sync and async usage; only AsyncClient
reliably exercises the async code path of such a middleware, but that
triggers the bug unless I add throwaway accesses of request.body.

Especially for authors of reusable applications/libraries that try to
support a broad range of Django versions, many of whom (like me!) are
finally getting around to async support, this is an unpleasant
situation, since it will require the request.body workaround to be
left in place in all such code for at least another 16 months or so
(which is when Django 3.2 LTS will finally drop out of upstream
support). And that's presuming such authors even know to put in the
workaround -- it took me quite a bit of debugging and following up on
irrelevant search results before I finally found #34063, and that's as
someone who has deep familiarity with Django -- someone less
experienced at delving into Django's internals to figure out root
causes and likely search terms would probably have had an even worse
time of it.

Finally, if it had been discovered prior to any of the releases in
which AsyncClient has been present, this would have been a clear
release blocker; it's quite a serious bug that seems to have gone
unnoticed for so long largely by accident (and, ironically, by
under-testing of the testing tools).

So I think the right thing to do, to help with Django's transition
into async support and to avoid imposing unnecessary burdens of
debugging on application and library authors, is to backport the fix
from #34063 to the full set of currently-supported Django releases:
4.1, 4.0, and 3.2 LTS.

-- 
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 receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CAL13Cg-Pexnfd7ynnOWEoLkmfM5gYhcMfHgkYzOG7nH8sWA9sQ%40mail.gmail.com.

Re: Integrate dj-database-url into Django

2022-11-28 Thread James Bennett

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
(https://pypi.org/project/django-environ/) is now one of the first
packages I reach for, and it has a much more comprehensive set of
helpers for configuring Django from environment variables and doing
appropriate parsing and type casts.

There also is Pydantic's settings model
(https://pydantic-docs.helpmanual.io/usage/settings/) which uses type
annotations to drive parsing/validation/type-casting and defaults to
reading from environment variables.

I'd rather see some sort of comprehensive "make settings-from-env
easier" in Django than one-off pieces like a database URL.

-- 
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 receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CAL13Cg-cqJi1JanmhN0S3rf1MYME9qH4XJsCEjLdB5wFXEQeAA%40mail.gmail.com.

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

2022-11-25 Thread James Bennett

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 a decorator.
>
> I’d like to see a form of CORS support in Django that more closely follows
> the design of the CSRF/clickjacking protection.
>
>> Another option: Content Security Policy support in core. The current
django-csp third-party app isn't necessarily bad, but I'd love to see more
good security tools in Django by default.

(some of this gets back to an old proposal for a consolidated top-level
SECURITY setting that could expand to cover all the tools, but that's
likely out of scope for a GSoC project)

-- 
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 receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CAL13Cg8zZZizDRvQCKfe4KS_tPS1zOyW-%3DZSQmj0MkZ7EGnGQA%40mail.gmail.com.

Re: Draft Steering Council DEP

2022-10-30 Thread James Bennett

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 the thing I've been saying repeatedly in the other
thread: how does this actually solve a problem that Django is facing right
now?

We've established that the Technical Board was not carrying out its duties.
There's also been a claim advanced that probably there is not a replacement
slate of board members who would step up and have the capacity to do what
DEP 10 asks.

So, either this new DEP is intended to be a slight clarification of the
Technical Board's role, in which case I don't see how saying "same as
before, but this time we actually expect you to do the thing" solves the
issue. Or it's intended to be a first step toward a more active group, in
which case I don't see how it can succeed given that a lower required level
of activity has already failed.

I also have concerns with the "Steering Council" name. In Python's case
it's something resembling Django's old technical board, which was made up
of core devs elected by core devs (technically Python does it as "must be
nominated by a core dev", not "must be a core dev", but in practice it
makes little difference). I don't want to create the impression that
Django's governance looks even a little bit like that, because it doesn't
look like that.

>

-- 
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 receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CAL13Cg-gULvacpiR6y8ZM89FKHeatoaaLZcj0Vrx9gPqGXG-XA%40mail.gmail.com.

Re: Proposal for Django Core Sprints

2022-10-26 Thread James Bennett

Organizing sprints is a fine idea, but:

* They should be designed around the assumption of remote-first, not
"hybrid" or in-person-first, and there should be no language in the
description whatsoever about in-person participation being important. There
simply are too many factors involved in trying to get a bunch of people all
in one place at the same time, and privileging in-person participation is
something I will put up massive resistance to.
* But I also think you're going to find that getting people to make another
commitment on top of existing events is going to be difficult, and so it
would make more sense to formally attach the sprint to a major event like
one of the DjangoCons.

Meanwhile, I think it is absolutely essential to drop the "Core" naming,
and to drop the idea that there are special classes of contributors whose
presence is especially needed.

Those last points, for me, are non-negotiable. The Django project
explicitly has only the roles defined in DEP 10. There are no special
statuses or classes of contributors whose input is more important than
others, and that is *deliberate*.

I knew when writing DEP 10 that some folks were never going to like the
flatter setup, and would probably eventually try to re-introduce something
resembling the old core team. I'm not saying that is what you're trying to
do here, or that that's what anyone else is trying to do right now, but it
feels like the proposals being put out right now are heading in that
direction, and I want to make sure we stop that before it gets even the
tiniest bit of traction.

On Wed, Oct 26, 2022 at 3:01 PM Paolo Melchiorre 
wrote:

> Following Andrew Godwin's example, I too share with you a proposal
> that I made during DjangoCon US 2022 and that I have already shared
> with some of you.
>
> Inspired by an article by Will Vincent, I wrote my proposal for Django
> Core Sprints, and its genesis, in an article and would also like to
> have the opinions of the Django community members interested in the
> idea:
>
> https://www.paulox.net/2022/10/26/about-my-proposal-for-the-django-core-sprints/
>
> Ciao,
> Paolo
> --
> Paolo Melchiorre
>
> https://www.paulox.net
>
> --
>
> ---
> You received this message because you are subscribed to the Google Groups
> "DSF Members" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to dsf-members+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/dsf-members/CAKFO%2Bx6FAf-M14fKx5QS1K8rru2L3mOiR1R%3Dn6FzDk%3DrnaUq3A%40mail.gmail.com
> .
>

-- 
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 receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CAL13Cg-TxdyiY623AkaB%3D_0pW_kHqy3wXTYe-Qh0Ar5CNgiV8Q%40mail.gmail.com.

Re: Changing the role of the Technical Board

2022-10-26 Thread James Bennett

On Wed, Oct 26, 2022 at 12:02 PM Andrew Godwin  wrote:

> At this point, it is my view that it is our job to govern with the people
> we have, and the time and energy they can provide, and that's my intention
> with these suggested changes.
>

If the problem in front of us is that the Technical Board isn't up to the
level of activity DEP 10 asks of them, and you believe no substitute group
of members exists that would be up to it either, I'm not sure I see how
your proposals are going to fix that, especially since you seem to
eventually want to create *more* responsibility for active intervention and
leadership.

>
At the end of the day, my feeling is that inaction is not the right path -
> we need to enact some sort of change. I'm more than willing to hear
> alternative suggestions for what that change should be (though as outlined
> previously, I really don't think that change should be "remove the entire
> current Board for underperformance and have another election").
>

A Technical Board election will automatically trigger at the release of
Django 4.2, which is not *that* far off. But the Technical Board could
always trigger an election any time they want to.

I personally would still like to understand how the current Technical Board
came to what seems to be such a misunderstanding of how the governance was
supposed to work. And while there have been explanations presented for why
the Technical Board didn't communicate the problems it was having, they
also come across as worrying -- we're all adults here, and we need to be
able to trust each other to speak up when there's a problem. How did we go,
apparently, multiple years with the Technical Board not carrying out their
responsibilities and also nobody saying anything about it?

Until we understand that I don't think we should be trying to change the
governance again.

And I still would like to see DEP 10 actually tried out. Maybe it involves
electing a Technical Board with much more explicit up-front communication
of expectations, since it seems a lot of the current members were unaware
of the Technical Board's actual responsibilities. Maybe it involves someone
just constantly poking them with reminders. Maybe something else. But it
feels wrong on many levels to start moving on from DEP 10 when it's
becoming increasingly clear that DEP 10 was never really *tried*.

-- 
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 receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CAL13Cg_%3DbczbtMP5B6avbNTLi%3DLf1SU_Z%3Dchz6j0u5L1MPMbzw%40mail.gmail.com.

Re: Changing the role of the Technical Board

2022-10-26 Thread James Bennett

I'm going to avoid trying to get too much into point-by-point
back-and-forth argument here, and try to present the larger picture.

The Technical Board has multiple active responsibilities under DEP 10.
Let's look at some of them:

1. Canvas for feature proposals once per feature release of Django. This
also comes with a responsibility to ensure the proposals are archived in a
useful way -- we used to have wiki pages in Trac for this, but DEP 10
doesn't require any specific mechanism. This is supposed to happen within
one week after feature freeze of each feature release.

2. Set the release schedule for each feature release of Django. This is
supposed to happen within one week after the prior feature release coming
out.

3. Maintain the teams of Mergers and Releasers, including by nominating and
confirming new members of those teams when the Technical Board considers it
necessary (or when the current roster falls below the DEP 10 quorum).

4. Vote, as requested, on DEPs.

5. Vote, as requested, on any technical decision that fails to resolve
through normal public discussion.

(1) has not been happening. It's possible that (2) has been happening and
just hasn't been that formally published, but I suspect it's been the
Fellows who've been doing that one. For 3-5, things have gone... not so
great.

It took multiple attempts to get the Technical Board to vote on the first
Merger nomination (Claude), and if we're being pedantic it still wasn't
quite done correctly because his appointment as a Merger should have been
temporary and auto-expired after the first Technical Board election unless
the new Board voted to confirm him permanently.

The first time the Technical Board voted on a DEP was the proposed DEP 484
for type hints. The Technical Board's discussion and voting on it
apparently took place entirely in private and the result was communicated
publicly via Carlton copy/pasting the reply he got from them. And we lucked
out that the Board didn't accept the DEP, because it was at a time when an
election was pending and thus they had no power to accept a DEP (similar to
the Merger nomination -- once an election triggers, the Board cannot accept
DEPs and can only make temporary appointments of Mergers/Releasers).

On (5) the only explicit request I can find in this mailing list's archive
is one from Carlton to make a decision on ticket 31747. Although several
Technical Board members posted opinions in response, I'm not finding any
statements of their votes on the matter.

If grant a half point for the Merger nomination (though the Board really
ought to hold a public vote to properly permanently confirm Claude), and
maybe another half point for the fact that release schedules have been
getting set (though, I suspect, not explicitly by the Board), that gets us
to 1 out of a possible 5. This is not a great track record.

Before we propose a different setup, I think we need to figure out what
went wrong here. It already seems like some members of the Technical Board
may not have really been familiar with the responsibilities, or may not
have understood that some of the required duties were in fact required. And
it seems that several members of the Technical Board found themselves in
positions where they didn't have the time/capacity to carry out the
responsibilities, but also took no action to communicate this outside the
Technical Board.

Are these things that would be solved by yet another governance rewrite? Or
are they things that could just as easily happen again? I suspect the
latter. So I think proposals for new governance should be on hold for now
until these things are sorted out.

Also, on a personal note, I'd be a bit annoyed if DEP 10 were basically
tossed aside without being properly tried in practice.

Re: Changing the role of the Technical Board

2022-10-25 Thread James Bennett

On Mon, Oct 24, 2022 at 6:33 PM Andrew Godwin  wrote:

> It has not. While I cannot speak for the other members of the Board, I got
> burnt out in 2019, and then the pandemic began, and so it has not really
> been something I've pushed for in the past three years (and I believe I was
> one of the drivers of getting that in DEP 10 in the first place). We never
> really got into the rhythm of doing it, and I think a lot of us got busy or
> burnt out.
>
> My personal belief is that if something is not working, it is time for a
> re-analysis of the situation and a change, even if what's written down in
> the rules is fine on its face.
>

Well.

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
that is going to fix it.

And it's not just the lack of canvassing for features that's worrying; if
members of the Technical Board didn't feel they were up to the job, they
should have let someone know that. Getting burned out or overcommitted is a
thing that happens, and a thing that was anticipated in drafting the
governance -- DEP 10 has a procedure for it!

Why did no member of the Technical Board do that?

This proposal is part of a larger set of community changes I would like to
> consider - I am, for obvious reasons, not blasting the community with them
> all at once, but I do believe that a strong, visible set of leaders, with a
> clearly outlined set of principles and shepherding a community-guided
> vision, is the most important thing to establish - both in terms of the
> Technical Board and the DSF Board.
>
> I have a much longer blog post in me about my evolving 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.
>

And I strongly disagree -- I think Django is far better off without
centralized hierarchical leadership, which is why I wrote and pushed DEP
10. People who want to be technical leaders for Django are free to do so
already; there's no need to have to occupy a formally-titled hierarchical
role in the project's governance in order to do that. And the lack of
requirement for such a formally-titled role is crucial to ensuring other
people feel *they* can jump in and start contributing their technical
leadership, too.

But what's most bothering me is that, from the sound of it, the DEP 10
governance wasn't even really tried.

I know people have asked for Technical Board input at least a couple times
in threads on the django-developers list, and I've looked at them and I'm
having a hard time finding anything resembling what was supposed to happen
under the DEP. It seems clear that the duty to collect feature proposals
was not carried out. And from the sound of what you're saying in this
thread, the Technical Board is mostly communicating with itself about this,
in private, when the direction of Django is supposed to be worked out
publicly and transparently. That's why we shut down the old private
communication spaces for the former "core team" after DEP 10 was adopted.

So forgive me for being blunt, but: if the Technical Board is not following
the governance we have, I think replacing the Technical Board's current
membership should be higher on the list of remedies than replacing the
governance.

>

-- 
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 receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CAL13Cg-rdfueZarLYZhysCpK58-H1f080uXad1EmWj%2Bt9uR13Q%40mail.gmail.com.

Re: Changing the role of the Technical Board

2022-10-24 Thread James Bennett

On Mon, Oct 24, 2022 at 2:24 PM Andrew Godwin  wrote:

> 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
> separately on an internal thread, where the current stance (not everyone
> has responded) is that I am personally happy to take on all the work here
> for now - but I want to make sure it's not just me in the long run, be that
> merely proving that the idea works or attracting board members who want to
> specifically mediate such discussions and interaction with the wider
> community.
>

I admit I haven't been following Django development all that closely since
I mic-dropped after DEP 10 passed, but this is worrying, because canvassing
for feature proposals is not an optional thing -- DEP 10 *requires* the
Technical Board to do this at least once per feature release of Django. Has
that not been occurring? Because if it hasn't, then we have a major
problem, and I don't see how the current proposal would resolve it.

Overall, if all we do is change the name and start actually doing calls for
> features as outlined in DEP 10, I'll honestly be happy - but I think, given
> the most recent TB election was uncontested and several long-time Django
> contributors have told me they'd be more willing to join a TB that was less
> strictly technical-all-the-time, that it makes sense for us to also look at
> those requirements.
>
> I have concerns about this because what it really feels like is a first
step toward merging the Technical Board and the DSF Board into a single
unified governance board of everything to do with Django, and I think the
split between governance of Django-the-codebase and
Django-the-everything-the-DSF-does is a useful and important one (not least
for legal reasons).

-- 
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 receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CAL13Cg93CvLgVU567MsvqKZAiWVBxxm1-L_YuEUhjr_JRySBwg%40mail.gmail.com.

Re: Changing the role of the Technical Board

2022-10-24 Thread James Bennett

Something I note here is that it's presenting a solution, but not clearly
(at least, from my reading) presenting the problem to be solved.

Is it a lack of people proposing features? If so, I'm not sure this helps
-- it would, to me, suggest that only members of the Technical
Board/Steering Council/whatever-it's called are supposed to do that, since
it's in their job description. Would people then expect to, or be expected
to, run for a seat in order to contribute something?

Is it a more general lack of engagement? If so, I'm still not sure how this
helps -- the idea of DEP 10 was to make it *easier* for people to step up
and get involved, since it got rid of the idea of the "core team" with
their special privileges, but I don't think any form of technical
governance actually solves engagement issues. At best it can make
engagement-specific efforts easier, but I don't see how re-centralizing
authority (or creating the impression of it) would achieve that.

Is it to make fundraising easier? That sounds again like something that
technical governance really can't do on its own -- it needs to involve the
DSF Board, and there are reasons why the DSF was historically wary about
doing targeted fundraising for specific features in Django.

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
balance where the more you loosen it up, the more you also open the door
for those kinds of people.

Also, regarding the multiple roles restriction: it currently is allowed for
a single person to simultaneously be on both the Technical Board and the
DSF Board, and there are even procedures in DEP 10 for things like
mandatory recusal for DSF Board votes and actions that affect the Technical
Board. What's not allowed is simultaneously being a Merger and on the
Technical Board.

Re: Why using django.contrib.sessions as the salt to encode session data? why not secret key?

2022-10-12 Thread James Bennett

On Wed, Oct 12, 2022 at 3:25 PM 'Adam Johnson' via Django developers
(Contributions to Django itself)  wrote:

> Thank you for diving into this John! All seems sensible then.
>
Yeah, the threat model here is you have, say, Endpoints A and B that each
work with HMAC'd values, and Endpoint A generates them based at least in
part on user input. With some cleverness, an attacker might figure out how
to get Endpoint A to generate an HMAC that Endpoint B will accept as valid.

Now, imagine that Endpoint B is, say, password reset.

This is why uses of HMAC should be namespaced. It's maybe unfortunate that
the exact keyword argument is named "salt" when people are used to that
being a unique-per-call random value rather than a constant, but a constant
is the expected pattern for many usages of HMAC in Django and in Django
apps.

-- 
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 receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CAL13Cg-vH4Otf6QWDnHpeYbufsDQfWfxhJ-1TF%3DS_iBk8CL%2BVw%40mail.gmail.com.

Re: Model-level validation

2022-10-09 Thread James Bennett

On Sat, Oct 8, 2022 at 8:32 PM Aaron Smith  wrote:

> Surely we can agree that *something* should happen here? The status quo
>> is confusing, a footgun and a gotcha. If it's not Model's concern, then get
>> it out of Model.
>>
>
I've already said that I wish model-level validation hadn't been added to
Django.

Unfortunately it's something that's been in long enough now that it would
be very difficult to deprecate and remove. But that's not an argument, to
my mind, for expanding it.

>

-- 
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 receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CAL13Cg8ZvG6%3DtCNEEKV-4rQURzZ_GFSuPRypkoOOqGULFC9pZw%40mail.gmail.com.

Re: Model-level validation

2022-10-08 Thread James Bennett

On Sat, Oct 8, 2022 at 8:44 AM Aaron Smith  wrote:

> The reason I don't want to use serializers or forms in celery tasks is
> because validation should happen every time a model attribute is changed.
> This pattern would mean more imports and boilerplate scattered around my
> codebase any time I want to update a status attribute on a model.
>

This feels to me like an important symptom -- regardless of ORM design
patterns (which I'll get to in a moment), data mutation should occur only
in well-defined, controlled ways. Having it "scattered around [the]
codebase" is somewhat worrying. In an Active Record ORM like Django, very
commonly this is just methods on the model itself exposing the desired
logical operations ("resolve this ticket", "publish this article", etc.),
while in a lot of Data Mapper ORM setups it would be in a "business logic"
or "domain" object or some sort of Repository pattern or CQRS setup or...
well, lots of options, but either way it would be strongly discouraged to
be directly mutating data from lots of places around the codebase.

I think you (and Django at large) are conflating Validation and
> conversion/serialization/santization/input filtering, I think of them as
> separate concepts.
>

I still think there's a static-versus-dynamic thing going on here where the
type conversion is seen as an afterthought in statically-typed frameworks
simply because they're statically typed (and a similar phenomenon occurs in
Python with Pydantic).

But the basic point -- that a web framework will have to do validation
that's completely independent of the persistence layer -- stands. There are
simply too many use cases for
forms/submissions/payloads/whatever-you-call-them that *don't* get
persisted to the DB, as I mentioned in my original message. Once that's
established, it's inevitable that a validation -- not just conversion --
layer is needed that isn't tied to the persistence layer. And once that
exists, it's reasonable to ask whether having *another* one in the
persistence layer is wasteful/redundant.

Anyway, I've explained this about as thoroughly as I can now. I think the
real underlying problem here is an unsupported generalization from liking a
particular pattern to deciding that pattern is objectively the only
correct/acceptable one. There are lots of acceptable patterns for how to
design and build and use ORMs and surrounding code. Django has settled on
one in particular, and isn't the only Python framework or ORM to have
settled on it. That doesn't mean it's wrong or bad, just that it's
different from the pattern you want or are used to.

And so I am still very strongly against trying to push a
model-layer-validation approach in Django, even optionally. Django's
pattern is fine, and works well/makes sense for a web framework, for the
reasons I've gone over multiple times now. I would suggest once again that
you adapt to it, because fighting against a framework is never pleasant.
Or, failing that, I'd suggest that you look into switching to something
better suited to your preferences.

-- 
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 receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CAL13Cg9NBVH-enng5C_4KaSQeRUsWLe5%2BEnkomsgCKXGj2UkiA%40mail.gmail.com.

Re: Model-level validation

2022-10-08 Thread James Bennett

On Fri, Oct 7, 2022 at 6:21 PM Aaron Smith  wrote:

> Mariusz - fair enough, I will consider my point made and apologies if it
> came off too strong. FWIW it's not just my opinion, it's shared by every
> developer (dozens) I've had this conversation with up until now. It's a
> stark contrast that makes me wonder how aware the core developers / old
> timers are of the broader user base's experience.

I would wonder how many of these developers you've talked to are used to
working in Python.

The main standalone ORM package people use in Python is SQLAlchemy, which
*also* does not do validation in the ORM layer. The last time I worked with
Flask, the standard practice was to use Marshmallow to write serializers,
and these days the popular async frameworks like Starlite and FastAPI have
you write Pydantic models. In either case they fill the role of, say, a DRF
serializer -- they do the validation, and data type conversion at the
application boundaries, so that the ORM doesn't have to.

It's true that when you start branching out into other languages you'll
encounter ORMs which have validation built-in, like Entity Framework or
Hibernate, but you'll also more often encounter that in statically-typed
languages where the data conversion step has already been handled for you.
It's also not always clear that the ORM is the right place for validation,
since often the rules being enforced are ones that aren't actually enforced
at the DB level by constraints.

Either way, I think I've made the case for why Django doesn't and shouldn't
do this. You seem to have a strong reluctance to use either Django forms
(in a "vanilla" Django project) or DRF serializers (in a more "API"
project) to validate data from sources other than direct user-initiated
HTTP request, but I don't really get that -- the validation utilities are
there, and if you're not willing to use them that still is not Django's
problem to solve -- after all, someone else might be equally set in their
conviction that all the existing validation layers are the wrong way to do
things, and demand we add yet another one, and I doubt you'd be supportive
of that.

So I think Django should continue to be Django, and validation should
continue to be a layer independent of the ORM (which, as I originally
noted, it *has* to be in a web framework, since not every use case for
validation will end up touching the database). For that reason I'd be very
strongly against ever adding even an optional default enforcement of
model-level data validation.

>

-- 
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 receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CAL13Cg90kbJtO50%3D8%3DPeVN0RkXuB5ixP87jv%3DGmZ-JhJ4CU9Uw%40mail.gmail.com.

Re: Model-level validation

2022-10-06 Thread James Bennett

On Thu, Oct 6, 2022 at 9:00 AM Aaron Smith  wrote:

> James - The problem with moving validation up the stack, i.e. to logical
> branches from Model (Form, Serializer) is that you must duplicate
> validation logic if your data comes from multiple sources or domains (web
> forms *and* API endpoints *and* CSVs polled from S3. Duplication leads to
> divergence leads to horrible data integrity bugs and no amount of test
> coverage can guarantee safety. Even if you consider Django to be "only a
> web framework" I would still argue that validation should be centralized in
> the data storage layer. Validity is a core property of data. Serialization
> and conversion changes between sources and is a different concern than
> validation.
>

I would flip this around and point out that the duplication comes from
seeing the existing data conversion/validation layer and deciding not to
use it.

There's nothing that requires you to pass in an HttpRequest instance to use
a form or a serializer -- you can throw a dict of data from any source into
one and have it convert/validate for you.  Those APIs are also designed to
be easy to check and easy to return useful error messages from on failed
validation, while a model's save() has no option other than to throw an
exception at you and demand you parse the details out of it (because it was
designed as part of an overall web framework that already had the
validation layer elsewhere).

So I would argue, once again, that the solution to your problem is to use
the existing data conversion/validation utilities (forms or serializers)
regardless of the source of the data. If you refuse to, I don't think
that's Django's problem to solve.

>

-- 
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 receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CAL13Cg-fB_hMSDz3_Ox8svEiqX%3DhGHxnTLFAkyT55M2NKgGYzg%40mail.gmail.com.

Re: Model-level validation

2022-10-06 Thread James Bennett

I see a lot of people mentioning that other ORMs do validation, but not
picking up on a key difference:

Many ORMs are designed as standalone packages. For example, in Python
SQLAlchemy is a standalone DB/ORM package, and other languages have similar
popular ORMs.

But Django's ORM isn't standalone. It's tightly integrated into Django, and
Django is a web framework. And once you focus *specifically* on the web
framework use case, suddenly things start going differently.

For example: data on the web is "stringly-typed" (effectively, since HTTP
doesn't really have data types) and comes in via HTML's form mechanism or
other string-y formats like JSON or XML payloads. So you need not just data
*validation*, but data *conversion* which works for the web use case.

And since the web use case inevitably involves supporting forms/payloads
that don't persist to a relational data store -- think of, for example, a
contact form that sends an email, or forms that store their results
client-side for things like language or theme preferences -- you inevitably
end up needing to do data conversion and validation *independently of the
ORM*.

And at that point, you have to start asking tough questions about whether
it's worth having *two* conversion and validation layers, just because
"every other ORM has this, so we have to put one in the ORM".

Which basically is where Django is. Yes, there are utilities to do your
data conversion and validation in the ORM layer if you want to. But Django
is, first and foremost, a web framework, which needs to support the web use
case I've described above, and so its primary conversion/validation layer
can never be the ORM.

Personally, I wish model-level validation had never been added even as an
option, because in a web framework like Django it's conceptually the wrong
place to put the validation logic. Though that battle was lost many years
ago, I'd be *strongly* against trying to expand it or start forcing the ORM
to default to doing validation work that, in Django, properly belongs to
the forms layer (or to serializers if you use DRF).

So: Django ships with ModelForm, which does the hard work of auto-deriving
as much validation logic as possible from your model definition so you
don't have to repeat it. DRF ships with ModelSerializer, which does the
same thing for its validation/conversion layer. I would strongly urge
people to use them. Trying to force all that validation back into the model
layer misses the bigger picture of what Django is and how it works.

Re: Switching to PEP 621 project metadata

2022-07-25 Thread James Bennett

On Mon, Jul 25, 2022 at 8:04 AM Ofek Lev  wrote:

> Can we please quantify such heuristics? I want something concrete to write
> in my OSS to-do list :)
>

I don't think we can or should provide an exact number of other projects
that need to adopt what you're doing before we will. It's more of a "we'll
know it when we see it" thing.

I can't find any such events; do you happen to have links? I'd like to
> improve Python's packaging experience, in this case by learning from the
> past.
>

Their GitHub issues have a packaging tag which turns up a fair number of
things, and searching their GitHub issues for terms like "wheel" or "PEP
517" or other packaging terms will generally find the rest.

-- 
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 receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CAL13Cg-OqkjsnEXN-Z8ZKSLyMJtDbJD7dEqBwcLyqoV-2WM2vA%40mail.gmail.com.

Re: Switching to PEP 621 project metadata

2022-07-24 Thread James Bennett

On Sun, Jul 24, 2022 at 1:34 PM Ofek Lev  wrote:

> > My initial reaction is "no", and that this request kind of rubs me the
> wrong way. In the pull request you say [...] But the blog post you quote is
> just saying to run "python -m build" instead of "python setup.py"
>
> This issue is that the `python -m build`/PEP 517 way does not support the
> deprecated RPM logic. I tried to articulate that as best as I could; I'm
> sorry if it wasn't clear!

We can run `python -m build` pretty much as-is using setuptools as the
build backend, though, and that suffices for Django's packaging needs.

I'm not familiar with what happened with black but I think you might be
> referencing how the recommended style was in flux for a time.
>

I am referring to the multiple occasions on which black's approach to
packaging caused installation of the package, via pip, to fail in often
mysterious ways.

This is something that's documented in the history of their issue tracker,
and that the maintainers have since apologized for and adopted policies to
try to prevent in the future.

>

-- 
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 receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CAL13Cg_F1JxY5ANKw53LvEYc8_JjJGb_%2BSs-dZ2YxWr_tRw1Vw%40mail.gmail.com.

Re: Switching to PEP 621 project metadata

2022-07-24 Thread James Bennett

On Sun, Jul 24, 2022 at 10:06 AM Ofek Lev wrote:

> Hello! This is about using only `pyproject.toml` for packaging
> https://github.com/django/django/pull/15874

My initial reaction is "no", and that this request kind of rubs me the
wrong way. In the pull request you say:

> As a result, the execution of setup.py files is now heavily discouraged
.

But the blog post you quote is just saying to run "python -m build" instead
of "python setup.py", not to entirely remove setup.py, or that using
setup.py as a configuration file is deprecated. In fact, the highlighted
tl;dr at the top of the post says exactly the *opposite* of that!

Setting that aside I also am, in general, strongly against Django being an
early adopter of any new packaging tool. While it's certainly helpful for
the tool, because our user base is large enough to uncover all sorts of
edge cases, it's not great for our users, who then get to be beta testers
against their will. I went through this myself with the code formatter
`black`, which was an eager and early adopter of several things and as a
result would break my CI pipelines every couple of months when one of those
early-adopted things had unintended side effects. Doing that to Django's
user base would be bad for our users, bad for Django ("why does Django keep
breaking?"), and bad for Python ("look, if even these high-profile packages
break all the time, Python packaging must really be as terrible as everyone
claims it is!").

So for now, the non-setup.py packaging ecosystem is still rapidly
developing and still has rough edges. Maybe in a few years when the
situation is improved, Django can adopt new and solid standard methods of
doing things. But for now, the solid standard still very much is setup.py
and the setuptools build backend.

About all I could support at the moment is switching the Makefile that
release managers run to use `python -m build`:
https://github.com/django/django/blob/main/extras/Makefile

Re: Idea: Add .checked(/) to QuerySet as alternative to .filter() w/ .first()

2022-07-14 Thread James Bennett

On Thu, Jul 14, 2022 at 4:09 PM Dave Gaeddert 
wrote:

> Yeah, I hope I'm not coming off as being too pushy, but I'm just curious
> why that is. Mariusz or Adam, did what I said about it being *more* than
> just an alias for `filter().first()` make sense or am I missing something?
> (Different behavior for multiple results — on accident or otherwise)
>

Speaking for myself:

I’d be against it because we’re getting into combinatorial territory with
diminishing returns. Adding this one opens the door to equally long and
repetitive threads in the future asking for all the others, and with less
room to push back each time.

Currently, Django covers the common cases of “if you didn’t find a match,
404” and “if there’s not exactly one result for this, throw an exception
and let me catch it”. The fact that you can make other variants kinda work
if you use first() or similar methods doesn’t, to me, obligate Django to
also provide the full matrix of methods doing all the someone-might-want-it
combinations of DoesNotExist, MultipleObjectsReturned, and None. People who
want specific behaviors not covered by the built-in stuff should write
their own, or somebody should make a
django-all-the-get-single-object-methods package and everybody who wants
one of these methods can install and use it.

>

-- 
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 receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CAL13Cg_UjHey%3DnTq8y0zycbCAQe9Cx%3DMh%2BaVFDu1hjukmae3pg%40mail.gmail.com.

Re: Blocking disposable or temporary email addresses

2022-05-11 Thread James Bennett

On Wed, May 11, 2022 at 2:21 PM Yonas 
wrote:

> What does the community think about adding a feature to Django where
> disposable or temporary emails are not accepted during account registration?

I used to try to do this in my django-registration package, but eventually
gave up on it because maintaining an up-to-date list of all possible
domains and other patterns was not feasible. I expect the same would be
true with Django — it would require frequent updates to the list of
domains/patterns to block, and people would complain that the updates
weren’t fast enough, because Django only releases once a month (and that’s
assuming updates to the blocked email list would be considered for
inclusion in the monthly bugfix releases, rather than only at feature
release updates).

So I expect this isn’t something Django could or should do.

-- 
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 receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CAL13Cg8hgvUkoQyQJ9ryXY%2ByvuabAjonUY4VibXtzmWAYYtt7Q%40mail.gmail.com.

Re: AppConfig subclass-subclass ignored

2022-02-06 Thread James Bennett

On Sat, Feb 5, 2022 at 7:39 AM Christian González
 wrote:
> Disclaimer: Yes, I know that I am somehow polluting the AppConfig namespace 
> with attrs and methods that could clash with the ones you will add in far 
> future... Pretix does that too, and honestly, there is hardly a good method, 
> except creating  that methods in another model and using AppConfigs only as 
> proxy with a pointer to that model...

I think this kind of gets at the core of the issue -- the namespace --
but not quite the right one, since the real issue is what you've put
into the module-level namespace of your apps.py, not the attributes
you're setting on your AppConfig.

So, Django *could* do some trickery to try to figure out how many
AppConfig subclasses in the module-level namespace were actually
defined in that specific 'apps' module, and decide that if there's
only one then that's the default, ignoring any that happen to be there
as a result of imports from other modules.

But then someone would write an email to this list saying that their
workflow involves a single AppConfig class that defines all the things
they want, and is just imported into apps.py, and why is Django no
longer respecting that? After all, it's an AppConfig subclass and it's
in the namespace of their apps.py, and there are no others visible
there, and Django's documentation clearly states that they shouldn't
have to do anything else!

So there's not really a "works for absolutely every use case" solution
here. Personally, I think that Django currently is doing the best
thing it can (given that there is no perfect thing available to do),
and that probably Django's behavior should not change. This means that
for your specific case you'll need to set default=True on the
AppConfig you want Django to use, but the documentation already was
telling you that :)

-- 
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 receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CAL13Cg8_rbQZOmtCBe%3DroNjWZYDyWE79Oc5fhcoYntrT-Pan2A%40mail.gmail.com.

Re: What to do about formfield_callback?

2021-06-05 Thread James Bennett

On Fri, Jun 4, 2021 at 11:54 PM Carlton Gibson  wrote:
> I'm sympathetic to the suggestion here, but wary of expanding the Forms API, 
> which already has a number of different ways of holding it.
>
> > ...to impose uniform custom widget attributes and error messages across a 
> > bunch of ModelForms...
>
> My initial query is, would not defining `field_classes`[1] on, say, a base 
> form class for your project be a/the way to go here?

Without getting too far off into details, the basic issue is I have an
app where there are a lot of ModelForms, and for certain model field
types we want the form field to always get set up in a way that
differs from Django's defaults (think of, say, always wanting a
particular custom widget setup, or custom error messages, for a
particular model field type).

It's a thing that you *can* do by writing out overrides or
re-declarations of the relevant fields on each form. But when you have
dozens of forms and there's no consistent pattern to the naming of the
fields you want to override, it gets really tedious to write out and
maintain all those overrides.

Which is why the code uses formfield_callback -- that is Django's
customization hook for this type of "every instance of model field of
this type, output a form field of this type" stuff. And it's already
crept into documented API, to some extent, because the model
form/formset factories document it as a parameter.

So I'd just like for it to become proper fully-documented API with
consistent behavior (since right now its behavior and effect varies
according to how you specify it and how you construct your forms).

(the only other real alternative right now is to go write a custom
model field subclass and implement formfield() on it, then go migrate
a bunch of models to use the new custom field instead of the default
Django one. But it feels odd and wrong to me that form-only behavior
would need to be overridden in the model rather than in the form)

-- 
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 receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CAL13Cg8thHw7Sj-8KoAzU4J0QgWo9EXMNXDw1jkt2QtZBvDf5g%40mail.gmail.com.

What to do about formfield_callback?

2021-06-04 Thread James Bennett

Currently, the ability to set 'formfield_callback' on a ModelForm is
undocumented, and a ticket to document it[1] was closed wontfix by Tim
with the comment:

> The attribute is described as an "internal implementation detail" in #12915
> and the possibility of moving it to Meta is discussed. Therefore, I don't
> think it's a good idea to document it as currently implemented.

I currently have an issue with a codebase at work which uses
formfield_callback (to impose uniform custom widget attributes and
error messages across a bunch of ModelForms) which is not quite
working as intended because of a somewhat-complex chain of issues:

1. The forms define formfield_callback
2. When ModelFormMetaclass runs it *pops* the 'formfield_callback'
attribute out of the form class, meaning it's no longer present
3. Some of those forms later get passed to modelformset_factory, and
since they no longer have formfield_callback set on them the forms
constructed by the factory do not get the effect of the
formfield_callback.

Which in turn is going to be solved, for now, by a bit of a hack which
will effectively triplicate the declaration of formfield_callback for
these forms:

1. Declare the "real" formfield_callback inside the form's Meta
(necessary to preserve it from being popped away by
ModelFormMetaclass)
2. Redeclare it on the form class as 'formfield_callback =
Meta.formfield_callback' (necessary for normal construction of the
form to work properly)
3. In view code which constructs formsets, look for
Meta.formfield_callback, grab it when present and pass it as the
formfield_callback argument to modelformset_factory (necessary for
formset construction to work properly)

One reason why this gets complicated is that Django has weird and
inconsistent support for declaring formfield_callback on Meta (the
reason appears to be that it's only allowed in order to support the
argument to modelform_factory). Suppose you have a ModelForm class
called "MyForm" which declares formfield_callback in its Meta. Now, as
far as I can tell, this will happen:

* Constructing instances of MyForm directly (i.e., via "my_form =
MyForm()") will *not* invoke the callback
* Constructing instances of MyForm via modelform_factory or
modelformset_factory *will* invoke the callback
* Defining a subclass of MyForm *will* pass on the formfield_callback
inherited from the parent Meta and use it when directly constructing
instances of the *subclass*

This seems to me to be sub-optimal.

So I'd like to propose the following:

1. Make formfield_callback officially supported and documented as an
attribute of ModelForm.Meta.
2. Have modelform_factory pick up a formfield_callback declared on
Meta and use it.
3. Put the current undocumented support for setting it directly on the
form class through deprecation.

If this started immediately we could have it supported for Django 4.0,
and the deprecation could complete in Django 4.2.

[1] https://code.djangoproject.com/ticket/26456

Re: Proposal to add attribute 'step' to FloatField and DecimalField

2021-03-22 Thread James Bennett

There are ways to check "close enough" equality for floats. There's
even the math.isclose() function which is arbitrarily tune-able:

https://docs.python.org/3/library/math.html#math.isclose

-- 
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 receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CAL13Cg9kom4X57gaUp%2Bq8%3DqdEF_33hTEZ9AMi8bucXjaKXsX8Q%40mail.gmail.com.

Re: 'npm init django' works, maybe let's stop that?

2021-03-08 Thread James Bennett

It's not really a discussion of whether "we" (this list) want
something removed; how to enforce Django's trademark is purely the
domain of the DSF. The DSF also has the ability to wave its ownership
of the trademark around and hire lawyers in cases where people are
reluctant to take something down, which has happened in the past. So
again I'd say that if people are putting packages up that seem to
conflict with the Django trademark, just notify the DSF board and let
them handle it.

-- 
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 receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CAL13Cg-quQd%3DgqhC2WbpBYqtEmg%3D2u56UwK6%3DHm3AB90m1XP%3Dg%40mail.gmail.com.

Re: 'npm init django' works, maybe let's stop that?

2021-03-07 Thread James Bennett

Any time this happens, just notify the DSF Board; they're the ones
with the legal standing to enforce the trademark.

-- 
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 receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CAL13Cg_%2B8qTkAFF82_6PrYt3BcTh_j6HtgHRQzKnn-D1XMD%2BMQ%40mail.gmail.com.

Re: About the ORM icontains operator's disadvantage on PostgreSQL performance and query results.

2021-02-28 Thread James Bennett

On Sun, Feb 28, 2021 at 2:39 AM Tom Forbes  wrote:
>
> Thank you for the clarification! I think the biggest argument for this change 
> is the fact that uppercasing Unicode can cause incorrect results to be 
> returned.
>
> Given that we now have much better support for custom index types, perhaps we 
> should change this? We need a custom expression index anyway, so it might not 
> be a huge ask to say “now you should use a gin index”?

It's worth pointing out that case mapping and transformation in
Unicode is difficult and complex. I wrote up an intro to the problem a
while back:

https://www.b-list.org/weblog/2018/nov/26/case/

One thing that's important to note is that there is no generic
one-size-fits-all-languages option that Django can just do by default
and get the right results. For example, a case mapping that does the
right thing for Turkish will do the wrong thing for (to pick a random
example) French, and vice-versa. Unicode itself provides a basic "hope
for the best" set of default case mappings that do the right thing for
many cased scripts, but also is clear in saying that you may need to
use a locale-specific mapping to get what you really want.

Postgres has the ability to configure locale, and when configured it
does the "right thing" -- for example, when the locale is tr_TR or
another Turkish locale variant, the UPPER() function should correctly
handle dotted versus dotless 'i' as required for Turkish. But Postgres
also warns that this will have performance impact, which I think is
what's being noted in the ticket.

I'm not sure there will be an easy or obvious solution here.

-- 
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 receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CAL13Cg9nYMJZwm2XcsCcWG5Fqn8gqqE93FM11Xcfs4TXsmTbZQ%40mail.gmail.com.

Re: Technical Board Decision Needed: Admin append_slash behaviour.

2021-01-06 Thread James Bennett

I'm going to be the contrarian here and at least ask whether the right
answer is "don't do any of these options".

To see why, consider a hypothetical world where we do one of the above
options, and a site sets whatever config is necessary to disable
APPEND_SLASH behavior in the admin.

The very next thing we're going to get is a report to the security address
saying there's a detectable timing difference between what we do to hide a
real app/model from a user with admin-access-but-not-to-that-model/app, and
what we do when that app/model genuinely doesn't exist, and in order to
properly hide apps/models could we please address that?

(and if we do end up taking one of the above options, please consider this
my report of this vulnerability, as I can pretty much guarantee that
404'ing a nonexistent app/model will be faster than finding it, resolving a
URL into it, and doing the associated permission check)

And this will never end. For a user who already has been granted admin
access, there likely *always* will be some detectable difference between
the admin's behavior with respect to a model/app that isn't present versus
one that is present but for which the user is not authorized. In an app
with the complexity of the admin, there are just too many possible
behavioral-difference vectors that people will be able to come up with, and
we'll never be able to close them all reliably.

So what I'd really like us to do here is pause and consider what kinds of
guarantees we can really commit to. Some are obvious and good and we
already do or try to do them -- you shouldn't be able to
access/modify/delete things you haven't been granted access to, you
shouldn't be able to escalate your own privileges, you shouldn't be able to
XSS the admin, etc.

But it's not at all clear to me that "the existence or nonexistence of
apps/models to which they don't have access is undetectable to an admin
user" is one of the guarantees the admin should make. I understand the
rationale, but I'm not sure the threat it wants to be securing against is
one we reasonably *can* secure against.

-- 
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 receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CAL13Cg_1QRhht3eSD29AJ25Cbkp%2BfbCxyOi7GdhYpfzcEkmDbQ%40mail.gmail.com.

Re: Unapplying migrations in a branch

2020-12-16 Thread James Bennett

On Wed, Dec 16, 2020 at 1:39 PM Adam Johnson  wrote:
>> manage.py migrate app 0050_migration_from_master will unapply too much 
>> (specifically, all the subsequent migrations from master)
>
>
> I don't follow you. This is exactly the thing I do, migrating back to the 
> last common migration.

I think the issue being described is if other apps have migrations
that *should* be applied in the main branch, but would be unapplied by
migrating back to app/0050. So migrating to app/0050 does not actually
restore the state the main branch expected.

I'm also not sure this is a thing that Django can automate in any way
that's likely to be reliable; too many migrations in large projects
have complex interdependencies, a lot of migrations aren't reversible,
etc.

-- 
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 receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CAL13Cg_dC5Fp%2BCu6xe%2BAzR-xdzwrp96LTZ8SWBwsOt%3DgrObtyg%40mail.gmail.com.

Re: Replace the default django test runner to a more robust testing framework (like pytest)

2020-12-15 Thread James Bennett

On Tue, Dec 15, 2020 at 6:07 PM Diptesh Choudhuri
wrote:
> Instead of removing the default test runner altogether, I can work on adding
> a TESTING_BACKEND variable in settings.py with possible values being
> 'django.testing.backends.pytest' (default) or
> 'django.testing.backends.DefaultRunner'. This way we need not compromise on
> the features that the default runner provides over pytest. Meanwhile I could
> work on some the issues pytest has by contributing to pytest-dev.

I would be against both the original proposal to switch Django to
pytest, and this proposal.

And it's not just because I'm a little bit biased here -- though I am,
in that I personally dislike pytest and when I use it in personal
projects I use it solely as a runner, where the tests themselves all
use the unittest and mock modules in the Python standard library.

There are several independent reasons why I don't think either of
these proposals is a good fit for Django:

One is that even though it's easier at first to add dependencies to
Django now than it was 15 years ago, every dependency still should be
carefully considered. It wasn't too long ago that this proposal would
have been "switch the Django test runner to nose", and now nose is
unmaintained and deprecated (its last release was in 2015) and though
there's a maintained "nose2" fork, it's not compatible with the
original and doesn't have anywhere near the development momentum the
original had. You might observe that pytest shows no signs of having
that happen to it, but the fact that it *can* happen has to be
considered when we're talking about integrating it into one of
Django's core components; we can think it's likely, and be hopeful,
that pytest would still be around and actively maintained 5 years from
now, but we can be much more certain that the Python standard
library's unittest module will still be around and actively
maintained.

Another is that pytest would be effectively a test-only dependency,
and the history of *those* in Python projects is largely an unhappy
and complicated one. It would create a potential risk for unwary users
(forgetting to install the extra dependency, or to do "pip install
Django[pytest]" or similar), or force every installation of Django --
including production installations which often don't want a large
third-party framework that won't be used at all in production -- to
also install pytest.

Still another is the basic incompatibility between pytest and unittest
runners. While it's true that Django lets you configure a lot of
things, they all are handled through carefully normalized APIs, so
that you don't notice the difference. This is what lets you start out
development with a local SQLite database and switch to Postgres when
you deploy, for example, or swap out cache or session or
authentication or email-sending backends without needing to rewrite
your own code that uses those features, because Django provides
normalized APIs for accessing whichever backend it's been configured
to use. But pytest is not that simple: pytest can run tests written in
unittest style, but unittest cannot run tests written in pytest style.
Only pytest -- which understands its own conventions for setup,
fixture loading, and so on -- can do this. Which means that if I write
my Django app using pytest style, and you want to use it in your
project that's otherwise completely unittest style, you cannot
integrate with full testing support unless you also switch your whole
project's configuration to pytest. That's a *big* difference from,
say, switching to a new auth backend.

So I'm in agreement with others in this thread that if you want to
improve things for people who prefer to use pytest, contributing to
pytest, pytest-django, and related projects would be a fine way to do
so. But trying to switch Django itself to pytest, or to introduce a
"test backend" concept that would have a pytest runner, does not seem
to me like a good idea.

Re: Admin accessibility

2020-11-02 Thread James Bennett

Taking this as a question posed under the DEP 10 voting process of whether
or not to accept DEP 11:

I vote +1.

I think the basic idea is good; there are a couple things worth clarifying,
mostly in terms of oversight, but that can be addressed in later edits.

And by "oversight" I mean a clear statement of how members of the team are
to be chosen, who will do the choosing, and whether the ultimate
responsibility lies with the Django Technical Board or with the DSF Board
of Directors. Since the scope of the DEP includes things that the Technical
Board lacks authority over, it may need to be the DSF Board or a mix of
both; also, the DSF Board would need to formally accept that responsibility.

On Thu, Oct 29, 2020 at 4:01 AM Carlton Gibson 
wrote:

> Hello all.
>
> Can I ask the Technical Board for Review and Resolution
> 
> on DEP 11 please?
>
> https://github.com/django/deps/pull/69/
>
> (Please let me know if I've done that wrong.)
>
> Kind regards,
> Carlton
>
> On Thursday, 22 October 2020 at 10:43:03 UTC+2 Carlton Gibson wrote:
>
>> Hi all.
>>
>> The DEP for creating an accessibility team is looking good.
>> https://github.com/django/deps/pull/69
>>
>> I'm going to ask for formal consideration shortly.
>> If you have an interest/a moment, over the weekend say, to give it a
>> glance before that, then any comments will be gratefully received I'm sure.
>>
>> Thanks.
>>
>> Kind Regards,
>>
>> Carlton
>>
>>
>> On Wednesday, 16 September 2020 at 00:17:35 UTC+2 Thibaud Colas wrote:
>>
>>> I’d love to! But worth bearing in mind that I haven’t done any Django
>>> contributions before.
>>>
>>> I decided to end my talk with a call for feedback on your DEP – this
>>> feels like the ideal call to action to end on.
>>>
>>> On Monday, 14 September 2020 at 18:00:03 UTC+1 t...@carrick.eu wrote:
>>>
 Carlton, I think that would be useful, thanks.

 Thibaud, shall I add you to the implementation team? It seems like
 you're doing more work on this than I am lately. I think we could still use
 one or perhaps two more people, but I think it's a good start.

 On Mon, 14 Sep 2020 at 16:44, Carlton Gibson 
 wrote:

> Hi All.
>
> Thanks for this. I'd be happy to play *Shepherd *if you need someone
> to put their hand up.
> I think that means I need to nag about getting it done. So... 
>
> Who's going to be on the team to do the first review, and then
> subsequent work? Answer that and you have the Implementation Team.
> I like that you've thought about how the team can refresh periodically
> — I don't suppose the burden will be too great but folks tend to cycle-out
> naturally, so good to plan for that.
> Thibaud: Asking for hands in your talk seems sensible.
>
> Kind Regards,
>
> Carlton
>
>
>
> On Sunday, 6 September 2020 at 00:45:36 UTC+2 Thibaud Colas wrote:
>
>> Hi all,
>>
>> Now that the DEP PR has been submitted I was wondering what the next
>> steps would be. According to the documented DEP process I found, it’s at
>> the "forming the team"
>> 
>> stage? How do you go about creating an *Implementation Team* and
>> finding a *Shepherd*?
>>
>> The main reason I ask is that I’ll be giving a talk about
>> accessibility at DjangoCon EU in a couple of weeks, and I thought it 
>> would
>> be a good occasion to raise awareness of the issues with the Django 
>> admin,
>> and mention this DEP. But I want to make sure I provide accurate
>> information.
>>
>> Thanks in advance,
>>
>> Thibaud
>>
>> On Tuesday, 14 July 2020 at 09:37:01 UTC+1 Thibaud Colas wrote:
>>
>>>  it’s wonderful to see this happening! Re-reading through the
>>> whole thing, as Tobias mentioned I also find it very easy to read, and
>>> makes a good case.
>>>
>>> On Tuesday, 14 July 2020 at 09:24:15 UTC+1 t...@carrick.eu wrote:
>>>
 I've added a PR to the DEPs repo to hopefully get some eyes on it:
 https://github.com/django/deps/pull/69

 Thibaud, I think whatever you have the time and motivation for
 sounds good, all of those things are useful. If you're not sure about 
 all
 the admin features, I think that's pretty normal. One project I've had 
 on
 my mind for a while now is to build a simple django site that is
 essentially just there to use every feature of the admin, so I might 
 bump
 that up the priority list, though it's somewhat daunting.

 Cheers,
 Tom

 On Mon, 13 Jul 2020 at 01:15, Thibaud Colas 
 wrote:

> Update for the proof of concept CI tests from my side – thank you

Re: Oddity found in password creation

2020-10-07 Thread James Bennett

On Tue, Oct 6, 2020 at 9:07 AM Florian Apolloner  wrote:
> So, I have been digging a little bit more and it seems there was a conscious 
> decision to not include an entropy check or character classes: 
> https://groups.google.com/g/django-developers/c/9GBhgGXmEKs/m/toKKgGhaqewJ -- 
> But I have to admit that this is all I could find and I was rather surprised 
> when you brought up the topic. I certainly would also have expected stronger 
> validation by default (then again I tend to customize those settings very 
> early on usually) -- maybe some kind of entropy check (but it's hard to write 
> a good error message on those).

A lot of this comes down to the threat model. Once upon a time, people
prioritized "someone randomly guesses my password" as a major threat
model and built validation routines to try to defeat it, by requiring
high-entropy passwords.

But the problem with this is that we've learned from experience what
the far more common threat model is: some site you used once gets
hacked, someone cracks all the hashes dumped from its user table (if
it even hashed...), and then they know that
jane...@example.com/"Passw0rd!" is a valid credential set and go plug
it into every other site they can think of (a credential stuffing
attack).

The solution to this is twofold: better storage server-side for those
of us who run sites with user accounts (Django does well at that), and
trying to stop people from using or re-using common passwords. Which
is why password entropy checks have fallen out of favor: it's far more
important to push people to *unique* passwords than it is to push them
to *complex* passwords. And if we make them set up complex passwords,
people will do things like write those passwords on little pieces of
paper stuck to their desks, which isn't good. Same if we make them
rotate their password every three months (fun trivia: that
recommendation apparently originated in an estimate of how long it
would take a group of hackers, presumably working in shifts, to
manually try every eight-character string on an ancient Unix system).

So modern recommendations mostly focus on avoiding the
credential-stuffing vector. For example, NIST 800-63B[1], for example,
is particularly instructive:

> Memorized secret verifiers SHALL NOT permit the subscriber to store a “hint” 
> that is accessible to an unauthenticated claimant. Verifiers SHALL NOT prompt 
> subscribers to use specific types of information (e.g., “What was the name of 
> your first pet?”) when choosing memorized secrets.
>
> When processing requests to establish and change memorized secrets, verifiers 
> SHALL compare the prospective secrets against a list that contains values 
> known to be commonly-used, expected, or compromised. For example, the list 
> MAY include, but is not limited to:
>
> Passwords obtained from previous breach corpuses.
> Dictionary words.
> Repetitive or sequential characters (e.g. ‘aa’, ‘1234abcd’).
> Context-specific words, such as the name of the service, the username, and 
> derivatives thereof.
>
> If the chosen secret is found in the list, the CSP or verifier SHALL advise 
> the subscriber that they need to select a different secret, SHALL provide the 
> reason for rejection, and SHALL require the subscriber to choose a different 
> value.
>
> Verifiers SHOULD offer guidance to the subscriber, such as a 
> password-strength meter [Meters], to assist the user in choosing a strong 
> memorized secret. This is particularly important following the rejection of a 
> memorized secret on the above list as it discourages trivial modification of 
> listed (and likely very weak) memorized secrets [Blacklists].
>
> Verifiers SHALL implement a rate-limiting mechanism that effectively limits 
> the number of failed authentication attempts that can be made on the 
> subscriber’s account as described in Section 5.2.2.
>
> Verifiers SHOULD NOT impose other composition rules (e.g., requiring mixtures 
> of different character types or prohibiting consecutively repeated 
> characters) for memorized secrets. Verifiers SHOULD NOT require memorized 
> secrets to be changed arbitrarily (e.g., periodically). However, verifiers 
> SHALL force a change if there is evidence of compromise of the authenticator.
>
> Verifiers SHOULD permit claimants to use “paste” functionality when entering 
> a memorized secret. This facilitates the use of password managers, which are 
> widely used and in many cases increase the likelihood that users will choose 
> stronger memorized secrets.

Appendix A of that document -- which I won't quote, you should all
read it yourselves! -- is especially enlightening in explaining why
these particular recommendations were chosen.

So the repeated-character password can be rejected, and maybe if we
don't reject that we could add a validator for it. But arbitrary
"entropy"/"complexity" requirements should not be added to Django, in
my opinion, for the reasons stated above and backed up by NIST.

[1]

Re: Rethink (?) how we handle security headers.

2020-08-19 Thread James Bennett

While I think Adam's right that adding one or two new settings
wouldn't be a problem, I do worry about the ongoing proliferation, and
it's a thing that I keep wanting to try to find the time to work on
but never actually succeed at.

Separate from the suggestion of a generic way to add headers on every
response, I've been leaning for a while toward the idea of
consolidating the security-header settings the way we've already
consolidated database and template settings. We can paint the bikeshed
whatever color, but suppose for sake of an example name we add a
SECURITY_HEADERS setting, with each one configured under its own key.
That would allow X-Frame-Options, content sniffing, HSTS,
Referrer-Policy, opener policy, and future stuff like CSP, built-in
CORS, etc. to all be defined in a single place that doesn't
proliferate a huge number of new settings, or require adding and
supporting a new setting every time a new one comes along (which, with
security headers, is about twice a week these days).

For now I think the best thing would be to accept the opener-policy
work as-is, then get consensus around a proposal for how future
security headers should be handled.

Re: Should the docs suggest namespace packages?

2020-05-20 Thread James Bennett

The use case for namespace packages is the ability to fragment
portions of a single package across multiple disparate locations on
the filesystem. And, potentially, to install or selectively
enable/disable access to only certain sub-portions of the package by
choosing which parts are present or by adding/removing their locations
in the import path.

Way way back in the day template tag libraries used to do a hack that
simulated this, where Django would see a "templatetags" directory in
your app and magically make it be importable from under
"django.templatetags" instead. That was one of the last pieces of the
original "magic" to be removed.

There's no reason to create implicit namespace packages for management
commands unless we want to move back to that sort of magical "lives
over *there* but imports as if it's actually over *here*" behavior,
and I'm pretty sure we don't want to do that.

-- 
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 receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CAL13Cg_4Ea0%3DAe2zzgHw63JAGDRXH3T40UQ27Nd2OQHy5HhQQg%40mail.gmail.com.

Re: Status of 3.1 release blockers.

2020-05-12 Thread James Bennett

I've been working on documentation updates to get the DEP 10
governance listed in the docs, but it's unlikely I'll be able to PR it
until this weekend. How do people feel about that also being included
in 3.1? It's not exactly a feature change, and it arguably corrects a
bug in that the docs as they exist now don't correctly describe the
way Django is governed...

-- 
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 receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CAL13Cg_J2X3%3DguTDDdDVaotjNAgFo6Yx4tp%3DRfhstxL_4E5FmQ%40mail.gmail.com.

Re: Removing url() ?

2020-05-05 Thread James Bennett

On Tue, May 5, 2020 at 2:24 PM Collin Anderson  wrote:
> If exception/special treadment is an issue, then I'd suggest making this an 
> official policy change going forward. I would be much happier if all of the 
> examples you gave were still around with warnings. All of those upgrades were 
> annoying. I think an ultra-ultra-extended deprecation cycle would be a good 
> precedent. I think it makes Django more attractive as a potential platform 
> for people to build their website on. I don't see it getting in the way of 
> future evolution. Could you say more?

If you'd like Django to commit to never removing anything, and instead
to preserve every piece of documented API forever, I'm sure the DSF
will be happy to accept the generous monetary donation you no doubt
intend to make in order to assist with that task, which I assume
you'll be willing to provide on an ongoing basis for... well, forever.
An initial contribution of a few million would help to get this
rolling, and we could set up recurring billing for the future
payments.

And I'm not joking about that. Every piece of deprecated code is a
maintenance burden; it requires keeping full regression tests around
and responding to bug reports and considering the possible interaction
of every new feature that ever gets introduced. All of which comes at
a cost of time and effort and -- if it's done by the Django Fellows,
which a lot of that work is -- a cost of literal cash money out of the
DSF's pocket.

Or we could allow Django to continue shedding deprecated APIs on a
predictable and documented cycle. I really do understand that it's
annoying to put in the effort to keep up to date. I lived through
magic-removal. I've done multi-version upgrades of massive codebases
basically by myself in the past. I remember them vividly, and I know
they're not fun. And there are platforms out there which have the
kinds of "nothing is ever removed" compatibility policies you're
advocating for. But Django isn't one of them, and I don't think it
should be or, at this point in its history, can be: to work at all,
that kind of policy has to be introduced early on and has to be
allowed to influence a lot of fundamental design decisions that, in
Django's case, were already made many years ago. If we introduce such
a policy now, the very first thing i'll do is go file a DEP asking for
the old "magic" ORM to be put back, and manipulators along with it.

Anyway. As Adam mentioned, there's a good reason to put the DEP 201
URL routing in front of people's eyes in a way they'll actually
notice. Our only truly reliable tool for doing that is deprecation
backed up by the knowledge that when we deprecate something, it will
end up removed. DEP 201 set out a deprecation schedule for url(); in
hindsight I wish it were shorter and just followed the normal post-2.0
policy of one LTS-to-LTS cycle, but at this point it's too late to
change that. I'll still argue quite strongly that the deprecation
period should not be made any longer, and I'll argue with every breath
I can devote to Django that a "deprecate but never remove" policy
should not be adopted.

-- 
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 receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CAL13Cg8WAEBYF-TWYdCOLxknrYyLfC0tSVfHnM6xWtVWHCwyyw%40mail.gmail.com.

Re: Removing url() ?

2020-05-05 Thread James Bennett

On Tue, May 5, 2020 at 2:04 PM Shai Berger  wrote:
> Why? Why is 10 years ok where 7 are not? James' points on this are spot
> on.
>
> Be that as it may, I can see sense in the request for a longer
> warned-deprecation period, which the current path does not offer. I
> would be ok with introducing now the RemovedInDjango41 or even
> RemovedInDjango50 warning, and waiting a couple more releases (for
> comparison, Python usually deprecates and removes in two versions, not
> three like Django).

Not to be contrarian, but I can come right back here with "why is
removal in 5.0 OK but removal in 4.0 isn't".

Under the current removed-in-4.0 plan, people will get *six* Django
feature releases from the time re_path was introduced to the time
url() goes away. Any argument for extending it to nine is also an
argument for extending it to twelve, fifteen, eighteen, and so on. At
some point we have to decide whether we can remove things or not. I
think we can and should, and I still don't see why url() needs this
kind of special treatment when all the other deprecations we do every
LTS-to-LTS cycle don't.

-- 
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 receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CAL13Cg_gJ1MXRFZgMF77ciDVF5A_0P2vJbKqXafRVP6S0Zxg6w%40mail.gmail.com.

Re: Removing url() ?

2020-05-05 Thread James Bennett

On Tue, May 5, 2020 at 1:05 PM Collin Anderson
wrote:If it were 10 years from the proposal being accepted (2017 to 2027),
I think that would be fine for removal then. It allows for a more natural
upgrade as path() becomes more and more common. I don't see keeping url()
around as slowing down Django's ability to evolve over time. It makes it
easier for people to upgrade, which means more projects will use newer
versions of django, which is a huge benefit to Django's ability to evolve.

I just published a kind of rant-y thing about the Python 2/3 transition, so
that's at the forefront of my mind. And honestly I think one lesson learned
there applies here too: once you get into a timeline of N years, for
sufficiently large N, arguments that "N years is not enough time to port,
but N+K years would be" simply don't hold up.

I understand as well as anyone that it takes work to keep up with evolving
platforms, and that it can feel unrewarding to do that work -- url()
already exists and works, why should I have to change to calling it
re_path()? -- but I also understand that if seven years wasn't enough time
to get around to doing this, ten years also wouldn't be enough. If we
postpone this to 2027 (and if Django and all of us are still around), then
in 2025 or so when the deprecation warning starts being reintroduced we'll
be asked for yet another extension, and every argument being made in favor
of extension in this thread will be as applicable on that day as it is
today.

Post-2.0, Django is a lot more predictable than it used to be in terms of
API stability and compatibility. We now make stronger promises that if you
run on a Django LTS and don't have deprecation warnings, you'll be able to
run on the next LTS too (and then if you fix deprecation warnings again,
you're set for the LTS after that). That's important both for users of
Django and for the project itself: users of Django can relax a bit and
enjoy a multi-year support cycle before they have to worry about upgrading,
and the project can continue to evolve at a reasonable pace. But it only
works if we actually stick to it: if we make exceptions and start doing
longer and longer and longer deprecation cycles, the deprecation policy
won't be taken seriously.

There's also no reason why url() in particular should be given special
treatment that other deprecated features or APIs don't get. Some other
old-time bits went far more quickly: render_to_response(), for example, got
the standard deprecation cycle, and was removed for good in 3.0. The old
django.core.urlresolvers module went away in 2.0. We've also long since
gotten rid of the patterns() helper in favor of just defining URLs as a
standard Python list. All of those were "useless code churn" -- the
previous functions/modules worked just fine, after all. But they're all
gone, and if you run on a supported Django version you've either dealt with
those changes or (in the case of render_to_response()) will deal with them
sometime in the near future.

So again, I don't think we should make an exception here. Doing an
ultra-ultra-extended deprecation cycle on url() beyond the current merely
ultra-extended one would be a bad precedent for Django's future evolution,
and I don't see any argument for it being a unique or painful enough change
to justify such handling.

Re: Removing url() ?

2020-05-05 Thread James Bennett

On Tue, May 5, 2020 at 9:45 AM ‫אורי‬‎  wrote:‬
> My project contains about 100 calls to url() with regex. Can you explain to 
> me what has been changed and why, and how should I change my code to stop 
> using url()? And where is it documented? I checked the documentation and I 
> didn't find an explanation why url() was changed and what are the differences 
> between url() and path() and re_path()?

There is no difference; django.conf.urls.url() is just an alias for
django.urls.re_path().

-- 
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 receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CAL13Cg8XcXgvuXcns1nQvro-c5XcaSWvUP-khBeW%3D8Nk_Wu5fw%40mail.gmail.com.

Re: Removing url() ?

2020-05-05 Thread James Bennett

On Tue, May 5, 2020 at 8:42 AM Collin Anderson  wrote:
> Is this really worth it? It's only a few lines of code to keep backward 
> compatibility, and it seems to me it would take almost no work to maintain 
> that compatibility shim compared to the countless programmer hours needed to 
> upgrade their code, including many unpaid programmers working on open source 
> projects. I'll personally need to do a find/replace for url() to re_path() 
> across my ~20 projects, and update all of the imports. Isn't this useless 
> code churn?

I think it should be deprecated and removed.

On the one hand, we're talking about an extremely long (~7 years)
timeline from when re_path() was introduced to when it would become
mandatory for projects that need regex-based URL routing. That seems
like plenty of time for projects to notice that a new URL routing
approach was adopted. And that's a long, *long* time to keep
effectively-dead code in Django, far longer than what the normal
deprecation cycle would be.

On the other hand, if it doesn't get removed, it sets a bad precedent
-- Django needs to be able to evolve over time, and part of that is
ensuring that once something is no longer the recommended approach it
gets removed from the framework. Without raising eventually-loud
deprecation warnings (further along in the cycle), people who still
have url() in their codebases might never even find out that the
simplified DEP 201 URL routing is available. Raising a deprecation
warning makes sure they find out; some projects will undoubtedly just
find-and-replace url() to re_path(), but others will probably be happy
to find out that the simpler path() routing exists.

-- 
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 receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CAL13Cg-8_Bu-KKMjGrMES5YyPjXFtn22qSguP4W9H7z1mD9e2Q%40mail.gmail.com.

Re: Generate JWTs with Django

2020-04-26 Thread James Bennett

On Sun, Apr 26, 2020 at 8:46 AM Adam Johnson  wrote:
>
> James, I too would like to know your criticisms! I've always understood that 
> they aren't much different to signed cookies, but I haven't looked too deeply 
> at them.

Well, people asked. So.

The short summary is: JWT is over-complex, puts too much power in the
attacker's hands, has too many configuration knobs, and makes poor
cryptographic choices. This is why we see vulnerabilities in JWT
libraries and JWT-using systems again and again and again.

And even if you get every single bit of it right, in the ideal perfect
world with the ideal perfect implementation, the payoff is you've put
in a ton of work to get something that already existed: signed
cookies, for the use case of session identification, or any of several
better token or token-like systems -- everything from PASETO to just
timestamped HMAC'd values -- for the use case of inter-service
communication.

The longer version goes more like this...

JWT is a more complex thing than many people appreciate. In fact, it's
at least *five* things, each specified in its own RFC, plus some more
you have to know about and implement if you want any hope of getting
the actually-sorta-secure version. And right off the bat, that's
worrying: the more different things you have to implement, and the
more places you have to look to find out what and how to implement,
the more opportunities there are to make mistakes.

This complexity comes from the sheer number of different options JWT
tries to support, which in turn is an anti-pattern. JWTs may be
signed, or they may not. They may be encrypted, or they may not. There
are multiple different options for how to sign, how to encrypt, how to
manage and specify keys... in a well-designed system there would be
far fewer options. Ideally, there'd be only one option, and the
solution for a vulnerability being found in it would be to increment
the version of the underlying spec, and change to something
better.

Anyway. In JWT, signature and encryption schemes are effectively
negotiable, which is yet another anti-pattern: you are putting
enormous power in the hands of attackers to negotiate you down to a
bad, or nonexistent, cipher/algorithm for encryption or signing. TLS/SSL
learned this lesson the hard way; JWT has chosen not to learn it at
all. Worse, JWT embeds the negotiation about how to handle the token
into the token itself. This is just asking for trouble, and in fact
trouble has routinely occurred. As a somewhat sarcastic author of my
acquaintance put it:

> It is extraordinarily easy to screw up JWT. JWT is a JSON format
> where you have to parse and interpret a JSON document to figure out
> how to decrypt and authenticate a JSON document. It has revived bugs
> we thought long dead, like “repurposing asymmetric public keys as
> symmetric private keys”.

(from: https://latacora.micro.blog/a-childs-garden/)

More succinctly: JWTs inherently and unavoidably violate the
Cryptographic Doom Principle
(https://moxie.org/blog/the-cryptographic-doom-principle/). Worse,
JWTs put full control of the violation in the hands of the attacker,
who -- thanks to the high level of configurability JWT offers -- is
free to find the set of options most likely to compromise you, and
foist them on you.

That quoted line above about revived long-dead bugs is no joke,
incidentally. Here's one from a few years back:

https://auth0.com/blog/critical-vulnerabilities-in-json-web-token-libraries/

Five different libraries, written in three different languages, all
had the same bug. I once had the misfortune of arguing with someone
who attributed this to the libraries being built by bad programmers,
or in bad languages. But I personally tend to agree with a line from
this talk:

https://www.okta.com/video/oktane19-cryptographic-wrong-answers/

> Now you can say look those are all implementation vulnerabilities,
> it's not actually JWTs fault, I disagree. If I can find the same
> vulnerability in five popular libraries, then maybe the spec did a
> bad job of making sure people avoided that vulnerability.

So to completely head off the "it's just bad implementations"
argument, let's turn to the specs themselves: RFCs 7515, 7516, 7517,
7518, and 7519 are the core specifications that make up with is
commonly called "JWT" (and in RFC-land is more properly called "JOSE"
-- "JSON Object Signing and Encryption", of which the token format is
but one part).

The JOSE RFCs make a number of choices regarding default sets of
standardized cryptographic options. For example, RFC 7518 standardizes
thirteen signature algorithm options, seventeen encryption key
management options, and six different encryption cipher options.

This is already a problem -- that's an absolutely gigantic
combinatorial space of options! But then it gets worse.

Let's look just at the first table of options in that RFC, which is
for signing algorithms. It categorizes them as "Required",
"Recommended+", "Recommended", or

Re: Generate JWTs with Django

2020-04-26 Thread James Bennett

I understand that this will probably get shouted down due to the
popularity of JWTs, but: I don't think Django should include any type
of JWT support in the core framework.

JWTs are an absolute security nightmare. Some of the Django security
team have heard me rant on this topic already, but: there is no such
thing as a safe JWT implementation, because there are fundamental
flaws in the design of JWT that cannot be remedied by just writing
better implementations. Supporting them in Django, even to the minimal
extent in the current PR, would encourage users of Django to adopt
them, which goes against our historical trend of pushing best
practices when it comes to application security, and would
significantly add to the security team's burden because of the
increased attack surface JWT support would open up.

If Django does end up shipping some type of JWT support, I'd lobby
very strongly for declaring it out of scope for our security process,
and labeling it "use at your own risk".

-- 
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 receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CAL13Cg8Csr1ageZCEKm9bd12Tb_vosx_xLSV%2B8WfvoWi01%2BfPA%40mail.gmail.com.

Progress report: DEP 10 implementation

2020-04-20 Thread James Bennett

Last month the process of adopting DEP 10 -- new governance for the
Django project -- was completed:

https://www.djangoproject.com/weblog/2020/mar/12/governance/

As a result, we are now in the implementation stage. Although there
will almost certainly be other items that pop up on the to-do list,
here's a quick status update on what has been done so far, and what
still needs to be done.

Some of these items require particular permissions; for example, I
believe I currently have the necessary permissions to handle the PyPI
configuration change, and I know I have the necessary permissions to
create a page on djangoproject.com for listing the recipients of the
initial grant of "Django Core Developer" status, but some others --
particularly closing mailing lists, and IRC-channel bureaucracy -- I
don't have access for, so consider this message a call to anyone who
*does* have those permissions to get in touch and coordinate on
getting them done.


* DONE -- Create a Mergers group for the main Django repository
* DONE -- Remove commit access for the main Django repository from the
former "Django Core" team

* IN PROGRESS -- DSF Board develops infrastructure for running a
Technical Board election
* IN PROGRESS -- Restrict PyPI package-upload access to Releasers
* IN PROGRESS -- Add page on djangoproject.com listing recipients of
"Django Core Developer" title
* IN PROGRESS -- Update Django documentation to describe DEP 10 governance

* TODO -- Close django-core mailing list
* TODO -- Close django-technical-board mailing list
* TODO -- Close #django-core IRC channel
* TODO -- Remove or change Django "committer" cloak on Freenode IRC
* TODO -- DSF Board to create a process for granting "Django Core
Developer" title beyond initial DEP 10 grant
* TODO -- First DEP 10 election of Technical Board

-- 
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 receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CAL13Cg9vj6qGbnR9Zj6inYNsRTv1Orbvn-CkWBmtCFRDoLTxGA%40mail.gmail.com.

Re: Form fields - should be OrderedDict?

2020-04-11 Thread James Bennett

On Fri, Apr 10, 2020 at 10:40 PM ‫אורי‬‎  wrote:‬
> In this form I need to insert fields in the beginning of the form, and 
> therefore I call move_to_end. It worked with Django 2.2 but not with 3.0 
> because this method is not defined in a dict. So I think if you revert to 
> using OrderedDict, users will be able to use this method to insert fields in 
> the beginning, or change the order of fields. So I think it was a mistake 
> changing it to a dict.

Reordering the fields of a form is a use case that already has supported API:

https://docs.djangoproject.com/en/3.0/ref/forms/api/#notes-on-field-ordering

You can either set the field_order attribute explicitly to the order
you want, or call the order_fields() method and pass in the new order.

Manually manipulating the underlying fields dict was never a
documented (and thus never a supported) feature of forms. If you need
to reorder fields, please just use the documented and supported API
for this.

-- 
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 receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CAL13Cg_Qv3LViW5yDPtmdv4RaauXOyBTYbtFmJNkNEew6OZjJw%40mail.gmail.com.

Re: Form fields - should be OrderedDict?

2020-04-10 Thread James Bennett

The purpose of OrderedDict is that it's a dictionary type where
iteration yields keys in the order they were inserted. In older
versions of Python, this was not guaranteed, so a special ordered
version was needed.

Django 3.0 supports only Python 3.6 and newer; as of Python 3.6,
iterating a normal dict yields the keys in insertion order (and this
is now a guaranteed part of the Python language specification). So
there is no longer any reason, in Django 3.0, to use OrderedDict for
situations that require insertion-ordered keys.

-- 
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 receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CAL13Cg_H_S5W1FpcC8OuGDh7mDLrPqm4MDg6dmxRtGVit7JE_Q%40mail.gmail.com.

Re: End of extended support for Django 1.11

2020-03-31 Thread James Bennett

The end of support simply means there will be no further releases, and
any showstopping bugs reported will not be fixed. It doesn't mean
Django itself will stop working. Also, the decision is in the hands of
the Technical Board, not the Django Fellows, so the correct process
would be to request that the Technical Board schedule additional
support/releases of Django 1.11.

That said, my personal opinion is that both the Python 2 EOL (2020-01)
and the Django 1.11 EOL (2020-04) were set years in advance;
organizations which waited until the last minute to do their upgrades
would simply wait until the last minute again if given an extension,
and be right back in the same problem. There has to be a cutoff date
at some point where we just say "sorry, but if you haven't prioritized
upgrading for years and years, we cannot tie up our open-source
project's resources because of that". And the announced cutoff, which
is in line with previous LTS releases of Django, seems as reasonable
as any other.

On Tue, Mar 31, 2020 at 6:57 AM Daniela Kim  wrote:
>
> Mariusz,
> Thank you for your response.
>
> Would it be possible for the Django Fellows to vote to extend Django 1.11's 
> EOL by a few weeks? For those of us with a large Django codebase, we were 
> bitten by the onerous Python 2->3 upgrade and so the start of our Django 
> upgrade was delayed by several weeks.
>
> Also, given the current global situation with Covid-19, including (1) 
> work-life difficulties/transitions for organizations and our developers and 
> (2) an evermore global online presence with further exposure to online 
> security threats, a graceful extension would be very much appreciated.
>
> Thank you for your consideration.
> Daniela
>
>
> On Thursday, March 26, 2020 at 1:15:18 AM UTC-4, Mariusz Felisiak wrote:
>>
>> No, support of Django 1.11 ends on 1st April.
>>
>> Best,
>> Mariusz
>>
> --
> 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 receiving emails from it, send an 
> email to django-developers+unsubscr...@googlegroups.com.
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/django-developers/f5718ec3-6041-40db-93fd-b7b8b354e64a%40googlegroups.com.

-- 
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 receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CAL13Cg_WBtBU%3D_ZrSPfgWfzP0U2PGsFXvcCMCY8GCcDRybS5tQ%40mail.gmail.com.

Re: Discuss ticket 20264: URLValidator should allow underscores in local hostname

2020-03-26 Thread James Bennett

I'm also in the "I don't think this should be allowed" camp. People
who really need it can set up their own validator easily enough, and I
worry about the security implications of supporting non-standard
behavior in something as crucial as hostname validation -- Django's
been bitten by that sort of thing several times in the past.

-- 
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 receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CAL13Cg-k6CGLZo9o%3DRG4LpGj5CbP57ayeGyBrKYXa7SPx07%2BWg%40mail.gmail.com.

Re: New Merger nomination.

2020-03-14 Thread James Bennett

On Sat, Mar 14, 2020 at 5:00 AM Markus Holtermann
wrote:
> Claude has been contributing to Django for almost a decade. His roles in i18n
> related matters has been a constant help to the project. Providing Claude
> with commit access to github.com/django/django and giving him the MERGER role
> will allow him to continue his work and maintain an up to date translation
> base in the project, especially in the days leading towards a release.

Again, I need to point out this is not how DEP 10 works.

The Merger role is not just a new name for "committer". If Claude is
appointed a Merger, he will be forbidden to do what you are saying --
a Merger cannot push their own contributions directly into Django!

DEP 10 says:

"[A] Merger MUST NOT merge a Minor Change primarily authored by that
Merger, unless the pull request has been approved by another Merger,
by a Technical Board member, or by the Django Security Team."

The reason for the Merger role is that we need people with the ability
to merge pull requests when the decision-making process says it is
time to merge them. Mergers have some power to use judgment on what
PRs get merged, but it is not the power to judge what is or isn't a
good technical change to make to Django -- it is the power to judge
when something does or does not need more discussion on the public
forums.

Mergers are not technical leaders. Their job is to serve the community
by keeping a specific part of the project -- merging pull requests
according to community decision process -- flowing properly. The role
of Merger is also not a reward or a way to recognize someone's past
accomplishments or contributions. Honoring and recognizing and
rewarding people's work is the DSF's job. We do not use "let's give
him commit access" for that anymore.

This is not to diminish the importance of the role, because it is
important. But it is important in a very different way than the old
"committer" role was, and has very different responsibilities and very
limited powers. Since the vote has been asked for, I urge the
Technical Board members to read DEP 10 carefully and be sure you
understand what a Merger does (and what a Merger doesn't do!) as you
consider your votes. Django probably should have only a very few
Mergers -- DEP 10 only requires that there be three of them -- because
the role of Merger is only to do very specific things to keep the
project working smoothly.

If the worry is about ensuring translations are brought in regularly
and smoothly from Transifex, the Technical Board has authority for
that that and can work with the translation team to set the process
(there is a whole section in DEP 10 about interaction between
different teams within the Django project, for this reason). Which
might end up being "Claude initiates the pulls from Transifex" (though
a process that depends on one specific person is a bad process), but
that is not a justification to make someone a Merger. If the worry is
about i18n code in Django itself, Claude already has the same power
anyone else has to open and review and comment on pull requests, start
discussions on the mailing list or forum about the best approaches,
and so on. But even if he is made a Merger, he would not have the
power to write code and commit it directly into Django, because that
is not a power of a Merger.

Re: New Merger nomination.

2020-03-13 Thread James Bennett

So I guess it's worth walking through how to do this.

The first step would be a member of the Technical Board deciding
Mariusz' suggestion is a good one, and nominating Claude to be a
Merger, putting the question to the full Technical Board for voting:
"Shall Claude be appointed a Merger?"

The Technical Board would have one week to cast their votes (+1, 0, or
-1) on the question. Those votes must be cast publicly.

If the result of that vote is 3 or higher, Claude would be appointed a
Merger, though the appointment would be a temporary one because of the
pending Technical Board election (an outgoing Technical Board can only
make temporary appointments under DEP 10). Once the election is over,
the new Technical Board could make the appointment permanent.

-- 
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 receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CAL13Cg-ihddEqua86k3J_CJ4MDDjuf4iVPBbWK_X4TKRzoXDfw%40mail.gmail.com.

Re: New Merger nomination.

2020-03-13 Thread James Bennett

A quick refresher on this since DEP 10 governance is still quite new:

Mergers have no special decision-making privileges -- being a Merger,
while important for the project, is not equivalent to the former
"committer"/"core" status, and is not used as an honor or as a reward
for past service or contributions.

The process for appointing a Merger or Releaser is:

* Anyone may suggest a candidate
* However, only a member of the Technical Board can formally nominate
someone to be a Merger or Releaser
* The nomination is then confirmed or rejected by public vote of the
Technical Board
* Because an election of the Technical Board has been triggered (by
acceptance of DEP 10), any appointment made by the current Technical
Board expires after the election unless the newly-elected Technical
Board confirms it

-- 
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 receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CAL13Cg-jFVG%3DhQ2RAaJWcF0RGp0ejai-4Kg33hGGUkvtMbQiJQ%40mail.gmail.com.

[ANNOUNCE] A new governance model has been adopted for the Django project

2020-03-12 Thread James Bennett

For several years, there have been efforts underway to change the way
the Django open-source software project is run. This eventually
produced a concrete proposal, which then went through discussion,
revision, and voting by the Django core team, Django Technical Board,
and Django Software Foundation Board, and has now been accepted.

There's a blog post up with a summary and link to the full new
governance document:

https://www.djangoproject.com/weblog/2020/mar/12/governance/

But if you want a super-short summary: up until now, there have been
around 50 "core" developers with full commit access and
decision-making power, and a Technical Board to act as a tie-breaker.
But this wasn't how the project actually worked -- most "core"
developers were inactive, and most decisions were made by consensus on
the django-developers mailing list or in the bug tracker. So we are
moving to a system that formally recognizes this, and officially
adopts a more open, consensus-based process that does away with the
special group of "core" developers. Since this is mostly just saying
officially that we'll do things the way they've been working, users of
Django probably will not notice any change :)

-- 
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 receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CAL13Cg9hvNNHLM3nZqVAtT3vRbjTFibuZt-%3DgbgARwhk%2B489uw%40mail.gmail.com.

Re: Forms submitted by bots

2019-12-14 Thread James Bennett

Since this discussion seems to be exclusively about how to use Django,
please take it to the django-users mailing list; the django-developers list
is not an appropriate place for this topic.

-- 
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 receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CAL13Cg8h%2BHsZbc5oZ5rwLiOO0%2BHTiS8EKpT6OW1P6bSUj1R1pA%40mail.gmail.com.

Re: Deprecate HttpRequest.is_ajax

2019-11-20 Thread James Bennett

On Wed, Nov 20, 2019 at 3:44 PM Curtis Maloney  wrote:

>
> Yeah, I expected DRF had this "solved" already. From my own
> experimentation, mapping `cgi.parse_header` over the the "Accept" header
> value, split by comma, gets a usable result; then sort that list by 'q'
> (defaulting to 1.0) and you have your priority.
>

Both the original and forks seem to've been abandoned now, but the
mimeparse library encapsulated this into a nice little function that took
an Accept header, and a list of content-types you could support in the
response, and told you which one was the best match. The code's still out
there and under a permissive license if somebody wants to pick it up again.

-- 
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 receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CAL13Cg9x9ZWM0LTLoMMF%3DxgMydqrOKhEnhsRn-miFkVk5Rx6tg%40mail.gmail.com.

Re: Stop QuerySet repr from executing queries

2019-10-15 Thread James Bennett

This request is a bit more complicated than I think people
realize. There's no practical way I can see to have the __repr__() of
a QuerySet supply information sufficient to reconstruct it, at least
not in a manner recognizable to most users of the ORM (there's no
internal record of which query methods were called, or with which
arguments -- only the manipulations of the nodes of the underlying
Query object).

And even if we decided to go to the trouble of having QuerySet store a
record of query method calls, it's likely to be a considerable amount
of trouble, since arguments to query methods may be objects that are
difficult or impossible to safely store (such as iterators which would
be consumed in creating a string representation).

So having QuerySet.__repr__() produce the sort of "information to
reconstruct the object" typical of the __repr__() of Python's builtins
is not going to work.

Which leaves the question of what to put in the __repr__(), if it's
not going to be a way to reconstruct the QuerySet and it's not going
to be the results of the query. We would also need to ensure QuerySet
implements __str__() in a way that *does* provide the visual debugging
aid of showing the results, since currently it doesn't, and relies on
Python falling back to __repr__() to get the string representation.

And... I don't have a good answer to this. Anything that isn't either
the method chain to reconstruct the query, or the results of the
query, is not going to be a sufficient debugging aid.

Which brings us back around to the current behavior; it seems to me
that this is the most useful thing we can do. It's already documented
that a string representation of a QuerySet shows the results, which
requires evaluating it and performing the query. There are some small
optimizations we could do -- such as checking for a populated result
cache and using it, rather than re-performing the query as __repr__()
currently does -- and we could be more explicit about the fact that
performing the query is a requirement for generating a string
representation, but I think that's about the best we can do for this
issue.

Re: Django LTS support time

2019-08-18 Thread James Bennett

The main issue with an LTS is that there's no such thing as "long enough".
Upgrading once every three years -- especially when the compatibility
policy now is that if you run on the previous LTS with no deprecation
warnings, you'll also be able to run on the next LTS without errors -- is
not that much of a burden. But many organizations won't put in the time to
do the upgrade until it's too late, and the length of the support period
doesn't actually matter: an organization that can't manage an upgrade in 3
years also won't manage an upgrade in 5 years, or even 10 years, because
the problem is not that the support period was too short. The problem is
the organization's priorities, specifically the fact that doing maintenance
work is not a priority.

A good example is Python 3 support. Python 3 was first released 11 years
ago, and Django introduced support 6.5 years ago once Python 3.2/3.3
stabilized a lot of things. But there are still people today who haven't
even *started* to upgrade to Python 3. It wouldn't matter if we gave them a
hundred years -- it still wouldn't be "enough time" for them to upgrade.

I understand the arguments for *why* organizations do this -- which mostly
come down to "it works right now, why should we spend time on something
that isn't broken when we have real bugs to fix and features to add?" --
but unfortunately they usually end up learning, when it's too late, why
they should have made time for maintenance work earlier. Giving them a
longer support period won't change this. And a 3-year support period is a
reasonable amount of time, especially given the work being done to make the
LTS-to-LTS upgrade easy, and doesn't overburden the Django team with having
to support ancient versions of the framework until the end of time.

With that said, there are Linux distributions which provide their own
packaged version of Django, and which have longer support periods in which
they will backport important fixes into their package even if the Django
team isn't supporting that version anymore. Some of them charge money for
this service, but if you need to buy a couple more years of support for an
old version of Django, using one of those distributions may be your best
option.

-- 
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 receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CAL13Cg8G2fU1XXi6%2Bx%2B55ReYJhmVbGXjZObz50sneZF4Jtk7fA%40mail.gmail.com.

Re: Proposing development discussion forums

2019-08-12 Thread James Bennett

I'm not necessarily opposed to this, but I am a bit skeptical of the
long-term archival utility of forums, in large part due to my experience as
a moderator of some decent-sized ones. I think making them useful for that
purpose is going to require about the same level of manual curation as,
say, the wiki on code.djangoproject.com does now.

-- 
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 receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CAL13Cg_L-seA-6AiAdHctheUcqoM5gzqS_ZrbwcCQ_d%3DGo3%2BNQ%40mail.gmail.com.

Re: Translation templatetag aliases

2019-07-27 Thread James Bennett

On Sat, Jul 27, 2019 at 11:01 AM Florian Apolloner 
wrote:

> Not opposed to changing it, but would make {% translateblock %} more sense
> than {% blocktranslate %}?
>

I'm in favor of the change to using the full word "translate". I don't have
a strong opinion on which variant to use for the block translate tag; if
there's no other reason advanced for picking "translateblock" I'd point out
that "blocktranslate" may make life slightly easier for people using
autocomplete since it ensures you don't accidentally complete into
"translate" when you wanted "translateblock" (or vice versa).

-- 
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 receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CAL13Cg9HXkXxYAJTi9wyhpstrgTu1aGjUfYpxk8%3D-B9PeUqRdQ%40mail.gmail.com.

Re: Proposal: security enhancements

2019-07-22 Thread James Bennett

I haven't forgotten about this, but it'll likely be another day or two
before I can lay out a proper plan.

-- 
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 receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CAL13Cg_oMP1Ak4OhB_WMcPPH5TgCrotj_3NB9iX3ZmJXgtyvXA%40mail.gmail.com.

Re: Proposal: security enhancements

2019-07-15 Thread James Bennett

On Mon, Jul 15, 2019 at 10:27 PM Curtis Maloney  wrote:

> I think there is certainly a strong case based on "secure by default" to
> include this in core, where it would otherwise face the "it works fine as a
> 3rd party app" barrier to entry.
>
> IMHO it would require, however, that the solutions be sufficiently generic
> as to not enforce an overly restrictive world view.
>
> I, for one, would be very interested to see more details here on what
> changes you propose.  Then, at least, we can keep a mailing-list history
> record of the discussion.
>

I had an attack of Real Life™ a while back which prevented following up on
this thread, but I have some thoughts I'd be happy to write up and share
here, and can at least try to find time to put in some work on
implementation.

I'll try to get something more detailed when the weekend rolls around
again, but the short version is that I'd like to spin up a third-party
project to do the implementation work in, and then look at integrating it
back into Django at a later time once it's been able to mature a bit.
That's been a successful model for a few other larger projects in the past,
and I think is also the right approach for doing this particular type of
security work, since there's still a decent amount of flux in the relevant
standards and their implementations (to take one example, the
Referrer-Policy header has had some consistency issues with browser
implementations) which would make me wary of putting it straight into
Django and enabled or even recommended by default.

-- 
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 receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CAL13Cg_LFUDGemLg7QYpcx-NKfhvc6U%3D3naaUz-YdTgt6G04RQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Python 3.8 and Django 2.2.3 Issues

2019-07-15 Thread James Bennett

On Mon, Jul 15, 2019 at 4:41 AM Ehigie Aito  wrote:

> Not at all, I create all new Django projects from scratch and with pipenv.
> This only happens with Python 3.8.0 b1
>

Open a Python interpreter and type this:

import django
print(django.VERSION)
print(django.__file__)

Make sure VERSION returns (2, 2, 3, 'final', 0).

Then go to the location that printed for django.__FILE__ and examine the
contents of conf/project_template/project_name/settings.py-tpl there.

-- 
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 receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CAL13Cg--q48U_5Ke9akjs5aqrCObkcZLtbQHmrgRRff8AqWhzw%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Python 3.8 and Django 2.2.3 Issues

2019-07-15 Thread James Bennett

On Mon, Jul 15, 2019 at 4:36 AM Ehigie Aito  wrote:

> Like I said, in older versions of Django, that variable used to be named
> MIDDLEWARE_CLASSES, if I create a Django project with Python 3.7 and Django
> 2.2.3, its MIDDLEWARE but Python 3.8 and Django 2.2.3 its named
> MIDDLEWARE_CLASSES which on running python manage.py runserver fails. Here
> is the traceback:
>

This seems very unlikely. Here is the default settings file Django 2.2.3
will create:

https://github.com/django/django/blob/2.2.3/django/conf/project_template/project_name/settings.py-tpl#L42

It contains MIDDLEWARE. It does not contain MIDDLEWARE_CLASSES.

Are you 100% completely certain that:

* You do not have an older version of Django that might have been used to
generate the settings file, and
* You are not using any sort of custom project template that hasn't been
updated to use the MIDDLEWARE setting?

-- 
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 receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CAL13Cg-H8H%2B7gUTaxp1zMBnG_7%3DLfycDSGCHDsFVmSm0SuhRXg%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Add logging to related descriptors

2019-05-28 Thread James Bennett

On Tue, May 28, 2019 at 9:30 AM Flavio Curella 
wrote:

> But there are many situations where a N+1 can get created and people
> usually have don't write tests for (even if they should have). For example,
> assume this model:
>

I guess my question is: if your devs won't check this in tests, why do you
expect they'll check it through another mechanism? :)

-- 
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 receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CAL13Cg-K6YXg3UkGbnKktd7x7TSE7CncT_p8ZGHyt_kGTAbXpg%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Add logging to related descriptors

2019-05-28 Thread James Bennett

Have you looked at the assertNumQueries assertion?

https://docs.djangoproject.com/en/2.2/topics/testing/tools/#django.test.TransactionTestCase.assertNumQueries

This can let you assert the expected queries and break your tests if
someone accidentally introduces an N+1.

-- 
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 receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CAL13Cg88D8DQovyY559GBMrEV6M7dXrT1Bnd70Ws8_tf-PgJ%2Bw%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Proposal to format Django using black

2019-04-25 Thread James Bennett

I like Django's style guide.

I like the *idea* of an autoformatter.

I dislike the particular mostly-unconfigurable style Black enforces, and I
find that several of its rules negatively impact code readability.

So I would be -1 on applying it to Django.

-- 
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 receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CAL13Cg-MJqE%2BxmxpBhymxaUz__6V_htE1XA-XRxZH5Uxa3WY_A%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Force "required" fields to be included in a ModelForm

2019-04-16 Thread James Bennett

Python has a warning system, and Django already uses it for things like
deprecation notices.

I don't like error by default as an approach to this, but a warning (which
is easy to ignore -- it doesn't break your code) would be fine.

-- 
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 receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CAL13Cg9FfQ4Fv3Mjvw-4qaL4d%3Dbgm1y5pWeYRfA%2BUcJqAymLdQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Force "required" fields to be included in a ModelForm

2019-04-16 Thread James Bennett

As the documentation points out, ModelForm avoids implicitly adding fields
to a form when you haven't told it to, and does so for security reasons.
Mass-assignment bugs have caused significant security issues in the past
for other systems which *did* implicitly support/add fields, and I'd like
to keep Django from doing that.

So if the proposal is just that any field with required=True is implicitly
included, I'd be against it. Similarly, I think it would complicate the API
too much to add support for some kind of "__all_required__" special
declaration.

I would suggest there's value in figuring out a way to either have
ModelForm raise some type of ignorable warning, or maybe having the
system-check framework warn you, if you do have a ModelForm that doesn't
include a required field, though.

-- 
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 receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CAL13Cg-EJYA7NAzPb%2BpQOR_Ywuzo5A_%3DBGJBS5CYd-J0SoKhSQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Proposal to format Django using black

2019-04-13 Thread James Bennett

On Sat, Apr 13, 2019 at 1:18 PM Florian Apolloner 
wrote:

> Maybe, but I think the benefits outweigh the costs -- and I also do not
> think that it is unnecessary. Our goal has always been to make contributing
> easier, well nowadays black is in the position to do just that.
>

I feel like Black is useful for projects that don't already have and
enforce a style guide. But we already have and enforce a style guide, and
some parts of it are things Black can't auto-enforce. So I'm not sure I see
what benefit we'd get out of Black, and the downside is a lot of churn.

-- 
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 receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CAL13Cg9UNSujA3qCCp4JcvtA5uZRduGOOEKCHp4OCNjCbbH2Zg%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Enable SESSION_COOKIE_SECURE by Default

2019-04-03 Thread James Bennett

On Wed, Apr 3, 2019 at 4:31 AM Aldian Fazrihady  wrote:

> Many production systems, including mine, are using HTTPS, which
> effectively blocks the capability of attackers from sniffing other people's
> cookies.
>

Closing off opportunities to sniff cookies is more complex than just using
HTTPS, which is why the 'Secure' and 'HttpOnly' flags exist on cookies, why
HSTS and preloading exist, and several other mechanisms.

If you are using HTTPS, you should have both SESSION_COOKIE_SECURE and
CSRF_COOKIE_SECURE set to True. This thread is discussing whether and how
we could default those to True.

-- 
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 receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CAL13Cg-JpDxFVzAHqGmveMxVMD_2k5i%3DB%2BfwwLERi8pGY0%3DGJQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Enable SESSION_COOKIE_SECURE by Default

2019-04-03 Thread James Bennett

On Wed, Apr 3, 2019 at 2:34 AM Carlton Gibson 
wrote:

> Yes, super thanks. Breaking login in development would qualify as a good
> *Why* yes. 
>
> I'll assume we're NOT going to do this, but anyone with input, please do
> comment.
>

Historically I've done something along the lines of

CSRF_COOKIE_SECURE = not DEBUG
SESSION_COOKIE_SECURE = not DEBUG

That guarantees I never go to production without the cookies set to secure,
but also avoids breaking local dev. I do similar things with other
SSL-related settings.

I'm not sure how well it generalizes to other people's use cases, though.

-- 
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 receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CAL13Cg8NrS3k_XXp4mB%3DaLQgmoo3yhuEMXOrrB2_yBj_tMV1qw%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Signals - Need a signal after annotations are added

2019-02-23 Thread James Bennett

On Sat, Feb 23, 2019 at 9:48 PM Philip James 
wrote:

> Hi! I think I'm misunderstanding what you're asking for. I've looked at
> every doc I can find on annotations to refresh my memory, and it looks like
> annotations only apply to query sets, not to objects? Could you say a bit
> more about your use case to help me grok what's going on?
>

When a QuerySet is annotated, each object in the results gets the
additional attribute(s) attached to it from the annotation. I think this is
a request for a signal that fires after those attributes have been added to
the model instances.

-- 
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 receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CAL13Cg-XRHTxB2roFBpoQGvwELS8Tj1E6XXqiodyPOxwpn8mtA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Will Django ever CompositePrimaryKeys?

2019-02-19 Thread James Bennett

On Tue, Feb 19, 2019 at 4:44 AM 'Lance Ellinghaus' via Django developers
(Contributions to Django itself)  wrote:

> Should I consider his statements to be the final statement from the Django
> core developers?
>
> You should take it as someone giving their opinion on the users list.

This is the current roster of "Django core":

https://www.djangoproject.com/foundation/teams/

As to your actual question, the main issues were also discussed in the
thread:

* Someone sufficiently motivated needs to sit down and write the code and
do it in a way that integrates well into Django
* That person needs to commit, or find someone willing to commit, to
maintaining this code in Djano

To date, nobody has stepped up and complete those things. If you'd like to
make an attempt because you need the feature, you're certainly welcome to,
and I don't think anyone will try to stop you (there would almost certainly
be constructive feedback on API design, but that's about guiding something
to completion, not stopping it).

-- 
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 receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CAL13Cg9e6ojROwOb%2BjFPdAsAQ5g1pQVOZ0%3DVwNbvY9ACri9uyw%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Proposal: Track used headers and use that information to automatically populate Vary header.

2019-01-25 Thread James Bennett

On Fri, Jan 25, 2019 at 9:39 AM Linus Lewandowski <
linus.lewandow...@netguru.co> wrote:

> True, probably a way to access headers without marking them as used would
> be required - maybe something like request.headers.get(XYZ,
> vary_response=False).
>
> However, right now people are commonly forgetting to patch Vary, which
> leads to problems with caching. This way - this won't happen ever again;
> but in some cases, we might make caching less efficient than possible,
> because somebody used request.headers[XYZ] and not request.headers.get(XYZ,
> vary_response=False). Given these two cases - I feel that working correctly
> is more important than perfectly-efficient caching - but opinions here may
> differ.
>

My immediate thought here is: if people already aren't taking the time to
patch using the existing mechanism, they also aren't going to take the time
to opt out of patching. So what you're proposing is effectively still "any
accessed header patches Vary". And that seems like it's as bad as the
problem it's trying to solve.

-- 
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 receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CAL13Cg-m7QgGbvFvX89Sd5UMz1HgTmKOiU8sdBZ_zoRRNNuk_w%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: revisiting the Python version support policy

2019-01-22 Thread James Bennett

I worry about the precedent we'd set if we made an exception for Debian,
because the next question would be "OK, can we have an exception for Red
Hat, too?" Keep in mind Red Hat currently sells up to fourteen years of
support for their RHEL platform.

So I think it's best to recognize that:

People who just want to use Django, and choose to prioritize long-lived
stable operating-system distributions, will get a supported version of
Django from their operating-system vendor (and the vendor will maintain
that version of Django for the length of the vendor's support period). They
don't get to use newer versions of Django that drop support for their
vendor's default Python version, but they've already made the choice to
prioritize stability rather than access to new versions, and this is the
consequence of the choice.

People who want to contribute to Django probably already need to solve the
problem of having multiple Python versions installed, since we don't have
any releases that are tied to only one version of Python. So they need to
use something other than their system's default Python no matter what, and
dropping support for an older system Python doesn't add any complications
to their workflow.

So I don't think we should make an exception for Debian, or any other
long-lived distributions.

--
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 receiving emails from it, send an email
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit
https://groups.google.com/d/msgid/django-developers/CAL13Cg8Kccb0p0pySci1cWxHYB7RrWFV%3DmX-HwULk%2B3FEVkrgA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Request to reconsider ticket #27910: using an Enum class in model Field choices

2019-01-11 Thread James Bennett

Shai, your rebuttal still misses an important use case, which is
containment.

To continue with your example of a 'SchoolYear(str, Enum)', the following
will both be False:

'FR' in SchoolYear
'FR' in SchoolYear.__members__

The first of those is also becoming illegal soon -- attempting an 'in'
comparison on an Enum, using an operand that isn't an instance of Enum,
will become a TypeError in Python 3.8.

Instead you have to do something like:

'FR' in [choice.value for choice in SchoolYear]

to get a containment check. And you need a containment check to perform
validation.

There are other ways to do it, but they're all clunky, and this is going to
be code that people have to write (in some form) over and over again,
unless we build our own choice abstraction that hides this by wrapping an
Enum and implementing a __contains__ that does what people want. And you'd
basically have to do it in a wrapper, because Enum does metaclass stuff
that interferes with a typical "just subclass and override" approach.

So I still don't think this is going to work for the model-choice use case
without a lot of fiddling (and I'm still not a fan of the enum module in
general, largely because it seems to have gone out of its way to make this
use case difficult to implement).

--
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 receiving emails from it, send an email
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit
https://groups.google.com/d/msgid/django-developers/CAL13Cg_KEtgmNzRo%3DC8cnCiNsukr5YOCTv3MF8AybV%3D%3DiUXP0g%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Request to reconsider ticket #27910: using an Enum class in model Field choices

2018-12-31 Thread James Bennett

FWIW I'm pretty strongly -1 on this feature because Python's enums don't
behave the way people want them to for many use cases.

The basic problem is that, to take the example in the ticket, if I were to
issue a request like "/students/?year=FR", and the view were to read that
"year" param and try to filter on it, it would fail -- the string "FR" will
not compare equal to the enum member "FR". So I couldn't easily use that to
filter for students whose year is Student.YearInSchool.Freshman.

This is a deliberate design decision in Python's enums which,
unfortunately, makes them unsuitable for the kinds of things people would
commonly use them for in Django; only the special one-off enum.IntEnum has
members that actually are comparable to a base Python type, and writing
special-case enum variants for other types to try to enable comparability
would be a pain.

--
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 receiving emails from it, send an email
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit
https://groups.google.com/d/msgid/django-developers/CAL13Cg8sn4FdjmFmsKenx_MTWNPC2TuE4vhEWpsM%2B%3DGReW4OwQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Password reset token safety

2018-11-07 Thread James Bennett

SECRET_KEY is the closest thing Django has to a “root password”. That’s why
we emphasize keeping it secret — someone who knows your SECRET_KEY can
effectively do anything to your site anyway. For example, they could
produce valid session cookies for any user, and then just hop in the admin
interface.

So any attack based on “assume you know the SECRET_KEY” is already going to
be able to do anything, just like anything that says “assume you know the
server’s root password” can do anything.

-- 
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 receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CAL13Cg-GRyUvqFV4dO7aO1tjtBbXgwJjRjA_sYTFAW0D%3Doe_vA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Idea: Allow queryset.get() and queryset.filter() to accept a positional argument for implicit primary key filtering

2018-11-05 Thread James Bennett

I still don't understand the problem this is solving; is typing "pk=" (or
"id=") that much of a burden? Or that frequently left out by accident?

As it stands, I agree with Adam that this adds implementation complexity
(including potential future implementation complexity, as Ivan noted) and
proliferates different ways to do the same thing, without presenting much
in the way of concrete arguments for why it's needed. If there's a really
convincing case to be made for this, I'm open to reading it when it's made,
but for now I'd be -1 on the whole thing.

-- 
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 receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CAL13Cg9ocm_LmZSGbQG%3DEB2U0Z%2BOF5eupJFwK3OWbyz46JDj5Q%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Adjusting Django's security notification policy

2018-10-03 Thread James Bennett

On Wed, Oct 3, 2018 at 2:18 AM Markus Holtermann 
wrote:

> Can: yes. Should: no.


Yeah, the idea's been proposed a couple times, and my stance on it is that
I'd quit not just the security team, but everything Django-related, if we
did that. Pay-to-play for security is not acceptable, period.

-- 
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 receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CAL13Cg9h1sWNFe_wEZ-eTGf0dp8RTz%2BS3aCKp3qbQCV1nz6wyg%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Adjusting Django's security notification policy

2018-09-29 Thread James Bennett

Does anyone else have feedback on this? I'd like to push it forward.

On Sun, Aug 26, 2018 at 7:10 AM Adam Johnson  wrote:

> Members who are known to the security team to be maintaining codebases
>>
> on unsupported versions of Django will also be asked to provide
>> details of how they plan to migrate to a supported version, and to
>> assess whether they still require full notifiations once that
>> migration is complete. Members who do not show progress in migrating
>> toward supported versions may be removed from the list if the security
>> team judges such removal appropriate.
>
>
> This is asymmetric as it's only about those entities the security team
> knows about - new members would be incentivized to not disclose/lie. Why
> not ask everyone to disclose on joining and at each renewal, and have a
> more explicit policy, e.g. if they're on an unsupported version two years
> in a row, with no migration progress, they get removed?
>
> (There are also a couple misspellings - notifiations and regaring)
>
> On Sun, 26 Aug 2018 at 12:37, James Bennett  wrote:
>
>> There's been some discussion recently amongst the Django security team
>> regarding the way we handle advance notifications of security isues,
>> and whether we ought to change that. But since the security team is a
>> pretty small group, we'd like to take the discussion public and get
>> broader input before any decisions are made.
>>
>>
>> The current state of notifications
>> --
>>
>> When a release is being prepared that fixes a notifiable security
>> issue in Django, we currently send out two types of notifications:
>>
>> 1. A public notification sent to the django-announce mailing
>>list. This notification includes the expected date of the release,
>>the affected release series of Django, the number of issues to be
>>fixed, and a general statement of the severity of the issues. A
>>recent example of such a notification can be found here:
>>https://groups.google.com/forum/#!topic/django-announce/niifyGP58-c
>>
>> 2. A non-public notification, sent to members of the security
>>pre-notification list. All the information from the public
>>notification is present, but this non-public notification also
>>includes a full description of the issues, and the patches which
>>will be applied to each version of Django.
>>
>> Both of these notifications are sent approximately one week in advance
>> of the security release, whenever possible (there have been
>> exceptional cases where a security isuee was publicly disclosed by
>> someone else and the normal one-week period was bypassed in order to
>> get the fix out as quickly as possible).
>>
>> The rationale for the public notification is to give anyone who wants
>> it a heads-up that Django is preparing a security release; this lets
>> users of Django get ready to update their dependencies and deploy the
>> upgrade on the day it's released.
>>
>> The rationale for the non-public notification, which includes much
>> more detail, is that there are entities which need to have that level
>> of information in advance.
>>
>>
>> The rationale and history of the non-public notification list
>> -
>>
>> The original security pre-notification list consisted solely of
>> third-party redistributors of Django (such as Linux distributions
>> which provide a Django package as part of their system). Providing the
>> full details and patches allowed them to have updated packages
>> available on the date of the security release, to better protect users
>> of Django who prefer to install from their operating system's package
>> manager.
>>
>> Later, the potential eligible entities for full notification expanded.
>> Our security policy currently states that we will provide full
>> notification to:
>>
>> > On a case-by-case basis, other entities who, in the judgment of the
>> > Django development team, need to be made aware of a pending security
>> > issue. Typically, membership in this group will consist of some of
>> > the largest and/or most likely to be severely impacted known users
>> > or distributors of Django, and will require a demonstrated ability
>> > to responsibly receive, keep confidential and act on these
>> > notifications.
>>
>> The full policy can be read at https://www.djangoproject.com/security/
>>
>> The primary motiviation here is recognizing that while security
>>

Re: New Password Validators

2018-08-31 Thread James Bennett

I'm agreeing with the other replies saying that if this is really needed,
it can be done as a third-party module.

As much as possible, I want to have Django avoid promoting outdated
security policies (and the fact that many places still use them doesn't
mean they're current; it means they haven't caught up to the published best
practices).

The numeric validator does make some sense because there are cases where
you want an all-numeric credential, and where it's not bad practice to do
that. So it can stay, but I wouldn't want to add validators that try to
enforce false "complexity".

-- 
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 receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CAL13Cg_2NJvttfavz0i5WMg9tQzWMOMu6gpY49EKZ1bp6hD91A%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: New Password Validators

2018-08-30 Thread James Bennett

This type of enforced "complexity" does not increase security, and relevant
standards groups now recommend not trying to enforce these rules.

Quoting US NIST 800-63B, Appendix A:

> As noted above, composition rules are commonly used in an attempt to
increase the difficulty of guessing user-chosen passwords. Research has
shown, however, that users respond in very predictable ways to the
requirements imposed by composition rules [Policies]. For example, a user
that might have chosen “password” as their password would be relatively
likely to choose “Password1” if required to include an uppercase letter and
a number, or “Password1!” if a symbol is also required.

The NIST guidelines now say (800-63B §5.1.1.1):

> Memorized secrets SHALL be at least 8 characters in length if chosen by
the subscriber. Memorized secrets chosen randomly by the CSP or verifier
SHALL be at least 6 characters in length and MAY be entirely numeric. If
the CSP or verifier disallows a chosen memorized secret based on its
appearance on a blacklist of compromised values, the subscriber SHALL be
required to choose a different memorized secret. No other complexity
requirements for memorized secrets SHOULD be imposed.

I would be against adding validators to Django to try to enforce these
deprecated practices.

--
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 receiving emails from it, send an email
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit
https://groups.google.com/d/msgid/django-developers/CAL13Cg_%2BKMi2naSExPR0MVvBb0JnY%3DFV7A6goDHeaTWRoSpaJQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Deprecate PickleSerializer for session serialization?

2018-08-26 Thread James Bennett

The only use case for pickle that I'm aware of is "I need a way to add a
security hole to my site". So let's just get rid of it.

-- 
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 receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CAL13Cg_0PragWeEqX4fZhMLi0nr_zC-Dn_rRG-7k%3D17A%3DNgC1g%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Adjusting Django's security notification policy

2018-08-26 Thread James Bennett

There's been some discussion recently amongst the Django security team
regarding the way we handle advance notifications of security isues,
and whether we ought to change that. But since the security team is a
pretty small group, we'd like to take the discussion public and get
broader input before any decisions are made.


The current state of notifications
--

When a release is being prepared that fixes a notifiable security
issue in Django, we currently send out two types of notifications:

1. A public notification sent to the django-announce mailing
   list. This notification includes the expected date of the release,
   the affected release series of Django, the number of issues to be
   fixed, and a general statement of the severity of the issues. A
   recent example of such a notification can be found here:
   https://groups.google.com/forum/#!topic/django-announce/niifyGP58-c

2. A non-public notification, sent to members of the security
   pre-notification list. All the information from the public
   notification is present, but this non-public notification also
   includes a full description of the issues, and the patches which
   will be applied to each version of Django.

Both of these notifications are sent approximately one week in advance
of the security release, whenever possible (there have been
exceptional cases where a security isuee was publicly disclosed by
someone else and the normal one-week period was bypassed in order to
get the fix out as quickly as possible).

The rationale for the public notification is to give anyone who wants
it a heads-up that Django is preparing a security release; this lets
users of Django get ready to update their dependencies and deploy the
upgrade on the day it's released.

The rationale for the non-public notification, which includes much
more detail, is that there are entities which need to have that level
of information in advance.


The rationale and history of the non-public notification list
-

The original security pre-notification list consisted solely of
third-party redistributors of Django (such as Linux distributions
which provide a Django package as part of their system). Providing the
full details and patches allowed them to have updated packages
available on the date of the security release, to better protect users
of Django who prefer to install from their operating system's package
manager.

Later, the potential eligible entities for full notification expanded.
Our security policy currently states that we will provide full
notification to:

> On a case-by-case basis, other entities who, in the judgment of the
> Django development team, need to be made aware of a pending security
> issue. Typically, membership in this group will consist of some of
> the largest and/or most likely to be severely impacted known users
> or distributors of Django, and will require a demonstrated ability
> to responsibly receive, keep confidential and act on these
> notifications.

The full policy can be read at https://www.djangoproject.com/security/

The primary motiviation here is recognizing that while security
breaches are bad in general, not all breaches are equally bad; some
entities, if breached due to a publicly-known security issue in
Django, would have much larger impact, either in terms of the number
of people affected or the way in which they are affected. For example,
there are installations of Django which handle sensitive personal
financial or health data, which could have much more severe effects on
users if breached.

The membership of the list which receives full notification (including
issue details and patches) is not public. For sake of providing some
reference point in discussions, fewer than 20 unique email addresses
currently receive these notifications, and several of the addresses
are alternate contact routes for the same entity.


Issues with the current system
--

Nobody seems to be against providing the major operating-system
vendors with full advance notification; that's a reasonably standard
practice, and we intend to continue doing that.

There has been recent debate -- and as so often happens, it was
motivated by separate unrelated things which occurred at about the
same time -- about whether and how to continue providing full
notification to other entities, and what the responsibilities of those
entities should be.

Here are some of the major issues:

* There are many entities using Django which would fit the above
  description of high impact if breached. Very few of them are on the
  list, however, and there is a worrying pattern where entities which
  apply for and receive membership on the notification list overlap
  significantly with entities that employ prominent members of the
  Django community (i.e., Django committers). While this mostly seems
  to be caused by those entities not being aware of the

Re: Model default modelform

2018-08-20 Thread James Bennett

I'd be -1 on anything that encourages people to use ModelForm with all
fields included by default; that's asking for mass-assignment security
holes.

-- 
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 receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CAL13Cg--AGfXz4uLtAbC0miGCrQE9M1o6_cbC114UULBVhOPJg%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: HTML5 and XHTML5 documents

2018-08-17 Thread James Bennett

On Fri, Aug 17, 2018 at 3:41 AM, Nils Fredrik Gjerull 
wrote:
>
> I am talking about being able to serve pages as application/xhtml+xml,
> this is defined by browser support as is the SGML version of HTML5. I
> hardly think XML version of HML5 is more ill-defined than the SGML
> version. I am not talking about supporting validators, as the browsers
> are the validators. No need to use a validator if the browser makes it
> clear when it is not. No need to limit what entities to use as long at
> it is supported by the browsers.
>

If you're basing your understanding on browser support, you're not doing
XML/XHTML. You're doing "a thing that looks like XHTML and works in my
browser".

I'm even *more* against having Django try to do that, since it's a moving
target.

-- 
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 receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CAL13Cg9UEtSBEPnc0_OJWy4HHALSA-XOLhgKBnnF5Fq7%3Dr811Q%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: HTML5 and XHTML5 documents

2018-08-17 Thread James Bennett

On Fri, Aug 17, 2018 at 1:50 AM, Nils Fredrik Gjerull
wrote:

> I still would like a technical answer to why not support both standards?
> And again XHTML5 is HTML5 with valid XML syntax. So valid XHTML5 is
> valid HTML5, so there is no problem for a framework to provide HTML5 it
> should just be done in the most compatible manner.
>

You probably won't get a "technical answer", because what you're proposing
is not a technical change.

So, look. I was someone who, in the 2000s, passed Evan Goer's "XHTML 100"
test, even if he didn't test my site as part of it. I bought into it. But I
gradually learned it's more of a headache than it's worth, and should be
discouraged as a default. People who do still have use cases requiring XML
toolchains are free to implement what's necessary to support that (for
Django, that's mostly templating changes, and I believe we make it easy
enough to supply your own overrides that you could do it as a 100%
third-party effort for anyone else who shares your desire for XHTML).

But requiring Django to maintain XML-serialization-of-HTML5 compatibility
is a non-starter. It commits everyone else on earth to keeping that
supported, to ensuring we never do anything that's not XHTML-compatible,
etc., in order to serve a very small subset of developers, and I don't
think you realize how much specialized domain knowledge is actually
necessary to do that (it's more complex than "/>" and specifying attribute
values).

And I suppose if you really want technical arguments:

JavaScript is not portable between XML and HTML contexts, full stop. This
isn't just about the CDATA dance you have to do with inline script
elements; it's about the fact that the HTML and XML DOMs are different. And
not just with respect to namespaced versus non-namespaced DOM methods:
XML's rules literally do produce a different parse tree from the same DOM
when compared to HTML's.

XHTML5 itself is neither well-specified nor robust; the new elements of
HTML5 are more or less dumped by fiat into the old 1999/XHTML namespace,
but who's to say parsers will actually be aware of that? Especially
validating parsers? Can you point to a standardized XML DTD, XSD, RELAX NG
or, well, anything that's broadly accepted as defining XHTML5? W3C doesn't
publish one that I'm aware of, and the Editor's Draft for Polyglot does not
provide guidance.

And speaking of validating parsers: HTML5 has a large set of named
entities. Validating XML parsers are required, as always, to accept only
the base five of XML, and can fatal-error on anything else. For
non-validating parsers, or for those which choose to accept more than the
base five named entities, XHTML and HTML historically did not agree on the
set (XHTML defined 253 named entities, HTML historically defined at most
252). More fun times there. XML-ENTITY-NAMES tried to alleviate this by
defining and exposing entity sets documents could refer to, but see again:
validating parsers don't have to accept them. Are we forbidden ever to use
an HTML5 entity, or anything outside the base five XML entities, in Django,
in order to make sure serving Django as XHTML works? I hope not.

While we're on the topic of characters: HTML5's character encoding rules
are not compatible with XML's. Compliant HTML5 processors *must* use the
8.2.2.2 encoding sniffing algorithm in their first pass, and this can
produce a different determined encoding than XML's rules (and let's not get
into the quagmire of default encoding varying with Content-Type headers).

And, well, I could go on for a while here because my rants on this topic
are pretty well-developed at this point, but I'll just leave it alone here.
I'm strongly against any attempt to have Django try to produce
XML-serializable polyglot HTML5.

--
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 receiving emails from it, send an email
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit
https://groups.google.com/d/msgid/django-developers/CAL13Cg_NdtL2kO_VCO41hAprWi3r5%3DF1baD0ASchCoBoMQexmQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Spaces between argument separator and argument in template filter generate error

2018-05-31 Thread James Bennett

On Thu, May 31, 2018 at 1:39 AM,  wrote:

> Are there any reasons that not allow spaces between separator and arg?
>

Every optional variant of template syntax is a potential source of bugs or
compatibility issues for the future. And a potential source of confusion
when someone is trying to learn by reading code -- why did one developer do
it *this* way, while another developer did it *that* way? And another
choice every dev team has to make when putting together their style guide,
and another option they have to set on their linters, to make sure they get
a consistent codebase.

For these reasons, the default position should be "don't add it unless
there's a very good reason to". If there is a good reason to add it, please
explain so we can understand why you're requesting it.

-- 
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 receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CAL13Cg98d4UX2RcypOeiRnCU-TczNzqO90unjLgt4y8q8YugPg%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Proposal: security enhancements

2018-05-15 Thread James Bennett

If anyone feels competent to review, there's a PR open now for the first
part of this, adding Referrer-Policy support:

https://github.com/django/django/pull/9953

-- 
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 receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CAL13Cg_S%2Bt4s4JN3pRxQbsqbguGExnyiNn8sgHwSJFOO2HqAtQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

1 2 3 4 5 6 7 8 9 10 >

1 - 100 of 901 matches

Mail list logo