Re: Proposal: make 1.4 more explicit

[Alex Kamedov]

On Fri, Apr 1, 2011 at 12:35 AM, Patryk Zawadzki wrote:

> Hi group,
>
> Currently Django has its own concept of namespacing (apps) and mostly
> ignores Python modules. I'd like to propose using Python paths
> wherever we can instead of apps. This would solve a lot of problems
> with conflicting submodule names that plague maintainers of reusable
> apps and frameworks. Currently if you try to provide a base
> frobnicator model and you choose to do so in
> "fooframework.frobnicator.models", you pretty much forbid the users
> from putting derived classes in a local module named
> "frobnicator.models". Bad things happen when two apps start to provide
> "frobnication_tags".
>

I propose the following:
>  * make the internal model handling operate on full paths to the
> classes, rather than just the app names and class names
>  * make the DB table names use full python paths instead of just the
> app name and the class name
>
I think it's may be interest to you to see on app-loading branch [1]
developed by Arthur Koziel in GSoC2010 [2].
It improve model loading mechanism and add ability to specify model table
name prefix in your app.
See the tests [3] for examples.

[1]
http://code.djangoproject.com/browser/django/branches/soc2010/app-loading
 
[2] http://code.djangoproject.com/wiki/SummerOfCode2010
[3]
http://code.djangoproject.com/browser/django/branches/soc2010/app-loading/tests/appcachetests

-- 
Alex Kamedov
skype: kamedovwww: kamedov.ru

-- 
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: Purpose of django.test.simple.reorder_suite

[Łukasz Rekucki]

On 1 April 2011 00:58, Karen Tracey  wrote:
> 2011/3/31 Łukasz Rekucki 
>>
>> I just started updating my custom TestSuiteRunner to Django 1.3 and it
>> seems that reorder_suite() is broken. At least I think it is, because
>> I wasn't able to deduce what it should do.
>>
>> In Django 1.2, the main effect that function was flattening the
>> TestSuite so it only consists of TestCase instances. It no longer does
>> that if the suite contains any unittest1.TestSuite instances (the
>> "isinstance(test, unittest.TestSuite)" fails, 'cause unittest is
>> unittest2 now).
>>
>> So my question is, does this function serve any other purpose then
>> flattening the TestSuite or can fix it and rename to flatten_suite() ?
>
> Its purpose is to reorder the test suite so that all tests that use the
> transaction rollback mechanism are run first. These tests are guaranteed to
> clean up after themselves, and they do not do anything on entry to reset the
> database to a known state (as TransactionTestCases do), so running them
> after either any TransactionTestCase tests or after any doctests may result
> in failures due to previously-run tests that did not clean up after
> themselves. (This reordering is documented:
> http://docs.djangoproject.com/en/1.3/topics/testing/#testcase).

Thanks for explaining, it makes perfect sense. I actually remember
reading that docs some time ago, but I guess it didn't stick to my
memory.

> If the function is no longer properly reordering things then it needs to be
> fixed, however its name should not be changed; its reason for being is to
> reorder, not flatten.

I made a few tests and the ordering works fine, because
django.TestCase can only be part of a TestSuite that comes from
django.utils.unittest, so it will be flatten properly. Old unittest
TestSuite will be treated as a plain TestCase, so it will be added
after all django.TestCases, but won't be flatten.

I guess it's a change in an undocumented behaviour, so it's not really
a bug. I just added a flatten function on my end.

Regards,
Łukasz Rekucki

-- 
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: Suggestion: a new "nature" field in Trac

[Russell Keith-Magee]

On Wed, Mar 30, 2011 at 7:42 AM, Russell Keith-Magee
 wrote:
> Barring objection, I'll try to find some time this afternoon to
> introduce the new flags.

A little later than originally intended... but I've just made these changes.

Ladies and Gentlemen start your triage!

Russ %-)

-- 
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: Proposal: make 1.4 more explicit

