AT LINE printed directly instead of to output stream

I capture the output streams for twill using the set_output and
set_errout function calls, and use them to filter/format the output.

But, not all of the prints are being redirected to these streams.
There's one in particular in parse.py that prints out "AT LINE:". I have
a patch attached that resolves this for me locally.

I've noticed another in that file as well that prints out '*** VAL IS',
but the "AT LINE" for me is noisier :) There may be others spread out as
well.

Robert

--- parse.py.orig	2008-03-31 17:05:57.000000000 -0400
+++ parse.py	2008-03-31 17:07:31.000000000 -0400
 <at>  <at>  -212,7 +212,7  <at>  <at> 
                 continue

             cmdinfo = "%s:%d" % (sourceinfo, n,)
-            print 'AT LINE:', cmdinfo
+            print>>commands.OUT, 'AT LINE:', cmdinfo

             cmd, args = parse_command(line, globals_dict, locals_dict)
             if cmd is None:

_______________________________________________
twill mailing list
twill@...

Re: FW: Is formfile closing uploaded file ?

indeed, it is not being closed.  You can fix commands.py yourself (with
an fp.close()) or you can just run the garbage collector,

import gc
gc.collect()

I'll patch this next time I work on twill, thanks for finding it!

--titus

On Fri, Apr 04, 2008 at 03:21:11PM +0000, STM 16 wrote:
-> 
-> 
-> Subject: Is formfile closing uploaded file ?From:
twill-owner@...:
stm_16@...: Fri, 4 Apr 2008 08:19:52 -0700I'm sorry, for spam
reasons, I've disabled posting from non-members.Please send your post directly to
titus@... and I will post it,OR just subscribe to the list and
send your message directory. thanks, --titus 
-> --Forwarded Message Attachment--From: stm_16@...:
twill@...: Is formfile closing uploaded file
?Date: Fri, 4 Apr 2008 15:19:46 +0000 Hi ! I am using twill-0.9b1-py2.5. I am having problems to delete
(unlink) a file after being uploaded using formfile until Py script is finished. Checking commands.py I
found: "... browser.clicked(form, control) fp = open(filename, 'rb') control.add_file(fp,
content_type, filename)  print>>OUT, '\nAdded file "%s" to file upload field "%s"\n' %
(filename,control.name,)..." I could not find something like fp.close() in commands.py neither in
browser.py. Any suggest on how to be able to unlink a file after being uploaded. I am currently uploading
log files and I am needing to exit python script (I would prefer to loop release spa
 ce just from inside script) after sucessfully upload so that file is released. Kind Regards,
SM//_________________________________________________________________Going green? See the top

Re: FW: Is formfile closing uploaded file ?

On Apr 4, 2008, at 4:26 PM, Titus Brown wrote:

> indeed, it is not being closed.  You can fix commands.py yourself  
> (with
> an fp.close())

We noticed this as well, while testing Trac.  The filehandle can't  
just be closed inside formfile since it needs to still be alive when  
the request is actually sent, and a file pointer isn't accepted as an  
arg to formfile (only filename).  Our monkeypatched version accepts  
either a filename (which is read into a StringIO) or a file pointer  
to be passed through directly (which can be later closed).

http://trac.edgewall.org/browser/sandbox/testing/trac/tests/ 
functional/better_twill.py?rev=6757#L54

Tim

Twill-sh -n, --never-fail option with csv_iterate extension

_______________________________________________
twill mailing list
twill@...
http://lists.idyll.org/listinfo/twill

Re: Twill-sh -n, --never-fail option with csv_iterate extension

On Fri, Apr 11, 2008 at 01:57:11PM -0700, eric vonb wrote:
-> Hello All,
-> 
-> I recently started using twill and think it's great of course. Only problem
-> I noticed was that when the option --never-fail is used when running my
-> script that uses the csv_iterate extension the --never-fail option is not
-> being used when csv_iterate runs the second script it calls. Is there
-> something I'm missing here?

Hi, Eric,

I don't see an obvious reason why that would happen... sounds like a bug
to me.  Can you send me an example?

thanks,
--titus

query_string handling in wsgi_intercept.py

Hello list,

I got myselft to start writing test code for my turbogear-1.x project
with twill. So, I use wsgi_intercept.add_wsgi_intercept() in my
testcase. It worked well except for the query_string value.

In make_environ function in the file wsgi_intercept.py, query_string
is decoded and stored as environ, but in my opinion, it shouldn't be
decoded in this stage. Actually, decoding the query_string in this
stage breaks encoded plus value (%2B)  in the query string of the URL
because my app will decode this value once again, and treat it as just
a space.

In short, query string is decoded twice like following
%2B -> + -> SPACE

