Re: Model-level validation

On Thu, Sep 29, 2022 at 6:19 PM Curtis Maloney wrote: > On Thu, 29 Sep 2022, at 14:29, Aaron Smith wrote: > > Why doesn't Django validate Models on save()? > > > The short answer is: backwards compatibility. > > Model level validation hasn't always been a thing, with Django initially > depending

Re: Simplify middlewares (again) and get rid of process_view

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 >

Re: Simplify middlewares (again) and get rid of process_view

Hi Florian, On 5/12/18 10:22 AM, Florian Apolloner wrote: > After refactoring the middlewares to new-style middlewares as we have them > now, I am left with two pain points: > > * atomic requests are still special cased and not in a middleware > * process_view is as useless as always (it can

Re: About migrations

On 07/07/2017 05:09 AM, Patryk Zawadzki wrote: > Right, and one reason for generating those "no-op" migrations is that > they aren't actually no-ops, if you value being able to write data > migrations in Python using the ORM. They keep the historical Python > models accurate. > >

Re: About migrations

On 07/04/2017 07:04 AM, Patryk Zawadzki wrote: > Have DB backends understand certain field types expressed as strings > ("varchar", "text", "blob", "decimal" and so on). > > Possibly some backends could implement a wider set than the others > ("json", "xml", "rasterimage" etc.). > > Have each

Re: Exceptions in model._meta._property_names with some 3rd-pty libraries

Hi Zack, On 06/02/2017 02:02 PM, Zack Voase wrote: > Hi all, > > I'm encountering exceptions in a number of popular third-party Django > libraries when upgrading from 1.8 to 1.11. The code path is typically > `MyModel.objects.get_or_create(...)`, which causes > `model._meta._property_names` to

Re: Cython usage within Django

On 05/21/2017 02:59 PM, Tom Forbes wrote: > There are lots of considerations to take into account (like ensuring the > Cython functions are in sync with the fallback ones) It's possible to only have one version of the code, using only Python syntax, and conditionally compile it with Cython if

Re: Database "execute hooks" for instrumentation

Hi Shai, On 04/07/2017 06:02 AM, Shai Berger wrote: > This is an idea that came up during the djangocon-europe conference: Add the > ability to install general instrumentation hooks around the database > "execute" > and "executemany" calls. > > Such hooks would allow all sorts of interesting

Re: A proposal for a new auto-reloader in Django

d Ma > > On Thursday, March 30, 2017 at 7:47:13 AM UTC-7, Carl Meyer wrote: > > Anyone working on this project should at least be aware of > https://github.com/Pylons/hupper <https://github.com/Pylons/hupper> > (based on work David Glick and I > origina

Re: A proposal for a new auto-reloader in Django

Anyone working on this project should at least be aware of https://github.com/Pylons/hupper (based on work David Glick and I originally did in https://github.com/carljm/wsgiwatcher), which aims to be a framework-agnostic solution to this problem for any Python web project. Docs at

Re: Adding a middleware to match cookies

On 01/07/2017 03:25 AM, Florian Apolloner wrote: > On Saturday, January 7, 2017 at 3:50:56 AM UTC+1, Jeff Willette wrote: > > What if there was an optional middleware early in the request > processing that matched cookies based on a regex in settings and > then modified the header to

Re: Adding a middleware to match cookies

On 01/06/2017 11:26 PM, Jeff Willette wrote: > Wy would this not help the efficiency of the downstream caches? Is it > because the request has already passed through them with the cookies > intact? and when it comes back through the response they have no way to > know they have been stripped?

Re: Adding a middleware to match cookies

Hi Jeff, On 01/06/2017 06:21 PM, Jeff Willette wrote: > I understand that calling is_authenticated on a user will require the > session to be accessed and the vary by cookie header to be in the > response, but if I understand how caching systems work then this will > cause all cookies in the

Re: Template handling of undefined variables

Hi Tim, On 01/04/2017 03:39 PM, Tim Martin wrote: > I've been looking at bug #24977 (Template variables with a value of > None are considered to be == to non-existent properties). ... > The suggestion on the ticket is to use an instance of a special > `Undefined` class to indicate an undefined

Re: Changing {% include %} to strip a trailing newline

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 plain text templates,

Re: Template-based widget rendering

On 12/20/2016 02:04 PM, Tim Graham wrote: > I think it would be nice to be able to look at the name of the "project" > renderer and understand that it's connected to settings.TEMPLATES. I'm > not sure if the term "project" does that well. Maybe > "TemplatesSettingEngines"? Yeah... I guess I

Re: Template-based widget rendering

On 12/20/2016 01:26 PM, Tim Graham wrote: > Okay I removed 'POST_APP_DIRS' from the PR. > > Next, we should discuss whether or not to make the ProjectTemplate > renderer the default FORM_RENDERER in the startproject template. (For > backwards compatibility, DjangoTemplateRenderer has to be the

Re: Template-based widget rendering

you > and Florian is to drop it. Fine with me. > > On Tuesday, December 20, 2016 at 2:26:33 PM UTC-5, Carl Meyer wrote: > > I think that a) wanting render forms via Jinja and everything else via > DTL, and b) caring about the perf impact of checking two engines is an >

