I doubt if there'd be any efficiency difference between the two
approaches. You'll see a much bigger difference by switching from 't'
to 'b'. Both the functions are native code in Python 2.6.
I withdraw my two previous suggestions. As you said, the 'name'
attribute is read-only (and documented as such). And there doesn't seem
to be any documented constructor for a file object to make deriving from
it feasible. So while there's undoubtedly a 'magic' way to do it, I
would no longer suggest it.
If you need the low level call, or if you measure some performance
difference for your application, then here's what I'd suggest for the
problem.
Create a class with a dictionary to hold those names, keyed by an Open
class object, and each time you call os.open(), add to the list. Then
create a method/function called getfilename() that looks up the name for
a given file object. If the file object was created by builtin-open(),
just return the name attrribute. But if the name is "<fdopen>" then
consult your dictionary.
The catch to this approach is that you will be hanging onto these
objects, so they won't be garbage collected unless you remove it from
this list when you close.
I've heard of something called weak-references, but have no experience
with them. It could solve the gc problem.
Otherwise, you could create what Python docs call a "file like" object.
That's a class with all (or carefully chosen subset of) the methods and
behavior of a builtin file object, but with additional methods (and
perhaps a constructor) that solve your needs. You wouldn't do this for
efficiency, but might for flexibility of modes.
Visco Shaun wrote:
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
