Re: Django ORM query syntax enhancement

[Josh Smeaton]

Most expressions already support strings, and most that support strings 
expect them to be field_paths that can be wrapped in F() expressions. So 
you have two options really, without built in support from other 
expressions.

1. P.field.other.some_field() returns an F()
2. P.field.other.some_field() returns a str that will be internally wrapped 
in an F().

The callable part of your syntax is just something I'm suggesting as an 
option. The requirement is that a string or F() be returned in some way 
though. I'm also using "P." as a stand-in as you used previously.

Supporting callables is an interesting idea, and I don't think that'll 
cause issues with existing expressions. The callable must return an 
expression though. If you wanted to write a patch to support callables, I'd 
be onboard to review ASAP.

Cheers

On Friday, 21 August 2015 00:16:45 UTC+10, Alexey Zankevich wrote:
>
> What about the idea to add interface to specify paths with special class 
> or callable?
>
>
> On Wednesday, August 19, 2015 at 10:49:07 AM UTC+3, Josh Smeaton wrote:
>>
>> If I finish the patch in time (I think I have about a month left), then 
>> it'll be included in 1.9. Review and comments on the PR will go a long way 
>> to helping me tidy it up sooner rather than later, so please feel free to 
>> review.
>>
>> Regards,
>>
>> On Wednesday, 19 August 2015 04:55:21 UTC+10, Alexey Zankevich wrote:
>>>
>>> Once Josh completes this patch 
>>> https://github.com/django/django/pull/5090
>>> (.filter method accepting class-based lookups and transforms), it will be
>>> almost everything required by third-party apps. Is it going to be a part 
>>> of
>>> Django 1.9, by the way?
>>>
>>> Additionally, for pure flexibility, next method and classes need to 
>>> accept
>>> either a callable or an object supporting special path interface (for 
>>> example,
>>> just a single method get_path() returning string path).
>>> They listed below:
>>>
>>> 1. The current methods.select_related, .prefetch_related, .order_by
>>> 2. Annotation classes Min, Max, Count, Sum
>>> 3. Future transforms and lookups classes
>>>
>>>
>>> Examples:
>>>
>>> >>> path = lambda x: 'user__last_login_date'
>>> >>> GameSession.objects.all().order_by(path)
>>>
>>> or
>>>
>>> >>> class LoginDatePath(object):
>>> ... def get_path(self):
>>> ... return 'user__last_login_date'
>>> >>> path = LoginDatePath()
>>> >>> GameSession.objects.all().order_by(path)
>>>
>>> Path generation is a critical part of external query syntax as it used in
>>> almost all aspects of the ORM, meanwhile each related method accepts 
>>> either a
>>> string or (in some cases) a specific kind of class - OrderBy for order_by
>>> method, Prefetch for prefetch_related and etc.
>>>
>>>
>>> On Tuesday, August 18, 2015 at 7:54:48 PM UTC+3, Michael Manfre wrote:
>>>
>>> +1 for making it doable for 3rd party apps.
>>>
>>> Regards,
>>> Michael Manfre
>>>
>>> On Tue, Aug 18, 2015 at 12:49 PM, Anssi Kääriäinen  
>>> wrote:
>>>
>>> I'm still thinking we shouldn't integrate any new query syntax into
>>> 1.9. Instead lets make it easy to create 3rd party apps that offer
>>> different querying syntax, and then lets see which solution (if any)
>>> gets popular enough to be integrated into Django.
>>>
>>>  - Anssi
>>>
>>>
>>>
>>> On Tue, Aug 18, 2015 at 5:54 PM, Collin Anderson  
>>> wrote:
>>> > Just a quick thought: I could imagine some newbies could get confused 
>>> by the
>>> > python-like syntax and try to do:
>>> >
>>> > Equal(P.user.get_full_name(), 'Bob Someone')
>>> >
>>> > I don't think it's not a huge deal, but worth noting.
>>> >
>>> > On Tuesday, August 18, 2015 at 8:00:17 AM UTC-4, Alexey Zankevich 
>>> wrote:
>>> >>
>>> >> Hi all,
>>> >>
>>> >> Thanks for detailed response. I thought over the described 
>>> expressions/
>>> >> transforms patches and here are my thoughts about the best way to
>>> >> implement simplified lookups.
>>> >>
>>> >> Firstly, I want to describe which properties of the new syntax seem 
>>> to be
>>> >> important:
>>> >>
>>> >> 1. Using Python operators to do basic lookups as it's a natural way in
>>> >> Python
>>> >> for that.
>>> >>
>>> >> 2. Syntax should be minimalistic for basic lookups, the use of that
>>> >> approach
>>> >> will be more noticeable on multiple filter conditions. In other words,
>>> >> next
>>> >> syntax is better:
>>> >>
>>> >> >>> GameSession.objects.filter(Q.user.profile.last_login.date() ==
>>> >> >>> datetime.now().date)
>>> >>
>>> >> than this one
>>> >>
>>> >> >>> GameSession.objects.filter(E(F.user.profile.last_login).date() ==
>>> >> >>> datetime.now().date)
>>> >>
>>> >> as it requires additional calls, which makes expressions less 
>>> readable.
>>> >>
>>> >> 3. I definitely like the idea of having explicit classes for lookups 
>>> and
>>> >> transforms and think it's worth to bundle dotted query syntax with the
>>> >> patch.
>>> >> Explicit classes will separate functionality and simplify functions
>>> >> signature
>>> >> checks.
>>

