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

[Russell Keith-Magee]

Hi all,

tl;dr; I've been working on a last little feature for 1.7 - an email-based
User model for contrib, but I need some help/guidance on the last step -
getting the tests working.

The idea here is that we just ship a normal auth.User, but with email
identification rather than username. This is essentially the 80% case for
requests for custom User models anyway, and it provides an example of "how
to do it" for anyone that wants to follow the lead.

I've also taken the opportunity to do a bit of refactoring of auth forms
and the AbstractUser to make re-use of common parts a bit easier.

Code is available here. Other than bikeshed stuff (name of module, name of
classes etc) it shouldn't be too controversial:

https://github.com/freakboy3742/django/tree/emailauth

There are two things still pending on this patch:

 1) Documentation. There isn't much to document, but obviously this is
required.

 2) Tests that work.

It's the second point where I need some assistance (or at the very least,
some suggestions of directions I can go with this).

There isn't that much that requires testing -- after all, it's a fairly
vanilla User model. A bit of light testing of forms, some checks to make
sure that the models can be created, and that they play well with
ModelBackend, and so on.

However, there's a problem with including these tests as part of Django's
own testing infrastructure, due to clashes with Django's default User model.

In a production app, you either want a normal Django User model, in which
case you don't include contrib.emailauth in your app; or you include
contrib.emailauth, and you set AUTH_USER_MODEL must be set (I haven't added
a formal check for this, but I could). As a result, there's no confusion
over which User model is active. I've done some manual testing, and the
user model all works as expected.

While running Django's test suite, however, the suite installs both
contrib.auth and contrib.emailauth, but *doesn't* set AUTH_USER_MODEL to
emailauth -- it can't, because we need to test default User behaviours.

Both auth.User and emailauth.User have relations with Group, and the names
clash, so the test suite won't start.

If you deliberately silence the model integrity system checks, you get
other errors, caused by the fact that there's confusion over which
AUTH_USER_MODEL is active at any given time.

So - I'm looking for suggestions for how this can be handled in Django's
test suite.

I've thought about explicitly excluding contrib.emailauth from the test
suite's INSTALLED_APPS, but then the tests in emailauth don't get
discovered and executed.

Even if you reorganise the tests to make them part of the "django" tests,
rather than tests that are part of the contrib app, you get problems
because you end up with two models with the same relation name to Group.

So - anyone got any ideas how to handle this? Is there some feature of the
new app loading code that I can exploit here?

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

Re: GSoC 2014 proposal [Improving error reporting]

[anubhav joshi]

Regarding the 'improving error reporting' part, I have started with some 
issues which may be comparatively easier:

Improving error reporting

django.forms

#15069

In forms.py:
self._errors[name] = self.error_class(e.messages)

When the list of errors is created, the value of the wrong/invalid field 
can be shown.

Some extra information could be shown, based upon the type of error.
eg. In FileField : In case of invalid, the encoding-type problem could be 
explained with better message/suggestion
In DateTimeField : Format/Example of correct datetime object or errors 
could be pointed out more explicitly.
Also such cases in other Field subclasses

Also some more type of errors could be added.

#13091

A patch was written for a part of this(which was decided to be dealt in 
another ticket) which was merged. But the major problem remained unsolved. 
Later a patch was written for this too, but as summarized by a core-dev, 
that will lead to another set of bugs.
I did go through the patch and realized the situation, there were some 
suggesstions that I too believe will work well:

Just fix this in the particular case of the admin. This could possibly be 
done by adding a manual call to full_clean once the instance is fully 
populated (might be a bit ugly getting any ValidationErrors back into the 
not-valid code path).
Add a warning to the above section of the docs (on partial ModelForms) 
about this issue and how to work around it in your own forms.


django.http

