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 c
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 Gaynor wrote:
>
> > Whe
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 i
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.
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, wi
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 cooki
> 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,
> 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 use
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