Re: revisiting the "easy pickings" flag in Trac

[Michael Manfre]

I never liked the "easy pickings" flag either. Your proposed change would
be a good way to identify the technical ability required to make the
changes to Django. Should we have a separate drop down with options to
identify the non-technical (bikeshedding) difficulty of the ticket? There
are certain tickets that are created that are not immediately closed as
won't fix that are not a technically challenging problem, but are a huge
uphill battle to get merged.



On Thu, Aug 20, 2015 at 7:35 PM, Tim Graham  wrote:

> In my experience the "easy pickings" flag is ill-defined and insufficient
> for describing the difficulty of a ticket. I don't want to get stuck in
> categorizing tickets just for the sake of it, but I think a drop down with
> options like the following could be useful in helping contributors find
> suitable tickets:
>
> Trivial - Typos, wording tweaks, etc.
> Easy - Simple features and bugs suitable for a first-time contributor.
> Moderate - Requires a basic knowledge of Django internals.
> Hard - Requires a thorough understanding of Django internals.
> Very Hard - Refactorings or features that are difficult for experienced
> core developers.
>
> Do you think this would be useful? If so, are the selections above
> suitable?
>
> --
> 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-developers+unsubscr...@googlegroups.com.
> To post to this group, send email to django-developers@googlegroups.com.
> Visit this group at http://groups.google.com/group/django-developers.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/django-developers/5544efa8-75a0-40ba-9210-bea027d32a72%40googlegroups.com
> 
> .
> For more options, visit https://groups.google.com/d/optout.
>



-- 
GPG Fingerprint: 74DE D158 BAD0 EDF8
keybase.io/manfre

-- 
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-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CAGdCwBs97cJzHnJ9n3dyvo0Yw5nRHi-xTQYm6jA6SEbNeK6b8Q%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

revisiting the "easy pickings" flag in Trac

[Tim Graham]

In my experience the "easy pickings" flag is ill-defined and insufficient 
for describing the difficulty of a ticket. I don't want to get stuck in 
categorizing tickets just for the sake of it, but I think a drop down with 
options like the following could be useful in helping contributors find 
suitable tickets:

Trivial - Typos, wording tweaks, etc.
Easy - Simple features and bugs suitable for a first-time contributor. 
Moderate - Requires a basic knowledge of Django internals.
Hard - Requires a thorough understanding of Django internals.
Very Hard - Refactorings or features that are difficult for experienced 
core developers.

Do you think this would be useful? If so, are the selections above suitable?

-- 
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-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/5544efa8-75a0-40ba-9210-bea027d32a72%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: A new setting for custom gettext domains?

[Claude Paroz]

In my opinion, the question to ask when wondering if a configuration should 
be a setting or not is: is this setting supposed to be changed for 
different installations. In this case, I would answer no. So I think this 
is more an application configuration thing which could be appropriate in an 
AppConfig.
For translation paths specified in LOCALE_PATHS (not related to an app), we 
could extend the LOCALE_PATHS setting format to accept a different 
structure, for example a dict {'path': ..., 'domain': ...}.

My 2 cents,

Claude

-- 
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-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/d2891fba-7bfe-4f97-88a5-a6dc04c88fdf%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Django Admin New Look

[Tim Graham]

Thanks everyone for feedback. I think it's a good idea to send this to the 
technical board to reach a consensus. Here is the summary as I see it:

Benefits of jQuery 2:
* Smaller file size (36KB or 11KB for minified version)
* "Faster" -- not sure this has any practical benefit currently, but might 
be helpful if rewriting the filter widgets which are notoriously slow [1])

Cons:
* No built-in IE6-8 support for admin JavaScript features

Pros of doing it now:
* Discourages use of old, unsupported browsers.
* It's bunched with other admin changes like the redesign and dropping 
fallback images for IE6/7 support (for no transparent png support by these 
browsers).
* "1.9 is the release following an LTS -- the perfect time for changes such 
as  JQuery 2 and dropping support for old browsers. If developers need to 
support  the legacy IE8, they can use Django 1.8." -Shai
* Possible to restore compatibility by overriding the admin's jQuery with 
an older version of jQuery with an app that looks like this:

admin-jquery-1/static/admin/js/vendor/
jquery.js
jquery.min.js

jQuery 1.X and 2.X have API compatibility so this technique should work for 
the foreseeable future.

Cons:
* IE8 won't be EOL until ~1 month after the release of 1.9.
* Workaround technique could be annoying for affected users.

[1] https://code.djangoproject.com/ticket/15220