Re: Template-based widget rendering

's no further input, I'll finish adding tests and > docs for the TEMPLATES 'POST_APP_DIRS' option tomorrow, > after which I think the widget rendering patch will be ready > for final reviews. > > On Wednesday, December 14, 2016 at 6:40:36

Re: Template-based widget rendering

Hi Tim, On 12/14/2016 12:50 PM, Tim Graham wrote: > My thinking is that there should typically be only one directory in each > project that overrides built-in templates, otherwise if multiple apps > provide overrides, they'll stomp on each other when using the > app_directories loader.Are your

Re: Template-based widget rendering

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 separate

Re: Template-based widget rendering

On 12/14/2016 10:27 AM, Tim Graham wrote: > I'm not sure if having the default renders insert the built-in form > templates directory after the app dirs (as opposed to before, as usual > with 'DIRS') is the best approach. On the PR, we discussed adding a new > TEMPLATES 'POST_APP_DIRS' option to

Re: Template-based widget rendering

Hi Tim, On 12/07/2016 08:41 AM, Tim Graham wrote: > This scheme seems to be working well so far. Great, thanks for working on implementation. I did have intentions of putting together the implementation once I'd gotten your feedback on the design, but I won't complain if you've already done it

Re: Template-based widget rendering

Hi Tim, On 11/16/2016 06:23 AM, Tim Graham wrote: > I took a stab at backwards-compatibility with respect to allowing the > admin to work without adding 'django.forms' to INSTALLED_APPS. It seems > to work for at least the simple TEMPLATES = 'BACKEND': >

Re: automating Django releases

Hi Tim, On 11/25/2016 11:49 AM, Tim Graham wrote: > After doing releases about once a month for a while, I'm thinking it > would be nice if releasing Django could be a bit more automated. As far > as I know, the process hasn't changed too much in 10 years, while the > state of Python packaging

Re: Should we require pytz for timezone support in Django?

Hi Kevin, On 10/09/2016 11:09 AM, Kevin Brown wrote: > I agree with requiring pytz if you have timezone support enabled in > Django, as that cuts out a set of edge cases and likely simplifies the > code base a bit in the long run. And I even agree with forcing it to be > installed with Django if

Re: Logging config tries too hard

On 09/08/2016 11:31 PM, Ivan Sagalaev wrote: > I'm not familiar with the current deprecation policy in Django. If you > can point me to it, I could probably carve some time in the nearby > future and prepare a pull request. Here is the deprecation policy:

Re: Logging config tries too hard

On 09/06/2016 04:57 PM, Ivan Sagalaev wrote: > I'm > talking about this function: > https://github.com/django/django/blob/master/django/utils/log.py#L66 > > When `LOGGING_CONFIG` isn't explicitly disabled it first unconditionally > initializes logging with the hard-coded configuration and then

Re: Adding support for importing models through the app registry while it is loading

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 >> Is it possible >> to

Re: Adding support for importing models through the app registry while it is loading

Hi Aymeric, On 09/04/2016 01:03 PM, Aymeric Augustin wrote: > Hello, > > Since Django 1.7, `get_user_model()` cannot be called at import time. > Django contains a lot of methods that start with `UserModel = > get_user_model()` while it would be more natural to declare it as a > global variable

Re: GitHub PR status within Trac

Hi Tobias, On 07/22/2016 04:53 PM, Tobias McNulty wrote: > I spent some time during the DjangoCon sprint today looking into > dashboard.djangoproject.com and how > it calculates metrics. I was hoping to add some new metrics that mash up > data from GitHub and

Re: change commit message format to present tense?

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 reasonable to me. Carl -- You received

Re: change commit message format to present tense?

On 06/24/2016 12:15 PM, Jon Dufresne wrote: > On Fri, Jun 24, 2016 at 10:48 AM, Carl Meyer <c...@oddbird.net > <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