If Http404 is returned instead of raised(because it is in the same file 
where other response classes have been defined i.e. 
django/http/response.py), then there is a problem of AttributeError.
One solution is renaming it to more clear name like Http404Exception, but 
we would have to replace it at several places.
Ithink a better solution could be to check this error in 
django/core/handlers/base.py .We can check the called response object for 
this, and then do something which is appropriate. I think we can check for 
Http404, if it is returned and convert the response to HttpResponseNotFound.


Feedback Needed.
Working on other issues, will be posting soon.


Regards,
Anubhav Joshi
IIT Patna

-- 
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/8526ac55-76cb-426f-ba70-b7d918f70a07%40googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: GSoC 2014 proposal [Improving error reporting]

[anubhav joshi]

On Tuesday, February 25, 2014 5:02:26 AM UTC+5:30, Tim Graham wrote:
>
> "Now I would like to know whether it would be suitable for GSoC?"
>
> Maybe! As these tickets touch many different aspects of Django, I'm 
> guessing you'll need to do quite a bit of research in order to convince us 
> you have the breadth of experience to tackle them all. Some of those 
> tickets also have existing patches -- you'll need to review them to see if 
> additional work needs to be done (or if not, please bump the ticket to 
> ready for checkin). If I were you, I'd map out more than 12 weeks worth of 
> tickets in case some of the ones you choose initially are completed by 
> community members in the meantime. Presumably if your proposal were 
> accepted, you could assign them to yourself at that time.
>

In order to chalk out work enough for 12 weeks, I think I will extend my 
proposal to 'improving error reporting and fixing related bugs/issues.' 
because while I am going through the issues, I have found many tickets 
which need work to be done regarding some strange thing happening, but they 
are not related to 'improving error reporting' but are worth fixing and 
AAMOF they interest me as well.


Regards,
Anubhav Joshi

-- 
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/b54ce376-7c6c-4cfc-845a-a7edad5a211b%40googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: allow list_display in admin to traverse onetoonfields and foreign key relations

[Zach Borboa]

I agree that the current behaviour is confusing and needs change in order 
to be DRY[1] and consistent[2].

[1] 
https://docs.djangoproject.com/en/dev/misc/design-philosophies/#don-t-repeat-yourself-dry
[2] https://docs.djangoproject.com/en/dev/misc/design-philosophies/#consistency



This is how I currently work around this issue.

models.py
class Question(models.Model):
text = models.CharField(max_length=200)
pub_date = models.DateTimeField('date published')

class Choice(models.Model):
question = models.ForeignKey(Question)
choice_text = models.CharField(max_length=200)
votes = models.IntegerField(default=0)

admin.py
class ChoiceAdmin(admin.ModelAdmin):
def question__text(self, obj):
return obj.question.text

list_display = ('pk', 'question__text', 'choice_text', 'votes')

admin.site.register(Choice, ChoiceAdmin)






On Tuesday, February 25, 2014 3:48:40 PM UTC-8, Wim Feijen wrote:
>
> Hello,
>
> Right now I have a School model containing a OneToOne-relation to User.
>
> In the admin, in search_fields, I can use double underscores to search in 
> related fields, for example:
> search_fields = ('place__name', 'school__name')
>
> But in list_display, I can't. For example,
> list_display = ['school', 'school__user', 'place', ]
> gives an error.
>
> I find this totally confusing. More people do.
>
> A ticket has been made six years ago and was eventually closed as won't 
> fix. Currently, the proposed solution is to write a custom method or 
> callable. I'd like to raise a discussion to reopen that ticket.
>
> For reference, see:
> https://code.djangoproject.com/ticket/5863
> https://groups.google.com/forum/#!topic/django-developers/eQSEv74bQh8
>
> My arguments to allow such a syntax are:
>
> 1. allowing 'school__user' in list_display is consistent with the 
> behaviour of search_fields, list_filter in the admin, and get() and 
> filter() query syntax in general.
> 2. it saves many people duplicating two to four lines of custom code, and 
> in my opinion, allows for a more concise yet extremely easy to understand 
> notation.
> 3. ideally, a solution would use select_related in order to save database 
> queries and thus be longer than two to four lines of code.
> 4. the need is common, and in onetoonefields specifically. Many people 
> have expressed their interest in this feature, and a core developer 
> initially accepted it.
> 5. a long time has passed since then and our policy of accepting tickets 
> has changed.
>
> Thanks for reading! I'd love to hear your response.
>
> Regards, Wim
>