On Thursday, August 20, 2015 at 12:00:36 PM UTC-4, Collin Anderson wrote:
>
> To be clear: jQuery 1.x and 2.x are the exact same except for IE < 9 
> compatibility. jQuery v1.11.3 and v2.1.4, released simultaneously, _are_ 
> the latest version of jQuery. It's not like "1.11.x" is an "old" release 
> series. 1.x and 2.x have the exact same features and API and are 100% 
> compatible with each other. The _only_ difference is that v2.1.4 is 
> slightly smaller because it doesn't have shims to support IE6-8 (and a few 
> other old browsers).
>
> The only advantage to switching to 2.x is a slightly smaller file size, 
> meaning a slightly quicker load time.
>
> In a few months, they'll switch to 3.x, breaking some backwards 
> compatibility, and instead of 2.x and 1.x, they'll have "jQuery" and 
> "jQuery Compat" with the same version numbers. That should make this more 
> clear.
>
> http://blog.jquery.com/2015/07/13/jquery-3-0-and-jquery-compat-3-0-alpha-versions-released/
>
> I personally suggest staying with jQuery Compat (1.x) through this next 
> LTS cycle. The file size is really not that much, and it shouldn't be any 
> extra work to maintain.
> https://mathiasbynens.be/demo/jquery-size
>

-- 
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-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/32a77996-4193-4730-bf22-6613df44b56b%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Django Admin New Look

[Collin Anderson]

To be clear: jQuery 1.x and 2.x are the exact same except for IE < 9 
compatibility. jQuery v1.11.3 and v2.1.4, released simultaneously, _are_ 
the latest version of jQuery. It's not like "1.11.x" is an "old" release 
series. 1.x and 2.x have the exact same features and API and are 100% 
compatible with each other. The _only_ difference is that v2.1.4 is 
slightly smaller because it doesn't have shims to support IE6-8 (and a few 
other old browsers).

The only advantage to switching to 2.x is a slightly smaller file size, 
meaning a slightly quicker load time.

In a few months, they'll switch to 3.x, breaking some backwards 
compatibility, and instead of 2.x and 1.x, they'll have "jQuery" and 
"jQuery Compat" with the same version numbers. That should make this more 
clear.
http://blog.jquery.com/2015/07/13/jquery-3-0-and-jquery-compat-3-0-alpha-versions-released/

I personally suggest staying with jQuery Compat (1.x) through this next LTS 
cycle. The file size is really not that much, and it shouldn't be any extra 
work to maintain.
https://mathiasbynens.be/demo/jquery-size

-- 
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-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/84b76673-7d30-4758-9537-9144c045bb2a%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: The hypothetical models.MultiField: is there a rationale to avoid it ? Or could it make it into future releases ?

[Podrigal, Aron]

Have a look at [1] it is a composite field implementation.

[1]
https://groups.google.com/forum/m/#!msg/django-developers/MZUcOE6-7GY/sZkBaHvC8wgJ
[2]
https://github.com/django/deps/blob/master/draft/0191-composite-fields.rst
[3]
https://github.com/django/deps/blob/master/draft/0192-standalone-composite-fields.rst
On Aug 20, 2015 10:31 AM,  wrote:

>
>
> Le mardi 18 août 2015 01:36:28 UTC+2, Tim Graham a écrit :
>>
>> I think the general idea is captured in ticket #5929 -- Allow Fields to
>> use multiple db columns (complex datatypes). Is that the gist of your
>> proposal?
>>
>
> Thank you for this link! It seems to discuss the same end result as what I
> tried to present in my first message: the ability to have a single
> models.Field managing an arbitrary number of DB columns under the hood.
>
> The proposed approach is perhaps a bit different: if I understood the
> ticked correctly, it proposes to change the base Field class to make it
> possible, when deriving from it, to manage one or several DB columns. My
> first idea was more to mimic the composite pattern implementation already
> in use with forms.MultiValueField:
> * The models.Field *leaf* classes would still manage a single DB column.
> * Introduce a models.MultiField class, which is a container of
> models.Field classes (be it leaf classes or other MultiField classes). This
> container would address the multiple columns indirectly, through the
> interface of the composing fields. And, to the eyes of the rest of the
> code, it would behave as a normal field, notably offering the to_python()
> feature, hiding the composition in its implementation details.
>
> I did not take time yet to try and assemble a prototype of this idea; In
> fact, I first wanted to confirm if such approach has not already been
> rejected in the past, before investing work in it ;)
>
> Does it sound like a feasible/interesting idea ? Or is there a good reason
> not to do it / too many obvious technical complications that I did not
> foresee ?
>
> Thank you for reading,
>   Ad
>
>
>> https://code.djangoproject.com/ticket/5929
>>
>> On Monday, August 17, 2015 at 5:11:01 AM UTC-4, boito...@gmail.com wrote:
>>>
>>> Hi,
>>>
>>>   While implementing  our collection management system based on Django,
>>> we are always excited by the extensibility of the framework.
>>>   Most recently, we were exposed to the *forms.MultiValueField* and*
>>> widgets.MultiWidget*, that seem to offer composition capacities to
>>> users of the *form* and *widget* layers. Yet, we did not find any
>>> equivalent in the *model* layer, which seemed a bit surprising knowing
>>> that those 3 layers can work hand-in-hand very easily
>>>
>>>   Is there a rationale to prevent implementation of such a
>>> models.MultiField class ? It could be a wrapper around the composite
>>> pattern in the *model* layer, allowing users to easily define custom
>>> models.Field that would leverage existing *models.Field* classes, by
>>> assembling them for specific purposes (while maximizing reuse).
>>>
>>> 
>>>
>>> This question was also raised in Stack Overflow here:
>>> http://stackoverflow.com/q/32014748/1027706. Below is a summary of the
>>> question's example motivating such feature request:
>>>
>>> Imagine we want to store partial date in the DB (i.e., a date that is
>>> either complete , or just month+year, or just year). We could model it in
>>> the models layer using a *models.DateField* + a *models.CharField*
>>> (this last field storing whether the date is complete, or month+year, or
>>> just year).
>>>
>>> Now, if we move to the forms layer, let's say we want a custom
>>> validation step that when a date is partial, the "unused" part of the
>>> DateField must be the value '1'. Because a *ModelForm* automatically
>>> maps one *forms.Field* to each *models.Field*, this constraint would
>>> require a cross-field validation.
>>>
>>> On the other hand, if there was a *models.MultiField*, one could define
>>> a *PartialDate* class to inherit from said *MultiField*. It would then
>>> be seen by other layers as a single *models.Field* (implemented by
>>> aggregating two other *models.Field*, but that would be an
>>> implementation detail hidden from other layers). In *ModelForm*, this
>>> single *models.Field* would map a to a single custom* forms.Field* (probably
>>> deriving from *forms.MultiValueField*), and the validation step above
>>> would not need to be a cross-field validation anymore (more precisely, this
>>> validation could now happen at the *forms.MultiValueField* level,
>>> instead of the *Form* level). With this approach, it seems that the
>>> *models.PartialDate* and the *forms.PartialDate* could be written once,
>>> and reused in as many models and applications as possible, thus respecting
>>> Django's DRY philosophy.
>>>
>>> 
>>>
>>> Could a prototype implementation of such composite model field be of
>>> interest ?
>>>
>>>
>>> --
> You received this message because you are subscribed to the Goog

