We din't currently do join trimming from the beginning of the query's
tables, only from the end of the tables.
Fixing this issue only doesn't seem worth it, as the current join trimmig
code can't be adapted to handle trimming from the beginning of the query's
tables. But we might be able to trim a
Am Donnerstag, 19. November 2015 15:12:16 UTC+1 schrieb Collin Anderson:
>
> What's a sitecustomize.py? :)
>
This module is automatically imported during initialization if the
interpreter.
We use it to:
- sort sys.path.
- monkey patching. During the Update from Django 1.6 to 1.7 we added a
So it seems a sitecustomize.py is something internal to your company, and
you are proposing to document this for Django in general. So that shouldn't
be in there, right?
Also, although circular dependencies are probably a sign of a less than
perfect design, reality isn't perfect and they sometimes
In
https://github.com/django/django/blob/master/django/contrib/admin/static/admin/css/forms.css#L31,
after
label {
font-weight: normal;
color:#666;
font-size:13px;
}
you would add
label::first-letter {
text-transform: capitalize;
}
(see https://css-tricks.com/almanac/selectors/f/fi
Looks easy enough. I was going to write, "Seems to me that there's more
complexity in a deprecation path that requires a temporary opt-in setting
rather than simply making the backwards incompatible change. Unless I
missed something, adding CSS like that shouldn't cause problems for any
apps ma
Hi all,
sorry if this is a stupid question, but after having read
https://code.djangoproject.com/ticket/5763 and the discussions linked from
it, why should __ne not be implemented?
Without __ne, I'm experiencing the same problems that asmoore82 described
at https://code.djangoproject.com/ticke
On Friday, November 20, 2015 at 8:37:02 PM UTC+1, Carsten Fuchs wrote:
>
> sorry if this is a stupid question, but after having read
> https://code.djangoproject.com/ticket/5763 and the discussions linked
> from it, why should __ne not be implemented?
>
>
Because Django ORM __ne SQLAlchemy.
B
With all due respect, looking through the ticket and reading responses
shows me that the 'pro' side has good use cases for __ne, and the 'con'
side basically says "use exclude" or "a core committer close the ticket,
stop opening it" with no good reasoning or rationale behind it.
-A
On Fri, Nov 20
8 years later, I still think we should figure out how to make exclude() do
what people expect it to do, rather than implement another lookup type that
overlaps with it.
On Fri, Nov 20, 2015 at 7:27 PM, Aaron C. de Bruyn
wrote:
> With all due respect, looking through the ticket and reading respon
Without the part of sitecustomize agree with the other parts.
+ there should be distinction between projects app and install apps
Reagards
On Thursday, November 19, 2015 at 3:54:40 PM UTC+6, guettli wrote:
>
> I created a ticket to find a better definition of "Project" vs "App"
>
> https://code
Hello Thomas,
Thanks for bringing this up. There’s definitely some room for improving the
documentation — I know because I wrote it.
In terms of organization, I’d rather discuss how each topic (settings, models,
etc.) relates to projects and apps than talk first about projects, then about
apps
11 matches
Mail list logo
