Re: [Python-ideas] Pythonic buffering in Py3 print()
[ Taken back on list - I can't see anyway personal here, and the objection is a good one. - Cameron ] On 11Jan2012 08:41, Paul Moore <p.f.moore@gmail.com> wrote: | On 11 January 2012 06:15, Cameron Simpson <cs@zip.com.au> wrote: | > | flush=None? | > | > +1 from me, if None means "honour the file's default flushing | > behaviour". | | The trouble with this is that we then have: | - no parameter (default None) => default behaviour | - flush=True => Always flush | | and that begs the question of what an explicit flush=False means, and | people will assume it means "never flush" even thought you can't force | that as the underlying stream might auto-flush (e.g., at a newline). | | +1 for flush=True/False, with a default of False (meaning do the | stream's default behaviour). Hmm. Good point about False suggesting "never flush", but I think it should just be considered invalid. What about flush=3, or flush=tuple? Better if we only specify behaviour for True (flush now) and None/default/missing (flush default) and make it slightly clear that other values do not have defined behaviour. That leaves scope later for defining a sane (or at least clear) meaning for False if a _useful_ one is ever agreed upon. Call it "reserved". Cheers, -- Cameron Simpson <cs@zip.com.au> DoD#743 http://www.cskk.ezoshosting.com/cs/ Copyright and Patents: To prevent the Progress of Science and useful Arts, by securing for unlimited Times to Authors and Inventors and Trolls the exclusive Right to all Writings and Discoveries. - http://science.slashdot.org/story/11/04/26/211258/Copyright-Law-Is-Killing-S...
On 1/11/2012 6:02 PM, Cameron Simpson wrote:
That was the intent of my suggested doc rewording -- file controls flushing unless flush=True is given. What I wrote on the issue was a first try and I suspect that there are other and perhaps better concise wordings. Post one on the issue if you have one. (But writing in 'doc style' is not always easy ;-). -- Terry Jan Reedy
On 11Jan2012 19:15, Terry Reedy <tjreedy@udel.edu> wrote: | On 1/11/2012 6:02 PM, Cameron Simpson wrote: | >Better if we only specify behaviour for True (flush now) and | >None/default/missing (flush default) and make it slightly clear that | >other values do not have defined behaviour. | | That was the intent of my suggested doc rewording -- file controls | flushing unless flush=True is given. What I wrote on the issue was a | first try and I suspect that there are other and perhaps better | concise wordings. Post one on the issue if you have one. (But | writing in 'doc style' is not always easy ;-). Do I comment here, or in #11633 (which is closed) or in #13761? We seem to have multiple streams of discussion. BTW, regarding #11633, I don't like your sentence: Use ``sys.stdout.flush()`` to ensure immediate appearance on a screen Shouldn't that be "*file*.flush()" ? I would _not_ want to give a shallow reader the idea that flushing stdout magicly sorts their problems with a specific file. And I've seen that level of logical gap in various questions on python-list (and elsewhere, of course). I'd also change "ensure immediate appearance on a screen" to "ensure immediate output, for example to ensure appearance on a screen". Again, it changes the wording from "to perform this specific special case call flush" to "calling flush does blah, for example to aid this specific case". Cheers, -- Cameron Simpson <cs@zip.com.au> DoD#743 http://www.cskk.ezoshosting.com/cs/ When in doubt, gas it. It may not solve the problem, but it ends the suspense. - Steve Moonitz (92 Ducati 900ss) <stevem@ew.timeinc.com>
On 1/11/2012 8:40 PM, Cameron Simpson wrote:
After much discussion that included the possibility of a behavior change, that issue became about changing the print doc, especially for 3.2.
or in #13761?
After Guido's approval of leaving the default behavior as is but adding a parameter to change it, that was opened for the behavior change for 3.3. That change will require further doc change for 3.3.
That was my original idea but I changed it after internal debate. But I was at most 60-40 for what I did.
If one of the doc people agree with you enough to refine the effectively temporary change for 3.2, fine, but I do not think it worth the effort. I suggest you focus on the doc further change for 3.3 after the behavior change. That will potentially be in the docs for several future versions. For that, post a post-change suggestion to #13761. -- Terry Jan Reedy
Thanks everybody for discussion. It took only 6 days between noticing the problem [1] and finding the cause [2]. I wish the process didn't require so intensive communication, because without holidays I'd probably gave up on this. =) It's good that I know English. 1. https://bitbucket.org/techtonik/python-pager/changeset/3e3d0700ba5f 2. https://bitbucket.org/techtonik/python-pager/changeset/ffe9da2d5316 -- anatoly t.
On 1/11/2012 6:02 PM, Cameron Simpson wrote:
That was the intent of my suggested doc rewording -- file controls flushing unless flush=True is given. What I wrote on the issue was a first try and I suspect that there are other and perhaps better concise wordings. Post one on the issue if you have one. (But writing in 'doc style' is not always easy ;-). -- Terry Jan Reedy
On 11Jan2012 19:15, Terry Reedy <tjreedy@udel.edu> wrote: | On 1/11/2012 6:02 PM, Cameron Simpson wrote: | >Better if we only specify behaviour for True (flush now) and | >None/default/missing (flush default) and make it slightly clear that | >other values do not have defined behaviour. | | That was the intent of my suggested doc rewording -- file controls | flushing unless flush=True is given. What I wrote on the issue was a | first try and I suspect that there are other and perhaps better | concise wordings. Post one on the issue if you have one. (But | writing in 'doc style' is not always easy ;-). Do I comment here, or in #11633 (which is closed) or in #13761? We seem to have multiple streams of discussion. BTW, regarding #11633, I don't like your sentence: Use ``sys.stdout.flush()`` to ensure immediate appearance on a screen Shouldn't that be "*file*.flush()" ? I would _not_ want to give a shallow reader the idea that flushing stdout magicly sorts their problems with a specific file. And I've seen that level of logical gap in various questions on python-list (and elsewhere, of course). I'd also change "ensure immediate appearance on a screen" to "ensure immediate output, for example to ensure appearance on a screen". Again, it changes the wording from "to perform this specific special case call flush" to "calling flush does blah, for example to aid this specific case". Cheers, -- Cameron Simpson <cs@zip.com.au> DoD#743 http://www.cskk.ezoshosting.com/cs/ When in doubt, gas it. It may not solve the problem, but it ends the suspense. - Steve Moonitz (92 Ducati 900ss) <stevem@ew.timeinc.com>
On 1/11/2012 8:40 PM, Cameron Simpson wrote:
After much discussion that included the possibility of a behavior change, that issue became about changing the print doc, especially for 3.2.
or in #13761?
After Guido's approval of leaving the default behavior as is but adding a parameter to change it, that was opened for the behavior change for 3.3. That change will require further doc change for 3.3.
That was my original idea but I changed it after internal debate. But I was at most 60-40 for what I did.
If one of the doc people agree with you enough to refine the effectively temporary change for 3.2, fine, but I do not think it worth the effort. I suggest you focus on the doc further change for 3.3 after the behavior change. That will potentially be in the docs for several future versions. For that, post a post-change suggestion to #13761. -- Terry Jan Reedy
Thanks everybody for discussion. It took only 6 days between noticing the problem [1] and finding the cause [2]. I wish the process didn't require so intensive communication, because without holidays I'd probably gave up on this. =) It's good that I know English. 1. https://bitbucket.org/techtonik/python-pager/changeset/3e3d0700ba5f 2. https://bitbucket.org/techtonik/python-pager/changeset/ffe9da2d5316 -- anatoly t.
participants (4)
-
anatoly techtonik -
Cameron Simpson -
Guido van Rossum -
Terry Reedy