Re: Getting user's real IP address in Django

2013-12-22 Thread Val Neekman
Russell,

I agree with the spoofing comment you made and it makes sense not to
provide a formal API.
I wish there was a middle-ground here, however, at this time, I do not have
a solid reason to make a case here. (not yet at least :)

BTW: IP logic was updated as per your feedback.

Thank you.

Val
















On Sun, Dec 22, 2013 at 7:30 PM, Russell Keith-Magee <
russ...@keith-magee.com> wrote:

>
> On Mon, Dec 23, 2013 at 7:27 AM, Val Neekman  wrote:
>
>> Majority of the sites/apps built on Django *may* require user's real IP
>> address for tracking, prevention, verification and many other reasons.
>>
>> To get (guess) user's real IP address, one must check few META fields in
>> a particular order to peel off the proxies.
>>
>> This is what lot of Django developers do already. I call it, "*~*DRYing
>> the *get_real_ip()* to death".
>>
>> With that said, may I purpose to have "*django-ipware*" blessed and
>> included in *core.utils.*
>>
>> Here is the code:
>> https://github.com/un33k/django-ipware/blob/master/ipware/ip.py
>>
>> I just want to know if such an API would have a place in core.utils. If
>> so, I'll send a pull request against the proper branch.
>>
>
> core.utils is probably the wrong place -- if we're going to add this sort
> of thing to core, it wouldn't be as a utility function, but as a readonly
> property on the request object itself.
>
> I don't recall if this particular idea has been proposed in the past.
> However I do remember a couple of discussions about the
> HTTP_X_FORWARDED_FOR and HTTP_X_REAL_IP headers because they can be spoofed
> by attackers under certain conditions. Therefore, encouraging end-users to
> rely on these headers (by providing a formal API) is problematic from a
> security point of view. As I recall, the argument is that any use of these
> headers must be aware of the local network conditions, and what is (or
> isn't) guaranteed to be produced by your own web stack, and as a result,
> we've avoided defining any formal API that uses these headers.
>
> I might be off on the details here; if you do a search of the django-dev
> archives, you should find any relevant discussions. It would be worth
> gathering those discussions before proceeding any further.
>
> As an aside, I'd also point out that your logic for private IPs is a
> little off -- the private network prefixes are 10.*, 172.16.*.* to
> 172.31.*.*, and 192.168.*.*, representing a class A, B and C network
> respectively. 127.0.0.1 is a loopback device, not a private network.
> There's also the fc00::/7 private network block specified by IPv6.
>
> Yours,
> Russ Magee %-)
>
>  --
> You received this message because you are subscribed to the Google Groups
> "Django developers" 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/CAJxq848_z0-JDTBk4EPoXz5DXPgMa2CFdBCFsR%3DQEZhh5%2BEp6Q%40mail.gmail.com
> .
> For more options, visit https://groups.google.com/groups/opt_out.
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" 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/CADy_H8ETL8vMvhdPQsczwrU9PHVQKiNdr%2Bb7sidBQRy5GmN4XA%40mail.gmail.com.
For more options, visit https://groups.google.com/groups/opt_out.


Re: Getting user's real IP address in Django

2013-12-22 Thread Russell Keith-Magee
On Mon, Dec 23, 2013 at 7:27 AM, Val Neekman  wrote:

> Majority of the sites/apps built on Django *may* require user's real IP
> address for tracking, prevention, verification and many other reasons.
>
> To get (guess) user's real IP address, one must check few META fields in a
> particular order to peel off the proxies.
>
> This is what lot of Django developers do already. I call it, "*~*DRYing
> the *get_real_ip()* to death".
>
> With that said, may I purpose to have "*django-ipware*" blessed and
> included in *core.utils.*
>
> Here is the code:
> https://github.com/un33k/django-ipware/blob/master/ipware/ip.py
>
> I just want to know if such an API would have a place in core.utils. If
> so, I'll send a pull request against the proper branch.
>

core.utils is probably the wrong place -- if we're going to add this sort
of thing to core, it wouldn't be as a utility function, but as a readonly
property on the request object itself.