Please look into the attached file. This change doesn't break the
twill's unittest at all.

Regards,

-- Takashi

_______________________________________________
twill mailing list
twill@...
http://lists.idyll.org/listinfo/twill

Re: query_string handling in wsgi_intercept.py

On Wed, Apr 16, 2008 at 09:36:14AM +0900, Takashi Matsuo wrote:
-> Hello list,
-> 
-> I got myselft to start writing test code for my turbogear-1.x project
-> with twill. So, I use wsgi_intercept.add_wsgi_intercept() in my
-> testcase. It worked well except for the query_string value.
-> 
-> In make_environ function in the file wsgi_intercept.py, query_string
-> is decoded and stored as environ, but in my opinion, it shouldn't be
-> decoded in this stage. Actually, decoding the query_string in this
-> stage breaks encoded plus value (%2B)  in the query string of the URL
-> because my app will decode this value once again, and treat it as just
-> a space.
-> 
-> In short, query string is decoded twice like following
-> %2B -> + -> SPACE
-> 
-> Please look into the attached file. This change doesn't break the
-> twill's unittest at all.

Hi Takashi, thanks -- I have to look into this more, but I have little
doubt your patch fixes a real problem :).

I should also check with Kumar to see if his latest version of
wsgi_intercept handles this properly...

cheers,
--titus

Re: query_string handling in wsgi_intercept.py

On Wed, Apr 16, 2008 at 3:06 AM, Titus Brown <titus@...> wrote:
>  -> In short, query string is decoded twice like following
>  -> %2B -> + -> SPACE
>  ->
>  -> Please look into the attached file. This change doesn't break the
>  -> twill's unittest at all.
>
>  Hi Takashi, thanks -- I have to look into this more, but I have little
>  doubt your patch fixes a real problem :).
>
>  I should also check with Kumar to see if his latest version of
>  wsgi_intercept handles this properly...

funny, Juergen Karnaller just reported this bug a few days ago:
http://code.google.com/p/wsgi-intercept/issues/detail?id=11

I take it no one can think of why unquoting was done here?  Otherwise
I'll go ahead and remove it and cut a bugfix release.

Re: query_string handling in wsgi_intercept.py

On Wed, Apr 16, 2008 at 12:42:46PM -0500, Kumar McMillan wrote:
-> On Wed, Apr 16, 2008 at 3:06 AM, Titus Brown <titus@...> wrote:
-> >  -> In short, query string is decoded twice like following
-> >  -> %2B -> + -> SPACE
-> >  ->
-> >  -> Please look into the attached file. This change doesn't break the
-> >  -> twill's unittest at all.
-> >
-> >  Hi Takashi, thanks -- I have to look into this more, but I have little
-> >  doubt your patch fixes a real problem :).
-> >
-> >  I should also check with Kumar to see if his latest version of
-> >  wsgi_intercept handles this properly...
-> 
-> funny, Juergen Karnaller just reported this bug a few days ago:
-> http://code.google.com/p/wsgi-intercept/issues/detail?id=11
-> 
-> I take it no one can think of why unquoting was done here?  Otherwise
-> I'll go ahead and remove it and cut a bugfix release.

Is "Titus is a butthead and didn't test the code" an acceptable
reason? :)

--titus

Re: query_string handling in wsgi_intercept.py

ok, fixed and released as 0.3.4.  easy_install -U wsgi_intercept to
grab the change, or download from:
http://pypi.python.org/pypi/wsgi_intercept/0.3.4

On Wed, Apr 16, 2008 at 7:46 PM, Titus Brown <titus@...> wrote:
>
> On Wed, Apr 16, 2008 at 12:42:46PM -0500, Kumar McMillan wrote:
>  -> On Wed, Apr 16, 2008 at 3:06 AM, Titus Brown <titus@...> wrote:
>  -> >  -> In short, query string is decoded twice like following
>  -> >  -> %2B -> + -> SPACE
>  -> >  ->
>  -> >  -> Please look into the attached file. This change doesn't break the
>  -> >  -> twill's unittest at all.
>  -> >
>  -> >  Hi Takashi, thanks -- I have to look into this more, but I have little
>  -> >  doubt your patch fixes a real problem :).
>  -> >
>  -> >  I should also check with Kumar to see if his latest version of
>  -> >  wsgi_intercept handles this properly...
>  ->
>  -> funny, Juergen Karnaller just reported this bug a few days ago:
>  -> http://code.google.com/p/wsgi-intercept/issues/detail?id=11
>  ->
>  -> I take it no one can think of why unquoting was done here?  Otherwise
>  -> I'll go ahead and remove it and cut a bugfix release.
>
>  Is "Titus is a butthead and didn't test the code" an acceptable
>  reason? :)
>
>  --titus
>