M
michele.simionato
Just said:
M
michele.simionato
(Not sure if my other message arrived)
I am guilty of using this idiom, too.
The standard library
http://www.python.org/dev/doc/devel/lib/module-sys.html#l2h-396
says:
"""
__stdin__
__stdout__
__stderr__
These objects contain the original values of stdin, stderr and
stdout at the start of the program. They are used during finalization,
and could be useful to restore the actual files to known working file
objects in case they have been overwritten with a broken object.
"""
Notice the "during finalization" sentence.
Maybe you should change the doc and explain what __stdout__ is intended
for?
Michele Simionato
I am guilty of using this idiom, too.
The standard library
http://www.python.org/dev/doc/devel/lib/module-sys.html#l2h-396
says:
"""
__stdin__
__stdout__
__stderr__
These objects contain the original values of stdin, stderr and
stdout at the start of the program. They are used during finalization,
and could be useful to restore the actual files to known working file
objects in case they have been overwritten with a broken object.
"""
Notice the "during finalization" sentence.
Maybe you should change the doc and explain what __stdout__ is intended
for?
Michele Simionato
R
Ron Garret
Just said:
It's helpful to provide an explanation when saying things like this.
In this case, it's best to save the original value of sys.stdout and
restore that, otherwise nested calls to with_output_to_string can fail,
e.g.
def f():
print 123
def g():
print 456
x = with_output_to_string(f)
print 789
with_outupt_to_string(g) # Will miss the 789
rg
R
Ron Garret
jfj said:
Then neither am I.
Yes, there's a reason people choose C over Lisp, just as there is a
reason that people choose Windows over OS X, the Ford Taurus over the
Lexus SC400, and Perl over Python. But I'm pretty sure joy isn't that
reason. If joy is part of your quality metric for a programming
language then Lisp is worth a look. (And it costs a lot less than a
Lexus.)
rg
J
JanC
Just schreef:
You're right, especially when this code would execute in an (at
programming time) unknown context.
You're right, especially when this code would execute in an (at
programming time) unknown context.
J
jfj
Ron said:
I've had it with all those lisp posts lately ;-)
There were functional and non-functional programming languages (the
first being *much* simpler to implement). There is a *reason* people
chose C over lisp. It's not that we were all blind and didn't see the
amazingness of lisp. Procedural languages are simply better, and I'm not
replying to this flamewar.
Thank you
G.
S
Steve Holden
Ron said:
Well, in the Computer Programming for Everyone stakes I'm pretty sure
that LISP and its derivatives don't stand a chance, simply because of
the rebarbative syntax one must use to express even relatively simple
algorithms and data structures.
While the language has a lot going for it in the hands of an experienced
and determined LISPer, the average programmer just isn't going to "get it".
regards
Steve
S
Simo Melenius
Just said:
It probably does the right thing, if someone is copypasting code off
the Usenet and tries it out at the Python prompt (and possibly gets
stuck in getting nothing printed on his tty).
If we're talking about real code it might be advisable to start by
first introducing the import statements omitted from the above
snippet, then worry about someone copypasting code into a serious
program instead of copythinkpasting it.
br,
S
R
Richie Hindle
[Erik]
+1 Quote of the Week!
+1 Quote of the Week!