Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > Python > Python! Is! Truly! Amazing!

Reply
Thread Tools

Python! Is! Truly! Amazing!

 
 
Ron Garret
Guest
Posts: n/a
 
      01-02-2005
In article <cr9ebu$re1$(E-Mail Removed)>, http://www.velocityreviews.com/forums/(E-Mail Removed) (Aahz)
wrote:

> In article <(E-Mail Removed)>,
> Roy Smith <(E-Mail Removed)> wrote:
> >In article <(E-Mail Removed)>,
> > Ron Garret <(E-Mail Removed)> wrote:
> >> In article <(E-Mail Removed) .com>,
> >> "Erik Bethke" <(E-Mail Removed)> wrote:
> >>>
> >>> I have NEVER experienced this kind of programming joy.
> >>
> >> Just wait until you discover Lisp!

>
> Taking this more seriously than it deserves, I've tried poking at Lisp a
> couple of times -- each time, I walk away shaking my head in disgust.
> Lisp just ain't as *READABLE* as Python.


Readability is in the eye of the beholder, but this is not the place to
argue this.

But this topic does bring up a legitimate question: I have a bunch of
code that generates HTML using PRINT statements. I need to convert all
this code to return strings rather than actually printing them (so I can
use the results to populate templates). In Lisp I could do this:

(with-output-to-string (s)
(let ( (*standard-output* s) )
(call-html-generating-code)
s))

Is there an equivalent Python trick to capture a function call's output
as a string?

Thanks,
rg
 
Reply With Quote
 
 
 
 
Mark McEahern
Guest
Posts: n/a
 
      01-02-2005
Ron Garret wrote:

> But this topic does bring up a legitimate question: I have a bunch of
> code that generates HTML using PRINT statements. I need to convert
> all this code to return strings rather than actually printing them (so
> I can use the results to populate templates). In Lisp I could do this:
>
> (with-output-to-string (s)
> (let ( (*standard-output* s) )
> (call-html-generating-code)
> s))
>
> Is there an equivalent Python trick to capture a function call's
> output as a string?
>
>

Just to make sure I understand, I'm going to restate your question:

Is there a way to capture stdout?

The answer: Sure, replace it with something file-like:

>>> import sys, StringIO
>>> default = sys.stdout
>>> writer = StringIO.StringIO()
>>> sys.stdout = writer
>>> print 'Whatever'
>>> sys.stdout = default
>>> print writer.getvalue()

Whatever

>>>


// m

 
Reply With Quote
 
 
 
 
Ron Garret
Guest
Posts: n/a
 
      01-02-2005
In article <(E-Mail Removed)>,
Mark McEahern <(E-Mail Removed)> wrote:

> Ron Garret wrote:
>
> > But this topic does bring up a legitimate question: I have a bunch of
> > code that generates HTML using PRINT statements. I need to convert
> > all this code to return strings rather than actually printing them (so
> > I can use the results to populate templates). In Lisp I could do this:
> >
> > (with-output-to-string (s)
> > (let ( (*standard-output* s) )
> > (call-html-generating-code)
> > s))
> >
> > Is there an equivalent Python trick to capture a function call's
> > output as a string?
> >
> >

> Just to make sure I understand, I'm going to restate your question:
>
> Is there a way to capture stdout?
>
> The answer: Sure, replace it with something file-like:
>
> >>> import sys, StringIO
> >>> default = sys.stdout
> >>> writer = StringIO.StringIO()
> >>> sys.stdout = writer
> >>> print 'Whatever'
> >>> sys.stdout = default
> >>> print writer.getvalue()

> Whatever
>
> >>>

>
> // m


That's exactly what I was looking for. Thanks!

rg
 
Reply With Quote
 
StvB
Guest
Posts: n/a
 
      01-02-2005
The way that Paul Graham sees Lisp:
($$$$$$$$$$$$)))yes!)))))
)
"Roy Smith" <(E-Mail Removed)> wrote in message
news:(E-Mail Removed)...
> In article <(E-Mail Removed)>,
> Ron Garret <(E-Mail Removed)> wrote:
>
>> In article <(E-Mail Removed) .com>,
>> "Erik Bethke" <(E-Mail Removed)> wrote:
>>
>> >
>> > I have NEVER experienced this kind of programming joy.

>>
>> Just wait until you discover Lisp!
>>
>>
>>
>> rg

>
> Shouldn't that be ))))))))))))) ?



 
Reply With Quote
 
JanC
Guest
Posts: n/a
 
      01-03-2005
Ron Garret schreef:

> But this topic does bring up a legitimate question: I have a bunch of
> code that generates HTML using PRINT statements. I need to convert all
> this code to return strings rather than actually printing them (so I can
> use the results to populate templates). In Lisp I could do this:
>
> (with-output-to-string (s)
> (let ( (*standard-output* s) )
> (call-html-generating-code)
> s))
>
> Is there an equivalent Python trick to capture a function call's output
> as a string?


Something like this:

