Re: Getting user's real IP address in Django

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.

Re: Getting user's real IP address in Django

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

Re: Improving aggregate support (#14030)

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

Re: Getting user's real IP address in Django

*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

Getting user's real IP address in Django

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

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

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

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

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.

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

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

Re: Improving aggregate support (#14030)

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

Re: Registering signal handlers

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. >

Re: Registering signal handlers

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

Registering signal handlers

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