Re: change commit message format to present tense?

sure because my memory sucks, but odds are that > I started > the current standard of using past-tense. > > FWIW I no longer care even at all, I think as long as commit > messages are > clear we I don't care what tense they are. Following the >

Re: change commit message format to present tense?

On 06/24/2016 10:55 AM, Tim Graham wrote: > A few contributors indicated in #django-dev that it could be beneficial > to change our commit message format to match git's guidelines of present > tense (instead of our current past tense convention) as it would be one > less thing to remember when

Re: decorator_from_middleware changes

Hi Shai, Apologies, I didn't fully process your suggestion or the reason for the flag the first time. I think it would work, though I'd be tempted to set the flag to False on the transition middleware by default, to provide perfect back-compat for existing uses of decorator_from_middleware until

Re: decorator_from_middleware changes

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 c

Re: decorator_from_middleware changes

Hi Tobias, On 06/21/2016 06:22 AM, Tobias McNulty wrote: > On Mon, Jun 20, 2016 at 10:51 AM, Carl Meyer <c...@oddbird.net > <mailto:c...@oddbird.net>> wrote >> Possible disadvantages of this approach: > > > >> 3. The new behavior may surprise some p

Re: decorator_from_middleware changes

Hi Shai, On 06/20/2016 11:07 PM, Shai Berger wrote: > Well, we can change decorator_from_middleware to introspect the middleware > itself and decide accordingly: > > -- if it does not have process_request or process_response as callable > attributes, and it is callable itself, it is a

Re: decorator_from_middleware changes

On 06/20/2016 06:57 PM, Tim Graham wrote: > I may have seen this idea in IRC but instead of a new > middleware_decorator function did you consider varying > decorator_from_middleware's behavior based on "if settings.MIDDLEWARE is > None" similar to what BaseHandler does? We could add a check in >

decorator_from_middleware changes

Hi all, In porting decorator_from_middleware to support DEP 5 middleware, I ran into one stumbling block: TemplateResponse. Normally with old-style middleware, process_response runs after TemplateResponses have been rendered. But a view decorator runs immediately wrapping the view, when

feedback needed re exception handling in DEP 5 middleware

Hi all, Any of you with a particular interest in middleware, DEP 5, and handling of view exceptions, please take a look at the discussion on https://github.com/django/django/pull/6618 and if you have strong feelings about what route we should take, please weigh in either there or here. (The code

Re: Clearing prefetch related on add(), change(), remove()

On 06/07/2016 06:11 AM, Marc Tamlyn wrote: > I may be "too close" to knowing the implementation of this feature to be > able to comment on whether the behaviour is surprising to most people, > but it doesn't surprise me. It's certainly analogous to that when you do > `MyModel.objects.create()` it

Re: Conditions DEP

Hi Connor, On 06/05/2016 07:52 PM, Connor Boyle wrote: > I'd like to make a proposal for the addition of a major new feature to > Django. Back in late March of this year, I wrote an original Google > Summer of Code proposal > that >

Re: Should we require pytz for timezone support in Django?

> On Jun 5, 2016, at 6:09 PM, Josh Smeaton wrote: > > It sounds like we have consensus that we can make pytz a required dependency > when USE_TZ = True, and clear up the associated documentation. > > I think now we should try and find (rough) consensus on whether or