[Patryk Zawadzki]

On Fri, Apr 1, 2011 at 12:01 AM, Luke Plant  wrote:
> On 31/03/11 19:35, Patryk Zawadzki wrote:
>>  * for 1.4 provide a number of fallback settings that can be used to
>> enable legacy behavior in each of the first three points
> but this is where it falls down, because the devil is in the details
> with regards to backwards compatibility.
>
> Settings to control this is not really an option, because it means you
> have to get everything upgraded together, which is just infeasible with
> the current app ecosystem. For each bullet point, you'll need a more
> fine-grained approach that allows upgrading at least on the level of an
> individual app, and users of that app to be able to use old apps.

I meant a set of separate settings. Like a list of apps that should
still use legacy table names. As for template loading, the ticket I
mentioned in the original post has a backwards-compatible patch. A
future version of Django can just remove the fallback part of the
code. The hardest part is making the internals work with fully
qualified paths.

> We would also need tools to migrate existing tables. Don't forget the
> contenttypes app, which contains data that use the existing app names.
> Remember also that we don't have any tools in core for upgrading
> existing tables or data.

It would be much easier if Django contained a migration mechanism that
apps such as the content types framework could use. We also have to
support a way to convert existing fixtures.

> This sounds to me more like the kind of change we might do for Django
> 2.0, not 1.4...

I hope that it would be possible to roll these out gradually. newforms
didn't happen overnight either :)

-- 
Patryk Zawadzki
I solve problems.

-- 
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: Purpose of django.test.simple.reorder_suite

[Karen Tracey]

2011/3/31 Łukasz Rekucki 

> I just started updating my custom TestSuiteRunner to Django 1.3 and it
> seems that reorder_suite() is broken. At least I think it is, because
> I wasn't able to deduce what it should do.
>
> In Django 1.2, the main effect that function was flattening the
> TestSuite so it only consists of TestCase instances. It no longer does
> that if the suite contains any unittest1.TestSuite instances (the
> "isinstance(test, unittest.TestSuite)" fails, 'cause unittest is
> unittest2 now).
>
> So my question is, does this function serve any other purpose then
> flattening the TestSuite or can fix it and rename to flatten_suite() ?
>

Its purpose is to reorder the test suite so that all tests that use the
transaction rollback mechanism are run first. These tests are guaranteed to
clean up after themselves, and they do not do anything on entry to reset the
database to a known state (as TransactionTestCases do), so running them
after either any TransactionTestCase tests or after any doctests may result
in failures due to previously-run tests that did not clean up after
themselves. (This reordering is documented:
http://docs.djangoproject.com/en/1.3/topics/testing/#testcase).

If the function is no longer properly reordering things then it needs to be
fixed, however its name should not be changed; its reason for being is to
reorder, not flatten.

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 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Re: Proposal: make 1.4 more explicit

[Luke Plant]

On 31/03/11 19:35, Patryk Zawadzki wrote:

> I propose the following:
>  * make the internal model handling operate on full paths to the
> classes, rather than just the app names and class names
>  * make the DB table names use full python paths instead of just the
> app name and the class name
>  * make templatetag loading use full paths rather than just the suffix
>  * allow fully qualified templatetag names ("{%
> foo.templatetags.frobnication_tags.frobnicate baz %}") and possibly
> loading aliases ("{% import foo.bar.tags as bar %}") to cover the case
> when conflicts are hard to avoid (different app authors etc.)

I general I think this is a noble goal (although some points are
debatable)...

>  * for 1.4 provide a number of fallback settings that can be used to
> enable legacy behavior in each of the first three points

but this is where it falls down, because the devil is in the details
with regards to backwards compatibility.

Settings to control this is not really an option, because it means you
have to get everything upgraded together, which is just infeasible with
the current app ecosystem. For each bullet point, you'll need a more
fine-grained approach that allows upgrading at least on the level of an
individual app, and users of that app to be able to use old apps.

We would also need tools to migrate existing tables. Don't forget the
contenttypes app, which contains data that use the existing app names.
Remember also that we don't have any tools in core for upgrading
existing tables or data.

This sounds to me more like the kind of change we might do for Django
2.0, not 1.4...

> PPS: Please don't shoot me. :>

No-one feels like shooting you - because we presume that if this is a
serious proposal, you're not expecting other people to do all the work,
and if it's not a serious proposal, we'll just ignore it :-)

