#18003: New policy: preserving originating call stacks for exceptions raised in a naked except block.

[Glenn Washburn]

I think the mailing list might be a better place to start/have this
discussion on policy.  But I've made a ticket (#18003) so it can be
officially dealt with an recorded.

I've had trouble with debugging exceptions passing through or coming
from django on several occasions because exceptions were caught then
wrapped and re-raised, effectively killing the originating exception's
call stack. So I feel strongly that django should have as a matter of
policy that originating call stacks should be preserved for raised
exceptions in naked or overly broad except blocks.

What are the downsides to having this?  I think the performance impact
will be negligible and acceptable considering this is on an exception
path.  Let's not unnecessarily throw away information that can be very
useful to debugging.  Comments/Suggestions/Criticisms?

Glenn

-- 
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: Revisiting multiline tags

[Glenn Washburn]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On Sun, 19 Feb 2012 10:01:06 -0700
Carl Meyer  wrote:

> Here's a discussion linked from #3888 in which Malcolm lays out in
> brief why multiline tags have been rejected:
> https://groups.google.com/forum/?fromgroups#!topic/django-developers/A17TJWd3YJU

Very brief I might add.  He only alludes to one technical reason
saying: "error trapping can occur much earlier".  I'm trying to
understand what is meant by this as well.  I don't see how my proposed
change affects error handling in anyway.  What problems are caused by
my change?  I'm actually very interested in this as I'm likely going to
be using this.

I hope I'm not being too demanding by desiring a documented list of
reasons why this is a bad idea.  I've search the groups and not found
anything significant related to this.  Where was it discussed an are
there logs? (was it on irc?)

> There is indeed precedent for wontfix decisions being reversed, but
> this isn't one. The lexing bug revealed in #3888 that caused
> multiline {# #} to sorta kinda work in a broken way had its own
> ticket opened (#4164) and was fixed. In any recent Django, including
> 1.3.1 and 1.4 beta, multiline {# #} does not work at all.

Thanks Carl for pointing that out; I hadn't read that issue close
enough.  And, you're correct I am seeing that multiline {# #} are not
working in 1.3.1.

Personally, I would like to be able to see a tag all at once (that is
without scrolling), even though I might have to scroll to get to the
start of it.  I believe this improves readability of the template. My
specific use case is with include tags with long template paths and
added context variables.

Is there a way we can move forward on this?

Glenn
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.11 (GNU/Linux)

iQEcBAEBAgAGBQJPQaqyAAoJEEPj94mUXoYs61oH/iGuxhABRXF9LT0qK1Kd+FHC
GH7LXijmGEsCo5KUZWmNCir3kKsi9yMJXgqt6oh7+TLj0MIpsD2PM1o9WgJwwxOz
Kbd2DYrq5jvhSPyufVaJbjgTtgLap+PtcdS5k5hJRq/gMDPbQzM8PKxbM3/Mzulo
prj5goCbVX+3NMVW7KrhnMcL3xQq8tB7cCY3azuOYCpAam8/SwFqzlx9sKdxtjbo
lGgaYPK8oi5TslQjEOvtffFXYv5yCuAAZmfFHjByr5eWYTcDJYQP7I/soQqKpkAS
fcUt74MpIODnKiiFAMroGdRfjXa7QhlxTaD6SB6kz1u7UDcM9WGFuzyajOnlzFo=
=X2ww
-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.

Revisiting multiline tags

[Glenn Washburn]

Hello django devers,

I'd like to reopen discussion on the multiline tag issue (see:
https://code.djangoproject.com/ticket/8652) which was closed 3 three
years ago as "won't fix".  The last comment notes that this won't
happen as the decision has been made many times.  But there is no link
to any discussion on this topic, so I can only assume mtredinnick's
point two is the supposed reason for not fixing this.

I've done rudimentary testing on a 6 character change in 1.3.1 to
template.base.tags_re (add the re.S flag to the regex), which appears
to solve the issue.  So I don't see all the work which was being
referred to in mtredinnick's point two.  Perhaps the template engine
has been rewritten since then.  The only test that fails after making
this change (in 1.3.1) is the one that explicitly tests that tgs should
not be multiline.

Since this change appears to be so low impact and such a simple
change.  Are there any reasons why this change shouldn't be included in
django?  Maybe I'm missing something.

Its interesting to note that
https://code.djangoproject.com/ticket/3888, which is referenced in the
issue, is also closed as "won't fix", but appears to be allowed in
1.3.1.  So there is a precedent for "won't fix" issues being included.

-Glenn

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