First of all
Thanks Dave for the reply
On Sat, 2009-03-28 at 09:51 -0500, Dave Angel wrote:
> First question is why you need os.open(), and not the open() function.
> I'll guess that you need some of the access modes (e.g. for file
> sharing) that you get from the low level functions. So assuming that:
of course access was an issue.. but i opted for it because in the
document it is mentioned that os.open(besides sharing b/w processes) is
low level resembling unix system call, and i thought may be efficiency
is more, even though interpreted by the same python interpreter...
But i never found any article regarding any efficiency difference
between those..
Can u comment on this
> I don't believe there's any way to use a fd ("file descriptor") to
> retrieve the file name that was perhaps passed to open. There are ways
> to spelunk inside Windows, but they're not advisable. And I don't know
> what Unix might offer there.
>
> So by the time fdopen() is invoked, the name is already gone.
>
> Here's what I'd do. Create your own open function that has the
> parameters of os.open(), but that will return an object derived from the
> file object. Your derived object can have its own filename, but close()
> will know what to do.
Well this is what i am trying now, though i wished if there was any
suitable method or attribute built within python
>
> Alternatively, you could encapsulate the line you showed, and just zap
> the name attribute of the existing file object.right when it's being
> returned by fdopen()
The name attribute appears to be read only as i tried that already
though through the interpreter rather than in code
--
http://mail.python.org/mailman/listinfo/python-list
