On 18 March 2005, Donovan Baarda said:
> Rationale
> =========
>
> Many Python library methods and classes like select.select(), os.popen2(),
> and subprocess.Popen() return and/or operate on builtin file objects.
> However even simple applications of these methods and classes require the
> files to be in non-blocking mode.
>
> Currently the built in file type does not support non-blocking mode very
> well. Setting a file into non-blocking mode and reading or writing to it
> can only be done reliably by operating on the file.fileno() file descriptor.
> This requires using the fnctl and os module file descriptor manipulation
> methods.
Is having to use fcntl and os really so awful? At least it requires
the programmer to prove he knows what he's doing putting this file
into non-blocking mode, and that he really wants to do it. ;-)
> Details
> =======
>
> The documentation of file.read() warns; "Also note that when in non-blocking
> mode, less data than what was requested may be returned, even if no size
> parameter was given". An empty string is returned to indicate an EOF
> condition. It is possible that file.read() in non-blocking mode will not
> produce any data before EOF is reached. Currently there is no documented
> way to identify the difference between reaching EOF and an empty
> non-blocking read.
>
> The documented behaviour of file.write() in non-blocking mode is undefined.
> When writing to a file in non-blocking mode, it is possible that not all of
> the data gets written. Currently there is no documented way of handling or
> indicating a partial write.
That's more interesting and a better motivation for this PEP.
> file.read([size]) Changes
> --------------------------
>
> The read method's current behaviour needs to be documented, so its actual
> behaviour can be used to differentiate between an empty non-blocking read,
> and EOF. This means recording that IOError(EAGAIN) is raised for an empty
> non-blocking read.
>
>
> file.write(str) Changes
> --------------------
>
> The write method needs to have a useful behaviour for partial non-blocking
> writes defined, implemented, and documented. This includes returning how
> many bytes of "str" are successfully written, and raising IOError(EAGAIN)
> for an unsuccessful write (one that failed to write anything).
Proposing semantic changes to file.read() and write() is bound to
raise hackles. One idea for soothing such objections: only make these
changes active when setblocking(False) is in effect. I.e., a
setblocking(True) file (the default, right?) behaves as you described
above, warts and all. (So old code that uses fcntl() continues to
"work" as before.) But files that have had setblocking(False) called
could gain these new semantics that you propose.
Greg
--
Greg Ward <[EMAIL PROTECTED]> http://www.gerg.ca/
I just forgot my whole philosophy of life!!!
_______________________________________________
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
