Response content as generator while debug = true? (Sending intermediate content)

[Chas Emerick]

Re:
http://groups.google.com/group/pylons-discuss/browse_frm/thread/32f4a69cfc4a170f/

I would like to be able to yield intermediate content even when debug
is on -- otherwise, testing is not pleasant (yes, I've been spoiled by
the interactive stack traces, etc!).

Is this possible? If not, I suppose I'll just hook into start_response
directly.

Thanks,

Chas Emerick
Snowtide Informatics

[Ben Bangert]

On Jan 17, 2007, at 8:12 AM, Chas Emerick wrote:

> As mentioned in the referenced post, a generator set as a Response's
> content (as of pylons 0.9.4.1) while debugging is on will be consumed
> entirely before any content is sent to the client.
>
> Is there any way to get around this? I've gotten too used to the
> fantastic interactive stack traces, etc. If no workaround is readily
> available, I'll just hook into start_response directly.

Not really, the interactive debugger can't show you the screen unless
the output is done. Plus, imagine the flow:

- Your iterator starts sending content, (yes, the screen is now
filling with your content)
- Error occurs
- Interactive debugger pops in somewhere in the flow of the existing
content?

At that point, it would be left in an extremely hairy situation,
trying to give you something meaningful to work with after you've
already started who-knows-how-much of the page. There's some other
issues like the steps the evalexception needs to take to preserve the
run-time environment.

AFAIK, it would be at the very least, very difficult to have the
EvalException middleware not consume the iterator first. Maybe Ian
Bicking can chime in if I'm missing the 'real' reason it can't handle
an iterator.

HTH,
Ben

[Chas Emerick]

Yes, I can see the difficulties involved. However, the debugger being
returned as the content that was requested when an error occurs is
really just a convenience -- there's always the unique debug URL that
is piped out to stdout as well.

I'd be perfectly satisfied if pylons/paste/etc were to simply abort the
response if an error occurs, and leave me to figure out that I need to
copy and paste the debug URL from the console to a new browser window.
(Maybe also outputting some reasonable final content indicating that
something went awry.) This behaviour would certainly need to be an
.ini file option so as to not disturb expectations elsewhere (or, even
better, add an attribute to the Response object so that each action
could determine the appropriate behaviour, rather than having the
setting apply application-wide).

Chas Emerick
Snowtide Informatics

[Ben Bangert]

On Jan 17, 2007, at 5:26 PM, Chas Emerick wrote:

> I'd be perfectly satisfied if pylons/paste/etc were to simply abort
> the
> response if an error occurs, and leave me to figure out that I need to
> copy and paste the debug URL from the console to a new browser window.
> (Maybe also outputting some reasonable final content indicating that
> something went awry.) This behaviour would certainly need to be an
> .ini file option so as to not disturb expectations elsewhere (or, even
> better, add an attribute to the Response object so that each action
> could determine the appropriate behaviour, rather than having the
> setting apply application-wide).

I believe this solution could work, can you file a ticket for it on
the PythonPaste trac?

Thanks,
Ben