I don't recall if this particular idea has been proposed in the past.
However I do remember a couple of discussions about the
HTTP_X_FORWARDED_FOR and HTTP_X_REAL_IP headers because they can be spoofed
by attackers under certain conditions. Therefore, encouraging end-users to
rely on these headers (by providing a formal API) is problematic from a
security point of view. As I recall, the argument is that any use of these
headers must be aware of the local network conditions, and what is (or
isn't) guaranteed to be produced by your own web stack, and as a result,
we've avoided defining any formal API that uses these headers.

I might be off on the details here; if you do a search of the django-dev
archives, you should find any relevant discussions. It would be worth
gathering those discussions before proceeding any further.

As an aside, I'd also point out that your logic for private IPs is a little
off -- the private network prefixes are 10.*, 172.16.*.* to 172.31.*.*, and
192.168.*.*, representing a class A, B and C network respectively.
127.0.0.1 is a loopback device, not a private network. There's also the
fc00::/7 private network block specified by IPv6.

Yours,
Russ Magee %-)

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" 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/CAJxq848_z0-JDTBk4EPoXz5DXPgMa2CFdBCFsR%3DQEZhh5%2BEp6Q%40mail.gmail.com.
For more options, visit https://groups.google.com/groups/opt_out.


Re: Improving aggregate support (#14030)

2013-12-22 Thread Josh Smeaton
Thanks for the response. I've noticed the JoinPromoter recently, and I have 
been looking into the custom lookups, but wasn't sure what the purpose was 
until now.

I'll see what I can do with this patch, and try to avoid as much complexity 
as I can. Then it just comes down to review on whether it makes it in or 
not (and my ability of course).

Regards,

Josh

On Sunday, 22 December 2013 22:04:36 UTC+11, Anssi Kääriäinen wrote:
>
> On Saturday, December 21, 2013 3:15:12 AM UTC+2, Josh Smeaton wrote:
>>
>> I'm interested in tackling 
>> ticket#14030, 
>> ideally before the Jan 20th cutoff, but I'm looking for some guidance. 
>> There have been a lot of references to Anssi Kääriäinen attempting an ORM 
>> refactor before trying to fix aggregates, but I'm not sure if this is still 
>> a goal or not.
>>
>
> Yes, more refactoring is still the plan. A lot has already been done. The 
> main part of the work has been bug fixing, code cleanup and join generation 
> changes.
>
> The next part is introducing custom lookups for 1.7 (see 
> https://github.com/django/django/pull/2019), and later on in 1.8 allow 
> usage of custom lookups in every part of the ORM. This means one can do 
> queries such as .order_by(' jsonfield__user__firstname'), or more relevant 
> to this ticket, .annotate(avg_year=Avg('datefield__year')).
>
> To make the above possible Django's ORM needs to switch to using unified 
> query expression API. For example aggregates, custom lookups and Expression 
> nodes will all respond to the same API. The API deals mainly with how to 
> produce SQL for the expressions, how to convert db values to Python values 
> and things like that. As a side effect Avg(F('somefield') + 
> F('anotherfield')) should just work.
>  
>
>> The work done by nateb at https://github.com/django/django/pull/46 was 
>> very similar to the structure I believed would be the right way forward - 
>> refactoring Aggregates to inherit from ExpressionNode. Unfortunately, the 
>> patch submitted has been closed because it no longer applies cleanly. There 
>> was also discussion regarding type coercion and a lack of real world tests 
>> that should be considered.
>>
>> What I'd like to do is attempt to rewrite the above PR so that it applies 
>> cleanly. The reviews that had already happened on that patch would then 
>> mostly apply to the rewrite, eliminating the need for a start to finish 
>> review of the concept in general. Is this something that I should go 
>> through with, or are we better off waiting for the ORM refactor then 
>> reevaluating the way forward?
>>
>
> Making Aggregates inherit from ExpressionNode shouldn't make the unified 
> query expression API significantly easier or harder to achieve. If the code 
> complexity stays manageable, I don't see a reason to not merge the changes. 
> The change will be needed for Avg('somefield')  + Avg('otherfield') support 
> even when unified query expression API was implemented.
>
> One of the main problems for this ticket has been the code complexity. 
> Both Aggregates and Expressions are somewhat complicated in the ORM. The 
> combination of the two results in even worse code complexity. On the other 
> hand this feature is clearly needed by many users, so maybe some code 
> complexity can be tolerated.
>
>  - Anssi
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" 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/1eeaa1b5-fe7a-4b7a-8fb7-8792bf45a49b%40googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.


Re: Getting user's real IP address in Django

2013-12-22 Thread Val Neekman
*correction*:

It should read: "*may I propose*" instead of "may I purpose".

Thanks,

Val



On Sun, Dec 22, 2013 at 6:27 PM, Val Neekman  wrote:

> Majority of the sites/apps built on Django *may* require user's real IP
> address for tracking, prevention, verification and many other reasons.
>
> To get (guess) user's real IP address, one must check few META fields in a
> particular order to peel off the proxies.
>
> This is what lot of Django developers do already. I call it, "*~*DRYing
> the *get_real_ip()* to death".
>
> With that said, may I purpose to have "*django-ipware*" blessed and
> included in *core.utils.*
>
> Here is the code:
> https://github.com/un33k/django-ipware/blob/master/ipware/ip.py
>
> I just want to know if such an API would have a place in core.utils. If
> so, I'll send a pull request against the proper branch.
>
> Thanks,
>
> Val
>
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" 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/CADy_H8Eb0kRBO%2Br676zEuRdGCKy__%3D9mce5V37bnNw%3D7SV82OQ%40mail.gmail.com.
For more options, visit https://groups.google.com/groups/opt_out.


Getting user's real IP address in Django

2013-12-22 Thread Val Neekman
Majority of the sites/apps built on Django *may* require user's real IP
address for tracking, prevention, verification and many other reasons.

To get (guess) user's real IP address, one must check few META fields in a
particular order to peel off the proxies.

This is what lot of Django developers do already. I call it, "*~*DRYing the
*get_real_ip()* to death".

With that said, may I purpose to have "*django-ipware*" blessed and
included in *core.utils.*

Here is the code:
https://github.com/un33k/django-ipware/blob/master/ipware/ip.py

I just want to know if such an API would have a place in core.utils. If so,
I'll send a pull request against the proper branch.

Thanks,

Val

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" 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/CADy_H8GLtbDNQNaCnsEDxHmiyo%2BRbqE7XiqWnG3D_GE-okiR2g%40mail.gmail.com.
For more options, visit https://groups.google.com/groups/opt_out.


Re: South data-migration and custom save() method

2013-12-22 Thread Christian Schmitt
That's what i do in south, sometimes.

But sometimes you have a bigger table with initial data, like a table with 
predefined prices. and it wouldn't be that cool to instantiate 20.000 or 
more prices manually.

Am Sonntag, 22. Dezember 2013 12:06:02 UTC+1 schrieb Andrew Godwin:
>
> It won't load initial_data fixtures - those are being deprecated for 
> migrated apps - but you could still call loaddata with a custom one, I 
> guess. I'd personally recommend moving away from fixtures and just 
> instantiating objects directly using the ORM inside data migrations.
>
> Andrew
>
>
> On Sat, Dec 21, 2013 at 10:45 PM, Christian Schmitt <
> c.sc...@briefdomain.de > wrote:
>
>> I didn't found anything in the docs... So... could I stil load a fixture 
>> with a migration? Like here: 
>> http://south.readthedocs.org/en/latest/fixtures.html
>>
>> Am Freitag, 20. Dezember 2013 17:41:22 UTC+1 schrieb Andrew Godwin:
>>>
>>> This will also be true for django.db.migrations; there's no way we can 
>>> serialise save methods as part of the model for later use in migrations. If 
>>> you want to use complex save logic in migrations, you'll have to copy it 
>>> into the migration file (which also means the migration will keep working 
>>> as originally written if you later change what the save method does).
>>>
>>> Andrew
>>>
>>>
>>> On Fri, Dec 20, 2013 at 4:15 PM, Val Neekman  wrote:
>>>
 South (latest) has a limitation where it ignores a custom save() method 
 in the model class.
  
 I am wondering if that is going to be true for the new South in the 
 core in Django 1.7?

 Thanks,

 Val

  -- 
 You received this message because you are subscribed to the Google 
 Groups "Django developers" 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/CADy_H8ERxnyrzf5UGOTPt1%
 3DUmj46himOBJ3w%2BBrxL49u_E3qyA%40mail.gmail.com.
 For more options, visit https://groups.google.com/groups/opt_out.

>>>
>>>  -- 
>> You received this message because you are subscribed to the Google Groups 
>> "Django developers" 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/c219ae48-16fe-4149-91c6-d49fe6cc7a26%40googlegroups.com
>> .
>>
>> For more options, visit https://groups.google.com/groups/opt_out.
>>
>
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" 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/a54f5360-1519-4a29-aa25-7cb9fe869c13%40googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.


Re: App-loading reloaded - custom app names in the admin

2013-12-22 Thread Aymeric Augustin
I’ve updated the pull request with these changes as well as a few minor 
comments made by reviewers.

https://github.com/django/django/pull/2089

I think it’s worth merging in that state. I still have a list of about 20 
things to check, but none of them is likely to change anything fundamental.

-- 
Aymeric.



On 21 déc. 2013, at 17:01, Aymeric Augustin 
 wrote:

> Hello,
> 
> Based on the feedback I received through several channels (GitHub, IRC, 
> private email) I’m planning to make two API changes before merging this pull 
> request.
> 
> 
> (1) Remove auto-discovery of AppConfig in application modules
> 
> I implemented this shim to make it possible to take advantage of app configs 
> without changing the format of INSTALLED_APPS. I wanted to increase 
> backwards-compatibility and accelerate adoption in pluggable apps. I also 
> wanted to keep INSTALLED_APPS short and readable in the common case and avoid 
> this pattern:
> 
> INSTALLED_APPS = (
>‘django.contrib.admin.app.AdminConfig',
>'django.contrib.auth.app.AuthConfig',
>'django.contrib.contenttypes.app.ContentTypesConfig',
>'django.contrib.sessions.app.SessionsConfig',
>'django.contrib.messages.app.MessagesConfig',
>'django.contrib.staticfiles.app.StaticFilesConfig’,
># et caetera ad nauseam
># cold enterprisey thorny feelings 
> )
> 
> Astute readers will note that MIDDLEWARE_CLASSES looks even worse but I’m not 
> buying the “make it consistently ugly" argument :-)
> 
> (Also I haven’t prepared any changes to Django’s contrib apps yet.)
> 
> However, I can also list a few reasons not to provide this shim:
> 
> - “There should be one-- and preferably only one --obvious way to do it.”
> - “Explicit is better than implicit.”
> - Django shouldn't encourage writing code in __init__.py files because it’s a 
> common cause of import loops eg. when a submodule attempts to import an 
> object defined in a parent package. Strictly speaking, importing the base 
> AppConfig class and implementing a subclass is safe: it doesn’t even load the 
> Django settings. But it’s still a code smell.
> - Python ≥ 3.3 introduces support for namespace packages (PEP 420) by making 
> __init__.py files optional. I’m pretty sure someone will find a good reason 
> to implement a Django app as a namespace package; then they couldn’t take 
> advantage of this convention any more. Besides, skipping __init__.py files 
> entirely might become a good practice in the next years.
> 
> One could also say that the explicit version makes it obvious which 
> applications use an application configuration and which don’t, but I don’t 
> find the difference between “using the application’s default AppConfig” and 
> “using Django’s default AppConfig” relevant.
> 
> I’m ambivalent about this question. Considering that it can easily be added 
> later, I’m leaning towards not including it for now. The reverse would be 
> much more complicated. 
> 
> 
> (2) Move the code back into django.apps
> 
> I originally wrote all the code in django.apps.
> 
> Then I realized it could cause confusion because “apps” shipped with Django 
> are in django.contrib, not in django.apps, and I moved the code to 
> django.contrib.apps. One could argue that apps are a core concept.
> 
> However, there are two strong arguments for moving the code back to its 
> original location.
> 
> - Most APIs intended to be imported by user code live outside of core: 
> “django.forms”, “django.db.models”, “django.templates”, “django.views”, etc. 
> - Most of the code in django.core would better live in a shallower hierarchy. 
> For instance “django.core.urlresolvers” doesn’t strike me a superior to 
> “django.urls”. Besides “flat is better than nested”.
> 
> 
> Let me if you have additional arguments in favor of or against this changes. 
> I’ll try to implement them tomorrow or on Monday.
> 
> -- 
> Aymeric.
> 
> 
> 
> On 20 déc. 2013, at 16:37, Aymeric Augustin 
>  wrote:
> 
>> Merge request
>> 
>> I sent a pull request implementing my second goal: 
>> https://github.com/django/django/pull/2089. It allows customizing 
>> application names in the admin.
>> 
>> A handful of core developers were kind enough to oversee my efforts. Their 
>> feedback on the design has been positive. However, as far as I know, that 
>> part of the branch hasn’t received a full review yet. It would be helpful if 
>> someone had the time to read through the commits.
>> 
>> Custom app names are implemented in a single commit that changes four lines 
>> and doesn’t have tests and docs yet. It doesn’t even deal with breadcrumbs. 
>> I’ve included it as a proof-of-concept but I can leave it aside for now if 
>> you find that too cavalier.
>> 
>> What I reallly want to merge is the seventeen previous previous commits. 
>> Their sole purpose is to make the app cache the only piece of code that 
>> knows about the INSTALLED_APPS settings. That’s a 

Re: South data-migration and custom save() method

2013-12-22 Thread Andrew Godwin
It won't load initial_data fixtures - those are being deprecated for
migrated apps - but you could still call loaddata with a custom one, I
guess. I'd personally recommend moving away from fixtures and just
instantiating objects directly using the ORM inside data migrations.

Andrew


On Sat, Dec 21, 2013 at 10:45 PM, Christian Schmitt <
c.schm...@briefdomain.de> wrote:

> I didn't found anything in the docs... So... could I stil load a fixture
> with a migration? Like here:
> http://south.readthedocs.org/en/latest/fixtures.html
>
> Am Freitag, 20. Dezember 2013 17:41:22 UTC+1 schrieb Andrew Godwin:
>>
>> This will also be true for django.db.migrations; there's no way we can
>> serialise save methods as part of the model for later use in migrations. If
>> you want to use complex save logic in migrations, you'll have to copy it
>> into the migration file (which also means the migration will keep working
>> as originally written if you later change what the save method does).
>>
>> Andrew
>>
>>
>> On Fri, Dec 20, 2013 at 4:15 PM, Val Neekman  wrote:
>>
>>> South (latest) has a limitation where it ignores a custom save() method
>>> in the model class.
>>>
>>> I am wondering if that is going to be true for the new South in the core
>>> in Django 1.7?
>>>
>>> Thanks,
>>>
>>> Val
>>>
>>>  --
>>> You received this message because you are subscribed to the Google
>>> Groups "Django developers" 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/CADy_H8ERxnyrzf5UGOTPt1%
>>> 3DUmj46himOBJ3w%2BBrxL49u_E3qyA%40mail.gmail.com.
>>> For more options, visit https://groups.google.com/groups/opt_out.
>>>
>>
>>  --
> You received this message because you are subscribed to the Google Groups
> "Django developers" 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/c219ae48-16fe-4149-91c6-d49fe6cc7a26%40googlegroups.com
> .
>
> For more options, visit https://groups.google.com/groups/opt_out.
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" 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/CAFwN1up%3DO1GReVuo_24%2BwtB_%3DBuJj7sDzdYzh6ThDCQybSaGUg%40mail.gmail.com.
For more options, visit https://groups.google.com/groups/opt_out.


Re: Improving aggregate support (#14030)

2013-12-22 Thread Anssi Kääriäinen
On Saturday, December 21, 2013 3:15:12 AM UTC+2, Josh Smeaton wrote:
>
> I'm interested in tackling 
> ticket#14030, 
> ideally before the Jan 20th cutoff, but I'm looking for some guidance. 
> There have been a lot of references to Anssi Kääriäinen attempting an ORM 
> refactor before trying to fix aggregates, but I'm not sure if this is still 
> a goal or not.
>

Yes, more refactoring is still the plan. A lot has already been done. The 
main part of the work has been bug fixing, code cleanup and join generation 
changes.

The next part is introducing custom lookups for 1.7 (see 
https://github.com/django/django/pull/2019), and later on in 1.8 allow 
usage of custom lookups in every part of the ORM. This means one can do 
queries such as .order_by(' jsonfield__user__firstname'), or more relevant 
to this ticket, .annotate(avg_year=Avg('datefield__year')).

To make the above possible Django's ORM needs to switch to using unified 
query expression API. For example aggregates, custom lookups and Expression 
nodes will all respond to the same API. The API deals mainly with how to 
produce SQL for the expressions, how to convert db values to Python values 
and things like that. As a side effect Avg(F('somefield') + 
F('anotherfield')) should just work.
 

> The work done by nateb at https://github.com/django/django/pull/46 was 
> very similar to the structure I believed would be the right way forward - 
> refactoring Aggregates to inherit from ExpressionNode. Unfortunately, the 
> patch submitted has been closed because it no longer applies cleanly. There 
> was also discussion regarding type coercion and a lack of real world tests 
> that should be considered.
>
> What I'd like to do is attempt to rewrite the above PR so that it applies 
> cleanly. The reviews that had already happened on that patch would then 
> mostly apply to the rewrite, eliminating the need for a start to finish 
> review of the concept in general. Is this something that I should go 
> through with, or are we better off waiting for the ORM refactor then 
> reevaluating the way forward?
>

Making Aggregates inherit from ExpressionNode shouldn't make the unified 
query expression API significantly easier or harder to achieve. If the code 
complexity stays manageable, I don't see a reason to not merge the changes. 
The change will be needed for Avg('somefield')  + Avg('otherfield') support 
even when unified query expression API was implemented.

One of the main problems for this ticket has been the code complexity. Both 
Aggregates and Expressions are somewhat complicated in the ORM. The 
combination of the two results in even worse code complexity. On the other 
hand this feature is clearly needed by many users, so maybe some code 
complexity can be tolerated.

 - Anssi

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" 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/1272168b-84f1-4968-a604-84141c174483%40googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.


Re: Registering signal handlers

2013-12-22 Thread Curtis Maloney
Well, if you were looking to do so in 1.6 for the scores of suffering
developers _now_... what would you do?


On 22 December 2013 19:55, charettes  wrote:

> Since Django 1.7 you can lazily reference model signal sender, it might
> help solving your circular import issues.
>
> It seems providing a reliable initialization signal is one of Aymeric's
> main goal.
>
> Simon
>
> Le dimanche 22 décembre 2013 03:22:29 UTC-5, Curtis Maloney a écrit :
>
>> Reading the posts on App reconfigure reminded me I wanted to raise this
>> for discussion.
>>
>> Recently we've been suffering circular imports, and the majority are,
>> IMHO, caused by people importing "receivers" in the apss __init__.py.
>>
>> By convention [in our app, at least] "receivers.py" registers all the
>> signal receivers.
>>
>> However, as Aymeric points out, puttng code in __init__ is a prime
>> candidate for triggering circular imports.
>>
>> A lot of times we can avoid the problems by breaking the loops with
>> get_model(), however it generally gets applied elsewhere.  We can't always
>> do this in models.py, because often that would require importing other
>> models, and I avoid that as much as possible.
>>
>> So I tried an autodiscover mechanism, just admin, to make it clean, clear
>> and obvious as to when all the receivers were hooked.
>>
>> But...
>>
>> When to run it?
>>
>> If I put it in urls.py, like admin.autodiscover, can I be sure it will be
>> triggered for, say, my celery tasks? Or management commands?  I could put
>> it at the end of settings.py, but that just feels wrong.
>>
>> I'm happy to trace the whole of Django from go to whoa, and decide on a
>> place to put it, but I'd like to hear from the community in general for
>> ideas.
>>
>> --
>> Curtis
>>
>>  --
> You received this message because you are subscribed to the Google Groups
> "Django developers" 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/643a1e10-f4c8-4a90-a96e-17620e7c9843%40googlegroups.com
> .
> For more options, visit https://groups.google.com/groups/opt_out.
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" 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/CAG_XiSATSiajDZSU5JmDdDnGy4QFYBq7nwffU23Kz3nX2vF8%3Dw%40mail.gmail.com.
For more options, visit https://groups.google.com/groups/opt_out.


Re: Registering signal handlers

2013-12-22 Thread charettes
Since Django 1.7 you can lazily reference model signal sender, it might 
help solving your circular import issues.

It seems providing a reliable initialization signal is one of Aymeric's 
main goal.

Simon

Le dimanche 22 décembre 2013 03:22:29 UTC-5, Curtis Maloney a écrit :
>
> Reading the posts on App reconfigure reminded me I wanted to raise this 
> for discussion.
>
> Recently we've been suffering circular imports, and the majority are, 
> IMHO, caused by people importing "receivers" in the apss __init__.py.
>
> By convention [in our app, at least] "receivers.py" registers all the 
> signal receivers.
>
> However, as Aymeric points out, puttng code in __init__ is a prime 
> candidate for triggering circular imports.
>
> A lot of times we can avoid the problems by breaking the loops with 
> get_model(), however it generally gets applied elsewhere.  We can't always 
> do this in models.py, because often that would require importing other 
> models, and I avoid that as much as possible.
>
> So I tried an autodiscover mechanism, just admin, to make it clean, clear 
> and obvious as to when all the receivers were hooked.
>
> But...
>
> When to run it?
>
> If I put it in urls.py, like admin.autodiscover, can I be sure it will be 
> triggered for, say, my celery tasks? Or management commands?  I could put 
> it at the end of settings.py, but that just feels wrong.
>
> I'm happy to trace the whole of Django from go to whoa, and decide on a 
> place to put it, but I'd like to hear from the community in general for 
> ideas.
>
> --
> Curtis
>
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" 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/643a1e10-f4c8-4a90-a96e-17620e7c9843%40googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.


Registering signal handlers

2013-12-22 Thread Curtis Maloney
Reading the posts on App reconfigure reminded me I wanted to raise this for
discussion.

Recently we've been suffering circular imports, and the majority are, IMHO,
caused by people importing "receivers" in the apss __init__.py.

By convention [in our app, at least] "receivers.py" registers all the
signal receivers.

However, as Aymeric points out, puttng code in __init__ is a prime
candidate for triggering circular imports.

A lot of times we can avoid the problems by breaking the loops with
get_model(), however it generally gets applied elsewhere.  We can't always
do this in models.py, because often that would require importing other
models, and I avoid that as much as possible.

So I tried an autodiscover mechanism, just admin, to make it clean, clear
and obvious as to when all the receivers were hooked.

But...

When to run it?

If I put it in urls.py, like admin.autodiscover, can I be sure it will be
triggered for, say, my celery tasks? Or management commands?  I could put
it at the end of settings.py, but that just feels wrong.

I'm happy to trace the whole of Django from go to whoa, and decide on a
place to put it, but I'd like to hear from the community in general for
ideas.

--
Curtis

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" 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/CAG_XiSCUci%3DvZJKjUj6ZbbsFXUb__YGy2phRJtRjUcJJyca2vg%40mail.gmail.com.
For more options, visit https://groups.google.com/groups/opt_out.