Re: create_permisions(): Call to ContentType.objects.clear_cache() missing

[Tim Graham]

I think you should aim for a lower level test which calls 
create_permissions() and update_contenttypes() in the order described in 
the ticket description. This problem precedes migrations, so I don't think 
there's a need to have that additional complexity in the test. Feel free to 
continue the discussion on the ticket or in #django-dev if you need further 
advice. Thanks!

On Thursday, August 20, 2015 at 9:47:45 AM UTC-4, guettli wrote:
>
> I wrote simple test for django before, but this is not easy. But maybe I 
> am able do it, if I get some help.
>
> The test would need to do the following:
>
> 1. Create a simple Model via migrations
> 2. implicit: ContentTypes and Permissions get created automatically.
> 3. Run migrations again.
> 4. This time a migration removes all exiting content-types and adds them 
> again. But with different PKs.
> 5. implicit: New permissions created for an existing ContentTypes should 
> be created. Up to now an exception happens. (See ticket).
>
> How can I write a unittest which does the above steps?
>
> Regards,
>   Thomas
>
> Am Donnerstag, 20. August 2015 13:14:21 UTC+2 schrieb Tim Graham:
>>
>> Hi Thomas, As indicated by the flags on the ticket, it "Needs tests" in 
>> order to be committed.
>>
>> On Thursday, August 20, 2015 at 5:31:46 AM UTC-4, guettli wrote:
>>>
>>> There is a six years old issue which has a working patch:
>>>
>>>  https://code.djangoproject.com/ticket/10827
>>>
>>> If a migration deletes and recreates content-types, then the 
>>> automatically called create_migrations()
>>> can result in ForeignKey constraint errors.
>>>
>>> Example:
>>>
>>> If Permission "Can add group" had primary key 1 before the migration and 
>>> after the migration
>>> it has the value 2, then things get broken.
>>>
>>> The cache needs to be cleared first.
>>>
>>> Please have a look at it.
>>>
>>> Thank you,
>>>
>>>   Thomas Güttler
>>>
>>

-- 
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-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/eb9965ab-1443-45ce-82ca-5b8b20d26a27%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: The hypothetical models.MultiField: is there a rationale to avoid it ? Or could it make it into future releases ?

[boitoletre]

Le mardi 18 août 2015 01:36:28 UTC+2, Tim Graham a écrit :
>
> I think the general idea is captured in ticket #5929 -- Allow Fields to 
> use multiple db columns (complex datatypes). Is that the gist of your 
> proposal?
>

Thank you for this link! It seems to discuss the same end result as what I 
tried to present in my first message: the ability to have a single 
models.Field managing an arbitrary number of DB columns under the hood.

The proposed approach is perhaps a bit different: if I understood the 
ticked correctly, it proposes to change the base Field class to make it 
possible, when deriving from it, to manage one or several DB columns. My 
first idea was more to mimic the composite pattern implementation already 
in use with forms.MultiValueField:
* The models.Field *leaf* classes would still manage a single DB column.
* Introduce a models.MultiField class, which is a container of models.Field 
classes (be it leaf classes or other MultiField classes). This container 
would address the multiple columns indirectly, through the interface of the 
composing fields. And, to the eyes of the rest of the code, it would behave 
as a normal field, notably offering the to_python() feature, hiding the 
composition in its implementation details.

I did not take time yet to try and assemble a prototype of this idea; In 
fact, I first wanted to confirm if such approach has not already been 
rejected in the past, before investing work in it ;) 

Does it sound like a feasible/interesting idea ? Or is there a good reason 
not to do it / too many obvious technical complications that I did not 
foresee ?

Thank you for reading,
  Ad


