[Twisted-web] Re: [Twisted-Python] again on nested sequence

[Valentino Volonghi aka Dialtone]

On Mon, 17 Jul 2006 15:39:10 -0200, Manlio Perillo <manlio_perillo at libero.it> wrote:
>And what about my first solution?
>http://twistedmatrix.com/pipermail/twisted-web/2006-July/002813.html

Better, although it rewrites the sequence renderer for more or less the same functionality. Not too bad of course but could be avoided with less code and more templates (that usually are dealt with by the designer).

>> The second is that IData is not for external use but rather internal
>> Nevow usage.
>>
>
>Ok, thanks for the advice.
>I have read about this trick in a message in the archive.
>
>Only one last question.
>I have read the whole ml archive but I was unable to find any message
>where it is explained why the context is bad.

The context has some bad points:
1) Changes the rules for passing arguments to python functions, instead of
   using normal foo(a, b, c) you do ctx.remember(a, IA)... and foo(ctx), then
   in foo you do IA(ctx) and so on. While this might have an advantage after
   an initial analysis it isn't like that at all since you can always use
   **kwargs and grab the arguments you need from kwargs, and kwargs is
   standard python convention (although explicitly defining arguments is 
   better for most cases).
2) It is slow... each adaptation is a non-trivial function call that might
   end up with multiple lookups into a tree. Of course there are 
   optimizations that could solve this problem but nobody dared to write them
   AND test them AND merge with trunk.
3) The context is slow in a way that can hardly be optimized because for each
   branch in the rendering/childlocating procedures a new context is created.
   I don't have real numbers but I can presume that for each request a 
   minimum of 3 contexts for a mostly static page at root level and an
   unlimited maximum of object creation/collection and this for _each_  
   request.
4) The context makes non trivial understanding what instead should be trivial
   because it saves state that is reused later breaking the tracebacks.

This are the first 4 reasons that came to mind.

>Ok.
>But I'm searching a simple solution that is database friendly; that is,
>where I can map directly database queries to data directives.

Just like everyone else does. Besides that writing a simple function like the following:

def mapComments(comments, for_atom=False):
    for comment in comments:
        yield dict(rank=comment[0],
                   author=comment[1],
                   id=comment[2],
                   body=comment[3],
                   date=comment[4]
                  )

Will give you a dict interface over the comments rows returned from the database without losing much performance compared to the situation without that functions (also thanks to generators).

Also consider that it's better to put time in creating something that makes a specific problem more generic so that an already existing tool can be used to solve it rather than creating many different solutions to the same problem.