py> import cStringIO
py> import sys
py>
py> def foo():
.... print "test"
....
py> f = cStringIO.StringIO()
py> sys.stdout = f
py> foo()
py> s = f.getvalue()
py> sys.stdout = sys.__stdout__
py> f.close()
py> print s.capitalize()
Test



--
JanC

"Be strict when sending and tolerant when receiving."
RFC 1958 - Architectural Principles of the Internet - section 3.9
 
Reply With Quote
 
Just
Guest
Posts: n/a
 
      01-03-2005
In article <Xns95D365EACCBD7JanC@213.224.134.77>,
JanC <(E-Mail Removed)> wrote:

> Something like this:
>
> py> import cStringIO
> py> import sys
> py>
> py> def foo():
> ... print "test"
> ...
> py> f = cStringIO.StringIO()
> py> sys.stdout = f
> py> foo()
> py> s = f.getvalue()
> py> sys.stdout = sys.__stdout__


You should always save stdout instead of using __stdout__. It may not be
the same! I don't think anyone should *ever* use __stdout__ except when
debugging. See also:

http://mail.python.org/pipermail/pyt...er/010144.html

> py> f.close()
> py> print s.capitalize()
> Test


Just
 
Reply With Quote
 
Simo Melenius
Guest
Posts: n/a
 
      01-03-2005
Ron Garret <(E-Mail Removed)> writes:

> (with-output-to-string (s)
> (let ( (*standard-output* s) )
> (call-html-generating-code)
> s))
>
> Is there an equivalent Python trick to capture a function call's output
> as a string?


I've sometimes replaced sys.stdout (and/or sys.stderr) to
capture/redirect debugging information in existing code that has
unwisely just "print"ed error and warning messages, instead of using
sys.stderr or error logging modules.

py> def with_output_to_string (func):
.... try:
.... sys.stdout = StringIO.StringIO ()
.... func ()
.... return sys.stdout.getvalue ()
.... finally:
.... sys.stdout = sys.__stdout__
....
py> def printing_code ():
.... print "Foobar"
....
py> with_output_to_string (printing_code)
'Foobar\n'
py>


br,
S
 
Reply With Quote
 
Just
Guest
Posts: n/a
 
      01-03-2005
In article <(E-Mail Removed)>,
Simo Melenius <(E-Mail Removed)-spam> wrote:

> I've sometimes replaced sys.stdout (and/or sys.stderr) to
> capture/redirect debugging information in existing code that has
> unwisely just "print"ed error and warning messages, instead of using
> sys.stderr or error logging modules.
>
> py> def with_output_to_string (func):
> ... try:
> ... sys.stdout = StringIO.StringIO ()
> ... func ()
> ... return sys.stdout.getvalue ()
> ... finally:
> ... sys.stdout = sys.__stdout__


Aargh, I can't believe how widespread this idiom is . See my other
reply in this thread: DON'T use sys.__stdout__. Ever.

Just
 
Reply With Quote
 
Ville Vainio
Guest
Posts: n/a
 
      01-03-2005
>>>>> "jfj" == jfj <(E-Mail Removed)> writes:

jfj> There were functional and non-functional programming
jfj> languages (the first being *much* simpler to
jfj> implement). There is a *reason* people chose C over
jfj> lisp. It's not that we were all blind and didn't see the
jfj> amazingness of lisp. Procedural languages are simply better,
jfj> and I'm not replying to this flamewar.

You did already . Lisp is not a functional programming language, if
that was the case it would be even less popular than it is now. Lisp
had it's heyday, while pure FP languages didn't even have that much.

Hey, it's 2005, I don't think we've used up our yearly Lisp flamewar
quota yet.

--
Ville Vainio http://tinyurl.com/2prnb
 
Reply With Quote
 
Christopher Koppler
Guest
Posts: n/a
 
      01-03-2005
On Mon, 03 Jan 2005 13:05:48 +0200, Ville Vainio wrote:

>>>>>> "jfj" == jfj <(E-Mail Removed)> writes:

>
> jfj> There were functional and non-functional programming
> jfj> languages (the first being *much* simpler to
> jfj> implement). There is a *reason* people chose C over
> jfj> lisp. It's not that we were all blind and didn't see the
> jfj> amazingness of lisp. Procedural languages are simply better,
> jfj> and I'm not replying to this flamewar.
>
> You did already . Lisp is not a functional programming language, if
> that was the case it would be even less popular than it is now. Lisp
> had it's heyday, while pure FP languages didn't even have that much.
>
> Hey, it's 2005, I don't think we've used up our yearly Lisp flamewar
> quota yet.


Lisp will strike back! Someday, it will be popular again! When all else is
dust, Lisp will rule the skies!

In the meantime, let's do Python.

--
Christopher

root@creation # python
Python inf (day 1)
[PyPy inf (Pythonix inf)] on pynuxinf
Type "help", "copyright", "credits" or "license" for more information.
>>> from Creation import lux
>>> lux.fiat()


 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off




Advertisments