new feature idea: even and odd forloop iteration variables
Hi all!
I've been working with Django for a while now, but today I decided to
make a first contribution to Django that would make templates less
ugly by adding these two values to loop_dict (in django/template/
defaulttags.py):
loop_dict['even'] = (i %2 == 0)
loop_dict['odd'] = (i %2 != 0)
Using {% if forloop.even %} would be more clear and readable than {%
if forloop|divisibleby:"2" %}.
As I am new to working *on* Django I don't know the history of this
idea (if there is one) and the correct way of sending patches, all
comments (and corrections!) are appreciated!
-Karlis Lauva /skazhy/
--
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.
Postgress array types
How can i store Postgress array types in Django models -- 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: Postgress array types
Please don't crosspost to both django-users and django-developers: pick the right list and post there. The right place for this question was django-users. 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: new feature idea: even and odd forloop iteration variables
On 09/19/2011 12:58 PM, skazhy wrote:
Hi all!
I've been working with Django for a while now, but today I decided to
make a first contribution to Django that would make templates less
ugly by adding these two values to loop_dict (in django/template/
defaulttags.py):
loop_dict['even'] = (i %2 == 0)
loop_dict['odd'] = (i %2 != 0)
Using {% if forloop.even %} would be more clear and readable than {%
if forloop|divisibleby:"2" %}.
As I am new to working *on* Django I don't know the history of this
idea (if there is one) and the correct way of sending patches, all
comments (and corrections!) are appreciated!
-Karlis Lauva /skazhy/
https://docs.djangoproject.com/en/dev/ref/templates/builtins/#std:templatetag-cycle
--
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: new feature idea: even and odd forloop iteration variables
Hey Karlis;
This is a cool idea. I don't do enough template work to always remember the
cycle syntax, but an odd/even is pretty simple to remember.
As for getting this into Django, check out the Contributing Docs[1]. It has
everything you need on how to help out. In particular the Requesting New
Features[2] section will be of interest to you. The first thing to do is
bring it up here on the list (like you've done) and see if others are
interested in adding it. You might also want to include links to any code
that you've changed so other's can take a look at the code.
Hope this help,
-T
[1]: https://docs.djangoproject.com/en/dev/internals/contributing/
[2]:
https://docs.djangoproject.com/en/dev/internals/contributing/bugs-and-features/#requesting-features
On Mon, Sep 19, 2011 at 5:58 AM, skazhy wrote:
> Hi all!
>
> I've been working with Django for a while now, but today I decided to
> make a first contribution to Django that would make templates less
> ugly by adding these two values to loop_dict (in django/template/
> defaulttags.py):
>
> loop_dict['even'] = (i %2 == 0)
> loop_dict['odd'] = (i %2 != 0)
>
> Using {% if forloop.even %} would be more clear and readable than {%
> if forloop|divisibleby:"2" %}.
> As I am new to working *on* Django I don't know the history of this
> idea (if there is one) and the correct way of sending patches, all
> comments (and corrections!) are appreciated!
>
>
> -Karlis Lauva /skazhy/
>
> --
> 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.
>
>
--
Travis Swicegood | @tswicegood (most everywhere) | Senior Open Source
Engineer @ Texas Tribune / Armstrong
--
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.
removing "milestone" field in Trac
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi all, The milestone field came up again in IRC discussion tonight between Julien and Paul and I -- namely, that it doesn't seem all that useful and causes noise in Trac. It might have made sense back when we had more feature-driven releases and a feature voting process, but as we're (trying to) move towards date-based releases and we've moved away from feature voting, I don't see what purpose it serves. Tickets marked "release blocker" must get fixed before release, any other accepted ticket is always a candidate to get fixed if someone works on it in time. Milestone doesn't add anything but noise. Julien already raised this topic a while back [1] and Luke more or less agreed. Can we just go ahead and remove the field, or does somebody want to present an impassioned defense of its usefulness (in which case you should explain what it means, which tickets should get a milestone set, who should set it, and under what conditions it should be removed or bumped)? Thanks, Carl [1] http://groups.google.com/group/django-developers/browse_thread/thread/bf7da09f1f5881dc/ -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk5393IACgkQ8W4rlRKtE2eVTgCgrAS6xav1CDdbzwIdBF1MHy3M G4AAnRDATInx+eFLqWlj6czhFUeT+49x =a3GB -END PGP SIGNATURE- -- 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: removing "milestone" field in Trac
On Tue, Sep 20, 2011 at 10:16 AM, Carl Meyer wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > Hi all, > > The milestone field came up again in IRC discussion tonight between > Julien and Paul and I -- namely, that it doesn't seem all that useful > and causes noise in Trac. > > It might have made sense back when we had more feature-driven releases > and a feature voting process, but as we're (trying to) move towards > date-based releases and we've moved away from feature voting, I don't > see what purpose it serves. Tickets marked "release blocker" must get > fixed before release, any other accepted ticket is always a candidate to > get fixed if someone works on it in time. Milestone doesn't add anything > but noise. > > > Julien already raised this topic a while back [1] and Luke more or less > agreed. Can we just go ahead and remove the field, or does somebody want > to present an impassioned defense of its usefulness (in which case you > should explain what it means, which tickets should get a milestone set, > who should set it, and under what conditions it should be removed or > bumped)? I agree that it's adding more noise and confusion than it's worth. Kill it with fire. The only use case for Milestone that I can think of is to track backwards incompatible changes that need to be revisited for when we get to v2.0. However, I think those could be handled just as elegantly with the someday/maybe ticket state. 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: removing "milestone" field in Trac
On Mon, Sep 19, 2011 at 9:16 PM, Carl Meyer wrote: > The milestone field came up again in IRC discussion tonight between > Julien and Paul and I -- namely, that it doesn't seem all that useful > and causes noise in Trac. I agree. I think the "release blocker" flag basically replaces the milestone idea as far as we're concerned. If there are no serious objections, I'll remove the field later this week. Jacob -- 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.
