Re: Proposal: Let Context handle template loading (#7815)
On Wed, 2008-09-24 at 16:34 +0200, Johannes Dollinger wrote:
[...]
> tpl.render(Context({}, loader=PrefixLoader(['a', 'b', 'c'])))
> }}}
>
> This would fix #2949, #3544, #4278, #6834, and #7931. But it's a
> backwards incompatible change: If you rely on compile time side
> effects (e.g. {% load %}) in included templates, that will break.
>
> Opinions?
-1 from me, since it's backwards incompatible. It looks like most of
those feature requests (or at least the ones that are worth doing --
it's not clear that things like #3944 are worth it) can be done without
backwards incompatible behavioural changes.
The template context is the static rendering context, not the
compiling/loading context and it feels like this is blurring that
boundary.
Regards,
Malcolm
--~--~-~--~~~---~--~~
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 [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/django-developers?hl=en
-~--~~~~--~~--~--~---
Re: session backed form wizard
On Fri, Sep 26, 2008 at 9:29 PM, David Durham, Jr. <[EMAIL PROTECTED]> wrote: > I did find more information here: > > http://docs.djangoproject.com/en/dev/internals/contributing/ > > But this method appears to only run the tests in tests, not the tests > in django/contrib/formtools/tests. Is that correct? If so, is there > a different means of running tests in a tests.py file within a > package? Nevermind. I see the reference to testing contrib apps in the contributing doc. -Dave --~--~-~--~~~---~--~~ 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: session backed form wizard
> So I'm working on tests for this, and I can see the pattern for > writing tests by looking at django.contrib.formtools.tests.py, but I > don't see what the infrastructure is, if any, for running these tests. > The documentation here doesn't seem to have the info I need > > http://docs.djangoproject.com/en/dev/topics/testing/ I did find more information here: http://docs.djangoproject.com/en/dev/internals/contributing/ But this method appears to only run the tests in tests, not the tests in django/contrib/formtools/tests. Is that correct? If so, is there a different means of running tests in a tests.py file within a package? Thanks, Dave --~--~-~--~~~---~--~~ 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: Denormalisation, magic, and is it really that useful?
Hi, Erik. The main purpose is to have declarative form of composition field calculation definition. Not to write imperative actions/signal connection/etc. I've made only flexible generic solution. In future I plan to write high-level subclasses that will can with minimal input parameters make all work very comfortable for developers. And then there will be no need to write all denormalisation functionality once again and again, from project to project. On Sep 26, 8:56 pm, Erik Allik <[EMAIL PROTECTED]> wrote: > I was just wondering.. Why all this abstraction? > > Why do we need a separate field for denormalization? Can't we just use > regular fields and simply set up denormalization in a procedural way > in the constructor? All that needs to be done to create a denormalized > field is connect a few signals maybe or do some expensive compuation > after modifying a field. But maybe I'm missing something crucial. > > Erik > --~--~-~--~~~---~--~~ 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: session backed form wizard
>> http://code.djangoproject.com/ticket/9200 > > I see this pattern a lot, and I guess it will be quite useful - I was > just thinking about writing someting like this class myself. > I have marked the ticked as "Need Docs" and "Need tests", and the status as > DDN. So I'm working on tests for this, and I can see the pattern for writing tests by looking at django.contrib.formtools.tests.py, but I don't see what the infrastructure is, if any, for running these tests. The documentation here doesn't seem to have the info I need http://docs.djangoproject.com/en/dev/topics/testing/ Thanks, Dave --~--~-~--~~~---~--~~ 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: Status report on CPython 2.6
On Fri, Sep 26, 2008 at 1:09 PM, zvoase <[EMAIL PROTECTED]> wrote: > > Just wondering if I could ask how compatible Django is with CPython > 2.6. I know that it should work fine anyway, but I thought it a good > idea just to check. Has anyone looked into this? > > There are no known problems with Django 1.0 running on Python 2.6. When I first tried it (back around 2.6 beta2) there were a few issues (which if you're really interested you can find in the tracker by searching on the python26 keyword), but all were resolved before Django 1.0. Just prior to 1.0 going out I ran the Django test suite on Linux and Windows with the latest availble Python 2.6 beta (3 on Linux, 2 on Windows because I don't have the tools to build it there, and no beta3 binaries were available for Windows) and there were no problems. Karen --~--~-~--~~~---~--~~ 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: Status report on CPython 2.6
Search the archives. This has been discussed a few times before. I believe someone (Karen?) has even been testing for 2.6 compatibility and a few changesets have been committed specifically for that purpose. IIRC, the policy is to support 2.6 where-ever practical as long as it doesn't break support for 2.3-2.5. Again, the previous discussions will provide answers - although, now that 1.0 is out, I suppose an update on that status wouldn't hurt. On Fri, Sep 26, 2008 at 1:09 PM, zvoase <[EMAIL PROTECTED]> wrote: > > Hi, > Just wondering if I could ask how compatible Django is with CPython > 2.6. I know that it should work fine anyway, but I thought it a good > idea just to check. Has anyone looked into this? > > Regards, > Zack > > > -- Waylan Limberg [EMAIL PROTECTED] --~--~-~--~~~---~--~~ 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Status report on CPython 2.6
Hi, Just wondering if I could ask how compatible Django is with CPython 2.6. I know that it should work fine anyway, but I thought it a good idea just to check. Has anyone looked into this? Regards, Zack --~--~-~--~~~---~--~~ 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: Denormalisation, magic, and is it really that useful?
I was just wondering.. Why all this abstraction? Why do we need a separate field for denormalization? Can't we just use regular fields and simply set up denormalization in a procedural way in the constructor? All that needs to be done to create a denormalized field is connect a few signals maybe or do some expensive compuation after modifying a field. But maybe I'm missing something crucial. Erik On 26.09.2008, at 18:45, Alex Koshelev wrote: > > Hi, guys! > > For a long time I have thoughts to make composition/denormalisation a > little bit easier and reusable. But I have no time to implement my > ideas. > Inspired by Anrew's blog post and its thread I recently wrote some > code. And I think that it really may be useful and cover most of > denormalisation use cases in Django. > > And this is an example of Anrew's code but with my CompositionField: > > class Picture(models.model): >user = models.ForeignKey(User) >user_username = CompositionField( > native=models.CharField(max_length=150), > trigger=dict( > sender_model=User, > field_holder_getter=lambda user: > user.picture_set.all(), > do=lambda picture, user, signal: > user.username >) > ) >image = models.ImageField(upload_to="foo") >title = models.CharField(max_length=100) > > Its more verbose but very generic and can be customized. And free > bonus - auto-generated `update_user_username` method. > > The code available here [1]. Its very generic but allows to write more > high-level subclasses with some introspection. > > Today I've written the blog post about it and my future suggestions. > It is in Russian[2], here is a google-translated version [3] (but with > broken code blocks) that I think can help to understand some concepts. > And it holds more usage examples. > > I have many new ideas of how my solution can be improved and I what to > hear you opinions about it. > > Thanks. > > [1]: http://svn.turbion.org/turbion/trunk/turbion/utils/composition.py > [2]: http://webnewage.org/post/2008/9/26/krasivaya-kompozitsiya/ > [3]: > http://translate.google.com/translate?u=http%3A%2F%2Fwebnewage.org%2Fpost%2F2008%2F9%2F26%2Fkrasivaya-kompozitsiya%2F%23comment_720=en=UTF-8=ru=en > > On Sep 23, 12:03 am, Andrew Godwin <[EMAIL PROTECTED]> wrote: >> So, hello everyone. I figure this list is the best place to ask this, >> but please feel free to deride me if not... >> >> After all the talk of multiple databases, and non-relational >> databases >> (bigtable, couchdb, etc.) that went on at DjangoCon and >> afterward,I've >> been thinking about denormali[s/z]ation and how to make it easier in >> Django; previously, I had thought denormalisation was something you >> did >> to ruin your database, but I can now see it can be additive as well. >> >> In this vein, last weekend I decided to see how easy it would be to >> write a magical DenormalisationField which handled all the >> synchronising >> of data from the relevant tables given a normal ForeignKey >> relationship; >> the results are athttp://www.aeracode.org/2008/9/14/denormalisation-follies/ >> >> Basically, yes, it is possible, and a lot of people (eight! for my >> blog, >> that's a lot) seem to like the idea; it certainly saves having to >> write >> that replicate-on-save logic that otherwise goes with this kind of >> schema design. >> >> Given the fact that it seems like a reasonably common thing to do in >> large-scale applications, I'd like to know what people think about >> adding this kind of thing into core (while I have a standalone >> implementation, that needs some hacks I'd like to see gone). My main >> issues with this idea are: >> >> 1) It relies on having a ForeignKey pointing to the other model, so >> this >> might not work for non-relational databases (well, unless ForeignKeys >> are still allowed in that case, but they just perform expensive >> SELECTs >> as well as possibly printing abusive messages to stderr). >> >> 2) I'm not sure how common a use case this is; it sounds like it >> might >> be verging into the long tail a bit. >> >> 3) People also want other things denormalised - count()s, aggregate >> queries, etc. Of course, writing fields for these too is similar, and >> I'd be happy to do it, but it might mean that even if the case for >> denormalisation is good this is only a piece of the puzzle. >> >> So, I'd love people's opinions about where I should take this - to a >> dark corner and hide it, to a separate app like django-extensions >> (which >> involves keeping the horrid hacks in there), into a separate app but >> with patches to core to make it less hackish (i.e. more signals), >> or add >> it as my 1.1 pony with the proviso that I'm happy to write all the >> code. >> >> Andrew > > --~--~-~--~~~---~--~~ You received this message
Django Book 1.0
Hello, This is directed at the benevolent dictators for life, Django. With Django 1.0 out the door, I was curious about the status of the Django book-- specifically if there is anything I could do to help with updating it for Django 1.0. The last post I saw about it said that the book would be updated after 1.0 was released. I'd be willing to help out with updating the book-- are there plans to make the source code available so the community could contribute? Thanks! Jeff Anderson signature.asc Description: OpenPGP digital signature
Re: Denormalisation, magic, and is it really that useful?
Hi, guys! For a long time I have thoughts to make composition/denormalisation a little bit easier and reusable. But I have no time to implement my ideas. Inspired by Anrew's blog post and its thread I recently wrote some code. And I think that it really may be useful and cover most of denormalisation use cases in Django. And this is an example of Anrew's code but with my CompositionField: class Picture(models.model): user = models.ForeignKey(User) user_username = CompositionField( native=models.CharField(max_length=150), trigger=dict( sender_model=User, field_holder_getter=lambda user: user.picture_set.all(), do=lambda picture, user, signal: user.username ) ) image = models.ImageField(upload_to="foo") title = models.CharField(max_length=100) Its more verbose but very generic and can be customized. And free bonus - auto-generated `update_user_username` method. The code available here [1]. Its very generic but allows to write more high-level subclasses with some introspection. Today I've written the blog post about it and my future suggestions. It is in Russian[2], here is a google-translated version [3] (but with broken code blocks) that I think can help to understand some concepts. And it holds more usage examples. I have many new ideas of how my solution can be improved and I what to hear you opinions about it. Thanks. [1]: http://svn.turbion.org/turbion/trunk/turbion/utils/composition.py [2]: http://webnewage.org/post/2008/9/26/krasivaya-kompozitsiya/ [3]: http://translate.google.com/translate?u=http%3A%2F%2Fwebnewage.org%2Fpost%2F2008%2F9%2F26%2Fkrasivaya-kompozitsiya%2F%23comment_720=en=UTF-8=ru=en On Sep 23, 12:03 am, Andrew Godwin <[EMAIL PROTECTED]> wrote: > So, hello everyone. I figure this list is the best place to ask this, > but please feel free to deride me if not... > > After all the talk of multiple databases, and non-relational databases > (bigtable, couchdb, etc.) that went on at DjangoCon and afterward,I've > been thinking about denormali[s/z]ation and how to make it easier in > Django; previously, I had thought denormalisation was something you did > to ruin your database, but I can now see it can be additive as well. > > In this vein, last weekend I decided to see how easy it would be to > write a magical DenormalisationField which handled all the synchronising > of data from the relevant tables given a normal ForeignKey relationship; > the results are athttp://www.aeracode.org/2008/9/14/denormalisation-follies/ > > Basically, yes, it is possible, and a lot of people (eight! for my blog, > that's a lot) seem to like the idea; it certainly saves having to write > that replicate-on-save logic that otherwise goes with this kind of > schema design. > > Given the fact that it seems like a reasonably common thing to do in > large-scale applications, I'd like to know what people think about > adding this kind of thing into core (while I have a standalone > implementation, that needs some hacks I'd like to see gone). My main > issues with this idea are: > > 1) It relies on having a ForeignKey pointing to the other model, so this > might not work for non-relational databases (well, unless ForeignKeys > are still allowed in that case, but they just perform expensive SELECTs > as well as possibly printing abusive messages to stderr). > > 2) I'm not sure how common a use case this is; it sounds like it might > be verging into the long tail a bit. > > 3) People also want other things denormalised - count()s, aggregate > queries, etc. Of course, writing fields for these too is similar, and > I'd be happy to do it, but it might mean that even if the case for > denormalisation is good this is only a piece of the puzzle. > > So, I'd love people's opinions about where I should take this - to a > dark corner and hide it, to a separate app like django-extensions (which > involves keeping the horrid hacks in there), into a separate app but > with patches to core to make it less hackish (i.e. more signals), or add > it as my 1.1 pony with the proviso that I'm happy to write all the code. > > Andrew --~--~-~--~~~---~--~~ 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
