#14633 - organization of settings docs

[Tim Graham]

I'd appreciate feedback on #14633- 
"Organize settings reference docs". So far I've broken out the settings 
for each contrib app into their own sections. The one comment on the pull 
request suggests further breaking up the settings listed in the "Core 
settings" section, e.g. logging, caches, globalization (i18n/l10n), email, 
file uploads/media, storages, and security. I don't feel strongly about 
this proposal: it could be useful, but it could also be ambiguous as to 
which section a particular settings belongs in.

The pull request also suggests organizing the default settings.py in a 
similar fashion.  While it may be outside of the scope of this ticket, it 
could be worthwhile to discuss that suggestion as well.

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To view this discussion on the web visit 
https://groups.google.com/d/msg/django-developers/-/Uku6Vo8oCvIJ.
To post to this group, send email to django-developers@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Re: Tutorials

[Tim Graham]

Hi Daniele,

I think additional tutorials would be welcome. My suggestion, before you 
dive in and start writing, would be to create a ticket with an outline of 
the proposed tutorial.  That will give the community a chance to take a 
look and provide feedback and suggestions before you spend time doing the 
actual writing.

For some ideas, here is the list of "coming soon" tutorials that were at 
the end of tutorial 4 for a long time:

   - Advanced form processing 
   - Using the RSS framework 
   - Using the cache framework (see ticket below) 
   - Using the comments framework (not sure about this, since I think 
   comments may be removed from Django, see #18965) 
   - Advanced admin features: Permissions 
   - Advanced admin features: Custom JavaScript

These may not be the best options at this point, but someone thought they 
were good ideas at one point.

In addition, here are some tutorial tickets that have been "accepted":

#16526  - Add a tutorial on 
caching
#19106  - Add new tutorial on 
breaking templates into blocks

I think your suggestion of logging is a good candidate -- you may want to 
take a look at #19395  as well.

Thank-you for your contributions thus far, and I look forward to seeing 
what you come up with in the future. :-)

Tim

On Friday, January 4, 2013 5:42:44 PM UTC-5, Daniele Procida wrote:
>
> I am one of those people who can only learn things by doing them, and 
> finds it very hard to grasp things from reference materials. The Django 
> documentation is excellent on the latter, but not quite so good on the 
> tutorials that would guide me through doing things in a way that will help 
> me learn. 
>
> I've made a couple of tutorial contributions so far (which if I am honest 
> simply reflect the steps I took when I was learning the topic). They are 
> the testing tutorial <
> https://docs.djangoproject.com/en/1.5//intro/tutorial05/> and a 
> uWSGI/nginx tutorial, which though it may not be quite right for the Django 
> docs has gone into the uWSGI docs. 
>
> I'd like to contribute more tutorials to the documentation, and since the 
> next thing I need to get to grips with is logging I will write my own notes 
> so I remember how to do it, and I could create a tutorial for it. 
>
> Would that be useful for the documentation? I realise that a tutorial is 
> always going to be a partial and incomplete introduction to a subject, but 
> newcomers need to start with something concrete, and it gives them some 
> purchase on the reference material that is already provided. 
>
> Are there other topics that really ought to have tutorials written for 
> them? 
>
> Daniele 
>
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To view this discussion on the web visit 
https://groups.google.com/d/msg/django-developers/-/vdn9xXpBvEAJ.
To post to this group, send email to django-developers@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Re: Possible memory leak with CBV's ?

[Andrey Antukh]

Thank you very much for the great explanation.
I'll try to avoid using __del__ methods whenever possible.

Andrey

2013/1/7 Anssi Kääriäinen 

> Avoid __del__ if possible,




-- 
Andrey Antukh - Андрей Антух - 
http://www.niwi.be/about.html
http://www.kaleidos.net/A5694F/

"Linux is for people who hate Windows, BSD is for people who love UNIX"
"Social Engineer -> Because there is no patch for human stupidity"

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-developers@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Re: Possible memory leak with CBV's ?

[Anssi Kääriäinen]

On 7 tammi, 16:06, Andrey Antukh  wrote:
> I've been experimenting, and I found a strange behavior. In the View class
> if I define the __ del__ method, and is never executed. In instances of
> other classes, which are members of View, feel the same behavior (eg
> HttpRequest is not removed by a garbage collector).
>
> The fault lies primarily in this line (django/views/generic/base.py):
>
> def view(request, *args, **kwargs):
>     # [...]
> *    if hasattr(self, 'get') and not hasattr(self, 'head'):
>         self.head = self.get*
>     # [...]
>
> When you create alias methods once the class has been instantiated seems to
> make some references (cyclical?) which prevent the garbage collector remove
> them.
>
> I have reproduced the same behavior with simple classes to verify the
> problem:https://gist.github.com/4475138
> If a custom view defines a head method, the problem disappears.
>
> So, is how it should work? I'm wrong about something?
>
> Thank you very much.

