Re: Custom user models in 1.5, not flexible/dry enough?

[Val Neekman]

I have used Django extensively on few "big" projects, yet I consider myself 
a newbie when it comes to Django (core).

As soon as the Class-Based views were released, I read the docs and tried 
to port my "then" ongoing project to the new Classy views.
I have to say that I *agree with Russell* on the learning curve. Way too 
many mixins. Too much options ended up creating a lot of confusions.

However, when I look back, I have come to really appreciate the mixins.

Only if there was a way to make Django work like Google Chrom's 
Preferences; where you'd only see few things that you'd need to worry about 
unless
you click the "under the hood" option. This model would save the newbies 
and allows the experienced room to maneuver while staying DRY.

Both Alex and Russell have valid points, but to further explain my view on 
this I use the following example.
 
Project "A" ONLY needs to swap out the username with an email address. 
That's all. (Django 1.5+ of course)
To spice it up,  few (NEW) custom fields need to be added to the Custom 
User Model. (like Facebook ID, ... etc)

The only thing the developer should need,  is to create a MyUser class that 
inherits from Django's (Whatever)User class.
Then set USERNAME_FIELD = 'email' and add the custom fields and be done 
with it.

(BTW: USERNAME_FIELD should be renamed to something more intuitive. e.g. 
USER_AUTH_UNIQUE_ID_FIELD)

Now that would be easy in a perfect world, but I think it would still be OK 
to expect the developer to inherit one extra mixin class to achieve the 
above.

The admin should work just as before with the above example.

If that is not the case and if the developer is required to copy and paste 
some Django code, modify it, and own it, so he could just bring the basic 
admin functionally back, then my friends, say goodbye to DRY.

Right now I am on Django 1.4 and I own a piece of code that allows me to 
login users with emails. I only use User for authentication and everything 
else is in UserProfile. I wish I didn't have to own a piece of custom code 
so I "just" could  allow login with an email address.

I know lot of other people are doing the same thing and repeating what I 
have done. (!DRY)

I would welcome such a mixin.

Ciao,

Val




On Thursday, 8 November 2012 14:01:24 UTC-5, Alex Ogier wrote:
>
> I agree entirely. The point of mixins is not that they are a particularly 
> healthy abstraction, just that they are one way of exposing the Django 
> permissions system, which is currently only done in full form (that is, 
> with is_active and is_superuser guards) in AbsractUser and User. If you 
> want to use Django permissions with AbstractBaseUser, you have to roll your 
> own, and/or depend on underscore-prefixed functions from 
> contrib.auth.models.
>
> I would be +1 for a solution that exposed those permissions checking 
> functions so that they can be used with less boilerplate. In general I 
> think having an explicit contract for User models in particular contexts is 
> a good thing, better than hiding behind an opaque mixin. That is,
>
> class MyUser(AbstractBaseUser):
> is_active = BooleanField(...)
> is_staff = BooleanField(...)
> @property
> def is_superuser(self):
> return False
> def has_perm(self, perm, obj=None):
> return user_has_perm(self, perm, obj)
> def has_perms(self, perm_list, obj=None):
> return user_has_perms(self, perm_list, obj)
> def has_module_perms(self, package_name)
> return user_has_module_perms(self, package_name)
>
> is arguably preferable to
>
> class MyUser(AbstractBaseUser, PermissionsMixin):
> pass
>
> The advantages of the former is that it is more explicit, and perhaps more 
> newbie friendly, but it is currently impossible to do without duplicating 
> logic since user_has_perm etc. don't exist. The advantage of the latter is 
> that it involves considerably less boilerplate, but it freezes is_superuser 
> and is_staff as boolean fields on the ORM (though this could be removed 
> from the mixin if people prefer implementing these themselves as Florian 
> suggested).
>
> The point isn't to go mixin-crazy, it's to find the best way to expose 
> permissions-checking (the most boilerplate-heavy of the requirements of an 
> admin-compatible user). The other contracts are probably better exposed as 
> tests in contrib.admin than as little piece-wise mixins.
>
> Best,
> Alex Ogier
>
>
>
> On Thu, Nov 8, 2012 at 7:12 AM, Russell Keith-Magee <
> rus...@keith-magee.com > wrote:
>
>>
>> Ok - so, I've been following this thread, and I should probably shed some 
>> light on the other side of the decision making process.
>>
>> I've got a history with Mixins. I was responsible for the final commit of 
>> Django's class-based views, which are very mixin heavy… and haven't been 
>> universally well received.
>>
>> There was a lot of very incoherent "this sucks" criticism (which -- as an 

Re: Custom user models in 1.5, not flexible/dry enough?

[Val Neekman]

OK, I went back and looked at Django 1.5 again. (New Custom User Model)

Here is what I think: (User Django 1.4 as base) 

1. Rename username to userid and increase the length to 255 chars while 
keeping the rest of attribute the same (e.g db_index ...etc)
2. Remove first_name, last_name and full_name (or not)
3. Have __unicode__ return the userid by default
4. Leave everything else alone (Permissions, Auth, Groups ... etc)

Developers would: (optional)

inherit: MyCustomUser(User):
set: AUTH_USER_MODEL = 'myApp.MyCustomUser'
set: Primary Key to UUID (optional)
use: userid field for storing emails, account numbers, or a username, or 
anything else if they wish so long it's unique
add: other fields as they wish
overwrite: __unicode__ that prints whatever they want (name, id, etc.) or 
just leave it alone
let: the developers decide if first name, last name is what they want, if 
prefix is required ... etc.
just: provider the auth,permission,group functionality and everything else 
is up to the developer

same goes for UserForms, UserAdmin ... Django provides the basic and 
developers customize and enhance if they wish
No need for UserProfile anymore of course.

Am I over simplifying thing?
This break backward compatibility? Is it already broken by removing 
UserProfile anyways?

It would be really nice for Django User to just do Auth, Permissions and 
Groups and stay out of the developer's way.

One thing I know for sure is that making User customizable is definitely 
going in the right direction.

Val







 


On Tuesday, 20 November 2012 16:37:17 UTC-5, Val Neekman wrote:
>
> I have used Django extensively on few "big" projects, yet I consider 
> myself a newbie when it comes to Django (core).
>
> As soon as the Class-Based views were released, I read the docs and tried 
> to port my "then" ongoing project to the new Classy views.
> I have to say that I *agree with Russell* on the learning curve. Way too 
> many mixins. Too much options ended up creating a lot of confusions.
>
> However, when I look back, I have come to really appreciate the mixins.
>
> Only if there was a way to make Django work like Google Chrom's 
> Preferences; where you'd only see few things that you'd need to worry about 
> unless
> you click the "under the hood" option. This model would save the newbies 
> and allows the experienced room to maneuver while staying DRY.
>
> Both Alex and Russell have valid points, but to further explain my view on 
> this I use the following example.
>  
> Project "A" ONLY needs to swap out the username with an email address. 
> That's all. (Django 1.5+ of course)
> To spice it up,  few (NEW) custom fields need to be added to the Custom 
> User Model. (like Facebook ID, ... etc)
>
> The only thing the developer should need,  is to create a MyUser class 
> that inherits from Django's (Whatever)User class.
> Then set USERNAME_FIELD = 'email' and add the custom fields and be done 
> with it.
>
> (BTW: USERNAME_FIELD should be renamed to something more intuitive. e.g. 
> USER_AUTH_UNIQUE_ID_FIELD)
>
> Now that would be easy in a perfect world, but I think it would still be 
> OK to expect the developer to inherit one extra mixin class to achieve the 
> above.
>
> The admin should work just as before with the above example.
>
> If that is not the case and if the developer is required to copy and paste 
> some Django code, modify it, and own it, so he could just bring the basic 
> admin functionally back, then my friends, say goodbye to DRY.
>
> Right now I am on Django 1.4 and I own a piece of code that allows me to 
> login users with emails. I only use User for authentication and everything 
> else is in UserProfile. I wish I didn't have to own a piece of custom code 
> so I "just" could  allow login with an email address.
>
> I know lot of other people are doing the same thing and repeating what I 
> have done. (!DRY)
>
> I would welcome such a mixin.
>
> Ciao,
>
> Val
>
>
>
>
> On Thursday, 8 November 2012 14:01:24 UTC-5, Alex Ogier wrote:
>>
>> I agree entirely. The point of mixins is not that they are a particularly 
>> healthy abstraction, just that they are one way of exposing the Django 
>> permissions system, which is currently only done in full form (that is, 
>> with is_active and is_superuser guards) in AbsractUser and User. If you 
>> want to use Django permissions with AbstractBaseUser, you have to roll your 
>> own, and/or depend on underscore-prefixed functions from 
>> contrib.auth.models.
>>
>> I would be +1 for a solution that exposed those permissions checking 
>> functions so that they can be used with less boilerplate. In g

Re: Why is GeoDjango in core ?

[Val Neekman]

Yeah, it's amazing that we have GeoDjango included as I'm using it right now. 

However I can fall back to geopy and still getaway with rough acceptable 
estimates with limited scope and capability which I'm fine with. (In my use 
case)