Re: Should we require pytz for timezone support in Django?

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 > ImproperlyConfigured (or

Re: Should we require pytz for timezone support in Django?

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 ImproperlyConfigured (or maybe having a site check raise an error?) if USE_TZ=True and

Re: Should we require pytz for timezone support in Django?

On 06/03/2016 03:55 PM, Philip James wrote: > Is there consensus on making pytz required? (I, personally, am in favor, > since I too can't remember the last project I did that didn't need it.) > > If it's required, should it be vendored? -1 on vendoring pytz. I think it's fine to just make it a

Re: Template-based widget rendering

On 05/17/2016 01:33 AM, Claude Paroz wrote: > I can imagine that django.forms would then be responsible to tell the > template engine to add the template source. Maybe this would need a new > API in the template code? Yes, it's certainly possible that we could address this with a new API in the

Re: Template-based widget rendering

Hi Simon, On 05/17/2016 07:28 AM, charettes wrote: > Did we consider defining a template loader that knows where to load the > widget > templates from instead of requiring 'django.forms' in INSTALLED_APPS with > 'APP_DIRS': True in TEMPLATES? > > Something along theese lines make more sense to

Re: Template-based widget rendering

On 05/16/2016 01:48 AM, Claude Paroz wrote: > Le samedi 14 mai 2016 16:03:57 UTC+2, Tim Graham a écrit : > > (...) > > I guess it will affect every project that uses the admin. I can't > think of a simple solution other than adding a system check upgrade > warning to detect this

Re: re-thinking middleware

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

Re: Template-based widget rendering

Hi Tim, On 05/14/2016 08:03 AM, Tim Graham wrote: > While testing this, I ran into a shortcoming with the fallback strategy > for backwards-compatibility. > > If you have a DjangoTemplates backend configured with 'APP_DIRS': True > (as in the tutorial) and you try to visit

Re: Template-based widget rendering

On 05/15/2016 11:01 PM, Curtis Maloney wrote: > So this seems to leave us only part way to removing rendering decisions > from the form code -- your widgets can be templated, but your form code > still needs to decide which widgets... Yep, one step at a time. With django-floppyforms templated

Re: Template-based widget rendering

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 "

Re: Template-based widget rendering

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 because you are

Re: Template-based widget rendering

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 startpr

Re: Template-based widget rendering

On 05/11/2016 11:30 AM, Tim Graham wrote: > I'm not sure about how common the need for custom widget templates are. > Speaking for djangoproject.com and a few other small projects I > maintain, I don't think these projects would make use of them but maybe > if the feature is there, I might realize

Re: re-thinking middleware

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 (to

Re: GitHub Issues for DEP repository?

Hi Kevin, On 05/10/2016 11:24 PM, Kevin Christopher Henry wrote: > With all the talk of DEPs flying around I thought I'd finally take a > look at one in detail. > > I wanted to make a suggestion about it and realized that there wasn't > really a good place to do so. The issue was too minor for a

Re: Process DEP for "official" non-core projects

On 05/10/2016 08:58 PM, Andrew Godwin wrote: > Following my decision to move Channels away from a 1.10 merge and > towards an existence as a separate app for a bit while it matures, I > would like to write up a process DEP for how we achieve this - > specifically, what it takes to be adopted as a

Re: re-thinking middleware

led 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 removed, but I also think the >

Re: Template-based widget rendering

Hi Tim, On 05/10/2016 07:10 AM, Tim Graham wrote: > About the fallback engines, the main use case I have in mind (as Claude > alluded to) is if you want to use django.forms "standalone" without the > rest of Django. In that case, it seems like it would be nice not to > require someone to

Re: Withdrawing Channels from 1.10

On 05/10/2016 10:39 AM, Andrew Godwin wrote: > - Being almost purely an addition to Django, even though it technically > inserts a new layer, makes it more well-suited to live externally than > many other features. While the external package will have to > monkey-patch a few things, it'll be

Re: DEPs (was: Making Django more PaaS-friendly)

Hi Anssi, Thanks for the clarification, that all makes sense. A few comments below: On 05/10/2016 12:00 AM, Anssi Kääriäinen wrote: > It's not so much the DEPs that have been written (though the channels > DEP is going to be post-design instead of supporting the design). It's > more about those

Re: Making Django more PaaS-friendly

Hi Anssi, On 05/09/2016 06:53 AM, Anssi Kääriäinen wrote: > I'm very much afraid we are in a situation where we have a documented > DEP process which isn't actually enforced, nor does it document what > we actually do. > > Python's PEP process is useful as the document evolves while the > design

Re: Template-based widget rendering

Hi Tim, On 05/09/2016 08:03 AM, Tim Graham wrote: > I've been working on testing and writing documentation for Preston's PR: > https://github.com/django/django/pull/6498 > > About backwards compatibility, the current implementation which seems to > be based on Carl's proposal requires either a)

Re: re-thinking middleware

le MIDDLEWARE > response handling. I guess a subclass of anything that uses > @override_settings(MIDDLEWARE=...) that uses > @override_settings(MIDDLEWARE_CLASSES=...) might work. Just putting > it out there in case anyone has a better idea. > > On Monday, Janu

Re: Thoughts on ASGI or Why I don't see myself ever wanting to use ASGI

On 05/06/2016 01:56 PM, Donald Stufft wrote: > User level code would not be handling WebSockets asynchronously, that > would be left up to the web server (which would call the user level code > using deferToThread each time a websocket frame comes in). Basically > similar to what’s happening now,

Re: Thoughts on ASGI or Why I don't see myself ever wanting to use ASGI

On 05/06/2016 11:09 AM, Aymeric Augustin wrote: > I think it's important to keep a straightforward WSGI backend in case we crack > this problem and build an async story that depends on asyncio after dropping > support for Python 2. > > I don't think merging channels as it currently stands hinders

Re: My Take on Django Channels

Hi Andrew, Replying off-list just to say that I totally understand your frustration here, and I wish I weren't contributing to it :( I hope I'm managing to speak my mind without being an asshole about it, and I hope you'd tell me if I failed. Really glad Jacob stepped up on the DEP; I was

Re: My Take on Django Channels

On 05/05/2016 04:37 PM, Andrew Godwin wrote: > To be honest, I had entirely forgotten the DEP process existed until > this thread started up; I'm not sure what to blame this on, but as a > member of the tech board I haven't got an email about approving a DEP > since last October, so it's been a

Re: My Take on Django Channels

Hi Andrew, On 05/05/2016 02:19 PM, Andrew Godwin wrote: > I will put my hand up and say that this sidestepped the DEP process, and > that's entirely my fault. It was not my intention; I've been working on > this for over two years, and only last year did I go public with my > semi-final design

Re: Should Template.render() return a safe string?

On 04/28/2016 11:46 AM, Aymeric Augustin wrote: >> On 28 Apr 2016, at 19:30, Aymeric Augustin >> wrote: >> >> It seems reasonable to assume that the result of rendering with >> autoescaping enabled is HTML-safe — that’s the reason why >> autoescaping exists. >

Re: Should Template.render() return a safe string?

Hi Aymeric, On 04/28/2016 11:02 AM, Aymeric Augustin wrote: > I just stumbled upon an interesting difference between Jinja2 and the > Django template language. > > |Template.render()| returns a safe string in Django. It's likely an > accident of the implementation more than a design choice. It

Re: Making Django more PaaS-friendly

Hi Marcin, On 04/26/2016 08:12 PM, Marcin Nowak wrote: > But I would like to say my thoughts about "settings" itself. > They were good (simple) before incuding nested dictionaries. > After switching to dicts the settings handling went harder way. I agree that settings grouped into dicts are

Re: Making Django more PaaS-friendly

Hi James et al, In general, I like the idea of adding a helper to Django to read settings from the environment. I think this helper should be kept as simple and non-magical as is reasonable. Thus: - I'm in favor of a flexible helper function that can be manually used in a settings file to read

Re: Django template 'if ... is' feature design

Hi Steve, On 04/07/2016 05:09 PM, Stephen Kelly wrote: > Am I right to think that using 'is' with numbers is expected to work like > this in the DTL? : The situation with integers is roughly the same as with strings, except that I believe CPython interns _all_ small integers, not just those

Re: Django template 'if ... is' feature design

Hi Steve, On 04/07/2016 04:36 PM, Stephen Kelly wrote: > Anyway, that makes at least two people telling me that > > In [81]: "True" is "True" > Out[81]: True > > and > > In: t = e.from_string( > "{% if \"True\" is \"True\" %}yes{% else %}no{% endif %}") > In:

Re: must we include the source files for all minified JavaScript?

It seems like a reasonable request to me. It's just generally useful to have the original source matching the minified code available, e.g. for debugging an issue with that code. In theory you can go find the corresponding non-minified code yourself, but it's not always easy to find exactly the

Re: [Review Request] Added support for database delegated fields (like AutoField)

Hi Anssi, On 02/11/2016 02:51 AM, Anssi Kääriäinen wrote: > I created a proof-of-concept pull request for improved deferred fields > loading. See https://github.com/django/django/pull/6118. In short, it is > faster and cleaner (no more dynamically created subclasses for deferred > loading!) than

Re: add prefered/default protocol in the sites framework #26079

On 01/25/2016 09:01 AM, Tim Graham wrote: > Oh, looks like django-hosts also has this problem. It looks like in some > cases the URLs will be correct (due to the PARENT_HOST setting, I think, > which is 'djangoproject.dev:8000' in the djangoproject.com dev > settings), but if you are browsing a

Re: re-thinking middleware

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 Django itself)"

Re: re-thinking middleware

On 01/10/2016 04:54 PM, Raphaël Barrois wrote: > I've got only one minor suggestion to the "backwards compatibility" > section of the DEP. > >> It currently states that "If the ``MIDDLEWARE`` setting is provided >> [...], the old ``MIDDLEWARE_CLASSES`` setting will be ignored. > > I suggest

Re: re-thinking middleware

On 01/11/2016 04:52 PM, Shai Berger wrote: > On Monday 11 January 2016 01:54:58 Raphaël Barrois wrote: >> I've got only one minor suggestion to the "backwards compatibility" >> section of the DEP. >> >>> It currently states that "If the ``MIDDLEWARE`` setting is provided >>> [...], the old

Re: re-thinking middleware

Hi Mat, On 01/12/2016 04:23 PM, Mat Clayton wrote: > +1 as well, this is really great work, on both patches! > > Modifying the middleware stack mid request would be very useful for us. > > We currently run 3 copies of the same code, with essentially different > urls.py and middlewares loaded,

Re: re-thinking middleware

On 01/10/2016 04:54 PM, Raphaël Barrois wrote: > I've got only one minor suggestion to the "backwards compatibility" > section of the DEP. > >> It currently states that "If the ``MIDDLEWARE`` setting is provided >> [...], the old ``MIDDLEWARE_CLASSES`` setting will be ignored. > > I suggest

Re: slow migrations

On 01/09/2016 09:29 AM, Shai Berger wrote: > There are two kinds of data migrations, generally speaking. > > One is the kind that is needed to facilitate some schema migrations. Changing > the type of some field, for example, usually involves creating the new field > (schema migration),

Re: PostGres 9.5 Upsert

On 01/08/2016 05:13 PM, bliyan...@rentlytics.com wrote: > Postgres 9.5 has added the functionality for UPSERT aka update or > insert. Any interest in aligning UPSERT on the db layer with the > get_or_create or update_or_create functionality in django? Sounds like > my company would be interested

Re: re-thinking middleware

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

Re: re-thinking middleware

Hi Ryan, On 01/08/2016 11:48 AM, Ryan Hiebert wrote: > I hadn't considered the option of just returning ``get_response``. > I really like it, because it avoids both raising an exception and > importing a common symbol. > > While class-based middleware factories couldn't just do the same thing >

Re: re-thinking middleware

Thanks everyone for the reviews. I've pushed a new commit addressing most of the issues raised: https://github.com/django/deps/commit/62b0ee351727cb0e7ef41ba6dd2f3f7280a219de More comments and replies (to various people in the thread) below: On 01/08/2016 09:01 AM, Florian Apolloner wrote: > PR1

Re: re-thinking middleware

Hi Curtis, On 01/08/2016 04:31 AM, Curtis Maloney wrote: > In general, I love it. Great! > It's MUCH simpler for people to write and comprehend... requires no > classes [but IMHO the callable class is "cleaner"] and allows for > configurable middlewares easily... > > I do wonder, though... how

re-thinking middleware

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-Modified: 2016-01-07

Re: Vote on Jira as bugtracker

Hi Andrey, On 01/07/2016 04:23 PM, Andrey Antukh wrote: > On Fri, Jan 8, 2016 at 12:42 AM, Florian Apolloner > The DRFv2 (as DRFv3) as far as I know is licensed using MIT permissive > license that does not impide take the source and re-license it under > other license. > > taiga.io

Re: slow migrations

On 01/07/2016 03:03 PM, Aymeric Augustin wrote: > As far as I understand, the CPU cost comes from generating a full set of > model classes for each step of the migration history. That’s consistent > with the profile sent by Florian. > > I usually end up throwing away the migration history and

Re: Deprecations vs. backwards-incompatible changes for tightening behavior that hides probable developer error

Hi Tim, On 12/21/2015 08:09 AM, Tim Graham wrote: > I'd like to ask for opinions about whether or not deprecations are more > useful than making small backwards incompatible changes when they move > Django in a direction toward unhiding probable developer error. > > An example from a past

Re: A community Poll

Hi Curtis, On 12/21/2015 06:52 AM, Curtis wrote: > Whilst I'm awake... a pull request I made to a 3rd party project > included replacing explicit model imports for relation fields with lazy > binding -- ForeignKey('contenttypes.ContentType') in this case. > > The author pointed out this didn't

Re: structural & functional review of django documentation

Hi Doug, On 12/18/2015 04:35 PM, Doug Epling wrote: > I filed bug report > > #25952 > > but apparently it was in the wrong place. In case it wasn't clear, it wasn't in the wrong place because it was documentation-related, it was in the wrong

Re: Channels integration plan, first draft

On 12/17/2015 11:50 AM, Andrew Godwin wrote: > - I thought SCRIPT_NAME was basically unused by anyone these days, but > hey, happy to be proved wrong. Do we have any usage numbers on it to > know if we'd need it for a new standalone server to implement? It's > really not hard to add it into the

  1   2   3   4   5   6   7   >