Dear all, I'm pretty new to flask,and I'm finding a way to debug my application not just the manage.py but also the inner view or model module in my application with every variables watched,I'm currently developing with wingide or pydev,any thought on this? Thanks all! 南方基金管理有限公司免责声明：本电子邮件可能含有保密信息，发件人保留与本邮件相关的一切权利。如果您非收件人（或收到的电子邮件含错误信息），请立即通知发件人并删除该邮件。任何未经授权者不得将本电子邮件所含内容复制、披露、转发或其他任何形式的使用。 This e-mail may contain confidential and/or privileged information, If you are not the intended recipient (or have received this e-mail in error), please notify the sender immediately and destroy this e-mail. Any unauthorized copying, disclosure or distribution of the material in this e-mail is strictly forbidden.
print or logging On Sat, May 14, 2011 at 8:29 AM, 黄盛 <huangsheng@southernfund.com> wrote: > > Dear all, > > I'm pretty new to flask,and I'm finding a way to debug my application not > just the manage.py but also the inner view or model > > module in my application with every variables watched,I'm currently > developing with wingide or pydev,any thought on this? > > Thanks all! > > > 南方基金管理有限公司免责声明：本电子邮件可能含有保密信息，发件人保留与本邮件相关的一切权利。如果您非收件人（或收到的电子邮件含错误信息），请立即通知发件人并删除该邮件。任何未经授权者不得将本电子邮件所含内容复制、披露、转发或其他任何形式的使用。 > > This e-mail may contain confidential and/or privileged information, If you > are not the intended recipient (or have received this e-mail in error), > please notify the sender immediately and destroy this e-mail. Any > unauthorized copying, disclosure or distribution of the material in this > e-mail is strictly forbidden. >
Hi, You can use pdb and set a trace or ipdb (slightly nicer) or alternatively you could even trigger the Werkzeug debugger like so: http://flask.pocoo.org/snippets/21/ On Tue, May 17, 2011 at 3:43 AM, LiChao <sockpuppet.lea@gmail.com> wrote: > print or logging > > > On Sat, May 14, 2011 at 8:29 AM, 黄盛 <huangsheng@southernfund.com> wrote: > >> >> Dear all, >> >> I'm pretty new to flask,and I'm finding a way to debug my application not >> just the manage.py but also the inner view or model >> >> module in my application with every variables watched,I'm currently >> developing with wingide or pydev,any thought on this? >> >> Thanks all! >> >> >> 南方基金管理有限公司免责声明：本电子邮件可能含有保密信息，发件人保留与本邮件相关的一切权利。如果您非收件人（或收到的电子邮件含错误信息），请立即通知发件人并删除该邮件。任何未经授权者不得将本电子邮件所含内容复制、披露、转发或其他任何形式的使用。 >> >> This e-mail may contain confidential and/or privileged information, If you >> are not the intended recipient (or have received this e-mail in error), >> please notify the sender immediately and destroy this e-mail. Any >> unauthorized copying, disclosure or distribution of the material in this >> e-mail is strictly forbidden. >> > >
On 05/17/2011 04:40 AM, Ross Lawley wrote: > You can use pdb and set a trace or ipdb (slightly nicer) or > alternatively you could even trigger the Werkzeug debugger like so: > http://flask.pocoo.org/snippets/21/ The problem I've had with triggering the Werkzeug debugger in views is that the stack jumps from the render_template call right down into Jinja2 code. This makes sense, of course, because you can't really run a template :) But if you have a template like such: > {% for x in foo: %} > {{ x['bar'] }} > {% endfor %} > {% assert False %} triggering Werkzeug with an assert won't help; the assert will prevent template compilation, meaning the things you would be interested in -- foo, x, etc -- will never make it to a stack frame. I'm not certain pdb or ipdb would exhibit any different behavior, though I've not tried them. I'd imagine though that trying to set a trace inside the view would lead to the same behavior -- you'd be able to debug Jinja2's loader & compiler, but the things you want to interact with would never be loaded from the template. I always use LiChao's solution of simply printing data to stdout, but would love to see a more interactive alternative. -- Owen Marshall FacilityONE http://www.facilityone.com | (502) 805-2126
Sometimes I'll wrap my methods in a try/catch, and in the catch, return a Flask Response in which the content is the output of traceback.format_exc() and the content-type is text plain. Not sure if this is very Flasky ( Flaskonic? Flaskish?). But it's easy, and the same approach works in any environment ( raw wsgi, etc ), and for most of my bugs I don't really need the debugger (though sometimes it is the perfect thing ). Jinja2's diagnostic messages are very good. Den May 17, 2011 kl. 9:30 AM skrev Owen Marshall: > On 05/17/2011 04:40 AM, Ross Lawley wrote: > >> You can use pdb and set a trace or ipdb (slightly nicer) or >> alternatively you could even trigger the Werkzeug debugger like so: >> http://flask.pocoo.org/snippets/21/ > > The problem I've had with triggering the Werkzeug debugger in views is > that the stack jumps from the render_template call right down into > Jinja2 code. This makes sense, of course, because you can't really run a > template :) > > But if you have a template like such: > >> {% for x in foo: %} >> {{ x['bar'] }} >> {% endfor %} >> {% assert False %} > > triggering Werkzeug with an assert won't help; the assert will prevent > template compilation, meaning the things you would be interested in -- > foo, x, etc -- will never make it to a stack frame. > > I'm not certain pdb or ipdb would exhibit any different behavior, though > I've not tried them. I'd imagine though that trying to set a trace > inside the view would lead to the same behavior -- you'd be able to > debug Jinja2's loader & compiler, but the things you want to interact > with would never be loaded from the template. > > I always use LiChao's solution of simply printing data to stdout, but > would love to see a more interactive alternative. > > -- > Owen Marshall > FacilityONE > http://www.facilityone.com | (502) 805-2126 >
On 05/17/2011 02:43 PM, Rob Mela wrote: > Jinja2's diagnostic messages are very good. Hear hear -- Jinja2's messages *are* quite nice. I was thinking and realized if I look back at my example, it's a bit wrong: > {% for x in foo: %} > {{ x['bar'] }} > {% endfor %} > {% assert False %} As I'd understand MVC separation, if I'm concerned with foo or x, I should likely be attaching my debugger to the responsible model, *not* the view. As a flask newbie, though, my desire was often to get a debugger at the view level -- but looking at this again I don't think it's the right place. -- Owen Marshall FacilityONE http://www.facilityone.com | (502) 805-2126