-- 
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/764cf67d-2107-4bdd-88bd-004a043a162f%40googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [GSOC 2014 proposal] enhancing security features in django

[Russell Keith-Magee]

Hi Prithviraj,

I suspect the reason you haven't had a response is that there isn't much to
respond to here.

Regarding integrating django-secure -- I agree that this would be a
worthwhile activity; it was part of the plan for last year's GSoC project
on the validation framework, but got dropped due to time constraints.
However, that body of work was estimated as 2 weeks of work or less - it
certainly won't be enough to sustain a GSoC project on its own. If you can
propose additional checks that could be added to django-secure, that
*might* bulk out your project proposal to fill the allotted time, but you'd
need to propose a *lot* of new checks - and as part of your proposal
process, we'd be expecting *you* to proposed which new checks you can add.

As for your other suggestion -- well... you suggest implementing an
"encrypted token pattern", but don't actually provide any references to
describe what you actually mean. You say "it is said", but don't say *by
whom*.

In short -- we need a lot more detail than this before we can provide any
meaningful feedback. If you've got specific questions, we're happy to
answer them, but based on the information you've provided so far, all we
can say is yes, improving Django's security features is a project on our
wish list.

Yours,
Russ Magee %-)



On Tue, Feb 25, 2014 at 1:25 PM, Prithviraj Billa <
prithviraj.m.bi...@gmail.com> wrote:

> I am eagerly waiting  to hear your comments and opinions.
>
> Thanks,
>
> Prithviraj M Billa
> github :: htttp://github.com/Prithvirajbilla
> blog:: http://blog.prithvirajbilla.com
>
>
>
> On Sunday, February 23, 2014 9:34:15 PM UTC+5:30, Prithviraj Billa wrote:
>>
>> Hello Guys!
>>
>>
>> I am planning to work on developing and improving the security features
>> of Django.
>>
>> I would like some help in formalizing the proposal so that it will meet
>> the requirements.
>>
>
>> Things i understood how security against csrf works and how it is
>> implemented in django. (please correct me if I'm wrong)
>>
>>
>>-
>>
>>When ever user request a csrf_token in the HTML view or using the
>>function csrf_protect(), the server creates a randomized token which is
>>different for every request. (changes for requests). and we set a cookie
>>csrf_token=value.
>>-
>>
>>When a POST request is sent (or some sensitive operation is done at
>>server side), we also send a hidden variable csrf_token which is validated
>>against the cookie.(Double submitting cookie technique.).
>>-
>>
>>The attacker may send the the request from the other domain on behalf
>>of the user logged in, but the attack will mostly fail because he cannot
>>read the session data (because of same origin policy)
>>-
>>
>>These all operations are taken care of CSRF middleware.
>>
>>
>> It is mentioned that you want to integrate the 
>> django-secureproject with the 
>> django project. ssl redirect, security against
>> clickjacking, some xss attacks were already implemented in the above
>> project. Do the candidate  have to improve those features or just have to
>> integrate those features with the present django?
>>
>> How can we enhance the security measures against the csrf attacks?(I
>> don't know how to enhance security the using  Double submitting cookie
>> technique which is already implemented in the django project).
>>
>> I think we can implement Encrypted token pattern to enhance the security
>> against csrf attacks.It is mentioned that it allows us greater control over
>> CSRF-defense, without introducing new security concerns or architectural
>> problems.I'm a newbie in this area .So please let me know, If this is not a
>> good idea.
>>
>>
>>
>> I like to hear your comments and opinions.
>>
>> Thanks,
>>
>> Prithviraj M Billa
>>
>> github: http://github.com/Prithvirajbilla
>>
>> blog: http://blog.prithvirajbilla.com
>>
>>
>>  --
> 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/9ba193b8-8308-41ed-9189-576fe8480f78%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 

allow list_display in admin to traverse onetoonfields and foreign key relations

[Wim Feijen]

Hello,

Right now I have a School model containing a OneToOne-relation to User.

In the admin, in search_fields, I can use double underscores to search in 
related fields, for example:
search_fields = ('place__name', 'school__name')

But in list_display, I can't. For example,
list_display = ['school', 'school__user', 'place', ]
gives an error.

I find this totally confusing. More people do.

A ticket has been made six years ago and was eventually closed as won't 
fix. Currently, the proposed solution is to write a custom method or 
callable. I'd like to raise a discussion to reopen that ticket.

For reference, see:
https://code.djangoproject.com/ticket/5863
https://groups.google.com/forum/#!topic/django-developers/eQSEv74bQh8

My arguments to allow such a syntax are:

1. allowing 'school__user' in list_display is consistent with the behaviour 
of search_fields, list_filter in the admin, and get() and filter() query 
syntax in general.
2. it saves many people duplicating two to four lines of custom code, and 
in my opinion, allows for a more concise yet extremely easy to understand 
notation.
3. ideally, a solution would use select_related in order to save database 
queries and thus be longer than two to four lines of code.
4. the need is common, and in onetoonefields specifically. Many people have 
expressed their interest in this feature, and a core developer initially 
accepted it.
5. a long time has passed since then and our policy of accepting tickets 
has changed.

Thanks for reading! I'd love to hear your response.

Regards, Wim

-- 
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/e384693f-72a9-4aba-bcaa-e0590dcfcbbe%40googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: Django cross reference: www.xrefs.info

[Russell Keith-Magee]

Hi John,

Thanks, but for future reference - this isn't an appropriate topic for
Django Developers. Django-dev is the mailing list for people wanting to
contribute to Django. If you want to make a Django-related product
announcement, use django-users instead.

Yours,
Russ Magee %-)


