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
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'
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
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
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**,
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
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)"
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
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
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
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
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
It feels like this needs to be a broader conversation about not just
changing DATABASES to accept a URL, or integrating a particular
database-settings project, but to re-think how Django does
settings-from-environment as a whole.
When I'm setting up new Django-based projects, django-environ
On 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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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,
>
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
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.
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
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
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
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
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
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
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
>
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
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
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
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
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
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
>
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
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
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
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
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,
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:
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
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,
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
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
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
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
>
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
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
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
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
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
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
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
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,
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
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
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
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
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 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
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
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
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
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
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
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,
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
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
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
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
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:
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'
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
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
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
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.
--
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 discuss
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
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
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
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
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
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
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
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
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)"
1 - 100 of 901 matches
Mail list logo