> https://code.djangoproject.com/ticket/5929
>
> On Monday, August 17, 2015 at 5:11:01 AM UTC-4, boito...@gmail.com wrote:
>>
>> Hi,
>>
>>   While implementing  our collection management system based on Django, 
>> we are always excited by the extensibility of the framework.
>>   Most recently, we were exposed to the *forms.MultiValueField* and* 
>> widgets.MultiWidget*, that seem to offer composition capacities to users 
>> of the *form* and *widget* layers. Yet, we did not find any equivalent 
>> in the *model* layer, which seemed a bit surprising knowing that those 3 
>> layers can work hand-in-hand very easily
>>
>>   Is there a rationale to prevent implementation of such a 
>> models.MultiField class ? It could be a wrapper around the composite 
>> pattern in the *model* layer, allowing users to easily define custom 
>> models.Field that would leverage existing *models.Field* classes, by 
>> assembling them for specific purposes (while maximizing reuse).
>>
>> 
>>
>> This question was also raised in Stack Overflow here: 
>> http://stackoverflow.com/q/32014748/1027706. Below is a summary of the 
>> question's example motivating such feature request:
>>
>> Imagine we want to store partial date in the DB (i.e., a date that is 
>> either complete , or just month+year, or just year). We could model it in 
>> the models layer using a *models.DateField* + a *models.CharField* (this 
>> last field storing whether the date is complete, or month+year, or just 
>> year).
>>
>> Now, if we move to the forms layer, let's say we want a custom validation 
>> step that when a date is partial, the "unused" part of the DateField must 
>> be the value '1'. Because a *ModelForm* automatically maps one 
>> *forms.Field* to each *models.Field*, this constraint would require a 
>> cross-field validation.
>>
>> On the other hand, if there was a *models.MultiField*, one could define 
>> a *PartialDate* class to inherit from said *MultiField*. It would then 
>> be seen by other layers as a single *models.Field* (implemented by 
>> aggregating two other *models.Field*, but that would be an 
>> implementation detail hidden from other layers). In *ModelForm*, this 
>> single *models.Field* would map a to a single custom* forms.Field* (probably 
>> deriving from *forms.MultiValueField*), and the validation step above 
>> would not need to be a cross-field validation anymore (more precisely, this 
>> validation could now happen at the *forms.MultiValueField* level, 
>> instead of the *Form* level). With this approach, it seems that the 
>> *models.PartialDate* and the *forms.PartialDate* could be written once, 
>> and reused in as many models and applications as possible, thus respecting 
>> Django's DRY philosophy.
>>
>> 
>>
>> Could a prototype implementation of such composite model field be of 
>> interest ?
>>
>>
>>

-- 
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-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid

Re: Django Admin New Look

[Aymeric Augustin]

2015-08-20 16:14 GMT+02:00 Tom Christie :

> Could we give users guidance on overriding the admin's application
> specific static files with global static files if we do this?
>

The general rule is: if several applications provide the same resource, the
earliest application in INSTALLED_APPS wins.

(NB: before 1.7, management commands had the opposite behavior.)

-- 
Aymeric Augustin.

-- 
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-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CANE-7mXPGi5e2UPvQFUZkhu4QLSk51qPzdK_cn0%2BwqbBgsnoUw%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Django ORM query syntax enhancement

[Alexey Zankevich]

What about the idea to add interface to specify paths with special class or 
callable?