If I had to choose between GeoDjango and South as a core package, I'd go with 
South for sure. 

GeoDjango might be for the 10% while South can  be for the 90%. 

Admin is a must for the beginners. And if we want to attract more people to use 
Django, then admin is the tool right out of the box. 

 I wish there was a way to have the core developers in charge of the core 
packages, the vision and the direction. 

They would also be in charge of blessing the contrib packages that are not a 
MUST. (contrib.auth is a must)

Then we could have a secondary team that takes care of the packages that fall 
In the same category as GeoDjango. 

It would be a nice divide and conquer strategy and both teams can help 
maintaining the "sync" state. 

pip install Django
pip install Django-contrib

Just a wild thought. :)

Val
Sent from my mobile device. 

On 2013-02-06, at 2:33 PM, Jacob Kaplan-Moss  wrote:

> The only historically-accurate answer is: "because it seemed like a
> good idea at the time."
> 
> Remember, this was 2008. So one problem was that Django's DB APIs
> weren't very polished, so GeoDjango had to do a bunch of trickery.
> Bringing it into core gave a good way towards pushing that flexibility
> down into the DB layer. Further, Python packaging was in a sorry
> state; keeping a version of GeoDjango installed and in sync with a
> version of Django wasn't exactly easy (the tight coupling between
> GeoDjango and Django means that you really need to versions to match
> up.) Finally, GeoDjango was an incredibly powerful addition to Django,
> something that wasn't available in any other web framework. Having it
> available out of the box really set us ahead of all other tools, at
> least in the GIS space.
> 
> How much of this is still true is left as an exercise to the reader.
> 
> Jacob
> 
> PS: I'm not exactly sure what you mean by the admin being a candidate
> for removal. I don't think anyone's suggesting that, at least not
> seriously.
> 
> On Wed, Feb 6, 2013 at 1:20 PM, Maxime Haineault  wrote:
>> I've seen lot of talk about removing the admin and many other contribs from
>> core.
>> 
>> For some I think it make sense, for others like the admin I'm not so sure.
>> 
>> However, I have not seen any talk about removing GeoDjango and I'm wondering
>> about the
>> rational of keeping this relatively huge domain specific codebase in django.
>> 
>> In the last five years i worked on at least 150 django projects, every
>> single one of them used
>> the admin and only one required GeoDjango.
>> 
>> I'm not advocating that it should be removed, but I can't help but wonder
>> why the admin would
>> be a good candidate for removal and not GeoDjango.
>> 
>> Regards
>> 
>> --
>> 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?hl=en.
>> 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?hl=en.
> 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?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.

Re: Proposal: deprecate and remove django.contrib.comments

[Val Neekman]

Yep. +1


Val
Sent from my mobile device. 

On 2013-03-07, at 11:48 AM, Jacob Kaplan-Moss  wrote:

> Hi folks --
> 
> This one's simple: I'd like to deprecate `django.contrib.comments`,
> scheduling it to be removed in a couple of releases.
> 
> My rationale is this: if you don't really care much about how comments
> work but just want something easy, then Disqus (and its competitors)
> are easier to use and have much better features (spam prevents,
> moderation, etc.). If you want something complex and specific, on the
> other hand, you're better off writing something from scratch.
> 
> Practically, I'd do this by deprecating `django.contrib.comments` in
> 1.6. We'd immediately stop making any changes to it (except for
> security or data loss issues). It'd stay deprecated in 1.7, and would
> be removed in 1.8.
> 
> If someone volunteers to maintain it as an external project I'll move
> the code to a new repo and direct people there in the docs. If nobody
> volunteers, then it'll go to the great /dev/null in the sky.
> 
> Any objections?
> 
> Jacob
> 
> -- 
> 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?hl=en.
> 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?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.

Re: Changes to django's settings module

[Val Neekman]

Yeah, split by role is what I have done.

settings/default.py (absolute necessities)
settings/deploy.py (inherits default.py & adds production specifics)
settings/debug.py (inherits deploy.py & overwrites debug stuff)
settings/test.py (inherits deploy.py & overwrites test specific)
settings/external.py (holds aws, google, and other social keys)

The above is coupled with:

bin/debug.py (= manage.py on development server)
bin/deploy.py (= manage.py on production server)
bin/test.py (= manage.py on integration server)

This has been working very well for me.

No loose files, everything has a directory to live in.
Very easy to manage.

Val


