Re: default Model.all()?

[Philippe Raoult]

While we're talking about that, is there a reason the default manager
isn't iterable (default mapping to .all()) ?

This is not as trivial as it sounds, because it means template writers
need to be aware of which member of the class are managers and which
are plain methods returning lists or querysets. For example:

{% for comment in blogpost.comments_set.all %}
vs
{% for comment in blogpost.custom_comments_method %}

There might be a good reason why it's like that, otherwise I'll
propose a patch...

Regards,
Philippe


On Thu, Oct 22, 2009 at 3:11 PM, Luke Plant  wrote:
>
> On Thursday 22 October 2009 12:45:13 Waldemar Kornewald wrote:
>> Hi, just a small issue we always wondered about:
>> Why doesn't Model provide a simple .all() function which just maps
>>  to self.objects.all() or self._default_manager.all()? Only few
>>  models provide multiple managers and it's annoying to write
>>  .objects everywhere. Is there a good reason to force people to
>>  write ".objects" all the time?
>
> Remember that methods on Model will be available to instances of
> Model.  Therefore it's really important not to pollute the namespace,
> which is shared with model field attributes.  Therefore, we decided on
> a single standard way to distinguish 'table level' attributes from
> 'row level', and that is ".objects".  Adding more methods to Model
> would only cause more potential conflicts with field names.
>
> Luke
>
> --
> "Some people says that if you play a Windows XP install CD
> backwards you will hear demon voices commanding you to worship
> Satan. But that's nothing. If you play it forwards it will install
> Windows XP."
>
> 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: default Model.all()?

[Philippe Raoult]

I have the following shorcut in my code:

class IterableManager(models.Manager):
use_for_related_fields = True

def __iter__(self):
return self.all().__iter__()

class CustomModel(models.Model):
objects = IterableManager()


I'm honestly not familiar with caching and threading and thus fail to
see how that breaks anything (vs using blogpost.comment_set.all in a
template). Maybe you could you enlighten me ?

Regards,
Philippe

On Thu, Oct 22, 2009 at 8:05 PM, Luke Plant  wrote:
>
> On Thursday 22 October 2009 18:16:23 Philippe Raoult wrote:
>> While we're talking about that, is there a reason the default
>>  manager isn't iterable (default mapping to .all()) ?
>>
>> This is not as trivial as it sounds, because it means template
>>  writers need to be aware of which member of the class are managers
>>  and which are plain methods returning lists or querysets. For
>>  example:
>>
>> {% for comment in blogpost.comments_set.all %}
>> vs
>> {% for comment in blogpost.custom_comments_method %}
>>
>> There might be a good reason why it's like that, otherwise I'll
>> propose a patch...
>
> The reason is caching: if you made it iterable, you would have to
> throw away the results rather than store in a cache, because otherwise
> it would always return the same results; Model.objects.all() always
> returns a fresh QuerySet.  It also wouldn't be thread safe.
>
> Luke
>
> --
> "Some people says that if you play a Windows XP install CD
> backwards you will hear demon voices commanding you to worship
> Satan. But that's nothing. If you play it forwards it will install
> Windows XP."
>
> 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: Proposal for 1.3 - decoupling a few things in Django a bit.

[Philippe Raoult]

My app does roughly the same thing and is organised as thus:

- each module has its own app (invoices, emails, stuff_we_sell...).
The app contains the models with most of the business logic and the
managing views (for our own use)
- a separate client access module that wraps around some of the
managing views, sometimes using simpler templates, and always doing
the extra security checks ("can this client access this particular
invoice").

It's roughly 30k lines of python + templates and the existing
framework seems adequate to handle this use case. One pattern I've
used a lot is simply doing my security checks in the client app then
calling the view from the business app.

One thing that I think is worth mentionning is that the generic CRUD
is common to the business and client sides. I just run per-instance
security checks based on who's connected (permissions for business
users, and "ownership" for client users). On top of that a custom
login middleware forbids client users from accessing most of the URL
space (they're mostly sandboxed into the client module's urls).

In short, I think this thread should be in django-users :)