The reason is that if you define a __del__ method for a class, and an
instance of that class is part of a reference cycle, then Python will
not release any object which is reachable from the cycle. This is
ugly, and once you know this you know to avoid __del__ methods if
possible. More here: http://docs.python.org/2/library/gc.html#gc.garbage

You can try to have a special cleaner object - the idea is that on
__init__ of an in-cycle object you assign a cleaner object to self.
Pass the cleaner object the data you want to clean up. The data passed
must not be part of the cycle or the trick doesn't work. When the in-
cycle object is garbage collected, then the cleaner object will be
garbage collected too (only reference to it is from the in-cycle
object). Now, the __del__ of the cleaner object is called and you can
do cleanup there (again, assuming that the cleaner is not part of a
cycle). This is ugly but if you have a cyclic object and you need to
have __del__ I don't know of anything better (ideas welcome!).

This idea is implemented here: 
https://github.com/akaariai/django_pooled/blob/master/base.py#L134
- the idea is that when a ConnectionWrapper is created we also create
PoolReleaser. The PoolReleaser has the needed data to release a
connection to the pool. When the ConnectionWrapper is gc'd, the
PoolReleaser's __del__ is called and we can release the connection
back to pool.

Avoid __del__ if possible,
 - Anssi

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-developers@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Possible memory leak with CBV's ?

[Andrey Antukh]

I've been experimenting, and I found a strange behavior. In the View class
if I define the __ del__ method, and is never executed. In instances of
other classes, which are members of View, feel the same behavior (eg
HttpRequest is not removed by a garbage collector).

The fault lies primarily in this line (django/views/generic/base.py):

def view(request, *args, **kwargs):
# [...]
*if hasattr(self, 'get') and not hasattr(self, 'head'):
self.head = self.get*
# [...]

When you create alias methods once the class has been instantiated seems to
make some references (cyclical?) which prevent the garbage collector remove
them.

I have reproduced the same behavior with simple classes to verify the
problem: https://gist.github.com/4475138
If a custom view defines a head method, the problem disappears.

So, is how it should work? I'm wrong about something?

Thank you very much.

--
Andrey Antukh - Андрей Антух - 
http://www.niwi.be/about.html
http://www.kaleidos.net/A5694F/

"Linux is for people who hate Windows, BSD is for people who love UNIX"
"Social Engineer -> Because there is no patch for human stupidity"

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-developers@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Re: About Understanding of source code

[Diederik van der Boor]

Hi,

What I find really valuable is using a editor/tool that allows you to jump to 
class/method/function definitions.
I'm using PyCharm for Django development and it really helps me to dive into 
Django code (Cmd+Click on a symbol).

Greetings,
Diederik

Op 7 jan. 2013, om 05:57 heeft Mayur Patil  het 
volgende geschreven:

> Hello there,
> 
>   I want to understand how to get deep insight into Django code?
> 
>   Thank You.
> 
> -- 
> You received this message because you are subscribed to the Google Groups 
> "Django developers" group.
> To view this discussion on the web visit 
> https://groups.google.com/d/msg/django-developers/-/CcvuNeLYrJsJ.
> To post to this group, send email to django-developers@googlegroups.com.
> To unsubscribe from this group, send email to 
> django-developers+unsubscr...@googlegroups.com.
> For more options, visit this group at 
> http://groups.google.com/group/django-developers?hl=en.

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-developers@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Re: About Understanding of source code

[Rohan Jain]

I would suggest you to start by looking into the contrib apps. This would
give you great insights onto writing Django apps. Now that you are already
in the source code, you can stumble into the rest of it or even the core.
This way has been particularly helpful to me.

Also, you might want to look into this great talk by James Bennett, titled
"Django in Depth": http://www.youtube.com/watch?v=t_ziKY1ayCo

--
Rohan Jain

On Mon, Jan 7, 2013 at 10:27 AM, Mayur Patil wrote:

> Hello there,
>
>   I want to understand how to get deep insight into Django code?
>
>   Thank You.
>
> --
> You received this message because you are subscribed to the Google Groups
> "Django developers" group.
> To view this discussion on the web visit
> https://groups.google.com/d/msg/django-developers/-/CcvuNeLYrJsJ.
> To post to this group, send email to django-developers@googlegroups.com.
> To unsubscribe from this group, send email to
> django-developers+unsubscr...@googlegroups.com.
> For more options, visit this group at
> http://groups.google.com/group/django-developers?hl=en.
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-developers@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.