, forms do,” or
better to say “the ORM will validate on Model.save() but not in various
other cases, so you still can’t really rely on the ORM to enforce model
validation invariants consistently.”
Carl
>
--
You received this message because you are subscribed to the Google Groups
&quo
After some digging, I was able to find the reason for why adding the
Whitenoise middleware to my Channels-enabled project was causing a massive
performance drop.
It appears that for every inbound HTTP request, Channels initializes a new
AsgiHandler. In turn, this means that the entire midd
On 5/16/18 10:49 AM, Florian Apolloner wrote:
> Hi Carl,
>
> On Wednesday, May 16, 2018 at 5:58:02 AM UTC+2, Carl Meyer wrote:
>
> I'm not sure this part is feasible. It's an intentional part of
> middleware design AFAIK (and useful) that middleware can modify
eware chain is entered
I'm not sure this part is feasible. It's an intentional part of
middleware design AFAIK (and useful) that middleware can modify
request.path and have this modification respected in view resolution.
Carl
--
You received this message because you are subsc
A may be one-way, and we shouldn't have to introduce knowledge
of B into A's migrations -- and A may even be third-party). IMO this
would be a reasonable feature addition.
Carl
--
You received this message because you are subscribed to the Google Groups
"Django developers (
though, that five or six years ago we _had_ a
range of different migrations solutions that chose different tradeoffs,
and South was the clear winner in user uptake. It's not due to arbitrary
whim that the Django migrations system is based on South and preserves
its popular features, like the hist
there could be much subtler problems (e.g.
performance issues) caused by e.g. accessing a descriptor that does a
database query or something.
Carl
--
You received this message because you are subscribed to the Google Groups
"Django developers (Contributions to Django itself)" group.
To unsu
ly provide little value to the majority of
Django users.
Carl
--
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
e one such context-manager instead of the existing CursorDebugWrapper.
Why a new thread-local instead of explicitly per-connection and stored
on the connection?
Carl
--
You received this message because you are subscribed to the Google Groups
"Django developers (Contributions to Django itself)
Hi David,
I wouldn't bother with the wsgiwatcher repo; it's proof-of-concept code
from one sprint's worth of hacking, not used by anyone. Look at hupper
instead, it is based on wsgiwatcher, but much changed, and actually used
in production.
Carl
On 04/02/2017 04:27 PM, qingni
://docs.pylonsproject.org/projects/hupper/en/latest/
Carl
--
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-developer
ut the
cookies you strip (e.g. only strip cookies that are known for sure to be
unused on the server, like Google Analytics cookies for instance.)
>
> This issue reminds me of another issue I came up with (or as Carl puts
> it: "…presenting the hypothetical case that exposed th
erve a
cached response. (And if the cache holds on to the response, it'll
associate with the the request it saw, which still had all its cookies).
Carl
--
You received this message because you are subscribed to the Google Groups
"Django developers (Contributions to Django itself)"
s, but they would still be safe (not serve anyone
the wrong response). And you should be able to help efficiency of
Django's own cache this way, if you strip cookies that Django / your
code doesn't care about before the request ever reaches the caching
middleware. Try it and experiment!
s the expression to have y's value when evaluated in
>an if. I think this is something to do with the fact that the two
>ways of handling failures (ignore_failures and string_if_invalid)
>do different things.
>
>I don't see a way to make backward compatible code here
On 01/04/2017 02:53 PM, Tim Graham wrote:
> I'd like to know from Carl, Adam, and others, how much effort would be
> required to adapt the templates in your project for the new behavior. I
> imagine a script could be written to add newlines after all {% include
> %} in all pla
k on "Engines" when we don't to any of
the other names (even though they all use a template engine or engines);
maybe just "django.forms.renderers.TemplatesSetting"?
I still slightly prefer "ProjectTemplates", but you're painting the
bikeshed, feel free t
emplate, why is the variable not in the templates
> for widgets, after all it is in the same template directory.
> I am already using django-sniplates via libraries in the TEMPLATE
> config, as migration step I want to reuse that for the widgets, why are
> they not getting picke
Sure, I guess Florian mentioned dropping Jinja2TemplateRenderer, but I
don't really see a strong argument against keeping and documenting it.
As you say, cost is low.
Carl
On 12/20/2016 11:55 AM, Tim Graham wrote:
> I thought maybe that use case could be an argument for kee
r", I think we mean as the most flexible and least
surprising option for most projects that just want Things To Work, not
that it will always meet everyone's needs. If you have more specific
needs, you can always write a form renderer that meets them.
Carl
On 12/20/2016 11:16 AM, Florian
eRenderer" -- it's not that hard to switch to
ProjectTemplateRenderer.
I would not be in favor of the FORM_TEMPLATE_DIRS setting. It adds a
brand-new concept and setting, which would typically be set to the same
value as your template DIRS in the common case, without really gaining
any flex
On 12/14/2016 11:08 AM, Carl Meyer wrote:
> As for whether a hypothetical third-party app that wants to override
> form widgets should do it by just providing the template overrides and
> clearly documenting that, or should do it by providing a custom form
> renderer, that's a sep
S 'POST_APP_DIRS' option to accomplish this but it might be
> unneeded complexity. I mentioned, "I'm concerned that it gives the idea
> that third-party apps should be overriding templates to customize things
> when that's really not appropriate since only the templ
teRenderer,
for completeness, and because not all projects use the admin. But the
docs should be clear about the limitations, and point to
ProjectTemplateRenderer for more flexible setups.
Let me know once you have a PR that you feel is ready for review, happy
to review it.
Carl
--
You received this
re sourced,
switch to ProjectTemplateRenderer.
And of course you can always write your own renderer class if you need
even more control than that.
Anything I missed?
Carl
I thought I'd try something to get the
> conversation going again. I've been reacting to some tickets based on
&g
only works if you are working from a git
repo, not an exported source tree. An exported source tree, independent
of git, should still know at least what released version it represents.
I am sure if we break this, it will break somebody's workflow.
Carl
--
You received this message becaus
ror
that pytz isn't installed. That's not acceptable. Having pytz installed
in some cases when it isn't strictly needed is a very small price to pay
for a smoother path in the common case.
Carl
--
You received this message because you are subscribed to the Google Groups
"Django
noted in the release notes). But
it's a big problem if someone were to silently stop getting logging
output that they currently get.
Carl
--
You received this message because you are subscribed to the Google Groups
"Django developers (Contributions to Django itself)" group.
To un
ation path to get there, at least for
people who currently have disable_existing_loggers=False, in order to prevent
them from suddenly losing the default config.
Carl
> - If `disable_existing_loggers` is True, the incompatibility would manifest
> itself in Django loggers not being silenc
Fixing this in a way that doesn't change logging behavior for projects
upgrading from a previous Django version may be tricky, unless we gate
the effect of the change on (yet another) setting.
Carl
--
You received this message because you are subscribed to the Google Groups
"Djang
On 09/06/2016 12:55 PM, Aymeric Augustin wrote:
> Hi Carl,
>
> Thanks for the feedback!
Of course! Thanks for working on things :-)
> ...
> The change I’m proposing doesn’t introduce random bugs. If models are
> missing reverse relations, that will be deterministic.
+1
>&
issues so I can't yet offer more detailed feedback on
how much the availability of this particular API would help.
Carl
--
You received this message because you are subscribed to the Google Groups
"Django developers (Contributions to Django itself)" group.
To unsubscribe from this
update latency low?
2) I think it was done this way originally because whoever did it was
scared of touching Trac's Python code (with reason), and it was simpler
to just do it in JS, not for any deeper reason.
Carl
--
You received this message because you are subscribed to the Google Groups
On 06/24/2016 03:04 PM, Tim Graham wrote:
> With the idea of saving characters in the first line, would "Fix #XXX:
> Message" be better than ""Fix #XXX -- Message" also? This saves two
> characters without any loss of readability as far as I see.
Seems reasona
On 06/24/2016 12:15 PM, Jon Dufresne wrote:
> On Fri, Jun 24, 2016 at 10:48 AM, Carl Meyer <mailto:c...@oddbird.net>> wrote:
>
> To be clear, the recommended git style is not present tense, it is
> imperative mood. So it should _not_ be "Fixes #12345 -- Regul
To be clear, the recommended git style is not present tense, it is
imperative mood. So it should _not_ be "Fixes #12345 -- Regulates the
frobnicator", it should be "Fix #12345 -- Regulate the frobnicator."
Carl
On 06/24/2016 11:45 AM, Tobias McNulty wrote:
> I'm in
to do clearly
when the entire commit message is supposed to worded in the past tense.
So I find all the advantages (except for consistency with past history)
in favor of switching to the imperative mood.
Carl
--
You received this message because you are subscribed to the Google Gro
or to behave, and I think probably it should have an API that
clarifies that what it's really doing is applying per-view middleware.
Still halfway tempted to go with the original "make middleware authors
responsible for this themselves, if they want to access
response.content" approa
On 06/21/2016 10:53 AM, Carl Meyer wrote:
> If we're OK in the long term with making middleware-turned-decorator
> authors responsible for correctly handling TemplateResponse themselves,
> we should just go there right away via
> https://github.com/django/django/pull/6765 -- we
Hi Tobias,
On 06/21/2016 06:22 AM, Tobias McNulty wrote:
> On Mon, Jun 20, 2016 at 10:51 AM, Carl Meyer <mailto:c...@oddbird.net>> wrote
>> Possible disadvantages of this approach:
>
>
>
>> 3. The new behavior may surprise some people accustomed to the ol
, leaving
them no way to continue to provide their old decorator with fully
backwards-compatible behavior.
Basically, I think middleware_decorator does something that's
fundamentally different enough from decorator_from_middleware that it is
clearer to make it a separate function and let people
rator itself doesn't have any dependency on
which type of middleware your project uses), but under this proposal it
would instead suddenly raise an error if you even try to import it.
I think this approach is more problematic and less backwards-compatible
(especially for third-party projects
he effects of the
middleware decorator in the actual response (it would only see a new
entry in view_func._extra_middleware).
Thoughts welcome.
Carl
[1] https://github.com/django/django/pull/6765
[2] https://github.com/django/django/pull/6805
--
You received this message because you are subscr
in that PR is less relevant, it doesn't represent the
latest plan of action that we need feedback on, which is outlined in the
discussion thread.)
Thanks,
Carl
--
You received this message because you are subscribed to the Google Groups
"Django developers (Contributions to Dja
the current behavior with prefetched-data on a related manager is
a bug that should be fixed (though it certainly should be mentioned in
the release notes).
Carl
--
You received this message because you are subscribed to the Google Groups
"Django developers (Contributions to Django itself)
some part of your concept externally, then discussion of addressing that
limitation would certainly belong here.
Carl
--
You received this message because you are subscribed to the Google Groups
"Django developers (Contributions to Django itself)" group.
To unsubscribe from this g
uding with proposals from
core team members. See for example South, django-security,
django-transaction-hooks, django-channels...
So my recommendation is that you implement your proposal as a
pip-installable library and advertise it, see whether it gains traction
that way, and see what you learn ab
start the project, and then run the internal
> web server are going to get missing dependency problems.
That's an excellent point. I agree, we should just add pytz to install_requires
if we require it for USE_TZ=True, otherwise the default new-project experience
is unpleasant.
Carl
--
On 06/04/2016 12:38 PM, Carl Meyer wrote:
> I just realized that I think something's gotten lost in this thread:
> Josh's original point was about requiring pytz _if you want timezone
> support_ (that is, if USE_TZ=True). That would I presume involve raising
> ImproperlyConfi
support their use-case, it's a non-zero added
burden to require them to pull in a frequently-updated useless dependency.
Carl
--
You received this message because you are subscribed to the Google Groups
"Django developers (Contributions to Django itself)" group.
To unsubscribe from
it's fine to just make it a required
dependency if that saves us significant work on a valuable new feature
or refactoring. I don't really see the hurry to make it a required
dependency just for its own sake, though.
Carl
--
You received this message because you are subscribed to
new API
in the template engines. That's a more significant change than I had
thought we needed, but it may be the best option.
I'm happy to work on this issue more, but it's not likely to be until
the PyCon sprints.
Carl
--
You received this message because you are subscribed
ONS': {
> 'loaders': [
> 'django.forms.templates.loader.WidgetTemplateLoader',
> ]
> },
> },
> }
I think the solution needs to be at a higher level than DTL loaders,
because it should work also for Jinja2.
And this approach doesn
ly and unconditionally know
about django.forms (even if you maybe aren't using forms at all -- maybe
you're using the template engine standalone for something else entirely)
doesn't seem right at all.
Carl
--
You received this message because you are subscribed to the Google Groups
&q
The technical board has approved DEP 5, and since the patch [1] is also
ready to go, I moved it straight to Final state. Thanks to everyone who
contributed to the discussion, and especially to Florian and Tim for the
patch.
Carl
[1] https://github.com/django/django/pull/6501
--
You
found by the same template
engine.
This might be another argument in favor of deprecating the fallback and
actively pushing people to just get 'django.forms' into their
INSTALLED_APPS. But we can wait on that, like you said.
Carl
--
You received this message because you are subscribed to the G
control not only markup
generation but also data retrieval, control over widgets themselves
needs to remain in Python code. But the rendering template could be
given the option to customize the template used to render the widget.)
Carl
--
You received this message because you are subscribed to th
On 05/15/2016 09:58 PM, Carl Meyer wrote:
> Yuck. Is there only one admin widget that includes a built-in widget? If
> so, I think we would maybe be better off just duplicating that one
> built-in widget in the admin templates.
That should read "built-in template," not "
On 05/12/2016 09:39 AM, Tim Graham wrote:
> So this discussion doesn't stall the rest of the patch, I suggest
> keeping the fallbacks for now and deprecation them later if they cause
> confusion or other problems.
Yes, I think that makes sense.
Carl
--
You received this message b
On 05/11/2016 11:52 AM, Carl Meyer wrote:
> On 05/11/2016 11:30 AM, Tim Graham wrote:
>> What's your proposal for changing the default TEMPLATES? Using Jinja2 or
>> DTL?
>
> At some point maybe we can adopt Jinja2 as a required dependency. Until
> then, the default st
rtproject template can't use it, so I think DTL is
the only real option.
> Since others have supported the idea, feel free to push your ideas to
> the branch -- I won't be working on that branch for the rest of today.
Ok, will do.
Carl
--
You received this message because
On 05/10/2016 03:37 PM, Carl Meyer wrote:
> I've
> updated the DEP with a couple minor changes to reflect the latest
> learnings from the implementation; you can see the latest changes at
> https://github.com/django/deps/compare/763530e1a9...master
Better version of this link
n be
contacted privately, even in early draft stages). So I'd personally be
fine with a PR to amend this section to remove mention of private
contact. Jacob, I think you wrote this (or adapted it from PEP 1) -- any
thoughts?
Carl
--
You received this message because you are subscribed to th
ages, as well, it could provide a useful
> base for that to structure around (though we'd want to beef up
> security/backwards-compat timelines).
>
> It's also probably sensible that whatever we come up with covers
> localflavor, as well, since that's sort of in
ed and
appropriately skilled party provides a useful graphic, that'd be great
of course!
Carl
> On Friday, May 6, 2016 at 7:59:38 PM UTC-4, Carl Meyer wrote:
>
> I agree with Simon on both counts. We do usually continue to test
> deprecated code paths until they are remov
ave the default
FORM_RENDERER setting be a renderer that doesn't allow easily overriding
templates, and I don't think that we should allow the transition
concerns to override reaching the right long-term solution after a
transition path.
Carl
--
You received this message because you a
staticfiles case is a known problem with management command
overriding, and I don't have a good solution. I guess it's a choice
between monkeypatching vs having to document a required ordering of
staticfiles vs channels in INSTALLED_APPS.
Carl
--
You received this message because yo
complain about this - if we are
> going to want DEPs for features similar to the ideas discussed in this
> thread, then the timing for requesting a DEP was accurate.
Agreed.
Carl
--
You received this message because you are subscribed to the Google Groups
"Django developers (Contrib
orking precisely the way it should work: first post some general
thoughts, collect ideas and responses to those thoughts, then work that
into a DEP with a specific proposal, followed by more detailed
discussion of that specific proposal.
Carl
--
You received this message because you are subscri
I think this
fallback is more flexible and simple enough that we could consider
keeping it in place permanently, if you and others prefer that.
(I also removed the whole engine_name thing in that commit; it doesn't
really seem worth it. If you're subclassing TemplateRenderer, it's e
the middleware is incidental to the tests vs
the direct subject of the test. But it might be simpler to just do them
all than to make that determination.
Carl
On 05/04/2016 08:57 PM, charettes wrote:
> Hi Tim,
>
> I think we should favor displaying a message in accordance with the
>
On 05/06/2016 02:31 PM, Andrew Godwin wrote:
>
> On Fri, May 6, 2016 at 1:19 PM, Carl Meyer <mailto:c...@oddbird.net>> wrote:
>
> On 05/06/2016 01:56 PM, Donald Stufft wrote:
> > User level code would not be handling WebSockets asynchronously, that
>
taken by hendrix [1]. I'd be curious, Andrew, if
you considered a thread-based approach as an option and rejected it? It
does seem like, purely on the accessibility front, it is perhaps even
simpler than Channels (just in terms of how many services you need to
deploy).
Carl
[1] http://hendrix.
s
for you and makes it really easy to keep all your code together. And (as
long as we still support plain WSGI) it doesn't remove the flexibility
for more advanced users who prefer different tradeoffs to still choose
other approaches. There's a lot to be said for that combination of
"accessi
s well (I think you've been
doing a great job with it so far on these latest threads) and a
satisfactory resolution is reached in time for a merge into 1.10.
Carl
> I think you're entirely right, Carl - I'm just getting frustrated with
> myself at this point for not realisin
gs of long-standing core aspects of how Django works, which in
my mind makes them prime DEP candidates, whereas FTS and password
validation both seem to me like small-to-medium peripheral features that
I wouldn't necessarily have expected to have one.
Carl
--
You received this message because y
ved DEP. The argument has been that merging it "sends
the right signal to the community," but I have some concern that rushing
the merge could send negative signals about process consistency and
fairness that could easily outweigh any positive signals about Django
"having an a
late that isn't destined for the
browser anyway, so doesn't need to be safe", then I think it would be
wrong to automatically mark that output as safe.
Carl
--
You received this message because you are subscribed to the Google Groups
"Django developers (Contributions to Djang
n to believe that a string resulting
from rendering a template is necessarily a safe string.
Carl
--
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 em
e, and I think it's fine, but this is
an example of precisely the sort of more-magical opinionated approach to
settings that I don't think belongs in Django core; it's perfectly
possible to implement it as a third-party package on top of Django's
current settings handling, for tho
number of arbitrarily-named modes, but in
practice I've never used anything but 'dev' and 'prod' (staging and demo
sites are generally set up as 'prod'). Hardcoding to those two modes
would perhaps allow a nicer syntax for specifying defaults, by using
separate kwargs in
ding tests for undefined and
unreliable behavior.
It might be worth adding a short documentation note. We largely want to
avoid documenting Python's behavior in the Django docs, but a short note
in the template `is` docs reminding people not to ever use `is` with
strings or numbers might be wor
t;` in Python is
effectively accidental and almost certainly useless (it does correctly
and reliably tell you whether the two string objects are the same
object, but for immutable objects this information is
performance-optimization-dependent and useless), so there is no
"correct" behavior here fo
xactly the right corresponding version, and there's not much
reason to make that work necessary.
Carl
On 04/06/2016 10:58 AM, Tim Graham wrote:
> From a Trac ticket [0]:
>
>
> In Debian, we like to have the sources of everything that we ship and we
> consider that minified j
Model.__init__() is specifically called out in the
documentation as something to avoid, and there is no mention in the
documentation of what is passed to __init__() in the case of defer/only.
I think this is a fine change to just document in the release notes.
Carl
--
You received this message
e in the long run.
+1 to this, I've long felt that the Site model was an anti-pattern. I
don't know if it's worth deprecating and switching to a different
system, though; it'd be a relatively painful deprecation for those using
it, I would guess.
Carl
--
You received this me
I've updated DEP 5 with a new round of clarifications and tweaks based on
the most recent feedback:
https://github.com/django/deps/compare/62b0...master
Carl
--
You received this message because you are subscribed to the Google Groups
"Django developers (Contributions to Dja
ks. I've added it to the todo checklist on the PR:
https://github.com/django/django/pull/5949
Carl
--
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
. We've run into this issue with the
> change of the database test settings.
Yes; I think a checks-framework warning (like what we do for
`TEMPLATE_*` vs `TEMPLATES`) is the appropriate level; likely to catch
an unintentional usage, but silence-able if the duplication is intentional.
Carl
rid middleware that conditionally does something-vs-nothing (or
one-thing-vs-another) depending on some attribute attached to the request.
Carl
--
You received this message because you are subscribed to the Google Groups
"Django developers (Contributions to Django itself)" group.
To unsu
idea. I think I had vaguely in mind that this wasn't
possible because the global default for MIDDLEWARE_CLASSES is non-empty,
but I guess we can still check to see whether the actual value != the
global default.
> Beyond that, I love the overall design of this upgrade :)
Great!
Carl
--
You
I think the template files should be shipped out as .py-tpl, since that's
their type (a Python template), and the resulting final files should just
have the extension renamed. Having two extension is just confusing and
leads to questions like this one about other kinds of templates.
--
You rec
t.
I agree that a "resetmigrations" command is dangerous. For my own usage
I'd be more worried about losing custom SQL schema or indexes added via
RunSQL than I would about initial-data migrations, but either way it's
certainly potentially lossy. I'd only be -0 on a
e interested in doing the work if the PR will get the
> traction.
That'd be great! I can't see any reason why a good PR for that wouldn't
be accepted. There's no reason to be using the ugly algorithms in
`get_or_create` or `update_or_create` when native UPSERT is availa
On 01/08/2016 11:38 AM, Carl Meyer wrote:
> On 01/08/2016 04:51 AM, Markus Holtermann wrote:
>> Nitpicking, I would also name the settings variable MIDDLEWARES
>> (i.e.plural) as it is a list of middlewares, not just one.
>
> Well, this is a matter of some debate
uot;just return ``get_response``" trick, whether it's documented or
not, and I think that's totally fine.
Carl
--
You received this message because you are subscribed to the Google Groups
"Django developers (Contributions to Django itself)" group.
To unsubscribe from thi
plural (there are such words in English) and dislikes "middlewares."
So I'd prefer to stick with MIDDLEWARE and haven't changed it in the
spec. But if most people think MIDDLEWARES is better, I won't stand in
the way.
We could also go with something like MIDDLEWARE_FACTORI
o
their settings file is almost certain to end with it blowing up in their
face at some point.
Carl
--
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
commenting via
email.
Comments welcome!
DEP 0005: Re-thinking middleware
:DEP: 0005
:Author: Carl Meyer
:Implementation Team: Florian Apolloner
:Shepherd: Carl Meyer
:Status: Draft
:Type: Feature
:Created: 2016-01-07
:Last-Modif
the issue is easily
resolved by including the original DRF license text in your base/api/
directory, and clarifying that that license (not the AGPL) is the
license that applies to all code taken from DRF.
Carl
--
You received this message because you are subscribed to the Google Groups
"Dj
1 - 100 of 768 matches
Mail list logo