On Tue, Feb 25, 2014 at 7:57 AM, John Smith  wrote:

> hello, I added Django in www.xrefs.info to provide cross reference search
> for Django development.
>
> http://www.xrefs.info is made for open source community in
> the hope of making open source developers more productive.
> The site hosts many open source code projects' cross references based
> on OpenGrok, which is a very fast cross reference tool, and easy to use.
>
> To access, you can go to http://www.xrefs.info, select a project, pick a
> version.
> If you want to search the definition of a function,
> simply type it in the definition box; If you want to do a full search,
> type your text in the first box; If you want to search a file, simply
> type file name in file path box. Hit search button, That's it!
>
> The site covers following:
>  - Linux kernel cross reference: from verion 0.01 - latest release, plus
> nightly linus' tree latest.
>  - Linux boot loaders cross reference: u-boot, lilo, grub, syslinux,plus
> nightly latest.
>  - Linux user space core packages cross reference
>  - Android various releases cross reference, plus nightly latest.
>  - Cloud computing other projects:
> - xen hypervisor cross reference
> - VirtualBox cross reference;
> - OpenStack cross reference
> - cloudStack cross reference.
> - Puppet cross reference
> - Salt cross reference
> - Cloud Foundary cross reference
> - OpenShift cross reference
> - Chef cross reference
> - Juju cross reference
>  - Big data project Hadoop cross reference
>  - BSD: FreeBSD cross reference, NetBSD cross reference, DragonflyBSD
> cross reference
>  - Database: MySQL cross reference, MariaDB cross reference, mongoDB cross
> reference, redis, neo4j, hbase, cassandra
> - Python web framework: Django, Grok, Zope2, Flask, web2py etc...
>  - Languages: OpenJDK cross reference, Perl cross reference, Python cross
> reference, PHP cross reference.
>
> If you have any questions, comments or suggestions for the site,
> please let me know.
>
> Thanks.
> xrefs.i...@gmail.com
>
>
>
>  --
> 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/4c16f902-8e4c-4b11-885e-b8296a0fe315%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/CAJxq84-%3D3yJ85fm96OP6BDgXEsTsboorYCFSNkLYoFdxHw-Q9A%40mail.gmail.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [GSoC] Switching to Jinja2 proposal

