On Fri, Jan 8, 2016 at 7:16 AM, Joe Tennies wrote:
> I'm not a lawyer, but I care about licensing.
> The MIT License would allow you to relicense it, but you must keep the
> original copyrights in tact. (From license: Redistribution and use in
> source and binary
Yes, the more relationships your models have the more time expensive migrations
become. Adding/Altering/Removing a field (ForeignKey or not) always requires
all related models to be recreated. See
for the reasoning
In general, I love it.
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 the anti-import-strings factions will
react... I'm sure it can, at
Thank you Florian and Carl for continuing the work on that topic. I like both
the DEP as well as the example.
I would, however, include the exception handling in the examples provided in
section "Specification" as that is an integral part of middlewares, too.
Nitpicking, I would also name the
On Friday, January 8, 2016 at 12:51:25 PM UTC+1, 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.
Yes, my thought too.
On January 8, 2016 10:31:49 PM GMT+11:00, Curtis Maloney <
I currently see no easy way to give *get_response* access to the list of
middlewares like done in
and following lines. The reason is that providing *get_response* at
setup/init time means it has
I've gone ahead and pushed a new commit to match the spec (not tested yet,
but hey :D).
On Friday, January 8, 2016 at 3:29:01 PM UTC+1, Florian Apolloner wrote:
> I currently see no easy way to give *get_response* access to the list of
> middlewares like done in
Haha, I was so focused on my previous approach that I forgot, that I could
just chain them during setup (thanks knbk). So the question remaining now:
Do we want to be able to change middlewares per request or not :D I guess
I'll submit a second PR with the non-request usage.
On Friday, January
PR1 (allows changing the middlewares during the middleware run):
PR2 (static middleware chain, seems simpler and probably the way to go):
On Friday, January 8, 2016 at 4:55:08 PM UTC+1, Florian Apolloner
The first argument to Constraint.construct() is a URL helper object which
allows you to set the scheme, host, path, querystring and fragment
separately. So reversing a domain constraint is as simple as this:
def construct(self, url_object, *args,
On 01/08/2016 04:31 AM, Curtis Maloney wrote:
> In general, I love it.
> 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
I've just pushed a simple middleware wrapper that lets you install
WhiteNoise by adding:
MIDDLEWARE_CLASSES = (
No messing with wsgi.py!
The only (and minor) concern I have is about allowing function-based middleware
factories to return None.
In the spirit of “there should be only one way to do it”, I would require
raising MiddlewareNotUsed explicitly to disable a middleware. A middleware
factory that returns
> On Jan 8, 2016, at 11:35 AM, Aymeric Augustin
> Great work.
> The only (and minor) concern I have is about allowing function-based
> middleware factories to return None.
> In the spirit of “there should be only one way to do it”,
> On Jan 8, 2016, at 11:57 AM, Ryan Hiebert wrote:
>> On Jan 8, 2016, at 11:35 AM, Aymeric Augustin
>> In the spirit of “there should be only one way to do it”, I would require
>> raising MiddlewareNotUsed explicitly
No problem. Don't forget the documentation too. That was called out in the
original license. For instance, I'd put it right on the README.md on the
correct project(s) on GitHub under the license section.
OTOH, I'm now interested in checking it out, so thanks.
On Fri, Jan 8, 2016 at 3:42 AM,
Thanks everyone for the reviews. I've pushed a new commit addressing
most of the issues raised:
More comments and replies (to various people in the thread) below:
On 01/08/2016 09:01 AM, Florian Apolloner wrote:
> On Jan 8, 2016, at 12:38 PM, Carl Meyer wrote:
> Yes, you and Ryan are absolutely right, allowing `None` was a mistake
> and I've removed it from the spec. For function-based middleware,
> there's also the option to simply return the ``get_response`` callable
> you were
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
> On Jan 8, 2016, at 12:53 PM, Carl Meyer wrote:
> On 01/08/2016 11:48 AM, Ryan Hiebert wrote:
>> While class-based middleware factories couldn't just do the same thing
>> in the __init__ method, they could do that in a __new__ method instead,
>> and then we could make
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 :-) See e.g.
During the refactor of lazy operations abstract models stopped resolving
their related field model reference by themselves in order to prevent
pending lookup pollution. This was necessary in order to warn the users
unresolved relationships in a reliable way.
This change introduced
That's a nice one, Simon.
tl;dr: I favor 2; am OK with 1 but against 3.
I was favoring 1) as well. But then thought that app relative relationships
actually make sense and the current behavior adds a nice new API feature. This
way a 3rd party app can provide an abstract model and require you
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 in doing the work if the PR will get the
On Saturday, January 9, 2016 at 1:13:26 AM UTC+1, bliy...@rentlytics.com
> Hey Guys,
> 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
On Wednesday, January 6, 2016 at 10:09:08 AM UTC-3, Victor Sosa wrote:
> I felt like lost using trac; it is kind of messy. I just don't feel
> with it.
> I see so many open source project using Jira that is just natural. Search
> is easy, categorize is easy, look
On Thu, Jan 7, 2016, at 19:12, Carl Meyer wrote:
> 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'm trying to write a PR for adding Postgres9.4's "FILTER" syntax for
aggregates, but I've hit a bug I can't figure how to fix [and nobody's
awake on IRC :)]
Basically, for the query:
qset = FilterAggParentModel.objects.annotate(
On 09/01/16 13:08, Hugo Osvaldo Barrera wrote:
Not an actual django developer (I'm a user lurking here really), but I'd
still like to chime in:
Doesn't make your input any less valid... in fact, perhaps makes it more
* Jira is too complex. Devs may end up understanding it,
Mail list logo