On Wednesday, August 19, 2015 at 10:49:07 AM UTC+3, Josh Smeaton wrote:
>
> If I finish the patch in time (I think I have about a month left), then 
> it'll be included in 1.9. Review and comments on the PR will go a long way 
> to helping me tidy it up sooner rather than later, so please feel free to 
> review.
>
> Regards,
>
> On Wednesday, 19 August 2015 04:55:21 UTC+10, Alexey Zankevich wrote:
>>
>> Once Josh completes this patch https://github.com/django/django/pull/5090
>> (.filter method accepting class-based lookups and transforms), it will be
>> almost everything required by third-party apps. Is it going to be a part 
>> of
>> Django 1.9, by the way?
>>
>> Additionally, for pure flexibility, next method and classes need to accept
>> either a callable or an object supporting special path interface (for 
>> example,
>> just a single method get_path() returning string path).
>> They listed below:
>>
>> 1. The current methods.select_related, .prefetch_related, .order_by
>> 2. Annotation classes Min, Max, Count, Sum
>> 3. Future transforms and lookups classes
>>
>>
>> Examples:
>>
>> >>> path = lambda x: 'user__last_login_date'
>> >>> GameSession.objects.all().order_by(path)
>>
>> or
>>
>> >>> class LoginDatePath(object):
>> ... def get_path(self):
>> ... return 'user__last_login_date'
>> >>> path = LoginDatePath()
>> >>> GameSession.objects.all().order_by(path)
>>
>> Path generation is a critical part of external query syntax as it used in
>> almost all aspects of the ORM, meanwhile each related method accepts 
>> either a
>> string or (in some cases) a specific kind of class - OrderBy for order_by
>> method, Prefetch for prefetch_related and etc.
>>
>>
>> On Tuesday, August 18, 2015 at 7:54:48 PM UTC+3, Michael Manfre wrote:
>>
>> +1 for making it doable for 3rd party apps.
>>
>> Regards,
>> Michael Manfre
>>
>> On Tue, Aug 18, 2015 at 12:49 PM, Anssi Kääriäinen  
>> wrote:
>>
>> I'm still thinking we shouldn't integrate any new query syntax into
>> 1.9. Instead lets make it easy to create 3rd party apps that offer
>> different querying syntax, and then lets see which solution (if any)
>> gets popular enough to be integrated into Django.
>>
>>  - Anssi
>>
>>
>>
>> On Tue, Aug 18, 2015 at 5:54 PM, Collin Anderson  
>> wrote:
>> > Just a quick thought: I could imagine some newbies could get confused 
>> by the
>> > python-like syntax and try to do:
>> >
>> > Equal(P.user.get_full_name(), 'Bob Someone')
>> >
>> > I don't think it's not a huge deal, but worth noting.
>> >
>> > On Tuesday, August 18, 2015 at 8:00:17 AM UTC-4, Alexey Zankevich wrote:
>> >>
>> >> Hi all,
>> >>
>> >> Thanks for detailed response. I thought over the described expressions/
>> >> transforms patches and here are my thoughts about the best way to
>> >> implement simplified lookups.
>> >>
>> >> Firstly, I want to describe which properties of the new syntax seem to 
>> be
>> >> important:
>> >>
>> >> 1. Using Python operators to do basic lookups as it's a natural way in
>> >> Python
>> >> for that.
>> >>
>> >> 2. Syntax should be minimalistic for basic lookups, the use of that
>> >> approach
>> >> will be more noticeable on multiple filter conditions. In other words,
>> >> next
>> >> syntax is better:
>> >>
>> >> >>> GameSession.objects.filter(Q.user.profile.last_login.date() ==
>> >> >>> datetime.now().date)
>> >>
>> >> than this one
>> >>
>> >> >>> GameSession.objects.filter(E(F.user.profile.last_login).date() ==
>> >> >>> datetime.now().date)
>> >>
>> >> as it requires additional calls, which makes expressions less readable.
>> >>
>> >> 3. I definitely like the idea of having explicit classes for lookups 
>> and
>> >> transforms and think it's worth to bundle dotted query syntax with the
>> >> patch.
>> >> Explicit classes will separate functionality and simplify functions
>> >> signature
>> >> checks.
>> >>
>> >> I suggest a mixed approach, with next properties.
>> >>
>> >> 1. We will have a separate class to define query paths (let's call it 
>> P,
>> >> we
>> >> can still use F as "field", but having F as multipurpose class may 
>> confuse
>> >> users, as well as implementation may become more complicated). And it 
>> will
>> >> be
>> >> the only purpose of the class. Below I'll reference it as "P" no 
>> matter we
>> >> call
>> >> it in future.
>> >>
>> >> 2. Any transforms and lookups will take query string or P class, as 
>> well
>> >> as
>> >> existing methods "select_related", "prefetch_related" and "order_by". 
>> The
>> >> simplest implementation will be overriding __str__ method of the path
>> >> class
>> >> to generate related strings.
>> >>
>> >> >>> path = P.user.last_login_date
>> >> >>> GameSession.objects.all().order_by(path)[:10]
>> >>
>> >> >>> print(path)
>> >> user__last_login_date
>> >>
>> >> 3. Implement transforms and lookups as classes or functions (not bound 
>> to
>> >> P class):
>> >>
>> >> >>> GameSes

Re: Django Admin New Look

[Tom Christie]

Could we give users guidance on overriding the admin's application specific 
static files with global static files if we do this?

Not immediately clear to me what order static files are copied in, but 
presumably it's possible to ensure that the jquery static files included in 
the admin app directory are overridden with user specified ones in a 
project-level static files directory, right?

Also, tho I'm broadly in favor with us staying with up to date with the 
currently active version of jQuery, to clarify: is there anything 
*specific* that we'd be gaining from the switch at this point?

-- 
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-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/972b31f8-f085-4b42-80fa-ea49abf40721%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Django Admin New Look

[Josh Smeaton]

The only reason that I'm on the fence about not actively ending IE8 support 
right now is that it will still be in support for the release of Django 
1.9. It'll only be a month, but it's something. I'd feel more comfortable 
about a soft deprecation now and a harder end for Django 1.10. It'll at 
least give some warning to the community if someone were to look for it.