Regards,

Luke

-- 
"If you're not part of the solution, you're part of the
precipitate." (Steven Wright)

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: GSoc : Templates Compilation

[Jonathan Slenders]

Another one:

Instead of:
def has_key(self,key):
for level in xrange(0,len(self._levels)) :
if self._levels[level].has_key(key) :
return True
return False

do:
def has_key(self,key):
return any((key in l) for l in self._levels)

Ony one "self" reference, and any-through-iterator is very fast, as
it's native python code (probably implemented in C). And lazy
evaluating.

It's challenging to understand your code. Maybe it's easier if you
explain in words-only how you want to implement inheritance.

-

My approach would be like this


For a template called 'x', create a dictionary 'x' with maps the block
names for this template to a func with it's matching implementation
code.
Somehow, a method render_block(name) should be made available. So when
a blocks are nested, one block should be able to call
render_block(other_name). The render_block method should do a lookup
in the dictionary for a block with this name, and call it.

Dynamic inheritance can easily be realized by replacing key/value
pairs in this dict by other implementations. Pass the original
implementation to the new implementation as an additional function
parameter. (As a curry.)

I guess it's fast, and can be cached in memory. For each rendering,
only a copy of the required template dictionaries have to be made.
(Not even a deep copy.)

---

Cheers,
Jonathan

-- 
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: GSoc : Templates Compilation

[Jonathan Slenders]

Hi Andrey

I haven't yet looked through all of your code, but already a little
feedback.

Remember that every dot operator requires a dictionary lookup or
getattr call. Also the [ ]-operator is another level of redirection. I
think using 'self' inside a for-loop is not a good idea. If you're
going to compile, you really want to optimize every possible detail.


On Mar 31, 6:00 pm, Andrey Zubko  wrote:
> ...
>     def super(self,key):
>         if len(self._levels) > 1 :
>             for level in xrange(1,len(self._levels)) :
>                 if self._levels[level].has_key(key) :
>                     return self._levels[level][key]
>         else :
>             if self._levels[0].has_key(key) :
>                 return self._levels[key]   ###  You mean:  return 
> self._levels[0][key]
>             else :
>                 return ""


Maybe turn it into this:

>     def super(self,key):
> levels = self._levels
>         if len(levels) > 1 :
> iter = levels.__iter__()
> iter.next() # Ignore first item
> for level in iter:
>                 if level.has_key(key) :
>                     return level[key]
>         else :
>             return levels[0].get(key, "")


Now you have only one lookup in 'self', half the amount of index
operators (has_key counts as index operator), no additional xrange
iterator, and only one call of "len". Gaining probably twice the
speed.


But is it really necessary to use classes and instance methods instead
of just plain methods in a module? A template should be stateless. (we
have render_context for the state when required.) Classes always have
overhead compared to methods.




-- 
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: ./manage.py loaddata calls .save() on all models... should it?

[Jeremy Dunck]

On Thu, Mar 31, 2011 at 2:02 PM, Patryk Zawadzki  wrote:
...
> Rather simple fix to the signal handler:
>
> def on_something_saved(sender, instance, created, **kwargs):
>    if not kwargs.get('raw', False):
>        do_stuff()

Concur, if the handler shouldn't run on loaddata, checking raw is the
right change.

-- 
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.

Purpose of django.test.simple.reorder_suite

[Łukasz Rekucki]

Hi,

I just started updating my custom TestSuiteRunner to Django 1.3 and it
seems that reorder_suite() is broken. At least I think it is, because
I wasn't able to deduce what it should do.

