> Named tuples eliminate neediness in values & values_list because they
> have all their features.
Not in your implementation. The order of fields in each tuple
corresponds to order in sql but not to order of fields in
namedtuples() call. See ValuesListQueryset.iterator() implementation
for detail
Hi Gregor, I've just put up a new version of django-forms [1] which implements
a similar version of the proposal with the main difference being "extends".
Take a look.
1. https://github.com/SmileyChris/django-forms
--
You received this message because you are subscribed to the Google Groups
Very nice work Akaariai.
I'll check this out over the next couple of days :)
Cal
On Mon, Jul 4, 2011 at 10:10 PM, akaariai wrote:
> I have implemented proof of concept versions of conditional
> aggregation, F-lookups in aggregates and annotating fields to a model
> (qs.field_annotate(age_x2=F('
On Jul 4, 2011, at 8:01 AM, Jacob Kaplan-Moss wrote:
> On Mon, Jul 4, 2011 at 8:54 AM, Jim Dalton wrote:
>> I've created a ticket for this and uploaded a patch:
>> https://code.djangoproject.com/ticket/16401
>> Please feel free to review and let me know if this is a good idea in the
>> first pl
I have implemented proof of concept versions of conditional
aggregation, F-lookups in aggregates and annotating fields to a model
(qs.field_annotate(age_x2=F('age')*2), note: no aggregation here). See
ticket #11305 for more details.
I would also hope to implement a patch which would allow to annot
Hi,
I wrote mainly documentation in the last week for how to use the new form
rendering as well as references in the template tag listing. I've also
implemented the form, formrow and formfield tags, I thought we might want to
have something to play with sooner than later. The docs/tests etc can be
On Mon, Jul 4, 2011 at 10:59 AM, Ole Laursen wrote:
> It sounds like you've never been bitten by strip bugs.
Then I must haven't been clear enough -- sorry -- because I certainly
have, many times. I've also found it incredibly easy to solve in my
user code: ``form.cleaned_data['field'].strip()``.
On Jul 4, 4:52 pm, Jacob Kaplan-Moss wrote:
> On Mon, Jul 4, 2011 at 12:13 AM, Ryan wrote:
> > Umm... How about now?
>
> Sorry, but this isn't going to happen. I left more information on the
> ticket:https://code.djangoproject.com/ticket/6362#comment:43.
It sounds like you've never been bitten b
On Mon, Jul 4, 2011 at 8:54 AM, Jim Dalton wrote:
> I've created a ticket for this and uploaded a patch:
> https://code.djangoproject.com/ticket/16401
> Please feel free to review and let me know if this is a good idea in the
> first place, as well as if the patch makes sense and is the right ap
On Mon, Jul 4, 2011 at 12:13 AM, Ryan wrote:
> Umm... How about now?
Sorry, but this isn't going to happen. I left more information on the
ticket: https://code.djangoproject.com/ticket/6362#comment:43.
Jacob
--
You received this message because you are subscribed to the Google Groups
"Django
I like this quite a bit. It's clean, and it allows for a common i18n pattern
where the footer contains a translation link for each supported language, and
the language names are localized to themselves (i.e. "Español | Français |
Deutsch").
Sam
On 2011-07-04, at 5:23 AM, brocaar wrote:
> On M
I've created a ticket for this and uploaded a patch:
https://code.djangoproject.com/ticket/16401
Please feel free to review and let me know if this is a good idea in the first
place, as well as if the patch makes sense and is the right approach.
Thanks,
Jim
--
You received this message becaus
On Mon, Jul 4, 2011 at 11:19 AM, Paul Miller wrote:
> Hi Yuri,
>
> I have not tested them for speed, but:
>
> - Named tuples have no instance dictionary, so their instances take no more
> space than a regular tuple (for example, casting thousands of sql records to
> named tuples has zero memory
I was told that for Python 2.5 nametuples "emulation" is 8 times
slower than regular tuples and dicts.
That's why I'm interested in benchmarks. If it's significantly slower
(at least for Python 2.4 and 2.5), this should be mentioned in docs.
On Mon, Jul 4, 2011 at 5:19 PM, Paul Miller wrote:
> Hi
+1
On Mon, Jul 4, 2011 at 6:13 AM, Ryan wrote:
> Umm... How about now? I've been bitten by trailing/leading blank spaces in
> form inputs several times now, and I'm tired of monkey patching django to
> fix this. Thanks.
>
> Ryan
>
> --
> You received this message because you are subscribed to t
Hi Yuri,
I have not tested them for speed, but:
- Named tuples have no instance dictionary, so their instances take no more
space than a regular tuple (for example, casting thousands of sql records to
named tuples has zero memory overhead).
- They also use C-speed attribute lookup using propert
On Monday, July 4, 2011 10:04:10 AM UTC+2, Jannis Leidel wrote:
>
> Agreed, what about just "language", e.g.:
>
> {% language lang_code %}
> {% trans "Register account" %}: {% url account:register %}
> {% endlanguage %}
>
>
> I agree too that the tag name in my example is quite ugly, it was onl
Hi everyone and first thanks for the fine framework (getting finer
everyday).
So well, possibly not something very important, but it's been 2 years
now since I first filled a ticket, and while it seems an easy fix,
nothing happened so far. Any chance this will make it into the trunk
someday ?
htt
On 04.07.2011, at 02:48, Chris Beaven wrote:
>
> On Monday, July 4, 2011 1:42:37 AM UTC+12, brocaar wrote:
> What about not implementing this as a url tag but as a translation-
> override tag? Then it is not only possible to specify the language to
> use for your URL translation, but as well f
19 matches
Mail list logo
