On 11/13/14 7:54 PM, satishmlm...@gmail.com wrote:
How to get file descriptors of sys.stdin, sys.stdout and sys.stderr?
You don't seem to be reading any of the responses you are getting. At
the very least, you don't seem to be understanding them, or engaging
with the authors
How to get file descriptors of sys.stdin, sys.stdout and sys.stderr?
--
https://mail.python.org/mailman/listinfo/python-list
How to get file descriptors of sys.stdin, sys.stdout and sys.stderr?
--
https://mail.python.org/mailman/listinfo/python-list
On Mon, Nov 25, 2013 at 1:31 AM, Steven D'Aprano
wrote:
> I don't think the REPL handles return values inside loops any different
> from how it handles them outside loops. The difference is that file.write
> methods used to return None in Python 2, in Python 3 they return the
> number of bytes wri
s get printed. In
> a script, that won't happen. To prevent that from happening
> interactively, just assign the result to something:
>
> for i in range(10):
> _=sys.stdout.write(".")
> sys.stdout.flush()
>
> There definitely is a difference between Py2 a
assign the result to something:
for i in range(10):
_=sys.stdout.write(".")
sys.stdout.flush()
There definitely is a difference between Py2 and Py3 there, but it's
nothing to do with sys.stdout - it's a change in the REPL (interactive
interpreter, Read/Eval/Print Loop) and how it handles re
found that the new 'print' function has a 'flush' argument, so it can now
be written as -
for i in range(10):
print('.', end='', flush=False)
time.sleep(1)
print()
I tried to read the docs on sys.stdout, and I see a lot of changes in this
area, but
> sys.stderr = os.fdopen(sys.stderr.fileno(), 'w', 0)
which unfortunately doesn't work! I guess will resort to python3 -u, although
I don't want stdout to be unbuffered.
--
https://mail.python.org/mailman/listinfo/python-list
It's surprising and broken that stderr should be buffered in python3. python3
calls setvbuf(3) on stderr at startup to achieve this chuckle-headed behavior.
It makes stderr line buffered if on a terminal, and fully buffered if
redirected to a log file. A fully buffered stderr is a very bad id
On 18/01/13 02:02, Utpal Sarkar wrote:
Hi,
I was assuming that sys.stdout would be referencing the same physical stream as
iostreams::cout running in the same process, but this doesn't seem to be the
case.
The following code, which makes a call to a C++ function with a python wrapper c
he same thing. Good luck, have fun. It's a LOT
messier than simply assigning to sys.stdout, unfortunately.
ChrisA
--
http://mail.python.org/mailman/listinfo/python-list
Thanks a lot Chris and Nobody! I'll have a look at dup2 for a start.
> > I was assuming that sys.stdout would be referencing the same physical
> > stream as iostreams::cout running in the same process, but this doesn't
> > seem to be the case.
>
>
>
>
On Fri, Jan 18, 2013 at 2:02 AM, Utpal Sarkar wrote:
> I was assuming that sys.stdout would be referencing the same physical stream
> as iostreams::cout running in the same process, but this doesn't seem to be
> the case.
That's more-or-less true, but there will likely be
On Thu, 17 Jan 2013 07:02:24 -0800, Utpal Sarkar wrote:
> I was assuming that sys.stdout would be referencing the same physical
> stream as iostreams::cout running in the same process, but this doesn't
> seem to be the case.
At startup, it refers to the same FILE* as C's std
Hi,
I was assuming that sys.stdout would be referencing the same physical stream as
iostreams::cout running in the same process, but this doesn't seem to be the
case.
The following code, which makes a call to a C++ function with a python wrapper
called "write", that writes
'datefmt' : '', },
'stderr' : { 'format' : '%(message)s',
'datefmt' : '', },
},
27;%(message)s',
'datefmt' : '', },
},
'handlers' : { 'stdout' : { 'class' : 'logging.StreamHandler',
in varying environments, the tools all have an --encoding option
>>>>> to provide output that meets the needs and preferences of the
>>>>> output's ultimate consumers.
[snip]
>>>>> In converting them to Python3, I found the best (if not very
iables, command line
arguments, etc.) causes various issues. So I'm curious of your use
cases.
In converting them to Python3, I found the best (if not very
pleasant) way to do this in Python3 was to put something like
this near the top of each tool[*1]:
import codecs
sys.stdou
tdout=sys.stdout
def write(self,x):
try:
if isinstance(x,unicode):
x=x.encode("utf8")
except (UnicodeEncodeError,UnicodeDecodeError):
sys.stderr.write("This should not happen !")
raise
self.old_stdout.wri
On 3/7/2012 3:57 PM, Peter Kleiweg wrote:
In Python 3, there seem to be two ways to set sys.stdout to
utf-8 after the script has started:
sys.stdout = codecs.getwriter('utf-8')(sys.stdout.detach())
sys.stdout = io.TextIOWrapper(sys.stdout.detach(), encoding='utf-8
In Python 3, there seem to be two ways to set sys.stdout to
utf-8 after the script has started:
sys.stdout = codecs.getwriter('utf-8')(sys.stdout.detach())
sys.stdout = io.TextIOWrapper(sys.stdout.detach(), encoding='utf-8')
I guess the second is better. At start
Hi Terry,
> The difference from 2.x should be in What's New in 3.0, except that the
> new i/o module is in 2.6, so it was not exactly new.
The io module existed in 2.6, but it was not used by default for
standard output and standard error. The only mention of this in
"What's New in 3.0" is in the
On 12/9/2011 2:32 PM, Geoff Bache wrote:
Hi all,
Short version:
I'm a bit confused in general as to the changes between python2 and
python3 regarding how standard output and standard error do buffering.
A few things seem to have changed and I've failed to find any
documentation of how and why.
Hi all,
Short version:
I'm a bit confused in general as to the changes between python2 and
python3 regarding how standard output and standard error do buffering.
A few things seem to have changed and I've failed to find any
documentation of how and why. Also, the meaning of "python -u" seems
to h
On Aug 30, 9:53 am, Michel Albert wrote:
> Unfortunately this setup makes `logging.basicConfig` pretty useless.
> However, I believe that this is something that more people could
> benefit from. I also believe, that it just "makes sense" to send
> warnings (and above) to `stderr`, the rest to `s
ements.
> > - I *always* create two stream handlers. One for `sys.stdout` with
> > level `INFO` and one for `sys.stderr` with level `WARN`
>
> > Well, the levels may variate occasionally, but that's only the rare
> > exception.
>
> How would a call to basicConf
Michel Albert wrote:
> I use python oftentimes to write automation scripts on Linux servers.
> And there's a big pattern in my scripts:
>
> - I *always* use `logging` instead of `print` statements.
> - I *always* create two stream handlers. One for `sys.stdout` with
> l
Hi,
I use python oftentimes to write automation scripts on Linux servers.
And there's a big pattern in my scripts:
- I *always* use `logging` instead of `print` statements.
- I *always* create two stream handlers. One for `sys.stdout` with
level `INFO` and one for `sys.stderr` with level
On Jan 11, 2010, at 1:47 PM Nobody wrote:
On Mon, 11 Jan 2010 10:09:36 +0100, Martin v. Loewis wrote:
In Python 3.1 is there any difference in the buffering behavior of
the
initial sys.stdout and sys.stderr streams?
No.
Were they different at some earlier point in Python's evol
On Mon, 11 Jan 2010 10:09:36 +0100, Martin v. Loewis wrote:
>> In Python 3.1 is there any difference in the buffering behavior of the
>> initial sys.stdout and sys.stderr streams?
>
> No.
>
>> Were they different at some earlier point in Python's evolution?
&g
> In Python 3.1 is there any difference in the buffering behavior of the
> initial sys.stdout and sys.stderr streams?
No.
> Were they different at some earlier point in Python's evolution?
That depends on the operating system. These used to be whatever the
C library set up as std
In Python 3.1 is there any difference in the buffering behavior of the
initial sys.stdout and sys.stderr streams? They are both line_buffered
and stdout doesn't seem to use a larger-grain buffering, so they seem
to be identical with respect to buffering. Were they different at some
ea
On Mon, 23 Nov 2009 23:08:25 +0100, Diez B. Roggisch wrote:
> Try printing
>
>stdout.write('\r-->%d')
^M-->0^M-->1^M-->2^M-->3... ;)
But it's probably good enough for the OP's purposes.
--
http://mail.python.org/mailman/listinfo/python-list
On Nov 23, 8:54 pm, Dave Angel wrote:
> Jankins wrote:
> > On Nov 23, 4:08 pm, "Diez B. Roggisch" wrote:
>
> >> Jankins schrieb:
>
> >>> I am trying to use sys.stdout to print out "process-bar" like:
> >>> -->1%
>
> &g
On Nov 23, 8:32 pm, Cousin Stanley wrote:
> >>
> >> You misunderstand what "flush" means. It is not about
> >> clearing the screen, or the line.
>
> >> Try printing
>
> >> stdout.write('\r-->%d')
>
> >> Diez
>
> > But there is still a problem. When you use control character '\r',
> > you a
Jankins wrote:
On Nov 23, 4:08 pm, "Diez B. Roggisch" wrote:
Jankins schrieb:
I am trying to use sys.stdout to print out "process-bar" like:
-->1%
Here is my program ‘test.py’:
from sys import stdout
for v in range(10):
s
>>
>> You misunderstand what "flush" means. It is not about
>> clearing the screen, or the line.
>>
>> Try printing
>>
>> stdout.write('\r-->%d')
>>
>> Diez
>
>
> But there is still a problem. When you use control character '\r',
> you actually move to the head of the current buffer line
On Nov 23, 4:08 pm, "Diez B. Roggisch" wrote:
> Jankins schrieb:
>
>
>
>
>
> > I am trying to use sys.stdout to print out "process-bar" like:
> > -->1%
>
> > Here is my program ‘test.py’:
>
> > from sys import stdout
> &g
On Nov 23, 4:08 pm, "Diez B. Roggisch" wrote:
> Jankins schrieb:
>
>
>
>
>
> > I am trying to use sys.stdout to print out "process-bar" like:
> > -->1%
>
> > Here is my program ‘test.py’:
>
> > from sys import stdout
> &g
Jankins schrieb:
I am trying to use sys.stdout to print out "process-bar" like:
-->1%
Here is my program ‘test.py’:
from sys import stdout
for v in range(10):
stdout.write('-->%d' % v)
stdout.flush()
else:
stdout.write('done!')
#end for
Then, I
I am trying to use sys.stdout to print out "process-bar" like:
-->1%
Here is my program ‘test.py’:
from sys import stdout
for v in range(10):
stdout.write('-->%d' % v)
stdout.flush()
else:
stdout.write('done!')
#end for
Then, I use 'python -
> Are you sure that Python wasn't just printing out "\n" because you'd
> asked it to show you the repr() of a string containing newlines?
Yes, I am sure. Because I dumped the ord() values to check them.
But again, I'm stumped on how complicated I have made this.
I should not try to code anymore at
Thierry wrote:
> Thank you to both of you (Marc and Tino).
>
> I feel a bit stupid right now, because as both of you said, encoding
> my source string to utf-8 do not produce an exception when I pass it
> to urllib.quote() and is what it should be.
> I was certain that this created an error sooner
Thank you to both of you (Marc and Tino).
I feel a bit stupid right now, because as both of you said, encoding
my source string to utf-8 do not produce an exception when I pass it
to urllib.quote() and is what it should be.
I was certain that this created an error sooner, and id not tried it
again
On Tue, 11 Nov 2008 12:18:26 -0800, Thierry wrote:
> I have realized an wxPython simple application, that takes the input of
> a user, send it to a web service, and get back translations in several
> languages.
> The service itself is fully UTF-8.
>
> The "source" string is first encoded to "lati
for help through google, I have found this post:
http://mail.python.org/pipermail/python-list/2007-October/462977.html
and I gave it a try. What I did, though, was not to override
sys.stdout, but to declare a new writer stream as a property of my
main class:
self.out=OutStreamEncoder(sys.stdout,
that unicode() would
force python to consider the given text as unicode, not to try to
convert it to unicode.
Here again, trying several normalize/decode combination did not helped
at all.
Then, looking for help through google, I have found this post:
http://mail.python.org/pipermail/python-list/2
> import sys
> class ThreadedOut:
> def __init__( self, old ):
> self._old= old
> def write( self, s ):
> self._old.write( s )
> sys.stdout= ThreadedOut( sys.stdout )
>
> Python 3.0a2 WinXP, on the console. 'a&#x
d.write( s )
sys.stdout= ThreadedOut( sys.stdout )
>>> a
>>> 0
0
Python 3.0a2 WinXP, on the console. 'a' is undeclared but error
message isn't thrown. With 'sys.stdout= Thr...' commented:
>>> a
Traceback (most recent call last):
File "&quo
Dirk Loss wrote:
> Bjoern Schliessmann wrote:
>> readline module applies its autocompletion functions to (and only
>> to) sys.stdout.
>
> I see. Then I guess I'll have to avoid redirecting sys.stdout and
> come up with some kind of workaround instead.
Just use a &q
Bjoern Schliessmann wrote:
> readline module applies its autocompletion functions to (and only
> to) sys.stdout.
I see. Then I guess I'll have to avoid redirecting sys.stdout and
come up with some kind of workaround instead.
Nevertheless, thanks for the info.
Regards
Di
Dirk Loss wrote:
> I want to have tab completion in my program for interactive input.
> Using readline and rlcompleter this works nicely. But I also have
> to catch and modify all "print" output, so I redirect sys.stdout
> to a custom file-like object. The problem is: A
Hi,
I want to have tab completion in my program for interactive input.
Using readline and rlcompleter this works nicely. But I also have to
catch and modify all "print" output, so I redirect sys.stdout
to a custom file-like object. The problem is: After the redirection,
readline sup
and sys.stdout to the socket
# start interactive python e.g. ipython ipshellembed()
# put sys.stdin and sys.stdout back to what they were
# debugging session is done
--
http://mail.python.org/mailman/listinfo/python-list
Hello All,
I am trying to capture some printf's from a C function called by
python.
I have tried to following:
STDOUT = 1# stdout fd
(re, we) = os.pipe()# Create re / write handlers
dup2(we, STDOUT)# override system's stdout, should dup first and
restore later..
call_my_hello_world
I have been studying your reply for many hours now, trying to figure it
all out. I am novice in many respects; eg. I did not know neither
Locale, the command locale, nl_langinfo(), hexdump, that ctrl+d is EOF,
etc. :-)
However I have found a way that solves my original problem, and I will
post sol
en ... perhaps. This encoding will only be used
when sending Unicode strings, not when sending byte strings (of those,
Python cannot know what encoding they have, and it sends them
unmodified).
>>>>sys.stdout = codecs.getwriter('utf-8')(sys.stdout)
>>>>sys.stdout.
' " simply write to sys.stdout?
2)
Exactly what does the following line return?
>>> sys.stdout.encoding
'ISO-8859-1'
Is it the encoding of the terminal? I think not, because when I change
the encoding in my terminal the result is still the same.
Is it the encoding of t
Jorgen Grahn a écrit :
> On 9 Sep 2005 03:40:58 -0700, Sébastien Boisgérault <[EMAIL PROTECTED]> wrote:
> >
> > Fredrik Lundh wrote:
> >> Sébastien Boisgérault wrote:
> >>
> >> > Thanks for your answer. The execution of your example leads to a
> >> > 'aaa' display during 2 secs, before it is era
On 9 Sep 2005 03:40:58 -0700, Sébastien Boisgérault <[EMAIL PROTECTED]> wrote:
>
> Fredrik Lundh wrote:
>> Sébastien Boisgérault wrote:
>>
>> > Thanks for your answer. The execution of your example leads to a
>> > 'aaa' display during 2 secs, before it is erased by the prompt.
>> >
>> > This behav
Fredrik Lundh a écrit :
> > what "python shell" are you using, and what platform are you running
> > it on? here's what I get on a standard Unix console:
> >
> import sys
> sys.stdout.write("")
> > >>> sys.stdout.write("\n")
> >
> sys.stdout.write("\n")
>
Fredrik Lundh wrote:
> Sébastien Boisgérault wrote:
>
> > Thanks for your answer. The execution of your example leads to a
> > 'aaa' display during 2 secs, before it is erased by the prompt.
> >
> > This behavior is standard ? The standard output is not supposed
> > to *concatenate* the 'aaa' and
> what "python shell" are you using, and what platform are you running
> it on? here's what I get on a standard Unix console:
>
import sys
sys.stdout.write("")
> >>> sys.stdout.write("\n")
>
sys.stdout.write("\n")
>
> >>>
btw, what does
>>> sy
Robert Kern wrote:
> Sébastien Boisgérault wrote:
> > Tiissa,
> >
> > Thanks for your answer. The execution of your example leads to a
> > 'aaa' display during 2 secs, before it is erased by the prompt.
> >
> > This behavior is standard ? The standard output is not supposed
> > to *concatenate* t
Sébastien Boisgérault wrote:
> Thanks for your answer. The execution of your example leads to a
> 'aaa' display during 2 secs, before it is erased by the prompt.
>
> This behavior is standard ? The standard output is not supposed
> to *concatenate* the 'aaa' and the '>>>' ?
what "python shell" a
Sébastien Boisgérault wrote:
> Tiissa,
>
> Thanks for your answer. The execution of your example leads to a
> 'aaa' display during 2 secs, before it is erased by the prompt.
>
> This behavior is standard ? The standard output is not supposed
> to *concatenate* the 'aaa' and the '>>>' ?
FWIW:
P
Tiissa,
Thanks for your answer. The execution of your example leads to a
'aaa' display during 2 secs, before it is erased by the prompt.
This behavior is standard ? The standard output is not supposed
to *concatenate* the 'aaa' and the '>>>' ?
SB
--
http://mail.python.org/mailman/listinfo/pyt
Sébastien Boisgérault a écrit :
> The sys.stdout stream behaves strangely in my
> Python2.4 shell:
>
> >>> import sys
> >>> sys.stdout.write("")
> >>> sys.stdout.write("\n")
>
> &
Hi,
The sys.stdout stream behaves strangely in my
Python2.4 shell:
>>> import sys
>>> sys.stdout.write("")
>>> sys.stdout.write("\n")
>>> sys.stdout.write("\n")
>>> s
On 07.06.2005, at 16:43, Ahmad Hosseinzadeh wrote:
> Hello,
>
> I’m trying to run an external program in my
> application. Both are coded in python. I need to write
> an independent module that is used in the main
> application. Its responsibility is to run the external
> program and redirect its
Hello,
Im trying to run an external program in my
application. Both are coded in python. I need to write
an independent module that is used in the main
application. Its responsibility is to run the external
program and redirect its stdout and stderr to the main
application.
The applications stdo
chris patton wrote:
> I tried adding the comma at the end
> print 'hello',
> It still added that extra character.
http://mail.python.org/pipermail/python-list/2003-September/184181.html
Peter
--
In diesen Kreisen kreiselt sich der Kreisler
--
http://mail.python.org/mailman/listinfo/python-li
ring.','\n']
It would be hard to get to the next prompt after a print "dsfdfdssd",
if the shell didn't add the \n to get it there.
Also note most shells use repr or str behind the scenes for output to
sys.stdout sys.stderr.
>>> def g():
... pass
...
&g
I tried adding the comma at the end
print 'hello',
It still added that extra character.
--
http://mail.python.org/mailman/listinfo/python-list
e
syntax described above. This form is sometimes referred to as ``print
chevron.'' In this form, the first expression after the >> must
evaluate
to a ``file-like'' object, specifically an object that has a write()
method as described above. With this extended form, the su
chris patton wrote:
>>>>import sys
>>>>class stuff:
>
> ... things = []
> ... def write(self, string):
> ... self.things.append(string)
> ...
>
>>>>def_stdout = sys.stdout
>>>>sys.stdout = stuff
>>> import sys
>>> class stuff:
... things = []
... def write(self, string):
... self.things.append(string)
...
>>> def_stdout = sys.stdout
>>> sys.stdout = stuff()
>>> print 'this is a string.'
>>> print
Hello,
I have a piece of code that gets run in a script that has its stdout
closed:
import sys
sys.stdout = sys.stderr
c = subprocess.Popen (...,
stdin = subprocess.PIPE,
stdout = subprocess.PIPE,
stderr
79 matches
Mail list logo