In Django 1.2, the main effect that function was flattening the
TestSuite so it only consists of TestCase instances. It no longer does
that if the suite contains any unittest1.TestSuite instances (the
"isinstance(test, unittest.TestSuite)" fails, 'cause unittest is
unittest2 now).

So my question is, does this function serve any other purpose then
flattening the TestSuite or can fix it and rename to flatten_suite() ?

-- 
Łukasz Rekucki

-- 
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:

[Brendan Smith]

lol

On Thu, Mar 31, 2011 at 6:47 PM, Rajendra Pondel wrote:

> Hi i m new to dejano?
>
> where can i find what it is?
>
> thanks
>
> --
> 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.
>
>


-- 
Brendan Smith, IT Specialist
National Priorities Project
http://www.nationalpriorities.org
http://www.costofwar.com
http://www.facebook.com/nationalpriorities
413 584 9556

-- 
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:

[Jeremy Dunck]

On Thu, Mar 31, 2011 at 1:47 PM, Rajendra Pondel  wrote:
> Hi i m new to dejano?
>
> where can i find what it is?

Please direct questions like this to django-us...@googlegroups.com.

You can find documentation here: http://docs.djangoproject.com/en/1.3/

-- 
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.

[no subject]

[Rajendra Pondel]

Hi i m new to dejano?

where can i find what it is?

thanks

-- 
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: ./manage.py loaddata calls .save() on all models... should it?

[Patryk Zawadzki]

On Wed, Mar 30, 2011 at 10:55 AM, George Karpenkov
 wrote:
> Oh thanks Russel!
>
> Turns out django-tagging was creating those objects via the post-save
> signal hook.
>
> http://code.djangoproject.com/ticket/8399 <- here is the ticket which
> proposes an option to disable the signal handling during the loaddata
> operation.
>
> Malcolm says that some people might want to use signals while running
> loaddata - ie to create related objects.
>
> I don't really understand why anyone would want that -- the only use
> case I've ever seen for the loaddata operation was "dump the entire
> database -> load entire database", though I guess use cases differ.
>
> Any updated comments on disabling the signal handling for the loaddata
> operation?

Rather simple fix to the signal handler:

def on_something_saved(sender, instance, created, **kwargs):
if not kwargs.get('raw', False):
do_stuff()

-- 
Patryk Zawadzki
I solve problems.

-- 
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.

Proposal: make 1.4 more explicit

[Patryk Zawadzki]

Hi group,

Currently Django has its own concept of namespacing (apps) and mostly
ignores Python modules. I'd like to propose using Python paths
wherever we can instead of apps. This would solve a lot of problems
with conflicting submodule names that plague maintainers of reusable
apps and frameworks. Currently if you try to provide a base
frobnicator model and you choose to do so in
"fooframework.frobnicator.models", you pretty much forbid the users
from putting derived classes in a local module named
"frobnicator.models". Bad things happen when two apps start to provide
"frobnication_tags".

I propose the following:
 * make the internal model handling operate on full paths to the
classes, rather than just the app names and class names
 * make the DB table names use full python paths instead of just the
app name and the class name
 * make templatetag loading use full paths rather than just the suffix
 * allow fully qualified templatetag names ("{%
foo.templatetags.frobnication_tags.frobnicate baz %}") and possibly
loading aliases ("{% import foo.bar.tags as bar %}") to cover the case
when conflicts are hard to avoid (different app authors etc.)
 * for 1.4 provide a number of fallback settings that can be used to
enable legacy behavior in each of the first three points

PS: http://code.djangoproject.com/ticket/12772

PPS: Please don't shoot me. :>

-- 
Patryk Zawadzki
I solve problems.

-- 
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: Composite primary keys

[Michal Petrucha]

