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 custom doctypes into account, which are perfectly valid to use (at least for some browsers ;)): http://static.cdn.ubuntu-de.org/xhtml1-strict-uu.dtd";> Cheers, Florian -- 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/-/io3ZhcGQhGUJ. 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: 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 Gaynor wrote:
>
> > When I did this externally a number of years ago, I basically subclassed
> > ManyToManyField, overrode a bunch of code (quite a bit of copy paste as
> > I recall), and it's related manager and made it return a custom
> > queryset, which used a cache off of the object, which was populated by
> > another custom queryset which overrode iterator() in order to do the
> > bulk loading.
>
> I've had another go, and I think it should be a lot more convincing now.
>
> https://code.djangoproject.com/attachment/ticket/16937/prefetch_3.diff
>
> It supports arbitrary depth, so you can do things like:
>
> User.objects.prefetch_related('groups__permissions')
>
> and it will also traverse singly-related objects (foreign key and
> one-to-one) in the chain.
>
> The implementation is significantly nicer, as it splits up
> responsibilities between QuerySet and the related managers the way it
> ought to be. One piece of evidence that the separation is good is that I
> implemented support for GenericRelations as a final step, and did so
> without touching the core 'prefetch_related' code at all - I simply
> added some methods to the manager produced by GenericRelation. This also
> means that the implementation could provide support for things like
> GenericRelation but in 3rd party apps.
>
> The implementation can also cope with the presence of a
> prefetch_related() fields already on any prefetched QuerySets (which can
> happen if a default manager has used prefetch_related), and will simply
> fold in the work to optimize the queries.
>
> With these things in place, it was literally a couple of lines to take
> one of my admin pages from 176 queries to 8.
>
> I think the combination of features here makes it a *very* compelling
> alternative to doing it outside core. Have I convinced you Alex? :-)
>
> I would like at some point to tackle the ability to prefetch objects
> with custom filters, as discussed on the ticket, rather than just the
> 'all()' case. However, that can wait, and I'd like some people to have a
> bash on this and find the bugs. It would be really nice if this could
> get in before the 1.4 alpha, because it has turned out to be a pretty
> neat feature I think.
>
> Regards,
>
> Luke
>
> --
> "It is a truth universally acknowledged, that a single man in
> possession of a good fortune, must be in want of a wife." (Jane
> Austen)
>
> Luke Plant ||http://lukeplant.me.uk/
--
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.
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 in section 1.6 say a feature "will be deprecated". Can we have a consistent policy on this terminology? Miriam-Webster: "deprecate: to express disapproval of" So something is 'deprecated' as soon as we say we are going to remove it - we are expressing disapproval, but allowing it to continue temporarily. The confusing thing from Python terminology is that we then add PendingDeprecationWarning, followed by DeprecationWarning, which suggest that deprecation is something that will happen in the *future*, the thing that happens when we finally remove it. But that isn't normal English usage, and we can't sensibly use 'deprecated' for both the beginning and the end of the process. So I'd suggest that we stick to: - deprecated = the first time we say we are going to remove it, and normally means we add PendingDeprecationWarning - removed - when we actually remove. In the deprecation timeline, we can simply say "X will be removed", or "X will be removed in favour of Y". If it is outside the normal deprecation policy in some way, we can mention that, otherwise no need to say which version it was deprecated in. In our release notes, we carry on announcing deprecation as we are doing now. The only problem is that our 'deprecation timeline' effectively becomes a 'removal timeline', but I think it will be clear enough if the rest of our terminology is. Comments? Luke [1] https://docs.djangoproject.com/en/dev/internals/deprecation/ -- "It is a truth universally acknowledged, that a single man in possession of a good fortune, must be in want of a wife." (Jane Austen) Luke Plant || http://lukeplant.me.uk/ -- 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: 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. -- 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: 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, will make it into a couple of days. The way it is done now still requires that two days but also make me think about separate deprecation concept, about what part of django is public and 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. On 2 окт, 00:10, Luke Plant wrote: > 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 in section 1.6 say a feature "will be deprecated". > > Can we have a consistent policy on this terminology? > > Miriam-Webster: > > "deprecate: to express disapproval of" > > So something is 'deprecated' as soon as we say we are going to remove it > - we are expressing disapproval, but allowing it to continue > temporarily. The confusing thing from Python terminology is that we then > add PendingDeprecationWarning, followed by DeprecationWarning, which > suggest that deprecation is something that will happen in the *future*, > the thing that happens when we finally remove it. But that isn't normal > English usage, and we can't sensibly use 'deprecated' for both the > beginning and the end of the process. > > So I'd suggest that we stick to: > > - deprecated = the first time we say we are going to remove it, > and normally means we add PendingDeprecationWarning > > - removed - when we actually remove. > > In the deprecation timeline, we can simply say "X will be removed", or > "X will be removed in favour of Y". If it is outside the normal > deprecation policy in some way, we can mention that, otherwise no need > to say which version it was deprecated in. In our release notes, we > carry on announcing deprecation as we are doing now. The only problem is > that our 'deprecation timeline' effectively becomes a 'removal > timeline', but I think it will be clear enough if the rest of our > terminology is. > > Comments? > > Luke > > [1]https://docs.djangoproject.com/en/dev/internals/deprecation/ > -- > "It is a truth universally acknowledged, that a single man in > possession of a good fortune, must be in want of a wife." (Jane > Austen) > > Luke Plant ||http://lukeplant.me.uk/ -- 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.
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 cookies. I believe that our signing implementation is secure and correct. However, I know that users of Django screw up from time to time. It's not uncommon to see SECRET_KEY in a git repository, and that value is often used in production. If SECRET_KEY is compromised, an attacker can sign arbitrary cookie data. The use of pickle changes an attack from "screw up the data in this application" to "arbitrary remote code execution". In light of this, we should be conservative and use JSON by default instead of pickle. -Paul -- 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: 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, and encourages you to upgrade even if you don't have time to make application changes. This stability is an important promise for many of our users. -- 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: 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 user, who himself doesn't hack into django may use third-party libs that do: migration, automatic caching, any orm, form and template extenders. And for the developers of that libs deprecation is a waste not help, at least what it feels for me. For common user this means he cannot upgrade until all hos libs upgraded or he himself is forced into hacking them. So dropping deprecation could be a strategic win in a sense it will help django infrastructure flourish. At least this is worth considering. -- 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: 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 cookies.
I believe that our signing implementation is secure and correct.
However, I know that users of Django screw up from time to time. It's
not uncommon to see SECRET_KEY in a git repository, and that value is
often used in production. If SECRET_KEY is compromised, an attacker
can sign arbitrary cookie data. The use of pickle changes an attack
from "screw up the data in this application" to "arbitrary remote code
execution".
In light of this, we should be conservative and use JSON by
default instead of pickle.
"""
If the size of the cookie turns out to be a problem, using compressed JSON
instead of JSON is a very simple change. I tested on my crummy old laptop, and
using zlib one can compress + decompress roughly 5000 short strings in a
second. On reasonable hardware I guess that figure will be 1-3 per
thread. In the limit, when the compressed size is around 4Kb, one can compress
about 500 strings a second (or 1000-3000 on reasonable hardware). So, this
could cause some performance concerns in extreme cases, but probably not enough
to worry about.
The test program is simple:
import bz2
from datetime import datetime
import json
import random
import zlib
nums = [random.randint(0, 10) for _ in range(0, 1000)]
var = json.dumps({'nums': nums})
start = datetime.now()
for i in range(0, 1000):
compressed = zlib.compress(var)
uncompressed = zlib.decompress(compressed)
print datetime.now() - start
print len(var)
print len(compressed)
Note that when compressing random integers, one will still get over 50%
compression. On more realistic data, the compression should be more.
- 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.
