IfEqualNode is missing a get_nodes_by_type method

[SmileyChris]

My ticket in #6510 [1] deals with this, along with a nice abstraction
of common recursive nodelist gathering patterns.

Although the ticket description, comments (and even tests in my patch)
mention {% block %}, this has *nothing* to do with conditional
inheritance.

If the patch is deemed too much of a feature to fit in the 1.2
schedule, I'd still advocate for just adding a get_nodes_by_type
method to the IfEqualNode. It's not a difficult or overly
controversial change, and the bug has existed far too long because of
confusion over the actual issue.

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

-- 
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: 404 debug pages should show the name of the tried urlpattern - #9310

[Jeremy Dunck]

On Wed, Feb 24, 2010 at 11:14 AM, Tobias McNulty  wrote:
...
> I'm hoping this will spark a discussion about how we can work more
> efficiently and put donated time to better use.  I may be a bit biased,
> because this is coming on the tail end of spending 2+ person hours trying to
> reproduce a ticket in the PyCon sprint that, I later found out, two others
> had done the same thing with a day earlier, but neither had indicated as
> much in the ticket.

The basic problem, as ever, is managing volunteer time.  In this case,
it looks like a failure of triage.  A committer often looks for
ready-for-checkin, and this ticket, despite having a patch, never got
marked ready-for-checkin.

Prompted by your question, I see that there are over 700 tickets in
this status -- I'd say a ticket should fairly quickly clear this stage
-- either be marked ready or marked patch-needs-improvement.  But of
course the triagers themselves are volunteers, doing relatively
unglamorous work when they can. (And thank you to all triagers for
their work!)

http://code.djangoproject.com/query?status=new=assigned=reopened_better_patch=%211_patch=1=priority=%21Ready+for+checkin

There are over 200 bugs marked 1.2 -- even after features got booted
to 1.3 (including yours), with the release date coming soon.  I'm sure
more will have to be pushed.  James got to be the bad guy booting
tickets for features late for 1.2-- some apparently due to workflow
failure.  But he's just following the workflow, too.

