Path: csiph.com!usenet.pasdenom.info!aioe.org!news.stack.nl!newsfeed.xs4all.nl!newsfeed6.news.xs4all.nl!xs4all!post.news.xs4all.nl!not-for-mail
To: python-list@python.org
From: Dennis Lee Bieber <wlfraed@ix.netcom.com>
Subject: Re: The opener parameter of Python 3 open() built-in
Date: Tue, 04 Sep 2012 14:44:45 -0400
Organization: > Bestiaria Support Staff <
References: <k2280c$nf1$1@speranza.aioe.org> <mailman.139.1346678967.27098.python-list@python.org> <504555a5$0$29978$c3e8da3$5496439d@news.astraweb.com> <mailman.167.1346728806.27098.python-list@python.org> <87bohm8j73.fsf@benfinney.id.au>
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 8bit
Precedence: list
Newsgroups: comp.lang.python
Message-ID: <mailman.189.1346784293.27098.python-list@python.org>
Lines: 75
NNTP-Posting-Host: 2001:888:2000:d::a6
Xref: csiph.com comp.lang.python:28420

On Tue, 04 Sep 2012 15:12:48 +1000, Ben Finney
<ben+python@benfinney.id.au> declaimed the following in
gmane.comp.python.general:

> 
> why not call that directly?
> 
>     f = opener(file, flags)
> 
> It certainly is cleaner than either of the alternatives so far, and it
> doesn't add a parameter to the builtin.
>
	But it returns an OS file descriptor... It doesn't return a Python
file object. From what I can tell, (I've just upgraded to Python 2.7
<G>) the opener is meant to replace the low-level function normally used
by Python's open(), and supplies an fd which gets wrapped by Python's
open().
 
>>> import os
>>> fd = os.open("somefile.txt", os.O_CREAT)
>>> type(fd)
<type 'int'>
>>> fo = open("somefile2.txt", "w")
>>> type (fo)
<type 'file'>

	The two are not compatible except by using os.fdopen(fd) to get a
file object, or fo.fileno() to get the low-level file descriptor

>>> fo.fileno()
4
>>> fo1 = os.fdopen(fd, "w")
>>> type (fo1)
<type 'file'>
>>> 


 
> > Furthermore, using "opener" could allow for a localized change to
> > affect all open statements in the module -- change file path, open for
> > string I/O rather than file I/O, etc.
> 
> I don't know of any real-life code which would be significantly improved
> by that. Can you point us to some?
>
	Not really -- but if they went one step further and supplied
"reader" and "writer" operations too, they'd get close to what I once
had to do in FORTRAN 77 under DEC VMS (by hooking in code to do double
buffering when reading data from magtape, while keeping the program
using regular F77 I/O statements; the open statement would do a pre-read
of one buffer and return; subsequent read statements would find a
pre-filled buffer, and issue an non-blocking read to fill the other
buffer -- cut the runtime for the program into a third or less as it was
no longer stuck waiting for slow mag-tape operations each time it did a
read). Implementing something like this in Python would likely require
"opener" to spawn a reader thread to do the I/O asynchronously, using a
limited Queue (1 buffer worth -- the reader thread would be the second
buffer, blocked on Q.put()), and a "reader" that would do Q.get() and
return the result to the Python read() logic for any parsing.

	Okay, in Python, one could probably subclass "file", and override
the read methods -- but one would not be able to use the Python
open()... You'd have to do something like f = myFile(normal, open, args)
instead...


> -- 
>  \      “I find the whole business of religion profoundly interesting. |
>   `\     But it does mystify me that otherwise intelligent people take |
> _o__)                                    it seriously.” —Douglas Adams |
> Ben Finney
-- 
	Wulfraed                 Dennis Lee Bieber         AF6VN
        wlfraed@ix.netcom.com    HTTP://wlfraed.home.netcom.com/