Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.python > #28420

Re: The opener parameter of Python 3 open() built-in

Show key headers only | View raw

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/

Back to comp.lang.python | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread

Thread

The opener parameter of Python 3 open() built-in Marco <marco_u@nsgmail.com> - 2012-09-03 14:32 +0200
  Re: The opener parameter of Python 3 open() built-in Dave Angel <d@davea.name> - 2012-09-03 09:05 -0400
    Re: The opener parameter of Python 3 open() built-in Marco <marco_u@nsgmail.com> - 2012-09-03 15:33 +0200
    Re: The opener parameter of Python 3 open() built-in Marco <marco.buttu@gmail.com> - 2012-09-03 15:33 +0200
  Re: The opener parameter of Python 3 open() built-in Christian Heimes <lists@cheimes.de> - 2012-09-03 15:29 +0200
    Re: The opener parameter of Python 3 open() built-in Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2012-09-04 01:13 +0000
      Re: The opener parameter of Python 3 open() built-in Dennis Lee Bieber <wlfraed@ix.netcom.com> - 2012-09-03 23:19 -0400
        Re: The opener parameter of Python 3 open() built-in Ben Finney <ben+python@benfinney.id.au> - 2012-09-04 15:12 +1000
          Re: The opener parameter of Python 3 open() built-in Ben Finney <ben+python@benfinney.id.au> - 2012-09-04 15:20 +1000
          Re: The opener parameter of Python 3 open() built-in Dennis Lee Bieber <wlfraed@ix.netcom.com> - 2012-09-04 14:44 -0400
        Re: The opener parameter of Python 3 open() built-in Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2012-09-04 05:25 +0000
          Re: The opener parameter of Python 3 open() built-in Ben Finney <ben+python@benfinney.id.au> - 2012-09-04 15:45 +1000
      Re: The opener parameter of Python 3 open() built-in Serhiy Storchaka <storchaka@gmail.com> - 2012-09-04 15:58 +0300
      Re: The opener parameter of Python 3 open() built-in Terry Reedy <tjreedy@udel.edu> - 2012-09-04 15:16 -0400
      Re: The opener parameter of Python 3 open() built-in Chris Angelico <rosuav@gmail.com> - 2012-09-05 08:18 +1000
      Re: The opener parameter of Python 3 open() built-in Terry Reedy <tjreedy@udel.edu> - 2012-09-04 19:16 -0400
      Re: The opener parameter of Python 3 open() built-in Antoine Pitrou <solipsis@pitrou.net> - 2012-09-06 00:34 +0000
        Re: The opener parameter of Python 3 open() built-in Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2012-09-06 06:34 +0000
  Re: The opener parameter of Python 3 open() built-in Serhiy Storchaka <storchaka@gmail.com> - 2012-09-03 19:06 +0300
  Re: The opener parameter of Python 3 open() built-in Serhiy Storchaka <storchaka@gmail.com> - 2012-09-04 16:01 +0300

csiph-web