> A couple ideas to get us started:
>
> 1) Reemphasize via documentation and/or training (and/or by reading this
> message) the proper work flow for tickets (e.g., accept it when you start
> working on it, post a comment when you're done, etc.):
>
> http://docs.djangoproject.com/en/dev/internals/contributing/#claiming-tickets

I don't think documenting it more is the solution -- if people aren't
clear on the process as documented, I certainly haven't heard that
confusion.  I think the issue is that documenting and doing are two
different things.  For example, I know that I should only have tickets
assigned to me if I'm actively working them, but that hasn't stopped
me from forgetfully breaking that rule pretty often.

> 2) For each release, assign several people (I'd be happy to take a turn) the
> task of searching through all outstanding tickets in the milestone in
> question a couple weeks before the feature freeze and assigning
> "committable" ones to specific committers.  Maybe this ticket is an outlier,
> but I expect there are others out there that are also getting missed.  I'm
> not sure if this means that the current way ticket triage is outlined to
> work is just not happening, or if there are changes we need to make so that
> it works more effectively:
>
> http://docs.djangoproject.com/en/dev/internals/contributing/#ticket-triage

This gets at the problem more directly -- we used to have a
feature/bug classification, but it was abused -- lots of people marked
things as bugs simply because they felt they were necessary, and hence
not "features".  Everything is miscellaneous, but if there is no
consistent distinction between bug and feature, there's no point in
having the field.

I don't think we need a workflow that assigns committables to specific
committers-- they're working and doing what they can, we already have
a ready-for-commit sign, and (I presume) the issue isn't that they
aren't committing as quickly as possible -- the # of ready-for-commit
tickets has hovered between 15 and 100 for a year, and sits at 50 now.
 Tickets are being resolved quite a bit, so the inflow is roughly
matching the outflow.

What you're asking for, I think, is some sensitivity to the scope of a
change vs. how long it's been pending.  This is a pretty hard problem
to address -- if it falls to triagers, you're back where we started of
triaging not being able to keep up with the queue.  It'd be nice if
Trac stored time-stamped state transitions to reveal this sort of
thing.

That said, I wasn't aware that the # of untriaged tickets was that
high-- if I had known, maybe I would have spent more time triaging.
So I'm asking myself: where in the process are there places that
workflow breaks down, and how can we make those places more visible?
I'm presuming that if it were more visible, it would be better
addressed -- but it may simply be the case that we need more
volunteers to step into the break -- to stop filing their feature
patches, and to start clearing the triage queue.

http://docs.djangoproject.com/en/dev/internals/contributing/#triage-by-the-general-community

-- 
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: Conditional block statements

[joep]

Yes, your version works as well, and is what I meant by "Or some
variation thereof---it depends on how far apart you want to
put these two particular bits of related logic." I agree it's
readable, it's just not particularly logical or straightforward, and I
would suggest that anybody who isn't already intimately familiar with
the issue to come up with it without a heck of a lot of head
scratching. Or, maybe it's just me.

On Feb 24, 2:14 am, Valts  wrote:
> Hello,
>
> I think that the working code would look like:
>
> {% block head %}
>   {{block.super}}
>   {% if need_form %}
>     {{form.media}}
>   {% endif %}
> {% endblock %}
>
> {% block content %}
>   {% if need_form %}
>     {{form.as_p}}
>   {% endif %}
> {% endblock %}
>
> IMHO it is simple enough and readable.
>
> Best regards,
> Valts.
>
> On Feb 24, 5:19 am, joep  wrote:
>
> > Thanks, Russ. That makes some sense. However it leads to constructs
> > like this:
>
> > {% if need_form %}
> >   {block head %}
> >     {{block.super}}
> >     {% if need_form %}
> >       {{form.media}}
> >     {% endif %}
> >   {% endblock %}
> >   {{form.as_p}}
> > {% endif %}
>
> >  (Or some variation thereof---it depends on how far apart you want to
> > put these two particular bits of related logic.)  Which I only arrived
> > at after a few hours of first figuring out why the straightforward
> > solution didn't work as expected. (And I believe--though I don't know--
> > that my expectations would be pretty commonplace). The necessity of
> > doing it this way is so counter intuitive though, that I guess it was
> > a bit frustrating.
>
> > On Feb 23, 7:24 pm, Russell Keith-Magee 
> > wrote:
>
> > > On Wed, Feb 24, 2010 at 2:53 AM, joep  wrote:
> > > > This is in regard to this 
> > > > ticket,http://code.djangoproject.com/ticket/10975,
> > > > which states, in response to the user's complaint, that 'A block
> > > > cannot be defined conditionally within any sort of "if" construct, and
> > > > this is by design; the structure of the template is the structure of
> > > > the template. '
>
> > > > I fail to see the logic here. To give an example of what I was trying
> > > > to do, before I stumbled across this, is that I have a form with
> > > > several widgets, each of which has media (css and js) attached. I
> > > > include the form conditionally, which means I only also want to
> > > > include the media in the 'header' block conditionally. What is the
> > > > rationale for not
> > > > allowing conditional blocks?
>
> > > Think of it in terms of operator priority.
>
> > > You're thinking of {% block %} as having the same priority as {% if
> > > %}. It doesn't - {% block %} has a higher priority. In the same way
> > > that 1 + 2 * 3 is 7, not 9, {% block %} is evaluated before {% if %}.
>
> > > This is what James is driving at when he says "the structure of the
> > > template is the structure of the template". In terms of the parsing
> > > process, the {% block %} structure defines which files need  to be
> > > loaded, and which parts need to be overwritten. Once you have a single
> > > template "page" loaded, you can evaluate the logic in that page - the
> > > {% if %} and other tags that represent the page logic.
>
> > > Yours,
> > > Russ Magee %-)

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

Admin accessibility tweaks

[Chris Adams]

We've been collecting various tweaks to the stock Django 1.1.1 which
have been requested by our 508 testers. I'd appreciate it if someone
could review these tickets:

Add scope=col to changelist table headers:
http://code.djangoproject.com/ticket/12957

Add alt text to SelectFilter2's filter widget:

http://code.djangoproject.com/ticket/12959

SelectFilter2 loses help_text - not a pure accessibility issue but it
can cause confusion in some cases:

http://code.djangoproject.com/ticket/6183

Feedback on streamlining these reports is welcome - I don't think we
have too much else but I'm still waiting for details about the issues
reported on all of our projects.

I'm tracking our changes here:

http://github.com/acdha/django/commits/1.1.1-508-fixes

Thanks,
Chris

-- 
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: 404 debug pages should show the name of the tried urlpattern - #9310

[Tobias McNulty]

What do we do with tickets like this?  Given that this has been ready for
commit since September, I emailed a reminder to the list in October, and
it's such a tiny request, I find it frustrating that this won't make it in
for 1.2.  Personally I have no motivation to maintain the patch going
forward and would rather see the ticket get marked as "wontfix" than be
pushed off indefinitely.  It is poor use of sprinters' time (and defeating,
both personally and to the project) to work on tickets that will never make
it in to trunk.

