Re: To keep or not to keep: logging of undefined template variables
On Thursday 16 March 2017 12:03:07 Tim Graham wrote: > Ticket #18773 [0] added logging of undefined template variables in > Django 1.9 [1], however, I've seen several reports of users finding > this logging more confusing than helpful. With channels hitting 2.0 and the already large stack of moving parts surrounding Django you need some basic system administration skills and programming experience to work with the system. And there are quite a few examples to link to from the user's list that deal with those moving parts rather then Django itself. It is *not* an application that you download, install and run. An introduction "What you need to know before starting Django" would help a lot in this respect and explaining the noisiness of some logging belongs in there. Because it *is* useful if you defined that variable to True in your settings, and it's working in all projects but this one. It could be there's an extra piece of context middleware that uses the same name and deletes the variable from the context. It could be there's a Mixin missing in the view hierarchy. Or a typo you don't notice anymore after plowing through 20+ included template bits. Noisy logging is exactly what you want when debugging. It should log things that may be working as designed, especially things that are ambiguous (like undefined and false). Another thing is that logging is the ugly duckling of Django. It's not mentioned much if at all in the tutorial. It is not mentioned at all in "How to write reusable apps" and it shows in the eco system. It's like finding a diamond when an app actually has logging implemented. But it also means that novice users touching the LOGGING configuration are exceptions and I don't think Django should cater to the exceptions. -- Melvyn Sopacua -- 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/70987480.KqXOiOpzpV%40devstation. For more options, visit https://groups.google.com/d/optout.
re :GSOC 2017 Project - Test framework cleanup
I'm doing my UG 3rd year .I m interested to work with Django in Test framework cleanup idea so please help where to start with and help me to draft proposal -- 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/3e620721-28e9-4413-b25d-5707f3cacc49%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: re :GSOC 2017 Project - Test framework cleanup
At this late stage, it's highly unlikely that you'd be able to put together a successful proposal, and demonstrate your ability to execute on it. We encourage students to spend some time contributing before proposal stage, to give us a better idea of the ability to complete their tasks. Further, students are expected to research and draft their proposals with little help. We're able to provide guidance on specific questions, but we won't help you to write your proposal. Research is a big component of GSOC. On Monday, 27 March 2017 06:38:38 UTC+11, Hari kiran wrote: > > I'm doing my UG 3rd year .I m interested to work with Django in Test > framework cleanup idea so please help where to start with and help me to > draft proposal > -- 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/a7374369-c484-41ff-a4a7-c19aa8d458c3%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: Deprecate is_superuser, is_staff and is_active
Am Freitag, 24. März 2017 14:12:44 UTC+1 schrieb Collin Anderson:
>
> Hi Thomas,
>
> "If the user should have all permissions, then why not give him all these
> permissions at database level?" - I have some use cases where there are
> only 3-5 people that need to log into the admin. I don't really need to set
> different levels of access for different people. I also don't want to have
> to go through and add new permissions to every person every time I add a
> model. So, I just mark them all as is_superuser and don't use permissions
> at all. It keeps things simple.
>
> Something like this might handle your situation:
> class MyUser:
> # etc
> is_superuser = False
> is_staff = property(lambda u: u.has_perm('admin'))
>
>
Yes, configuring permission each time you add a model makes no fun. I have
to think about this again.
Regards,
Thomas Güttler
--
You received this message because you are subscribed to the Google Groups
"Django developers (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit
https://groups.google.com/d/msgid/django-developers/abd56b3b-a0af-4fd8-847e-1ea7d06dd9b6%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