[Curtis Maloney]

Yah... my oops ... I was reading on my phone and missed the link :)


On 25 February 2014 21:03, Christopher Medrela wrote:

> The link is here: http://pastebin.com/DWjE1axV
>
> It times only rendering -- templates are parsed and cached in the setup.
>
>
> On Tuesday, February 25, 2014 8:34:14 AM UTC+1, Curtis Maloney wrote:
>>
>> Did I miss the link to your benchmark code?
>> Does it time just rendering, or parsing also?
>> --
>> Sent from my Android device with K-9 Mail. Please excuse my brevity.
>>
>  --
> 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/eda8c6ea-79b6-4bb1-a4b5-7af8d2dfd3bf%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_XiSBr%2BkokDaX5h27MMEMe2A25PkybfWzBZfO3uTuEe2xuNA%40mail.gmail.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [GSoC] Switching to Jinja2 proposal

[Kevin Christopher Henry]

>
> What kind of support do you except for third-party template tags? Suppose, 
> that
> `cycle` tag is not builtin. Would it be acceptable to write sth like that:
>
> dtl cycle '1' '2' as rows
>
> It could be quite easily implemented as a Jinja2 extensions. Of course, I 
> guess
> that you'd prefer this style:
>
> cycle '1' '2' as rows
>

Good question. In my opinion, making the tag invocation look the same as it 
does in DTL should not be an important goal. These are different languages, 
after all, with different syntaxes and different calling conventions. For 
example, many things that need to be tags in DTL are just functions in 
Jinja. (django-jinja took this approach by implementing the built-in 'url' 
as a function rather than a tag.)

Another relevant issue is that there could be name ambiguities. In DTL you 
specify a module with the load tag, which allows you to have multiple apps 
that use the same template tag name. Without the load tag you need some way 
to specify which 'cycle' you're referring to. (This is not just an issue 
with wrapping DTL tags, it's also going to be an issue if multiple apps try 
to register global Jinja functions with the same name.)

-- 
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/57769035-c8c3-45a0-a7c3-4fc757b79497%40googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: GSOC 2014 Project Proposal

[Daniel Greenfeld]

One more note in this thread:

http://www.amazon.co.uk/The-Definitive-Guide-Django-Development/dp/1430258810

The Definitive Guide to Django is being revised. Apress has added Katie 
Cunningham to the author list, something that now I just remembered Jacob 
Kaplan-Moss mentioned to me in early 2013. I can only guess that 
djangobook.com will be updated as well.

I apologize for not considering the ownership issues in my first email in 
this discussion.

Daniel Greenfeld