On Wed, Mar 13, 2013 at 9:32 PM, Russell Keith-Magee
 wrote:
>
> On Thu, Mar 14, 2013 at 1:08 AM, Alex Ogier  wrote:
>>
>> I find the value of separate settings modules is not splitting them by
>> topic, but overriding them in specific contexts, like staging, production
>> and development. Your implementation (and, I think, any solution that
>> compiles multiple settings modules independently) don't have a way to
>> specify orderings in a non-magical way. That's why I prefer explicitly
>> importing some common settings into one module and overriding them
>> piecemeal. The Zen of Python says "Explicit is better than implicit" and I
>> think that is the case here. Packages provide settings and reasonable
>> defaults. If you want to modularize them, you are free to do so yourself. I
>> think composing settings internally is just added complexity for little
>> benefit.
>
>
> I agree with Alex.
>
> Splitting settings files in the way you've described in your patch doesn't
> strike me as something that solves a problem that actually exists in
> practice. Settings files aren't *that* long, and to the extent that splits
> are needed, they're based on roles, not content -- you need "production"
> settings, not "template" settings.
>
> Even if you did want to break out settings into multiple files, a master
> file with "from template_settings import *" strikes me as a lot better
> approach than a settings gathering process -- and that requires no extra
> code in Django.
>
> 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?hl=en.
> 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?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.

Re: Changes to django's settings module

[Val Neekman]

Yeah, settings is more about the environments than the framework.
There is not a single solutions that can make everyone happy. I'd say
whatever works for you is the best solution for you.

With that said, I also agree that a few good examples would be very
beneficial to people new to Django.

Val