On Thursday, 20 August 2015 20:12:45 UTC+10, Marc Tamlyn wrote:
>
> I think this is a bit of a misnomer - if we include a jQuery without IE8 
> support we will start dropping IE8 from the CSS, our own custom javascript, 
> new jquery features, community plugins will drop it etc etc. For 1.9 itself 
> it may simply be a case of swapping in a different jQuery version, but it 
> won't stay that way for long.
>
> On 20 August 2015 at 00:49, Josh Smeaton  > wrote:
>
>> >My own opinion is that if you really need IE8 support, it's not 
>> difficult to write a custom template and conditionally include the old 
>> jQuery version.
>>
>> Good point. It's easy enough for users to support IE8 themselves if they 
>> need to. Consider me a +1 then.
>>
>> On Thursday, 20 August 2015 00:34:01 UTC+10, Tim Graham wrote:
>>>
>>> To see what's required, I made a pull request for jQuery 2 here: 
>>> https://github.com/django/django/pull/5155 
>>>
>>> The selenium and JavaScript tests pass without any modifications to the 
>>> admin's JavaScript.
>>>
>>> My own opinion is that if you really need IE8 support, it's not 
>>> difficult to write a custom template and conditionally include the old 
>>> jQuery version. If we view the admin as an internal management tool for 
>>> "staff users", I think it's reasonable for organizations to know what 
>>> browsers their staff uses and be able to make these determinations.
>>>
>>> For me, moving to jQuery 2 is a bit like the Python 2/3 debate. As long 
>>> as we have to support Python 2/jQuery 1.x we are somewhat restricted in 
>>> reaping the benefits of Python 3/jQuery 2. I'm not sure there are any new 
>>> features in jQuery 2 at this time - the main benefit seems to be smaller 
>>> size. Of course, if we start using new features of jQuery 2 at some point, 
>>> we might break the solution proposed in the previous paragraph, but that 
>>> seems okay to me since the point is that we shouldn't spend much time 
>>> caring for unsupported browsers.
>>>
>>> If we don't want to use end-of-life dates for deciding a browser support 
>>> policy, then what alternative metric should we use? 
>>>
>>> On Wednesday, August 19, 2015 at 5:59:21 AM UTC-4, sdcooke wrote:

 I meant jQuery 2 and 1.11 are API compatible - you're right though, the 
 latest versions of jQuery might have deprecated things that are currently 
 used in Django.

 On Wed, 19 Aug 2015 at 10:39 elky  wrote:

>
> On Wednesday, 19 August 2015 14:27:53 UTC+5, sdcooke wrote:
>>
>> and get the performance boost of jQuery 2 in modern browsers. As far 
>> as I'm aware they are still API compatible.
>>
>
> We should carefully check jQuery change log. I remember they removed 
> toggle method in one of the latest versions, so some apps may broke 
> because 
> of that.   
>
> -- 
> 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-develop...@googlegroups.com.
> To post to this group, send email to django-d...@googlegroups.com.
> Visit this group at http://groups.google.com/group/django-developers.
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/django-developers/446e9038-0b45-4a67-8b14-8cb402722f4b%40googlegroups.com
>  
> 
> .
> For more options, visit https://groups.google.com/d/optout.
>
 -- 
>> 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-develop...@googlegroups.com .
>> To post to this group, send email to django-d...@googlegroups.com 
>> .
>> Visit this group at http://groups.google.com/group/django-developers.
>> To view this discussion on the web visit 
>> https://groups.google.com/d/msgid/django-developers/975c070b-8c0f-4af8-a207-84acf828547a%40googlegroups.com
>>  
>> 
>> .
>>
>> For more options, visit https://groups.google.com/d/optout.
>>
>
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contribution

Re: create_permisions(): Call to ContentType.objects.clear_cache() missing

[guettli]

I wrote simple test for django before, but this is not easy. But maybe I am 
able do it, if I get some help.

The test would need to do the following:

1. Create a simple Model via migrations
2. implicit: ContentTypes and Permissions get created automatically.
3. Run migrations again.
4. This time a migration removes all exiting content-types and adds them 
again. But with different PKs.
5. implicit: New permissions created for an existing ContentTypes should be 
created. Up to now an exception happens. (See ticket).

How can I write a unittest which does the above steps?

Regards,
  Thomas

Am Donnerstag, 20. August 2015 13:14:21 UTC+2 schrieb Tim Graham:
>
> Hi Thomas, As indicated by the flags on the ticket, it "Needs tests" in 
> order to be committed.
>
> On Thursday, August 20, 2015 at 5:31:46 AM UTC-4, guettli wrote:
>>
>> There is a six years old issue which has a working patch:
>>
>>  https://code.djangoproject.com/ticket/10827
>>
>> If a migration deletes and recreates content-types, then the 
>> automatically called create_migrations()
>> can result in ForeignKey constraint errors.
>>
>> Example:
>>
>> If Permission "Can add group" had primary key 1 before the migration and 
>> after the migration
>> it has the value 2, then things get broken.
>>
>> The cache needs to be cleared first.
>>
>> Please have a look at it.
>>
>> Thank you,
>>
>>   Thomas Güttler
>>
>

-- 
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-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/824a93e2-cd20-474d-9fa0-2c72537202d0%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: A new setting for custom gettext domains?

[Raphael Michel]

Hi,

I think the setting is worth it, it can be really useful when working
with complex translation setups.

However, I feel that LOCALE_FILENAMES is a poor choice for the setting
name, as it differs from standard gettext terminology in a very unclear
way. Why not name it LOCALE_DOMAINS?
(To me, _FILENAMES sounds as if I should pass either a path or at least
a full filename, but it is neither of both.)

Raphael

Am Tue, 28 Jul 2015 11:48:14 -0700 (PDT)
schrieb Tim Graham :

> Since adding new settings is sometimes controversial, I wanted to ask
> for thoughts about this ticket [1] / pull request [2] which proposes
> a new LOCALE_FILENAMES setting to allow using additional gettext
> domains besides "django". I don't use translations myself, so
> thoughts about whether the usefulness of the feature justifies a new
> setting or if there is some other solution to the problem described
> in the ticket would be welcome.
> 
> [1] https://code.djangoproject.com/ticket/6376
> [2] https://github.com/django/django/pull/5053
> 