On Monday, February 24, 2014 8:39:41 AM UTC-8, Daniel Greenfeld wrote:
>
> After due consideration, I think updating djangobook.com should not be a 
> GSOC project. Why not?
>
> First, the book is owned by the authors and Apress, not the Django 
> project. The Django community has no control. This probably runs afoul of 
> some sort of GSOC rule.
>
> Second, it's representative of something that is at least partly a 
> commercial effort. In theory, Apress could take the revised content and 
> publish it as a third edition. While I'm not opposed to the commercial 
> selling of books at all, I think Google would take significant exception to 
> GSOC funds being used this way.
>
> Third, I think providing example projects for the tutorial chapters is not 
> worthy of a GSOC project. It's too much of a low-hanging fruit and people 
> have certainly done it already. I know because people try to do this with 
> Two Scoops of Django's chapters (search GitHub and you'll find some 
> attempts).
>
> Fourth, because of the third issue, we risk complaints of plagiarism. The 
> content already exists, it's just a matter of finding it. GSOC funding for 
> code examples that already exist? No. No. No. Bad idea!
>
> Daniel Greenfeld 
>
> On Monday, February 24, 2014 2:28:41 AM UTC-8, Tom Evans wrote:
>>
>> On Sat, Feb 22, 2014 at 5:31 PM, Devashish Badlani  
>> wrote: 
>> > Sir, 
>> > 
>> > 
>> > Sample projects with the updated Django 1.6.2,use of latest modules in 
>> each 
>> > of them and an helpful documentaion ,would certainly enhance the value 
>> of 
>> > DjangoBook is what I feel 
>> > 
>>
>> How would this work? The book currently admonishes readers that: 
>>
>> """ 
>> The community edition of The Django Book is in transition. While the 
>> book mentions Django version 1.4 in places, the vast majority of the 
>> book is for Django version 1.0 
>> """ 
>>
>> So you will write sample projects aimed at 1.6.2 for each chapter in a 
>> book written for 1.0? This does not seem wise. 
>>
>> Cheers 
>>
>> Tom 
>>
>

-- 
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/8decc06e-2704-446a-a900-30fc0802de3c%40googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: The unsettings project

[Jonathan Slenders]

Not sure whether this has already been covered. Maybe it is.

I'd like to specify the settings as a class instead of a module. Mostly 
because I don't like the "from settings_local import *" pattern to extend 
some base settings with machine specific settings. By having the 
possibility to define it in a class, I could use inheritance.

from project.base_settings import BaseSettings
class MySettings(BaseSettings):
INSTALLED_APPS = BaseSettings.INSTALLED_APPS + [...]
...

It's also a solution for "lazy" settings, like said above. Create a 
property in the settings class, etc..
This should easily be backwards compatible.

-- 
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/428b0f36-b4b5-40db-af97-39ebbba01b09%40googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: Issue with save/save_model/clean from admin (django 1.6.3dev)

[Jonathan Pentecost]

I _think_ your problem might lie in the confusion between "blank" and 
"null"; taken from 
https://docs.djangoproject.com/en/dev/ref/models/fields/#blank; 

 
null
 is 
purely database-related, whereas 
blank
 is 
validation-related. If a field has blank=True, form validation will allow 
entry of an empty value. If a field has blank=False, the field will be 
required.




