to get name of file opened

[Dave Angel]

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
>
>
>
>