On Thu, Mar 31, 2011 at 09:54:49AM -0700, Christophe Pettus wrote:
> What concerns me about composite fields is that they seem to be a
> lot of Python machinery just to accomplish the goal of allowing this
> annotation.  If they were super-useful in their own right, that
> would be one thing, but I'm not sure that I see the utility of them
> absent indexes and foreign keys.  I'm also bothered, perhaps
> excessively, about having two different ways of getting at the same
> field in the model just to support this.

Just an observation, there already are two ways of getting at the same
field in case of primary keys...

> So, another proposal:
> 
> In the foreign key case, just extending the ForeignKey syntax to
> allow for multiple related fields makes the most sense:
> 
>   overThere = models.ForeignKey(OtherModel, to_field=('first_name', 
> 'last_name', ))
> 
> For indexes on the table for the model, include the declaration in
> the Meta class, since that's the obvious place to stick indexing:
> 
>   class SomeModel:
> 
>   class Meta:
>   primary_key = 'some_field'
>   indexes = ['some_field', 'some_other_field', ('field1', 
> '-field2', ), ]
>   raw_indexes = [ 'some_invariant_function(some_field)' ]
> 
> (This was proposed by someone else, and isn't original to me;
> apologies that I can't find the email to give credit.)
> 
> Of course, the existing syntax would still work as a shortcut for
> primary_key and indexes.
> 
> Thoughts?

One thing I'm missing in this proposal is the behavior of the pk
property. Since the primary key is a tuple, I can't imagine any other
representation in .pk than some flavor of a tuple. And to make things
like SomeModel.objects.get(pk=some_value) possible, we'd still have to
implement most of the functionality of a composite field.

Michal Petrucha


signature.asc
Description: Digital signature

Re: Composite primary keys

[Christophe Pettus]

On Mar 21, 2011, at 12:20 PM, Jacob Kaplan-Moss wrote:

> I think we're talking slightly different concerns here: I'm mostly
> interested in the Python-side API, and to my eyes a composite field
> matches more closely what's happening on the Python side of things.

I agree 100%!  I think I'm just drawing a different conclusion from that point, 
which is that indexes are more metadata on the database rather than a critical 
part of the Python API: In an imaginary perfect database (like, say, the SQL 
spec envisions), we wouldn't need to talk about indexes as all.

The more I think about it, the less I like including this directly in the field 
declaration part of the model, including my Index type proposal.  It just 
doesn't seem to belong there.

What concerns me about composite fields is that they seem to be a lot of Python 
machinery just to accomplish the goal of allowing this annotation.  If they 
were super-useful in their own right, that would be one thing, but I'm not sure 
that I see the utility of them absent indexes and foreign keys.  I'm also 
bothered, perhaps excessively, about having two different ways of getting at 
the same field in the model just to support this.

So, another proposal:

In the foreign key case, just extending the ForeignKey syntax to allow for 
multiple related fields makes the most sense:

overThere = models.ForeignKey(OtherModel, to_field=('first_name', 
'last_name', ))

For indexes on the table for the model, include the declaration in the Meta 
class, since that's the obvious place to stick indexing:

class SomeModel:

class Meta:
primary_key = 'some_field'
indexes = ['some_field', 'some_other_field', ('field1', 
'-field2', ), ]
raw_indexes = [ 'some_invariant_function(some_field)' ]

(This was proposed by someone else, and isn't original to me; apologies that I 
can't find the email to give credit.)

Of course, the existing syntax would still work as a shortcut for primary_key 
and indexes.

Thoughts?

--
-- Christophe Pettus
   x...@thebuild.com

-- 
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.

Urgent Requirement: - Python Developer // 9 months // San Jose, CA

[Amit Reks]

Hi,



I have a potential job opportunity for you with one of my direct clients in
San Jose, CA.



Please find the job description below.



*Job Title: Python Developer*

*Job Location: San Jose, CA*

*Duration: 9 months
Position Type: Contract*



*Job Description*

 - Experience with Python

-  Experience with Django

If this project does not match your exact skills perhaps you know of someone
with the necessary experience and availability; if so, please feel free to
forward this e-mail at your discretion.

If you are available and interested, please do send me a word copy of resume
along with following details:

IT Experience: in years

Python:

Django:
Billing Hourly Rate__on W2 / 1099 / Coro-Corp (Please mention)
Earliest availability for the assignment :
Earliest availability for the Interview :
Current location :
Preferred contact number :

Best time to reach you:

Work Authorization: Citizen/Green Card/EAD/H1b/TN Visa



Thanks & Regards,



*Amit |* Intelliswift Software Inc * |*
2201 Walnut Avenue, #180, Fremont, CA 94538*|* Phone: 510 870 8644  *|*
Fax: 510-578-7710  *| *www.intelliswift.com

-- 
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: GSoc : Templates Compilation

[Andrey Zubko]

Hello, Jonathan
 > How exactly do you want to solve dynamic inheritance? It seems that
 > some people are still interested in dynamic inheritance, by using
{%
 > extends variable %}. (Which is still dirty in my opinion, but
anyway.)
 > Block information has to be kept somehow.

For supporting dynamic inheritance compiled template will be looked
more complicated. To resolve this i should :
1.Create class Template_BlockOutput similiar to ContextRender  :

class Template_BlockOutput(object):
def __init__(self):
self._levels = [{}]

def __getitem__(self,key):
for level in xrange(0,len(self._levels)) :
if self._levels[level].has_key(key) :
return self._levels[level][key]
raise AttributeError()

def super(self,key):
if len(self._levels) > 1 :
for level in xrange(1,len(self._levels)) :
if self._levels[level].has_key(key) :
return self._levels[level][key]
else :
if self._levels[0].has_key(key) :
return self._levels[key]
else :
return ""

def has_key(self,key):
for level in xrange(0,len(self._levels)) :
if self._levels[level].has_key(key) :
return True
return False

def __setitem__(self,key,value):
self._levels[0][key] = value

def append(self,d):
if isinstance(d, Template_BlockOutput) :
for level in d._levels :
self._levels.append(level)
elif isinstance(d,list) :
for level in d :
self._levels.append(level)
elif isinstance(d,dict) :
self._levels.append(d)

The instance of this class will be named as «blocks_output». Saving
all blocks output is used
for block.super expression.

2.Add list named blocks_sequence_output, that will contain blocks
output sequence. Every time parser will find «extends» tag —  the list
will be overridden by parent blocks output sequence.
3.Add get_compiled_template_or_create function to
django.template.loader that will be imported in compiled template for
compiling and importing external template.
To support all that requirements classes BlockNode, ExtendsNode should
contain compile functions like :

class BlockNode(Node):
   def super_compile(self):
compiled_code = ["blocks_output.super('%s')" % self.name]
return compiled_code

def compile(self,parent_name):
compiled_childs = self.nodelist.compile(self.name)
compiled_code = ["blocks_output['%s'] = %s"  %
(self.name,compiled_childs),
 "blocks_sequence_output.append('%s')" %
self.name]
return compiled_code

class ExtendsNode(Node):
def get_parent_compiled(self):
if self.parent_name_expr:
parent = self.parent_name_expr.compile()
else :
parent = self.parent_name
if not parent:
error_msg = "Invalid template name in 'extends' tag:
%r." % parent
if self.parent_name_expr:
error_msg += " Got this from the '%s' variable." %
self.parent_name_expr.token
raise TemplateSyntaxError(error_msg)
if hasattr(parent, 'compile'):
return parent.compile() # parent is a Template object

code = ["extenal_blocks_output,
external_blocks_sequence_output =
get_compiled_template_or_create(%s,no_output=True)" %
self.parent_name,
"blocks_output.append(external_blocks_output)",
"blocks_sequence_output =
external_blocks_sequence_output"]

return code

def compile(self):
compiled_parent = self.get_compiled_parent()
return compiled_parent


And compiled template structure for supporting dynamic template
extending :

from ... import ...

def resolve(context,var_name):
""" should be looked like method _resolve_lookup in
django.template.Variable """

blocks_output = Template_BlockOutput()
blocks_output_sequence = list()

def output():
for block_name in blocks_output_sequence :
if blocks_output.has_key(block_name) :
print blocks_output[block_name]

def render(context,no_output=False):
""" compiled template will be here """

""" function footer """
if no_output :
return blocks_output, blocks_output_sequence
else :
output()

Yours Suggestion  :
 > Maybe one small improvement. Isn't the following
 >  > date(context.variable or "Default value"),"Y-m-d") faster than
this?
 >  > date(default(resolve(context,variable),"Default value"),"Y-m-d")
Yes, it will be good to add to every filter function additional
«compile» function that will generate optimesed code. E.g. :
def default_compiled(value, arg):
"""If value is unavailable, use given default."""
return "context.%s or '%s'" % (value,arg)
default_compiled.is_safe = False

register_compiled = Library()

register_compiled.filter(default_compiled)

Re: Customizable Serialization

[Vivek Narayanan]

Hi Russ,

Thanks for the suggestions once again, I've thought of changing the
model for handling nested fields.

Each model can have a no of serializers, and they can be plugged in to
other serializers
and in this way nested models can be handled instead of cycling
through a tree of arbitrary depth.
Each serializer object would have a ``dump_object()`` method that
would return a python object.
This method is called when a serializer is plugged into another in a
nested model.

>My point is that it should be *possible* to define a "generic"
>serialization strategy -- after all, that's what Django does right
>now. If arguments like this do exist, they should essentially be
>arguments used to instantiate a specific serialization strategy,
>rather than something baked into the serialization API.

Yes, I'll be adding arguments ``attrs`` and ``exclude`` to the
__init__ method of the serializer.

Here is how the API can be used for generating the formats in those 2
examples:

"""
For the first option.
"""

class OriginalOutput(JSONSerializer):
wrap_fields = "fields"
indent = 4

def meta2_pk(self, obj):
#get pk
def meta2_model(self, obj):
#get model name

"""
The second option.
"""

class Base(JSONSerializer):
"""
A base serializer with formatting options.
"""
indent = 4

class Editor(Base):
"""
This can be used to serialize a Person model.
Note the company field, if no such Serializer object is specified,
the foreign key is returned.

By specifying the ``attrs`` argument while initializing the
object, one can restrict the fields
being serialized. Otherwise, all available fields and metadata
will be serialized.
"""
company = Company(from_field = 'company', attrs = ['name',
'founded'])

class Author(Base):
"""
The dump_object method is called when a serializer is plugged into
another and returns a python object,
this is normally a dict but this can be overridden.
"""
def dump_object(self, obj):
return obj.first_name + ' ' + obj.last_name


class BookDetails(Base):
"""
This is the serializer that will yield the final output.

Since the 'authors' field is M2M, the Author serializer will be
applied over the list of authors.

Aliases is a dict that maps attribute names to their labels during
serialization.

"""
wrap_all = "book details"
authors = Author(from_field = 'authors')
editor = Editor(from_field = 'editor', attrs = ['firstname',
'lastname', 'coworkers', 'phone', 'company'])
aliases = {
'title': 'book_title',
'acount': 'author_count'
}

def meta2_acount(self, obj):
# return count of authors


The serialized data can be obtained by calling BookDetails.serialize()
or OriginalOutput.serialize().

Some of the options I didn't cover in the above example are:

* A ``fieldset`` option, which is a list of fields to be serialized.
If it is not set, all fields are part of the
serializer. This can be additionally restricted during initialization
as shown above.

* Reverse relations can be used in the same way as other pluggable
serializers by
specifying the ``from_field`` argument as the related name during
initialization.

I hope this will add more flexibility.

-- 
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.