On Tuesday, 25 February 2014 14:17:21 UTC+11, Stefano Crosta wrote:
>
> Hello!
>
> I'm trying to understand if this is a bug, or a not clearly documented 
> feature.
>
> I have a simple model where one field should be calculated at save. eg.
>
> class MyModel(models.Model):
> a = models.CharField(max_length=255) 
> b = models.CharField(max_length=255, blank = True)
>
> Now, if I create an instance in the admin and I try to save leaving `b` 
> empty (that's ok because it's blank=True) I get a ValueError:
>
> Cannot assign None: "app.MyModel" does not allow null values.
>
> Now, I would expect to be able to set `b` to my calculated value in one of 
> the following places, according to the documentation:
>
>
> - overriding save() in the model class
> - in the clean() method in the model class
> - with a custom save_model() in the admin class
>
> Instead, none of those locations are reached, and I get the ValueError 
> from 
>
> django/db/models/fields/related.py in __set__
>
>1. 
>
>return rel_obj
>
>2. 
>
>3. 
>
>def __set__(self, instance, value):
>
>4. 
>
># If null=True, we can assign null here, but otherwise the value 
> needs
>
>5. 
>
># to be an instance of the related class.
>
>6. 
>
>if value is None and self.field.null == False:
>
>7. 
>
>raise ValueError('Cannot assign None: "%s.%s" does not allow 
> null values.' %
>
>
>
>1. 
>
>(instance._meta.object_name, 
> self.field.name))
>
>
>
> now, also checking the stack (and even debugging) it seems like this comes 
> earlier than save.
>
>
> *My question: **Is this somehow expected, is this a bug/a regression?*
>
> If it's expected, I'll find another workaround; if it's a bug, I can add a 
> ticket.
>
>
> Thanks!
>
> Stefano
>
>
>
> Stacktrack
>
>
>- /home/3h/django/django/contrib/admin/options.py in add_view
>1. 
>   
>   if form.is_valid():
>   
>   ...
>▶ Local vars 
>- /home/3h/django/django/forms/forms.py in is_valid
>1. 
>   
>   return self.is_bound and not bool(self.errors)
>   
>   ...
>▶ Local vars 
>- /home/3h/django/django/forms/forms.py in errors
>1. 
>   
>   self.full_clean()
>   
>   ...
>▶ Local vars 
>- /home/3h/django/django/forms/forms.py in full_clean
>1. 
>   
>   self._post_clean()
>   
>   ...
>▶ Local vars 
>- /home/3h/django/django/forms/models.py in _post_clean
>1. 
>   
>   self.instance = construct_instance(self, self.instance, 
> opts.fields, opts.exclude)
>   
>   ...
>▶ Local vars 
>- /home/3h/django/django/forms/models.py in construct_instance
>1. 
>   
>   f.save_form_data(instance, cleaned_data[f.name])
>   
>   ...
>▶ Local vars 
>- /home/3h/django/django/db/models/fields/__init__.py in save_form_data
>1. 
>   
>   setattr(instance, self.name, data)
>   
>   ...
>▶ Local vars 
>- /home/3h/django/django/db/models/fields/related.py in __set__
>1. 
>   
>   (instance._meta.object_name, 
> self.field.name))
>   
>   ...
>▶ Local vars 
>
>

-- 
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/ae35ebac-7937-4239-ae4c-706f09b8fae1%40googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Spell checker

[Szczepan Cieślik]

Hi,

I've added spell checker for documentation. Ticket: 
https://code.djangoproject.com/ticket/22141 and PR: 
https://github.com/django/django/pull/2354

In summary it allows to check documentation against typos. One disadvantage 
is that there must be wordlist for words, that are not recognized as 
proper. Anyway it works quite good, there is also distinct PR with results 
of such check: https://github.com/django/django/pull/2353

-- 
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/fb18957a-b65e-4575-b4f3-683abdf04cb3%40googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [GSoC] Switching to Jinja2 proposal

[Christopher Medrela]

The link is here: http://pastebin.com/DWjE1axV

It times only rendering -- templates are parsed and cached in the setup.

On Tuesday, February 25, 2014 8:34:14 AM UTC+1, Curtis Maloney wrote:
>
> Did I miss the link to your benchmark code?
> Does it time just rendering, or parsing also?
> -- 
> Sent from my Android device with K-9 Mail. Please excuse my brevity.
>

-- 
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/eda8c6ea-79b6-4bb1-a4b5-7af8d2dfd3bf%40googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: GSoC 2014 proposal [Improving error reporting]

[anubhav joshi]

On Tuesday, February 25, 2014 5:02:26 AM UTC+5:30, Tim Graham wrote:
>
> "Now I would like to know whether it would be suitable for GSoC?"
>
> Maybe! As these tickets touch many different aspects of Django, I'm 
> guessing you'll need to do quite a bit of research in order to convince us 
> you have the breadth of experience to tackle them all.
>

Yes I have already started looking into those issues and will be posting 
soon as and when I reach somewhere.
 

> Some of those tickets also have existing patches -- you'll need to review 
> them to see if additional work needs to be done (or if not, please bump the 
> ticket to ready for checkin). If I were you, I'd map out more than 12 weeks 
> worth of tickets in case some of the ones you choose initially are 
> completed by community members in the meantime. Presumably if your proposal 
> were accepted, you could assign them to yourself at that time.
>

Ok will keep that in mind


Regards,
Anubhav Joshi
IIT Patna 

