Re: Project-wide cache prefix (low-level API)
On Jun 2, 9:51 am, batiste wrote: > What about the problem that you can, in theory, use the same > application several time (several instance) within the same project? There is a Google Summer of Code Project http://code.djangoproject.com/wiki/SummerOfCode2010 that will hopefully take care of these issues. Cheers, Stefan -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-develop...@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: Problem with randrange in django/middleware/csrf.py
> >> By playing around in a python session it seems that the call to the > >> system randrange with random.SystemRandom().randrange(0, > >> _MAX_CSRF_KEY) never stops (or doesn't seem to stop in less than 30 > >> minutes) whereas a call to the "normal" randrange with randrange(0, > >> _MAX_CSRF_KEY) happily returns the desired random number. This sounds like python is unable to get a secure random number from the OS. The OS can run out of entropy, it may even happen faster on shared systems. http://www.entropykey.co.uk/ says (and they probably know): "Applications that require random data, [...] read from this pool. The problem is that the pool is of fixed size (just 4kB) and as standard has limited entropy input. If an application tries to read from the pool, and there is not enough data to satisfy its request, the application is frozen in limbo until enough entropy has been collected to fill the pool to the point of being able to satisfy the request, leading to delays in the delivery of services." Sounds like what happened to you. > I'm unclear on why we even allow this code to work with the "default" > random implementation, which is based on a Messrne Twister, and > (quoting the Python docs here), "is completely unsuitable for > cryptographic purposes". To my understand that's how we're trying to > use it, and if I'm wrong here I wonder why we give preference to the > system random at all? If DEBUG=False, there shouldn't be a fallback to non-secure random numbers, maybe there shouldn't even be a fallback at all. If the host has not enough entropy, Django shouldn't fix it, an administrator should. Cheers Stefan -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-develop...@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: Model translation
Hi Hejsan, we discussed this topic at the sprints of DjangoCon.eu some time ago. There is a page in the wiki for this topic where we summarized some ideas: http://code.djangoproject.com/wiki/ModelInterNationalization Instead of one of the existing solutions (which all have serious drawbacks), I am in favor of approach number 4 on the wiki page: http://code.djangoproject.com/wiki/ModelInterNationalization#Multilingualmodelwithoneobjectperlanguage4 It avoids schema changes when a language is added and doesn't need JOINs for translating content. It also has drawbacks, but I would argue there are manageable. Please have a look at the proposal and it's API discussion. I agree with Jacob in that ModelTranslation will not be necessarily something for the Django core. We should rather identify issues or existing tickets which need to be resolved in order to go forward. The wiki page would be a good place to start collecting tickets (there's already one). Cheers Stefan -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-develop...@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: Model translation
Hi, > 1. You have an object for each language. This object contains some > language-attribute which makes it easy to filter stuff. Admin and views > are no-brainers. I think this is the right approach. A sample API is open for discussion here: http://code.djangoproject.com/wiki/ModelInterNationalization#Multilingualmodelwithoneobjectperlanguage4 Two points against other approaches: 1. In my opinion JOINs and serialization are a no-go for just querying a translatable model. Of course you can cache results of JOINs, but then you could just use a different solution. 2. The model has to scale with the number of languages. Sure, there's a finite number of languages and your project might only need three of them, but others may need 50. Having a db table for each language or having a column for each translatable value for each language is becoming a mess at the db level, even if it is abstracted nicely behind south and magic. There are use cases where the db must be accessible to other non-Django applications and good db design is important for that. I know that hacking that stuff in Django is fun and it might also work, but have a look at it from the non-abstracted site. It's not nice. Adding a language field and a grouping id for same objects in different languages to a model solves many problems. 1. Queries stay easy. 2. Object must not exist in language. 3. Falling back to other languages if object doesn't in desired language is easy. 4. Database stays easy Disadvantage: duplicated non-translatable fields across rows. This is not nice. However, syncing is still a no-brainer and scales with the number of languages, since you can update all non-translatable fields for the same objects in one query: UPDATE stuff WHERE group_id=123. Think of it as denormalization, something we do all the time anyways. This duplication can be abstracted away and the database still stays clean. There are definitely use cases where another approach might be faster (only three languages, one model). But we should go for the general use cases, with many languages. Concerning third party apps and their models These apps might add data to objects of my tables via Generic Foreign Keys. This isn't a problem for translation, because the third-party object "inherits" the language from my translated object. Concerning Ease of Integration I don't think that you shouldn't have to modify code in order for translation to work. A registration approach is nice, but when you build in translation of models as an afterthought there are many things you need to change anyways. Plug-and-Play can't really be a goal, you never know if it really works with a third party app. A translatable model is a design decision. It should be really easy to integrate a solution (like inheriting your models from e.g. TranslationModel), but code changes are probably unavoidable when you decide for translatable models too late in the development process. If you have other ideas/apps, please contribute to the wiki page, because this thread will end some time and will then be lost in the mailing list archives. Django Wiki on Model Internationalization: http://code.djangoproject.com/wiki/ModelInterNationalization Getting the ideas in a structured way, listing solutions and even linking to this thread, saves us from having this discussion over and over again. Cheers Stefan -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-develop...@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: a new template algorithm
Hello, I guess the most interesting point in this discussion is: > After a while that I spent time to develop new tags and filters > especially for > new projects, I began to think a way to implement a template engine > that > would let me no more write sort of "plugins" like tags and filters, a > thing that > really bother me. The template language is great, it's design decisions are sensible, but writing filters and tags is too complex and time-consuming. Unnecessarily so, as wrappers around creating template tags have shown (e.g. django-templatetag-sugar by Alex Gaynor). If people don't see a documented way of easily bringing features to their templates, they may switch the template engine or, well, start patching the template engine. Bottom line: we need to improve the template tag creation. Cheers Stefan -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-develop...@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.
