Re: deprecation vs removal

> It allows you the luxury of taking the time, > and encourages you to upgrade even if you don't have time to make > application changes. It doesn't really saves time for me. But maybe I'm an uncommon case. Some of things I do with django are pretty tied up to its internals. But even a common

Re: deprecation vs removal

> what is not cause they have separate deprecation policies. It also > encourages me to slack at upgrading and use something deprecated for a > while longer. Yes, but in the meantime you're using the newer, better supported, and often more-secure code. It allows you the luxury of taking the time,

Removing pickle from cookie-based session storage

We recently committed changes to 1.4 that added signed cookie based session storage. Session data is pickled, signed, and sent to the client as a cookie. On receipt of the cookie, we check the signature, unpickle, and use the data. We could use JSON instead of pickle, at the expense of longer

Re: deprecation vs removal

For me, as an extensive django user, a whole deprecation thing is somewhat useless and confusing. I'd prefer deprecated elements were just removed. Then when I upgrade django I'll just upgrade it and fix any wrong calls, imports, monkey patches etc. Proper upgrading docs, which you write anyway,

Re: deprecation vs removal

I agree with your analysis of the word, but also agree that the terminology is likely to confuse people for a while. PendingDeprecation is a rather unfortunate construction. If we can pull through the phase where people are confused, our terminology will be more precise for the change. +1 from me.

deprecation vs removal

Hi all, The Django deprecation timeline [1] is very inconsistent in its usage of the terminology 'deprecated'. For example, the 1.5 section often says "is deprecated" or "has been deprecated", when what they mean is "will be removed", which is what the other sections generally tend to say. Some

Re: prefetch_related - new feature suggestion

This look great! I think this approach is better than the one's used by other orms that force a single, heavy, query to retrieve the whole many to many object graphs, would be nice to see it in 1.4 thanks Nicola On 1 Ott, 04:42, Luke Plant wrote: > On 29/09/11 21:43, Alex

Re: How about doctype webdesign helper

Hi, I think it's unnecessary, since nowadays many people tend to go towards html5 and there you usually just have "" + it's something you put into the document once for a project, so I guess it would require more time to look up the tag than to lookup the doctype :) Plus you tag doesn't take

filter users by group in the admin user_list

Hello, When using groups, it would be handy to filter users by group. Ticket #16835 proposes to add this to the admin by default. Do we need to limit the number of groups displayed, if there are many many groups? (I am not sure if people are using groups that way, I use them primarily to manage