-- 
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/8b073b7b-a8ce-41c2-94f3-91e290abe6ce%40googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: Issue with save/save_model/clean from admin (django 1.6.3dev)

[Shai Berger]

Hi Stefano,

You are leaving out important details -- the error you are getting is clearly 
about a "related field" (ForeignKey, OneToOne or ManyToMany), but there is no 
such field in the model you provided.

I suspect it is more likely to be a usage issue rather than a problem in 
Django code or documentation, and therefore I suggest you bring it up (with 
the missing details) at the django-users list.

HTH,
Shai.

On Tuesday 25 February 2014 05:17:21 Stefano Crosta wrote:
> Hello!
> 
> I'm trying to understand if this is a bug, or a not clearly documented
> feature.
> 
> I have a simple model where one field should be calculated at save. eg.
> 
> class MyModel(models.Model):
> a = models.CharField(max_length=255)
> b = models.CharField(max_length=255, blank = True)
> 
> Now, if I create an instance in the admin and I try to save leaving `b`
> empty (that's ok because it's blank=True) I get a ValueError:
> 
> Cannot assign None: "app.MyModel" does not allow null values.
> 
> Now, I would expect to be able to set `b` to my calculated value in one of
> the following places, according to the documentation:
> 
> 
> - overriding save() in the model class
> - in the clean() method in the model class
> - with a custom save_model() in the admin class
> 
> Instead, none of those locations are reached, and I get the ValueError from
> 
> django/db/models/fields/related.py in __set__
> 
>1.
> 
>return rel_obj
> 
>2.
> 
>3.
> 
>def __set__(self, instance, value):
> 
>4.
> 
># If null=True, we can assign null here, but otherwise the value
> needs
> 
>5.
> 
># to be an instance of the related class.
> 
>6.
> 
>if value is None and self.field.null == False:
> 
>7.
> 
>raise ValueError('Cannot assign None: "%s.%s" does not allow
> null values.' %
> 
> 
> 
>1.
> 
>(instance._meta.object_name,
> self.field.name))
> 
> 
> 
> now, also checking the stack (and even debugging) it seems like this comes
> earlier than save.
> 
> 
> *My question: **Is this somehow expected, is this a bug/a regression?*
> 
> If it's expected, I'll find another workaround; if it's a bug, I can add a
> ticket.
> 
> 
> Thanks!
> 
> Stefano
> 
> 
> 
> Stacktrack
> 
> 
>- /home/3h/django/django/contrib/admin/options.py in add_view
>1.
> 
>   if form.is_valid():
> 
>   ...
>▶ Local vars 
>- /home/3h/django/django/forms/forms.py in is_valid
>1.
> 
>   return self.is_bound and not bool(self.errors)
> 
>   ...
>▶ Local vars 
>- /home/3h/django/django/forms/forms.py in errors
>1.
> 
>   self.full_clean()
> 
>   ...
>▶ Local vars 
>- /home/3h/django/django/forms/forms.py in full_clean
>1.
> 
>   self._post_clean()
> 
>   ...
>▶ Local vars 
>- /home/3h/django/django/forms/models.py in _post_clean
>1.
> 
>   self.instance = construct_instance(self, self.instance,
> opts.fields, opts.exclude)
> 
>   ...
>▶ Local vars 
>- /home/3h/django/django/forms/models.py in construct_instance
>1.
> 
>   f.save_form_data(instance, cleaned_data[f.name])
> 
>   ...
>▶ Local vars 
>- /home/3h/django/django/db/models/fields/__init__.py in save_form_data
>1.
> 
>   setattr(instance, self.name, data)
> 
>   ...
>▶ Local vars 
>- /home/3h/django/django/db/models/fields/related.py in __set__
>1.
> 
>   (instance._meta.object_name,
> self.field.name))
> 
>   ...
>▶ Local vars 

-- 
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/201402250959.51184.shai%40platonix.com.
For more options, visit https://groups.google.com/groups/opt_out.