Author haypo
Recipients David.Sankel, amaury.forgeotdarc, brian.curtin, christian.heimes, christoph, davidsarah, ezio.melotti, haypo, hippietrail, lemburg, mark, pitrou, santoso.wijaya, sorin, terry.reedy, tim.golden, tzot, v+python
Date 2011-03-25.02:12:28
SpamBayes Score 4.203e-11
Marked as misclassified No
Message-id <1301019139.25217.22.camel@marge>
In-reply-to <1301014476.12.0.0130606260499.issue1602@psf.upfronthosting.co.za>
Content
Le vendredi 25 mars 2011 à 00:54 +0000, David-Sarah Hopwood a écrit :
> David-Sarah Hopwood <david-sarah@jacaranda.org> added the comment:
> 
> I wrote:
> $ python3 -c 'import sys; sys.stdout.write("foo");
> sys.stdout.buffer.write(b"bar"); sys.stdout.write("baz\n")'
> barfoobaz
> 
> Hmm, the behaviour actually would differ here: the proposed
> implementation would print
> 
> foobaz
> bar
> 
> (the "foobaz\n" is written by a call to WriteConsoleW and then the
> "bar" gets flushed to stdout when the process exits).
> 
> But since the naive expectation is "foobarbaz\n" and you already have
> to flush after each call in order to get that, I think this change in
> behaviour would be unlikely to affect correct applications.

I would not call this "naive". "foobaz\nbar" is really weird. I think
that sys.stdout and sys.stdout.buffer will both have to flush after each
write, or they may be desynchronized.

Some developers already think that adding sys.stdout.flush() after
print("Processing.. ", end='') is too hard (#11633). So I cannot imagine
how they would react if they will have to do it explicitly after all
print, sys.stdout.write() and sys.stdout.buffer.write().
History
Date User Action Args
2011-03-25 02:12:30hayposetrecipients: + haypo, lemburg, terry.reedy, tzot, amaury.forgeotdarc, pitrou, christian.heimes, tim.golden, mark, christoph, ezio.melotti, v+python, hippietrail, sorin, brian.curtin, davidsarah, santoso.wijaya, David.Sankel
2011-03-25 02:12:29haypolinkissue1602 messages
2011-03-25 02:12:28haypocreate