-- 
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-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/20150820153900.300d77ec%40kvothe.
For more options, visit https://groups.google.com/d/optout.


pgpyKOcMfnmQ2.pgp
Description: Digitale Signatur von OpenPGP

Re: create_permisions(): Call to ContentType.objects.clear_cache() missing

[Tim Graham]

Hi Thomas, As indicated by the flags on the ticket, it "Needs tests" in 
order to be committed.

On Thursday, August 20, 2015 at 5:31:46 AM UTC-4, guettli wrote:
>
> There is a six years old issue which has a working patch:
>
>  https://code.djangoproject.com/ticket/10827
>
> If a migration deletes and recreates content-types, then the automatically 
> called create_migrations()
> can result in ForeignKey constraint errors.
>
> Example:
>
> If Permission "Can add group" had primary key 1 before the migration and 
> after the migration
> it has the value 2, then things get broken.
>
> The cache needs to be cleared first.
>
> Please have a look at it.
>
> Thank you,
>
>   Thomas Güttler
>

-- 
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-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/f45d9e64-22ef-46b1-b2f8-93f29af1b54d%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Django Admin New Look

[Marc Tamlyn]

I think this is a bit of a misnomer - if we include a jQuery without IE8
support we will start dropping IE8 from the CSS, our own custom javascript,
new jquery features, community plugins will drop it etc etc. For 1.9 itself
it may simply be a case of swapping in a different jQuery version, but it
won't stay that way for long.

On 20 August 2015 at 00:49, Josh Smeaton  wrote:

> >My own opinion is that if you really need IE8 support, it's not difficult
> to write a custom template and conditionally include the old jQuery version.
>
> Good point. It's easy enough for users to support IE8 themselves if they
> need to. Consider me a +1 then.
>
> On Thursday, 20 August 2015 00:34:01 UTC+10, Tim Graham wrote:
>>
>> To see what's required, I made a pull request for jQuery 2 here: 
>> https://github.com/django/django/pull/5155
>>
>> The selenium and JavaScript tests pass without any modifications to the
>> admin's JavaScript.
>>
>> My own opinion is that if you really need IE8 support, it's not difficult
>> to write a custom template and conditionally include the old jQuery
>> version. If we view the admin as an internal management tool for "staff
>> users", I think it's reasonable for organizations to know what browsers
>> their staff uses and be able to make these determinations.
>>
>> For me, moving to jQuery 2 is a bit like the Python 2/3 debate. As long
>> as we have to support Python 2/jQuery 1.x we are somewhat restricted in
>> reaping the benefits of Python 3/jQuery 2. I'm not sure there are any new
>> features in jQuery 2 at this time - the main benefit seems to be smaller
>> size. Of course, if we start using new features of jQuery 2 at some point,
>> we might break the solution proposed in the previous paragraph, but that
>> seems okay to me since the point is that we shouldn't spend much time
>> caring for unsupported browsers.
>>
>> If we don't want to use end-of-life dates for deciding a browser support
>> policy, then what alternative metric should we use?
>>
>> On Wednesday, August 19, 2015 at 5:59:21 AM UTC-4, sdcooke wrote:
>>>
>>> I meant jQuery 2 and 1.11 are API compatible - you're right though, the
>>> latest versions of jQuery might have deprecated things that are currently
>>> used in Django.
>>>
>>> On Wed, 19 Aug 2015 at 10:39 elky  wrote:
>>>

 On Wednesday, 19 August 2015 14:27:53 UTC+5, sdcooke wrote:
>
> and get the performance boost of jQuery 2 in modern browsers. As far
> as I'm aware they are still API compatible.
>

 We should carefully check jQuery change log. I remember they removed
 toggle method in one of the latest versions, so some apps may broke because
 of that.

 --
 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-develop...@googlegroups.com.
 To post to this group, send email to django-d...@googlegroups.com.
 Visit this group at http://groups.google.com/group/django-developers.
 To view this discussion on the web visit
 https://groups.google.com/d/msgid/django-developers/446e9038-0b45-4a67-8b14-8cb402722f4b%40googlegroups.com
 
 .
 For more options, visit https://groups.google.com/d/optout.

>>> --
> 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-developers+unsubscr...@googlegroups.com.
> To post to this group, send email to django-developers@googlegroups.com.
> Visit this group at http://groups.google.com/group/django-developers.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/django-developers/975c070b-8c0f-4af8-a207-84acf828547a%40googlegroups.com
> 
> .
>
> For more options, visit https://groups.google.com/d/optout.
>

-- 
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-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CAMwjO1HBBC2JQF%2BqcQ6Rmt912E8Zr6NdZ%3DXr68bn6O0mpcFTaw%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

create_permisions(): Call to ContentType.objects.clear_cache() missing

[guettli]

There is a six years old issue which has a working patch:

 https://code.djangoproject.com/ticket/10827

If a migration deletes and recreates content-types, then the automatically 
called create_migrations()
can result in ForeignKey constraint errors.

Example:

If Permission "Can add group" had primary key 1 before the migration and 
after the migration
it has the value 2, then things get broken.

The cache needs to be cleared first.

Please have a look at it.

Thank you,

  Thomas Güttler

-- 
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-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/7ab12a7d-1c49-4daa-b516-bc3d2cce6b9b%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.