I'm hoping this will spark a discussion about how we can work more
efficiently and put donated time to better use.  I may be a bit biased,
because this is coming on the tail end of spending 2+ person hours trying to
reproduce a ticket in the PyCon sprint that, I later found out, two others
had done the same thing with a day earlier, but neither had indicated as
much in the ticket.

A couple ideas to get us started:

1) Reemphasize via documentation and/or training (and/or by reading this
message) the proper work flow for tickets (e.g., accept it when you start
working on it, post a comment when you're done, etc.):

http://docs.djangoproject.com/en/dev/internals/contributing/#claiming-tickets

2) For each release, assign several people (I'd be happy to take a turn) the
task of searching through all outstanding tickets in the milestone in
question a couple weeks before the feature freeze and assigning
"committable" ones to specific committers.  Maybe this ticket is an outlier,
but I expect there are others out there that are also getting missed.  I'm
not sure if this means that the current way ticket triage is outlined to
work is just not happening, or if there are changes we need to make so that
it works more effectively:

http://docs.djangoproject.com/en/dev/internals/contributing/#ticket-triage

Cheers,
Tobias

On Mon, Oct 12, 2009 at 7:30 AM, Tobias McNulty wrote:

> In case it's not already on someone's radar, the patch on this ticket
> could use a review at some point:
>
> http://code.djangoproject.com/ticket/9310
>
> Thanks -
> Tobias 
>



-- 
Tobias McNulty
Caktus Consulting Group, LLC
P.O. Box 1454
Carrboro, NC 27510
(919) 951-0052
http://www.caktusgroup.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-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.

Django ORM and multidimensional data

[thierry]

Hi all,

Have django developers planned the integration of new model fields
capable to store multidimensional data ? If it's not the case, how can
I submit this implementation request ?

By implementing this kind of basic types, I think it could be a way
for the Django project to reach the scientific community where Python
and databases are more and more popular to store experimental and
analyses data.

Thanks,

Thierry.

-- 
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: Conditional block statements

[Valts]

Hello,

I think that the working code would look like:

{% block head %}
  {{block.super}}
  {% if need_form %}
{{form.media}}
  {% endif %}
{% endblock %}

{% block content %}
  {% if need_form %}
{{form.as_p}}
  {% endif %}
{% endblock %}

IMHO it is simple enough and readable.

Best regards,
Valts.

On Feb 24, 5:19 am, joep  wrote:
> Thanks, Russ. That makes some sense. However it leads to constructs
> like this:
>
> {% if need_form %}
>   {block head %}
>     {{block.super}}
>     {% if need_form %}
>       {{form.media}}
>     {% endif %}
>   {% endblock %}
>   {{form.as_p}}
> {% endif %}
>
>  (Or some variation thereof---it depends on how far apart you want to
> put these two particular bits of related logic.)  Which I only arrived
> at after a few hours of first figuring out why the straightforward
> solution didn't work as expected. (And I believe--though I don't know--
> that my expectations would be pretty commonplace). The necessity of
> doing it this way is so counter intuitive though, that I guess it was
> a bit frustrating.
>
> On Feb 23, 7:24 pm, Russell Keith-Magee 
> wrote:
>
>
>
> > On Wed, Feb 24, 2010 at 2:53 AM, joep  wrote:
> > > This is in regard to this 
> > > ticket,http://code.djangoproject.com/ticket/10975,
> > > which states, in response to the user's complaint, that 'A block
> > > cannot be defined conditionally within any sort of "if" construct, and
> > > this is by design; the structure of the template is the structure of
> > > the template. '
>
> > > I fail to see the logic here. To give an example of what I was trying
> > > to do, before I stumbled across this, is that I have a form with
> > > several widgets, each of which has media (css and js) attached. I
> > > include the form conditionally, which means I only also want to
> > > include the media in the 'header' block conditionally. What is the
> > > rationale for not
> > > allowing conditional blocks?
>
> > Think of it in terms of operator priority.
>
> > You're thinking of {% block %} as having the same priority as {% if
> > %}. It doesn't - {% block %} has a higher priority. In the same way
> > that 1 + 2 * 3 is 7, not 9, {% block %} is evaluated before {% if %}.
>
> > This is what James is driving at when he says "the structure of the
> > template is the structure of the template". In terms of the parsing
> > process, the {% block %} structure defines which files need  to be
> > loaded, and which parts need to be overwritten. Once you have a single
> > template "page" loaded, you can evaluate the logic in that page - the
> > {% if %} and other tags that represent the page logic.
>
> > Yours,
> > Russ Magee %-)

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