On Thu, Mar 14, 2013 at 10:43 AM, Alex Ogier  wrote:
> I think the important point is that all of these techniques for constructing
> settings are done without the help of Django (and in fact *should* be done
> without the help of Django, because some parts of Django expect to import a
> settings module that isn't under construction). I don't know if there is a
> good way to document these practices -- it's not an easily searchable topic,
> and more than a single settings.py is just added confusion for little
> benefit until you need to care about deploying to multiple contexts (it's
> not good tutorial material). Maybe somewhere in the how-tos on deployment we
> could write up some good practices for managing settings in multiple
> contexts -- that would be more welcome than code in Django core, I think.
> Midterms end today for me, so maybe I will try writing up some of the
> practices that make managing settings easier for me later tonight.
>
> Best,
> Alex Ogier
>
>
> On Thu, Mar 14, 2013 at 9:16 AM, Val Neekman  wrote:
>>
>> Yeah, split by role is what I have done.
>>
>> settings/default.py (absolute necessities)
>> settings/deploy.py (inherits default.py & adds production specifics)
>> settings/debug.py (inherits deploy.py & overwrites debug stuff)
>> settings/test.py (inherits deploy.py & overwrites test specific)
>> settings/external.py (holds aws, google, and other social keys)
>>
>> The above is coupled with:
>>
>> bin/debug.py (= manage.py on development server)
>> bin/deploy.py (= manage.py on production server)
>> bin/test.py (= manage.py on integration server)
>>
>> This has been working very well for me.
>>
>> No loose files, everything has a directory to live in.
>> Very easy to manage.
>>
>> Val
>>
>>
>> On Wed, Mar 13, 2013 at 9:32 PM, Russell Keith-Magee
>>  wrote:
>> >
>> > On Thu, Mar 14, 2013 at 1:08 AM, Alex Ogier 
>> > wrote:
>> >>
>> >> I find the value of separate settings modules is not splitting them by
>> >> topic, but overriding them in specific contexts, like staging,
>> >> production
>> >> and development. Your implementation (and, I think, any solution that
>> >> compiles multiple settings modules independently) don't have a way to
>> >> specify orderings in a non-magical way. That's why I prefer explicitly
>> >> importing some common settings into one module and overriding them
>> >> piecemeal. The Zen of Python says "Explicit is better than implicit"
>> >> and I
>> >> think that is the case here. Packages provide settings and reasonable
>> >> defaults. If you want to modularize them, you are free to do so
>> >> yourself. I
>> >> think composing settings internally is just added complexity for little
>> >> benefit.
>> >
>> >
>> > I agree with Alex.
>> >
>> > Splitting settings files in the way you've described in your patch
>> > doesn't
>> > strike me as something that solves a problem that actually exists in
>> > practice. Settings files aren't *that* long, and to the extent that
>> > splits
>> > are needed, they're based on roles, not content -- you need "production"
>> > settings, not "template" settings.
>> >
>> > Even if you did want to break out settings into multiple files, a master
>> > file with "from template_settings import *" strikes me as a lot better
>> > approach than a settings gathering process -- and that requires no extra
>> > code in Django.
>> >
>> > 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?hl=en.
>> > For more options, visit https://groups.google.c

GeoDjango and __within query when IDL is involved

[Val Neekman]

If you build a geom with a bounding box that contains IDL (International Date 
Line) and run a point__within query on it, then the result is unpredictable and 
incorrect. 

Does anyone know of a native GeoDjango solution to this?

If not, would there be a lot of resistance against a patch that incorporates 
this functionality in GeoDjango?


Val
Sent from my mobile device. 

On 2013-03-17, at 12:39 AM, Omer Katz  wrote:

> Well, I was wrong. It took me exactly 5 minutes to get the basics of 
> django-configurations right: https://gist.github.com/thedrow/5180120
> This gist loads settings from a class instead of a module and shows how to 
> load the settings from a module and override them by using a class.
> All tests run correctly.
> Are you guys still not convinced?
> 
> 
> 2013/3/16 Omer Katz 
>> Shai,
>> The google groups editor is kinda annoying. I'll be using GMail from now on 
>> because it removes formatting on random basis (I don't really know why)
>> 
>> Also, I can rewrite django-configuartion in a couple of hours using the 
>> changes in this patch. Heck, I'll even make a pull request out of it.
>> 
>> Aymeric,
>> I can revert this patch to be a refactoring if we decide that we don't see 
>> any value in the extensibility part of this patch.
>> I hope we all agree that this patch does make the code much clearer and 
>> understandable.
>> 
>> I'll get back to you guys when I'll have more progress.
>> 
>> 
>> 2013/3/15 Aymeric Augustin 
>>> On 15 mars 2013, at 09:22, Omer Katz  wrote:
>>> 
>>> > Doesn't the fact that the patch makes the code clearer is a reason enough 
>>> > for a merge (providing that there will be tests attached to it and 
>>> > documentation)?
>>> 
>>> 
>>> Hi Omer,
>>> 
>>> This patch isn't only a refactoring; it adds a new feature. Otherwise you 
>>> wouldn't be talking about documentation.
>>> 
>>> Each feature added to Django creates a burden:
>>> - for users of Django, who must learn to use it;
>>> - for the core team, who must maintain it for the foreseeable future.
>>> 
>>> To be accepted, a new feature must:
>>> (a) provide benefits that clearly outweigh these costs
>>> (b) not get in the way of future improvements — as much as can be foreseen.
>>> 
>>> Unfortunately (a) the benefits of your PR still aren't clear and (b) 
>>> judging by the discussion, your abstraction doesn't match very well the 
>>> needs of most users, and I suspect it could hinder further efforts to make 
>>> per-environment settings (the actual problem) easier to define.
>>> 
>>> --
>>> Aymeric.
>>> 
>>> --
>>> You received this message because you are subscribed to a topic in the 
>>> Google Groups "Django developers" group.
>>> To unsubscribe from this topic, visit 
>>> https://groups.google.com/d/topic/django-developers/1M5nfnpba0M/unsubscribe?hl=en.
>>> To unsubscribe from this group and all its topics, 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?hl=en.
>>> 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?hl=en.
> 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?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.

Re: GeoDjango and __within query when IDL is involved

[Val Neekman]

I must have hit reply on my iPhone instead of new email. 
Not meant to be a response to your email. 
Sorry about the confusion. 

Sent from my iPad

On Mar 18, 2013, at 5:40 AM, Omer Katz  wrote:

> Sorry, how is this related?
> 
> בתאריך יום ראשון, 17 במרץ 2013 19:34:53 UTC+3, מאת Val Neekman:
>> 
>> If you build a geom with a bounding box that contains IDL (International 
>> Date Line) and run a point__within query on it, then the result is 
>> unpredictable and incorrect. 
>> 
>> Does anyone know of a native GeoDjango solution to this?
>> 
>> If not, would there be a lot of resistance against a patch that incorporates 
>> this functionality in GeoDjango?
>> 
>> 
>> Val
>> Sent from my mobile device. 
>> 
>> On 2013-03-17, at 12:39 AM, Omer Katz  wrote:
>> 
>>> Well, I was wrong. It took me exactly 5 minutes to get the basics of 
>>> django-configurations right: https://gist.github.com/thedrow/5180120
>>> This gist loads settings from a class instead of a module and shows how to 
>>> load the settings from a module and override them by using a class.
>>> All tests run correctly.
>>> Are you guys still not convinced?
>>> 
>>> 
>>> 2013/3/16 Omer Katz 
>>>> Shai,
>>>> The google groups editor is kinda annoying. I'll be using GMail from now 
>>>> on because it removes formatting on random basis (I don't really know why)
>>>> 
>>>> Also, I can rewrite django-configuartion in a couple of hours using the 
>>>> changes in this patch. Heck, I'll even make a pull request out of it.
>>>> 
>>>> Aymeric,
>>>> I can revert this patch to be a refactoring if we decide that we don't see 
>>>> any value in the extensibility part of this patch.
>>>> I hope we all agree that this patch does make the code much clearer and 
>>>> understandable.
>>>> 
>>>> I'll get back to you guys when I'll have more progress.
>>>> 
>>>> 
>>>> 2013/3/15 Aymeric Augustin 
>>>>> On 15 mars 2013, at 09:22, Omer Katz  wrote:
>>>>> 
>>>>> > Doesn't the fact that the patch makes the code clearer is a reason 
>>>>> > enough for a merge (providing that there will be tests attached to it 
>>>>> > and documentation)?
>>>>> 
>>>>> 
>>>>> Hi Omer,
>>>>> 
>>>>> This patch isn't only a refactoring; it adds a new feature. Otherwise you 
>>>>> wouldn't be talking about documentation.
>>>>> 
>>>>> Each feature added to Django creates a burden:
>>>>> - for users of Django, who must learn to use it;
>>>>> - for the core team, who must maintain it for the foreseeable future.
>>>>> 
>>>>> To be accepted, a new feature must:
>>>>> (a) provide benefits that clearly outweigh these costs
>>>>> (b) not get in the way of future improvements — as much as can be 
>>>>> foreseen.
>>>>> 
>>>>> Unfortunately (a) the benefits of your PR still aren't clear and (b) 
>>>>> judging by the discussion, your abstraction doesn't match very well the 
>>>>> needs of most users, and I suspect it could hinder further efforts to 
>>>>> make per-environment settings (the actual problem) easier to define.
>>>>> 
>>>>> --
>>>>> Aymeric.
>>>>> 
>>>>> --
>>>>> You received this message because you are subscribed to a topic in the 
>>>>> Google Groups "Django developers" group.
>>>>> To unsubscribe from this topic, visit 
>>>>> https://groups.google.com/d/topic/django-developers/1M5nfnpba0M/unsubscribe?hl=en.
>>>>> To unsubscribe from this group and all its topics, 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?hl=en.
>>>>> 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...

GeoDjango International Date Line (IDL) handling

[Val Neekman]

My previous email got messed up (ended up in a different thread), so I
am sending again.

--

If you build a geom with a bounding box that contains IDL
(International Date Line) and run a point__within query on it, then
the result is unpredictable and incorrect.

Does anyone know of a native GeoDjango solution to this?

If not, should I create a patch that incorporates this functionality
in GeoDjango?
Or handling of IDL in the above case would be considered not within
the scope of the framework?

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?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.

Re: Goodbye, Malcolm

[Val Neekman]

Met him for the first time in DjangoCon 2012. What a down to earth guy. 

He'll be missed. 

Val
Sent from my mobile device. 

On 2013-03-19, at 3:25 PM, Leon Matthews  wrote:

> On 20 March 2013 06:01, Jacob Kaplan-Moss  wrote:
>> We have difficult news: Malcolm Tredinnick has passed away.
> 
> What a shock.  Malcolm was a great guy, and a huge asset to our
> community.  I had the pleasure of hearing him talk in Wellington.
> 
> He will be missed...
> 
> -- 
> 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?hl=en.
> 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?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.

Re: New additions to django.contrib?

[Val Neekman]

Awesome news indeed. Thx

On Fri, Mar 22, 2013 at 12:58 PM, Mateusz Harasymczuk
 wrote:
> About your topic on adding South to Django core.
> Andrew is working on that:
> https://www.djangoproject.com/weblog/2013/mar/22/kickstarting-schema-migrations-django/
>
> --
> 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?hl=en.
> 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?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.

Re: URL dispatcher fallthrough?

[Val Neekman]

+1 here!

It might also be a great feature to run the 404 through before sending
that email out.
A replacement and/or complement to IGNORABLE_404_URLS

Val


On Tue, Mar 26, 2013 at 1:25 PM, Loic Bistuer  wrote:
> +1 for me.
>
> Having a catchall view under a single URL pattern is a tightly coupled
> system, more so than allowing independent views to "test the water".
>
> Django core relies on middleware hacks because the URL dispatcher is missing
> this very feature. Having this in core would allow a cleaner implementation
> of the fallback mechanisms in contrib.flatpages and contrib.redirects.
>
> --
> Loic
>
> On Mar 19, 2013, at 11:18 PM, Adrian Holovaty  wrote:
>
> I'd rather not add this to the framework, as it's already possible
> with a "wrapper" view (as others have suggested). And on a more
> theoretical level, it introduces more coupling between URL patterns
> and views.
>
>
> --
> 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?hl=en.
> 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?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.

Re: Kickstarter for Django Admin?

[Val Neekman]

The beauty of kickstarter is that people speak with their wallets. If a
project doesn't have a merit, then no one would pitch in and that would be
the end of the project.

Django admin is a great tool. In my projects I use it for quick view and
edits so I don't have to fallback to command line or SQL. Mind you, that I
have put extensive checks and validation around it to ensure I don't have a
booboo.

I think a nicer admin (more modern and feature rich) would encourage
newcomers to pick up Django as their main framework and
that in-turn injects fresh blood into the community.

Imagine a Django-Admin that could turn Django into a replacement
of Wordpress in 5 minutes? (not a perfect example, but you get what I mean)

Can't wait for "new" South  ...

Val








On Wed, Apr 3, 2013 at 10:35 AM, Felipe Prenholato wrote:

> I have a point about kickstarter powered projects. Anyone can send one,
> but in my opinion only projects extensively discussed here with a complete
> roadmap can have success. Actually I think that it also should have
> mentors, like GSOC, while aproved by community via money.
>
> Also, Andrew proposal is something that will impact (for good) on life of
> every Django developer. Every Django developer with even very small
> projects use South today. About admin, my self as superuser of my projects
> don't use it very much, and never used any re-skin.
>
> Of course I'm +1 to improvements on admin, but I'm sure that we have
> points where we can improve much more with help of kickstarter, as example
> improvements on ORM, NoSQL databases integration, Form Templates (
> https://code.djangoproject.com/wiki/SummerOfCode2012#FinishingoffFormTemplates
> ).
>
> It isn't in any way criticism to your idea Victor, but I fear that
> everyone want to start your own project to Django in that kickstarter model.
>
> Bests,
>
> Felipe 'chronos' Prenholato.
> Linux User nº 405489
> Home page: http://devwithpassion.com | http://chronosbox.org/blog
> GitHub: http://github.com/chronossc/ | Twitter:
> http://twitter.com/chronossc
>
>
> 2013/4/1 Amirouche Boubekki 
>
>>  For the former - I believe there was already discussions on that sort
 of thing on this board?

 There's a wiki page with some notes as well:

 https://code.djangoproject.com/wiki/AdminNext

>>>
>>> There's a world of difference between "some notes" and "a clear plan and
>>> direction" :-)
>>>
>>
>> Hopefully 2013.djangocon.eu Idan's 
>> talkwill clear things up.
>>
>> --
>> 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?hl=en.
>> 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?hl=en
> .
> 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?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.

Re: Ticket 20147 - deprecate and replace request.META

[Val Neekman]

+1 for leaving META alone. 


On Apr 8, 2013, at 7:45 PM, Russell Keith-Magee  wrote:

> 
> On Tue, Apr 9, 2013 at 5:13 AM, Carl Meyer  wrote:
>> Hi Luke,
>> 
>> On 04/08/2013 02:02 PM, Luke Plant wrote:
>> > This is already the subject of a ticket, but I didn't get a response
>> > yet. Basically, the idea is replace things like:
>> >
>> >   request.META['HTTP_ACCEPT']
>> >
>> > with
>> >
>> >   request.HEADERS['Accept']
>> >
>> > request.META should be deprecated and replaced with request._META,
>> > because it is just an implementation detail, and a really bizarre one at
>> > that, full of cruft from a previous generation of web applications (CGI)
>> > that should not be exposed in our API.
>> 
>> I have no problem with providing a nicer API for getting at request
>> headers that allows asking for un-mangled header names, but I don't
>> think we should deprecate request.META (or turn it into a private
>> implementation detail).
>> 
>> Although the concept of a unified "request environ" that includes HTTP
>> headers mashed together with various other environment and web server
>> info may date back to CGI, it is not outdated; in fact it is a part of
>> the WSGI specification too:
>> http://www.python.org/dev/peps/pep-/#environ-variables
>> 
>> I think the WSGI environ should always remain accessible through public
>> API on a Django request object.
>> 
>> > Anything else needed from META should also be replaced with a sensible API.
>> 
>> I'm not sure how you envision this happening, since there is no fixed
>> set of things that might be "needed from META" that we can provide
>> purpose-specific API for. It is a legitimate use of WSGI for people to
>> set arbitrary environ variables from their WSGI server and expect to be
>> able to read those variables from Django, and they shouldn't have to use
>> private API to do this.
> 
> I agree with Carl. I like the idea of the new HEADERS that is simpler to 
> access, but I think removing/renaming META isn't desirable. 
> 
> HEADERS will be introducing a layer of smarts, and as helpful as those smarts 
> will be under 95% of circumstances, I'd be willing to bet that *someone* has 
> a use case for getting at the raw headers. 
> 
> On top of that, there's plenty of code out there that is currently using META 
> without any problems -- the issue is with new users understanding which META 
> key to use, not with the key working correctly once it's been discovered. 
> We're not closing a security hole, or making new functionality possible -- 
> we're just making some code a little easier to read. Forcing all that code to 
> be updated to use HEADERS strikes me as code churn.
> 
> I'd much rather see META continue as a publicly available, but generally 
> discouraged API, rather than formally deprecating it.
> 
>> > This might seem to be a big change simply for the sake of a clean API,
>> > but I'm more and more motivated by these thoughts:
>> >
>> > * Web development is hard enough as it is. "Explain this to a newbie
>> > without getting embarrassed" is a good test.
>> 
>> Sure; if we introduce a new API for getting at HTTP headers sans
>> name-mangling, I think it'd be fine to consider request.META "advanced
>> API" and adjust the documentation accordingly to make it much less
>> prominent.
>> 
>> > There is also the advantage of a *much* cleaner repr(request),
>> > especially in a development environment, because you don't have all the
>> > other junk from os.environ.
>> 
>> If we are trying to make repr(request) really be a full reproduction of
>> all relevant request data (such that the request instance could be fully
>> reconstructed from it) then I don't think this goal is achievable; it is
>> not an option (IMO) to remove WSGI environ data from the request
>> entirely, because this would make data that is part of the WSGI spec
>> inaccessible to Django users.
>> 
>> (I haven't checked whether the current repr(request) meets the
>> full-reconstruction criteria; if it already doesn't then I don't really
>> care what we show in it, we could trim it down further with or without
>> your proposed change.)
>> 
>> > The biggest problem is what to do with our test Client and
>> > RequestFactory, which allow specifying headers as keyword arguments
>> > using the CGI style of naming e.g.:
>> >
>> >   self.client.get('/path', HTTP_X_REQUESTED_WITH='XMLHttpRequest')
>> >
>> > Since keyword arguments can't have "-" in them, this is harder to
>> > replace. We could either leave it as it is, or add a new 'headers'
>> > keyword argument to these methods, deprecating **extra.
>> 
>> Similar to above, I think we could add a new "headers" arg for
>> friendlier specification of HTTP headers, but I don't think we should
>> deprecate **extra. (This of course would mean we have to decide and
>> document which takes precedence if they conflict.)
>>  
>> > The silliness has infected other places, like SECURE_PROXY_SSL_HEADER
>> > which follows the same CGI convention (and in each c

Ability to save 4xx messages to database

[Val Neekman]

I am wondering if it would be a good idea to save a copy of *404s* in
database instead of sending the email out to the ADMIN.

The reason is, while I see a notification of some sort beneficial, with
sites that items are added and deleted on a regular basis, all those 404
messages (emails) can be costly and annoying at times. Not knowing about
your missing links is not ideal either.

An App that keeps a copy of all the 404s and admin can indicate to receive
a single notification per (day/week or # new 404s) would be great.

*Sentry* is great for 5xx logs, but I am looking to have a built-in feature
in Django for 404s.

I often get a russian bot that tries lot of specific links, while another
bot (spammer) tries different links so they can exploit the site.

With current setup (email to ADMIN), I get 10-20 emails for a single bot
scanning the site.
I can't afford not notifying myself of the 404s either, but I don't want to
see all those bogus 404s to generate emails. IGNORABLE_404_URLS is used now
and it has its limits.

Of course I can role out my own app for this, but I think it would
be beneficial to the community if Django did this out of the box.

Now, the $64 K question: is Django a good place for this?

Appreciate your feedback.

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?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.

Custom Users + Signals (reusable app)

[Val Neekman]

Folks,

I am to release an app as a reusable app. However, the app makes the use of
post_save signals raised by the User model and there is a problem.

With the limitation of a Custom User + Signals in mind, I cannot really
call it a "true" reusable app, if it doesn't work for setups that have
rolled out their own custom users.

I wonder if anyone has come across the same issue when releasing a "true"
reusable app?

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_H8Hvu09%2BGTpRDjE8NCMPfmPeoADchQZ5JMZ9v5YmD5nbvQ%40mail.gmail.com.
For more options, visit https://groups.google.com/groups/opt_out.

South data-migration and custom save() method

[Val Neekman]

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-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_H8ERxnyrzf5UGOTPt1%3DUmj46himOBJ3w%2BBrxL49u_E3qyA%40mail.gmail.com.
For more options, visit https://groups.google.com/groups/opt_out.

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

[Val Neekman]

Yep, this is what I currently do and I was just hoping for a cleaner
solution in 1.7. That's all.
Thanks for django.db.migrations Andrew.

Val





On Fri, Dec 20, 2013 at 11:41 AM, Andrew Godwin  wrote:

> 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-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_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/CAFwN1ura0utpBXaQ9armeYwRRbM6eCQYWiMecYuUpMCj94DuCg%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_H8Gx2sydztS9HojAZJbgRHEQHiOopwnbsG77tCb5%2BZEc0g%40mail.gmail.com.
For more options, visit https://groups.google.com/groups/opt_out.

Getting user's real IP address in Django

[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: Getting user's real IP address in Django

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

Re: Getting user's real IP address in Django

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

Django 1.7 - Named migration directory

[Val Neekman]

I am wondering if it would be a good idea for a django app to name its
migration directory and if nothing is provided then the name would default
to 'migrations'.

The case: (let's call it a GEO app)

GEO app looks at the setting.py file for a flag called
"GEO_USING_GEO_DJANGO".

# in models.py

if settings.GEO_USING_GEO_DJANGO:
from django.contrib.gis.db import models
from django.contrib.gis.geos import Point
else:
from django.db import models

class Location(models.Model):

if settings.GEO_USING_GEO_DJANGO:
point = models.PointField(_('Point'), default='POINT(0.0 0.0)')
else:
# lat/lng of location
lat = models.FloatField(_('Latitude'), default=0.0)
lng = models.FloatField(_('Longitude'), default=0.0)

objects = models.GeoManager() if settings.GEO_USING_GEO_DJANGO else
models.Manager()

The above may not be the best practice here, but it works really well for
people who don't want to install PostGIS and all the required software. All
they have to do is to set GEO_USING_GEO_DJANGO = False and use geopy for
lat/lng calculation.

This is to support both geoDjango and non-geoDjango users, and from the
same source code.

Now, all works great till the first *migration*. Then game is over and the
maintainer has to either stick with the geoDjango or the non-geoDjango
version as far as the migration goes.

*Only if the app could set its own migration directory!*

in settings.py
-
If GEO_USING_GEO_DJANGO:
   GEO_MIGRATION_DIR_NAME = 'migrations_geo'

The maintainer of the app would set GEO_USING_GEO_DJANGO=True and run
 schemamigration, then set GEO_USING_GEO_DJANGO=False and rerun the
schemamigration again. We'd end up with two distinct migration directories.

The end users just have to set GEO_USING_GEO_DJANGO=True/False.

I know this is not an ideal solution, but if avoiding duplicate versions of
the same application was the final goal, this would achieve it.

This would complicate things for sure, but is there an easier way to avoid
the duplicate source code?

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_H8ESPLR24Y7tD6xNxSS-%2BkT%3Dwc2a-60boN%3DAZ5Aphms3KA%40mail.gmail.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: Django 1.7 - Named migration directory

[Val Neekman]

How did I miss that. Excellent!

Thanks.

Val



On Mon, Dec 23, 2013 at 7:08 PM, Andrew Godwin  wrote:

> There's already a setting for changing an app's migrations directory,
> called MIGRATION_MODULES. The app can just instruct people who want to not
> use PostGIS to set that to a different place if they want to ship the app
> like that, achieving exactly the result you want without an extra setting
> per app :)
>
> Andrew
>
>
> On Mon, Dec 23, 2013 at 11:57 PM, Val Neekman  wrote:
>
>> I am wondering if it would be a good idea for a django app to name its
>> migration directory and if nothing is provided then the name would default
>> to 'migrations'.
>>
>> The case: (let's call it a GEO app)
>>
>> GEO app looks at the setting.py file for a flag called
>> "GEO_USING_GEO_DJANGO".
>>
>> # in models.py
>>
>> if settings.GEO_USING_GEO_DJANGO:
>> from django.contrib.gis.db import models
>> from django.contrib.gis.geos import Point
>> else:
>> from django.db import models
>>
>> class Location(models.Model):
>>
>> if settings.GEO_USING_GEO_DJANGO:
>> point = models.PointField(_('Point'), default='POINT(0.0 0.0)')
>> else:
>> # lat/lng of location
>> lat = models.FloatField(_('Latitude'), default=0.0)
>> lng = models.FloatField(_('Longitude'), default=0.0)
>>
>> objects = models.GeoManager() if settings.GEO_USING_GEO_DJANGO else
>> models.Manager()
>>
>> The above may not be the best practice here, but it works really well for
>> people who don't want to install PostGIS and all the required software. All
>> they have to do is to set GEO_USING_GEO_DJANGO = False and use geopy for
>> lat/lng calculation.
>>
>> This is to support both geoDjango and non-geoDjango users, and from the
>> same source code.
>>
>> Now, all works great till the first *migration*. Then game is over and
>> the maintainer has to either stick with the geoDjango or the non-geoDjango
>> version as far as the migration goes.
>>
>> *Only if the app could set its own migration directory!*
>>
>> in settings.py
>> -
>> If GEO_USING_GEO_DJANGO:
>>GEO_MIGRATION_DIR_NAME = 'migrations_geo'
>>
>> The maintainer of the app would set GEO_USING_GEO_DJANGO=True and run
>>  schemamigration, then set GEO_USING_GEO_DJANGO=False and rerun the
>> schemamigration again. We'd end up with two distinct migration directories.
>>
>> The end users just have to set GEO_USING_GEO_DJANGO=True/False.
>>
>> I know this is not an ideal solution, but if avoiding duplicate versions
>> of the same application was the final goal, this would achieve it.
>>
>> This would complicate things for sure, but is there an easier way to
>> avoid the duplicate source code?
>>
>> 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_H8ESPLR24Y7tD6xNxSS-%2BkT%3Dwc2a-60boN%3DAZ5Aphms3KA%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/CAFwN1uphseP5Q2AsTXdKmTyrM%3Dct60NpkttRhTnKvGp5Vx63tQ%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_H8EgnFJ6EaFqHaDzDc8ax0uHfSZUHb3w%3Dpc9qcWzG5YJkA%40mail.gmail.com.
For more options, visit https://groups.google.com/groups/opt_out.

Why SlugField overrides get_internal_type()?

[Val Neekman]

None of the other subclasses of CharField override get_internal_type() but
the SlugField and I am wondering why?

Class SlugField(CharField):

def get_internal_type(self):
return "SlugField"

Thx,

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_H8G1UecD5%2BRz%2B%2BVm%2BKnE_ikfd%2BYzF4RnTgoAN3gdkfqqeQ%40mail.gmail.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: Why SlugField overrides get_internal_type()?

[Val Neekman]

Oh, I see.

Thanks Carl.

Val



On Fri, Feb 7, 2014 at 6:14 PM, Carl Meyer  wrote:

> Hi Val,
>
> On 02/07/2014 04:07 PM, Val Neekman wrote:
> > None of the other subclasses of CharField override get_internal_type()
> > but the SlugField and I am wondering why?
> >
> > Class SlugField(CharField):
> >
> > def get_internal_type(self):
> > return "SlugField"
>
> "Internal type" abstracts a field class from the database column type
> used to represent it in various database backends. "SlugField" is a
> distinct internal_type from "CharField" because we use different
> database column types to represent SlugField and CharField in some
> databases.
>
> See the implementation of `Field.db_type()` and the `data_types` class
> attribute on the various DatabaseCreation classes in the db backends.
>
> Carl
>
> --
> 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/52F568DB.7030504%40oddbird.net
> .
> 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_H8HnLAG%2BzLLRHoXFNJLY5-uSR7LZ7r3rnVZyUNKfzPtC%3DQ%40mail.gmail.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: Testing 1.7a2 -- pre_migrate and post_migrate (py2.7)

[Val Neekman]

Is the following statement still valid?

"Any handlers that listen to this signal need to be *written* in a
particular place: a management module in one of your
INSTALLED_APPS.
If handlers are *registered* anywhere else they may not be loaded by
migrate
."

1. I scanned the source and did not find the code imposing the above
statement.
2. Handlers that are not in the management directory are still called.

Unless the statement means something different or the supporting code has
been removed.

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_H8Et%3DbSfVM4ijY4t7PnKKEamPusnbooYtDpw5m4UG6wWBA%40mail.gmail.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: Testing 1.7a2 -- pre_migrate and post_migrate (py2.7)

[Val Neekman]

Yeah, I do remember times where I had to put the signal handlers in the
urls.py in order to lazyfy them, hence, avoiding the circle-dance. Of
course, they would not fire via the management commands.

Ok, good to have the AppConfig.ready() for that.

Thanks,

Alight, Perhaps, I should create a ticket and enhancement for the
documentation update.

Thanks,

Val





On Tue, Feb 11, 2014 at 2:24 PM, Aymeric Augustin <
aymeric.augus...@polytechnique.org> wrote:

> On 11 févr. 2014, at 20:20, Carl Meyer  wrote:
>
> > this documentation probably should be
> > updated to recommend registering these signal handlers (and all other
> > signal handlers) in the ready() method of an AppConfig, rather than as
> > an import side effect anywhere.
>
> Indeed, that's the best practice as of Django 1.7.
>
> --
> Aymeric.
>
>
>
>
> --
> 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/8B2A0448-6CDA-457D-BF76-E7EBDD786A4D%40polytechnique.org
> .
> 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_H8F9%2BznkUKXK9m6gzkgh_bxLANLruBPv%2Bc4EtuogcGeLhQ%40mail.gmail.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: #20824 - Email-based auth contrib module; some help required

[Val Neekman]

The following may be a viable solution for the case-insensitive fields.
(email, username, alias ... etc.)

Look at lines: 23, 66 and 159.

https://gist.github.com/un33k/9273782

Val




On Fri, Feb 28, 2014 at 5:05 AM, Tilman Koschnick  wrote:

> On Thu, 2014-02-27 at 08:43 +0800, Russell Keith-Magee wrote:
>
> > It does - assuming you use User.objects.create_user() to create all
> > your users. However, the UserCreationForm doesn't use this (and hasn't
> > ever used this); it also doesn't account for fixtures, or any other
> > path into the database that might exist.
>
> Would it be possible to additionally guard in the save() method of the
> email User class against duplication by checking with "not
> filter(email__iexact=...).exists()"?
>
> The documentation could also explain how to manually add a constraint at
> the database level where this is supported. (The current kickstarter
> project for improved PostgreSQL support seems likely to add expression
> indexes to Django proper one day.)
>
> > So - while normalising case is probably a good idea, and should
> > probably be added to the Create/Update User form, the searches will
> > still need to be case insensitive.
>
> While there is no way to enforce this, it could at least be added to the
> documentation that get_by_natural_key() should be used for email based
> users, or filter(email__iexact=...).
>
> Kind regards, Til
>
> --
> 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/1393581918.9673.31.camel%40mother.subnetz.org
> .
> 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_H8G7ygPY%2BgT71C910Me_MnO67A%2BgaocpgGxUUoO%2BY7exNg%40mail.gmail.com.
For more options, visit https://groups.google.com/groups/opt_out.

APPEND_SLASH skip per URL or per base_uri

[Val Neekman]

Some JavaScript frameworks(e.g. AngularJS) remove the ending slash before 
making a request.
If APPEND_SLASH = True, then the API would not be consumable by AngurlarJS.

Would it be a good idea to add options to disable the APPEND_SLASH 
behaviour per *url()*, or per a *base_uri*?

*Example 1:*
*settings.py:*
APPEND_SLASH = True

*urls.py:*
url(r'^profile', views.profile, name='profile', append_slash=False),

*Example 2:*
*settings.py*
APPEND_SLASH = True
APPEND_SLASH_EXCLUDE = ('/api/v1/', '/api/v2/', '/etc/)

What do you think?

If the answer is YES, then would it be too late to push a patch up for 
inclusion in 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-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/e01272a7-585f-42fe-85e5-8b0020aef882%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: APPEND_SLASH skip per URL or per base_uri

[Val Neekman]

Yep, $ is required.


On Thu, Mar 13, 2014 at 5:21 PM, Ryan Hiebert  wrote:

> Sorry, auto-send.
>
> In your example, APPEND_SLASH wouldn't add a slash, because the URL in the
> URLConf doesn't have a slash on it.
>
> I figure you probably meant this, though:
>
> url(r'^profile$', views.profile, name='profile', append_slash=False),
>
> (with a dollar sign at the end of the regex pattern).
>
>
> On Thu, Mar 13, 2014 at 4:19 PM, Ryan Hiebert wrote:
>
>> In your example, APPEND_SLASH
>>
>>
>> On Thu, Mar 13, 2014 at 4:12 PM, Val Neekman  wrote:
>>
>>> Some JavaScript frameworks(e.g. AngularJS) remove the ending slash
>>> before making a request.
>>> If APPEND_SLASH = True, then the API would not be consumable by
>>> AngurlarJS.
>>>
>>> Would it be a good idea to add options to disable the APPEND_SLASH
>>> behaviour per *url()*, or per a *base_uri*?
>>>
>>> *Example 1:*
>>> *settings.py:*
>>> APPEND_SLASH = True
>>>
>>> *urls.py:*
>>> url(r'^profile', views.profile, name='profile', append_slash=False),
>>>
>>> *Example 2:*
>>> *settings.py*
>>> APPEND_SLASH = True
>>> APPEND_SLASH_EXCLUDE = ('/api/v1/', '/api/v2/', '/etc/)
>>>
>>> What do you think?
>>>
>>> If the answer is YES, then would it be too late to push a patch up for
>>> inclusion in 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-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/e01272a7-585f-42fe-85e5-8b0020aef882%40googlegroups.com<https://groups.google.com/d/msgid/django-developers/e01272a7-585f-42fe-85e5-8b0020aef882%40googlegroups.com?utm_medium=email&utm_source=footer>
>>> .
>>> For more options, visit https://groups.google.com/d/optout.
>>>
>>
>>
>  --
> 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/CABpHFHRSM%2BwirffyTWVtAn5spojQ%3DY6QWcr%3DHukPnAj-sejgqQ%40mail.gmail.com<https://groups.google.com/d/msgid/django-developers/CABpHFHRSM%2BwirffyTWVtAn5spojQ%3DY6QWcr%3DHukPnAj-sejgqQ%40mail.gmail.com?utm_medium=email&utm_source=footer>
> .
>
> For more options, visit https://groups.google.com/d/optout.
>

-- 
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_H8FWs9W7ttYAHinei%2Bz%2B9xkm5pACZq_wPxq2%3DD3_iBSOoQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: APPEND_SLASH skip per URL or per base_uri

[Val Neekman]

Hi Aymeric,

Localized solution is fine, but when I saw the number posts from people who 
were trying to find a solution to this, I thought, perhaps it would be a 
nice little enhancement to the APPEND_SLASH functionality.

Thanks,

Val


On Thursday, 13 March 2014 17:12:51 UTC-4, Val Neekman wrote:
>
> Some JavaScript frameworks(e.g. AngularJS) remove the ending slash before 
> making a request.
> If APPEND_SLASH = True, then the API would not be consumable by AngurlarJS.
>
> Would it be a good idea to add options to disable the APPEND_SLASH 
> behaviour per *url()*, or per a *base_uri*?
>
> *Example 1:*
> *settings.py:*
> APPEND_SLASH = True
>
> *urls.py:*
> url(r'^profile', views.profile, name='profile', append_slash=False),
>
> *Example 2:*
> *settings.py*
> APPEND_SLASH = True
> APPEND_SLASH_EXCLUDE = ('/api/v1/', '/api/v2/', '/etc/)
>
> What do you think?
>
> If the answer is YES, then would it be too late to push a patch up for 
> inclusion in 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-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/ef92c706-34f7-4716-b75e-f26ad1da71c4%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

rotate_token via test client in 1.7a2

[Val Neekman]

Just wondering if CSRF token should be also rotated when accessed via 
unittest client.
Middleware is in place and rotation happens via a browser.

Bug or intended behaviour, or perhaps a misuse ?

# Example
self.client = Client(enforce_csrf_checks=True)
resp = self.client.get(reverse('admin:login'))
csrf_token_from_cookie_pre_login = 
self.client.cookies['csrftoken'].value

credentials = {
'username': 'me',
'password': 'pass',
'csrfmiddlewaretoken': csrf_token_from_cookie_pre_login,
}
resp = self.client.post(reverse('admin:login'), data=credentials)
csrf_token_from_cookie_post_login = 
self.client.cookies['csrftoken'].value

   self.assertNotEqual(csrf_token_from_cookie_*post_login*, 
csrf_token_from_cookie_*pre_login*)
   # They are equal

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/153f64ae-5211-471d-bb95-5cd76adb6699%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Built-in router link generator in Django

[Val Neekman]

Folks,

I am wondering if Django would benefit from the inclusion of this package 
or something like it?

https://github.com/un33k/django-menuware

A utility module to auto generate links from configuration.

Thanks,
Val
 

-- 
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 https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/6df84fa1-e831-4ee2-abaf-e140d9e28b89%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.