Hope that helps,
Philippe


On Jun 21, 7:11 am, M Rotch  wrote:
> I'm sorry. My example is a bit misleading (actually a confusing mess),
> but the reason for splitting off models into separate was just my idea
> of a means to an end but probably is a bad solution. I should have
> started with my business problem instead of mingling my solution into
> the explanation.
>
> Let me start again in a less convoluted manor.
>
> The software I started on this month has businesses (which pay to use
> the software) and it has clients (which are clients of those
> businesses). The business has one interface athttp://manage.example.com
> and the client has a whole different interface (completely different
> design and different functionality) athttp://clients.example.com.
> Let's say you have a model ModelXYZ. ModelXYZ instances belong to a
> client of a business. The client can create, read, update, or delete
> their ModelXYZ instances. The business who owns the client can also
> CRUD their client's ModelXYZ instances.
>
> The problem is that the views and templates a business is using while
> editing their client's ModelXYZ instances are completely different
> from the views and templates that are used by the client to edit the
> same ModelXYZ instance. The logical thing for me seemed to create a
> separate app for businesses and one for clients, but I ran into 2
> things that made me reconsider: #1) For each set of related models I
> have to have 2-3 apps (1 for models, 1 for business access, and 1 for
> client access (unless I decide to put business access into the same
> app as the models which leads to just two apps)) and #2) Naming
> conventions are a mess this way. If I have a ModelXYZ (and a few other
> related models), I might have an app called projects/apps/xzy (which
> contains models) and two sub-folders of this app; one called project/
> apps/xyz/client/, and one called project/apps/xyz/business. Perhaps
> this isn't so bad. What's your thought. Am I over thinking this, or do
> you think my solution makes any more sense than after reading my
> previous post?
>
> Thanks
> Mark
>
> On Jun 20, 9:52 pm, Russell Keith-Magee 
> wrote:
>
> > On Mon, Jun 21, 2010 at 10:07 AM, M Rotch  wrote:
> > > I just have a few practical ideas that I want to lay out, pertaining
> > > to loose coupling.
>
> > > I've worked with Django for a while and one of the things I love is
> > > that you can do things your own way, instead of having the
> > > constricting requirements that "convention over configuration" brings
> > > (like in Rails). Django does enlists a few "convention" requirements
> > > if you want to make things easy and automatic. This is fine unless you
> > > need to do it the non-automatic way (larger applications bring this
> > > need up).
>
> > > There are a few areas where this comes up but I'll only touch on the
> > > most obvious:
>
> > > When you're building an application that has many related data models
> > > and different types of users that have many views which access data
> > > from multiple apps, it becomes really easy to forget where you put
> > > certain models and seems disorganized.
>
> > > Splitting things up into more and more apps doesn't fix the problem,
> > > because having apps that only serve as a host for views and apps that
> > > only serve as a host for models makes a mess in larger applications.
> > > What does fix the problem is keeping a taxonomy that makes sense for
> > > your business; data models based on where they belong and views based
> > > on who/what they're for (e.g. data models in ``project/data/company/
> > > models.py``, views that access those models in ``project/views/clients/
> > > tickets.py`` and ``project/views/company/dashboard.py``).
>
> > > My proposal (This solution could be way off but I'm really wanting to
> > > hear what others think

Ticket #12823

[Philippe Raoult]

I have updated my patch for this old query bug versus current trunk. I've
been happily using it for over a year in production, and was hoping someone
higher up the foodchain would check it out for inclusion in the upcoming
release.

This bug is long-standing and silently produces broken queries, where a FK
is compared to the wrong table index.

[1] 
http://code.djangoproject.com/ticket/12823

Bien cordialement,
Philippe

-- 
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: Migrating to 1.4

[Philippe Raoult]

Thanks for the heads-up. My 50k python lines project is still running
1.2.7 + #12823. For some reason this patch can't seem to be commited,
despite being a potiential data-loss. I'm still worrying about
migrating to 1.3.1!

Best regards,
Philippe



On 14 March 2012 16:22, Dan Fairs  wrote:
> Hi,
>
> Since most people only ever report bugs, I wanted to report success in the
> initial migration of a relatively large project (~35k lines of Python
> application code, excluding comments and migrations, with ~43k lines of test
> code over ~2.5k tests) to Django 1.4 rc1. The production environment is
> running Django 1.3.1. Both are using Python 2.7.2 and MySQL.
>
> Relatively few changes were necessary.
>
> There were a couple of bumps on the way (bugs #17879 and #17891) which were
> fixed quickly.
>
> I also had to spend some time updating some of our code which customises
> bits of Django that don't look like they were meant to be customised. We
> have custom logic for computing template lookup paths that depends on the
> request (skinning, basically), which doesn't 'fit' into a custom template
> loader. 'Normal' views are handled by way of an overridden
> get_template_names() in a base view - all our views are class-based, but:
>
> - We have a custom template tag that derives from ExtendsNode, and overrides
> get_parent
> - We have a custom Library implementation that overrides inclusion_tag(),
> which knows
>   about our template lookup logic; it broke because the signature for
> generic_tag_compiler
>   changed.
>
> Both of these were fixed by using the new implementations from Django
> itself, and re-applying our small changes.
>
> Should I raise backwards-incompatibility tickets for these? They're pretty
> obscure, and I can't imagine many people are doing them. I raised #17891
> because the code involved a clear extension point.
>
> At this point, everything else seems to have 'just worked' - including some
> moderately scary model generation code - and I was finally able to remove
> our `backports` app containing signed cookies and cookie-based sessions, and
> our build-time patch for select_for_update(). Next up is checking that there
> aren't any significant performance regressions.
>
> Thanks, everyone!
>
> Cheers,
> Dan
> --
> Dan Fairs | dan.fa...@gmail.com | www.fezconsulting.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.

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

RFC #12823

[Philippe Raoult]

I have produced a patch for this [1] long-standing SQL bug.

The SQL produced with the patch is correct AFAIK, but my understanding
of the sql code is rather poor so I'm hoping that someone who knows
better will give it a look. There might be a more correct/elegant way
to fix this.

[1] http://code.djangoproject.com/ticket/12823

Best regards,
Philippe

-- 
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: SQL join promotion as a result of querying for a NULL value

[Philippe Raoult]

I too was rather surprised by this behavior. I have since changed my
code to use exclude(related__field__isnull = False) instead of
filter(related__field__isnull = True) to avoid this issue.

I'm all for an API, but I'm not sure which would be best. Maybe
filter(related__field__isnull_nopromote = True) ? This isn't
particularly elegant though. I'd prefer filter(related__field__isnull
= True, no_promote = True) but that would forbid users from using
no_promote as a field name.

Another backward-compatible way would be to add a no_promote() method
to the queryset:
Model.objects.no_promote().filter(related__field__isnull = True)



On 6 January 2011 22:13, Byron Ruth  wrote:
> I am speaking of this particular if statement:
> http://code.djangoproject.com/browser/django/tags/releases/1.2.4/django/db/models/sql/query.py#L1051
>
> There are a few implications of this assumption. One being, that if
> the user is actually trying to get the "real" rows that exist with a
> column that has a NULL value, they will get those in addition to all
> the rows generated that are empty as a result of the LEFT OUTER JOIN.
>
> Given the example:
>
>    SELECT * FROM table1 INNER JOIN table2 ON (table2.table1_id =
> table1.id) WHERE table2.foo IS NULL
>
> With the INNER JOIN, if table2 is empty, no rows will return. Any
> table2 rows that match 'foo IS NULL' will return if and only if it
> references a row in table1 (obviously if table1_id is not nullable,
> this will always be true).
>
>    SELECT * FROM table1 LEFT OUTER JOIN table2 ON (table2.table1_id =
> table1.id) WHERE table2.foo IS NULL
>
> With the LEFT OUTER JOIN, if table2 is empty, all of the rows from
> table1 will return! In addition, any rows in table2 that match 'foo IS
> NULL' will return as well as the ones that don't have rows that exist
> in the table!
>
> This seems like very strange behavior to have by default. I suggest
> there be a way to prevent the joins from being promoted to LEFT OUTER
> JOIN when the specifying a QuerySet condition using NULL values.
>
> Obviously the fact that people have been relying on this behavior for
> 2+ years either proves to be the correct assumption or not many have
> come across these scenarios. I propose exposing a small API that
> allows for keeping INNER JOINs and not promoting simply because of a
> NULL value.
>
> Any thoughts or feedback on this argument?
>
> --
> 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.
>
>

-- 
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: RFC #12823

[Philippe Raoult]

Just wanted to bump on this issue.
The join is indeed a bit weird to the human eye (extra
related__pk__isnull = False added) but that's just eye candy. This is
true of many queries generated by django anyway, all that matters for
the time being is correctness.

I would mark ready for checkin but I understand that'd be bad manners
since I wrote the patch.

Philippe



On 16 December 2010 09:37, Harro  wrote:
> Made some comments about the bug and the patch.
> The patch gives the right result, but the JOIN there is a bit weird.
>
> On Dec 15, 7:54 pm, Philippe Raoult 
> wrote:
>> I have produced a patch for this [1] long-standing SQL bug.
>>
>> The SQL produced with the patch is correct AFAIK, but my understanding
>> of the sql code is rather poor so I'm hoping that someone who knows
>> better will give it a look. There might be a more correct/elegant way
>> to fix this.
>>
>> [1]http://code.djangoproject.com/ticket/12823
>>
>> Best regards,
>> Philippe
>
> --
> 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.
>
>

-- 
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: Towards a more friendly NoReverseMatch

[Philippe Raoult]

+1 on this, been bitten repeatedly.

I assume the url parser already "knows" this so this is mostly a
matter of raising the appropriate exception.

Bien cordialement,
Philippe



On 12 October 2011 17:13, Wilfred Hughes  wrote:
>> >    >>> reverse('i_dont_exist')
>> >    NoReverseMatch: Reverse for 'i_dont_exist' with arguments '()' and
>> > keyword arguments '{}' not found.
>>
>> > In this case, it would be nicer to have something like:
>>
>> >    NoURLPattern: No patterns specified for 'i_dont_exist'.
>>
>> Just on this point, I must disagree. For instance, consider if you
>> have a URL named 'i_dont_exist', and the URL pattern has two
>> positional arguments.
>
> Ah, sorry. I've been unclear. My point here is that when there /isn't/
> a URL with that name. It would be good to distinguish between having
> no regexes and not being able to reverse the regex.
>
> So, if I have an URL:
>
>    url(r'^fruit/(bananas|apples)$', some_view, name='fruit'),
>
> And I make a spelling mistake:
>
>    >>> reverse('rfuit', args=['bananas'])
>
> I would like some hint that the problem isn't in my regex. The two
> options I'm proposing are:
>
>    NoURLPattern: No patterns specified for 'rfuit'.
>
> Or:
>
>    NoReverseMatch: Reverse for 'rfuit' with arguments '()' and
> keyword arguments '{}' not found (patterns tried: []).
>
> --
> 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.
>
>

-- 
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: Is this true. that django really takes a lot of memory?

[Philippe Raoult]

Hi,

I did a reply on the post. Might be some time before it's approved.
The gist is that yes it's that bad if you're using it naively. As long
as you know what's gonna be loaded from the DB you can avoid those
cases pretty easily.

You can also check
http://github.com/dcramer/django-idmapper/tree/master which is a
rewrite of the infamous ticket 17
(http://code.djangoproject.com/ticket/17).

Regards,
Philippe

On Tue, Feb 17, 2009 at 1:40 PM, NitinHayaran  wrote:
>
> Hi All,
> Today i read this article and was wondering whether django orm is
> really that bad.
>
> http://dayhacker.blogspot.com/2009/02/why-django-orm-sucks-it-takes-hell-lot.html
>
> I think this is the right place to ask?
>
>
>
> >
>

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

Using model classes in templates #16307

[Philippe Raoult]

Hello all,

I've had some troubles with default callables in FKs and tracked it down to 
one of my templates tags which returns a model class. I'm not sure if this 
is considered kosher or not so feel free comment on that too. 

In my template I have a something like:

{{ my_project_lookup_class.classname.get_verbose_name }}

my_project_lookup_class.classname will the return the django model class, 
and the template engine apparently checks if the class is callable, then 
calls it which will try to instanciate a new object with no arguments. In 
that specific case it fails because of missing default values but my intent 
was to call a classmethod anyway. I worked around it by using the 
do_not_call_in_templates flag on my models, because I'll never intend to 
call a constructor from a template anyway. 

I've found a ticket corresponding to this issue. 
https://code.djangoproject.com/ticket/16307

and here's the discussion regarding the do_not_call_in_templates flag:
https://code.djangoproject.com/ticket/15791

So my question is, would it make sense to make do_not_call_in_templates 
default to True for django's Model class ? 
This would potentially break stuff if people used that trick to actually 
instantiate objects, I have no idea whether this is a common use case or 
not. 


-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/4d367c99-06e0-4812-ad5a-38defbc05ec8%40googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

form_for_model arguments

[Philippe Raoult]

Here are two quick suggestions:
form_for_model in the trunk supports a 'fields' argument. What do you
guys think about adding an 'exclude_fields' argument ? It is very
handy when you want to have all but one or two fields from a model in
a form.

In the same vein, I have studied the queries generated with
select_related(), and it would be useful to limit the related fields/
classes. I'd suggest adding fields, exclude_fields, models and
exclude_models arguments. Tell me what you think and I'll implement it
during or after the sprint!

Regards,
Philippe


--~--~-~--~~~---~--~~
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: Call to Arms -- Caching Mechanisms

[Philippe Raoult]

I'm too wasted to write a coherent answer, but I'd like to point out
that http://code.djangoproject.com/ticket/17
has a patch for caching that has been refactored during the sprint.

Regards,
Philippe


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

0.96.1 / 096-bugfixes

[Philippe Raoult]

I was wondering why there is no 096-bugfixes branch. Does that reflect
a policy change since previous versions ? Since 0.97 looks pretty far
away with all the merging waiting to happen (queryset-refactor &
newforms-admin at least), would it make sense to backport a few
bugfixes and maybe a couple of simple features to 0.96 to have a new
stable release ?

I already have a good candidate for backport: #4789 select_related +
depth gives wrong result. Anyone else has suggestions ?

We could start by listing tickets worth the trouble of backporting and
see if there's enough to warrant the hassle of packaging a minor
release. Otherwise we could just have a list of tickets with patches
which applies cleanly to 96 and are known to work as expected.

Regards,
Philippe


--~--~-~--~~~---~--~~
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: Usage of items() vs iteritems()

[Philippe Raoult]

I'd venture that it's a simple oversight. items() is likely taking
more memory in addition to being slower because it creates a list of
the items while iteritems simply returns an iterator.

On Mar 24, 9:51 am, David Cramer <[EMAIL PROTECTED]> wrote:
> Ive been having to dig into code vs documentation lately, and there
> are *tons* of uses of items() vs iteritems(). I was wondering why this
> is?
>
> I did a quick benchmark, on an example I found in newforms, to try and
> give myself an answer:
>
> In [31]: timeit.Timer("attrs2=attrs.copy();[(field_name,
> attrs2.pop(field_name)) for field_name, obj in attrs2.items()]",
> "attrs = dict((('adfadsfasdf', 'hello'),)*10)").timeit()
> Out[31]: 1.7580790519714355
>
> In [32]: timeit.Timer("attrs2=attrs.copy();[(field_name, obj) for
> field_name, obj in attrs2.iteritems()]", "attrs =
> dict((('adfadsfasdf', 'hello'),)*10)").timeit()
> Out[32]: 1.2866780757904053
>
> The first example is what's currently in new forms, and I can't see it
> saving much memory, for being that much slower.
--~--~-~--~~~---~--~~
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
-~--~~~~--~~--~--~---