By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
449,411 Members | 999 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 449,411 IT Pros & Developers. It's quick & easy.

Problem deriving a class from the built-in file object

P: n/a
Hi all!

I'm trying to extend the functionality of the file object by creating a
class that derives from file. MyFile class re-implements __init__(),
write(), writelines() and close() to augment the capabilities of file.

All works fine, except for one thing: 'print >> myfile' does not
execute Myfile.write(), it executes the file.write(). If I execute
myfile.write() explicitly, then Myfile.write() is called as expected.

I was not expecting that behaviour. I though that 'print >> afileobject
' would execute the afileobject.write() as you can easily obtain by
defining a simple file-like class that implements write() and writeline().

I am running Python 2.3.4. Can't move to 2.4 yet.

Is it the expected behavior?

# M y F i l e -- Testing inheritance from file --
# ^^^^^^^^^^^
#
class MyFile(file):
""" Testing new-style class inheritance from file"""

#
def __init__(self, name, mode="r", buffering=-1, verbose=False):
"""Constructor"""

self.was_modified = False
self.verbose = verbose
super(MyFile, self).__init__(name, mode, buffering)
if self.verbose:
print "MyFile %s is opened. The mode is: %s" % (self.name,
self.mode)

#
def write(self, a_string):
""" Write a string to the file."""

super(MyFile, self).write(a_string)
self.was_modified = True

#
def writelines(self, sequence):
""" Write a sequence of strings to the file. """

super(MyFile, self).writelines(sequence)
self.was_modified = True

#
def close(self) :
"""Close the file."""

if self.verbose:
print "Closing file %s" % self.name

super(MyFile, self).close()
self.was_modified = False


Jul 19 '05 #1
Share this Question
Share on Google+
2 Replies


P: n/a
Pierre Rouleau wrote:
I'm trying to extend the functionality of the file object by creating a
class that derives from file.**MyFile*class*re-implements*__init__(),
write(), writelines() and close() to augment the capabilities of file.

All works fine, except for one thing:**'print*>>*myfile'**does*not
execute Myfile.write(), it executes the file.write().***If*I*execute
myfile.write() explicitly, then Myfile.write() is called as expected.
As a workaround, you can use delegation instead of inheritance:
class File(object): .... def __init__(self, *args):
.... self.file = file(*args)
.... def __getattr__(self, name):
.... return getattr(self.file, name)
.... def write(self, s):
.... print "writing", s
.... self.file.write(s)
.... f = File("tmp.txt", "w")
for s in ["alpha", "beta", "gamma"]: .... print >> f, s
....
writing alpha
writing

writing beta
writing

writing gamma
writing
f.close()
File("tmp.txt").read()

'alpha\nbeta\ngamma\n'
I was not expecting that behaviour.**I*though*that*'print*>>*afileobject
' would execute the afileobject.write() as you can easily obtain by
defining a simple file-like class that implements write() and writeline().

I am running Python 2.3.4.**Can't*move*to*2.4*yet.
Nothing has changed with 2.4 in that respect.
Is it the expected behavior?


I certainly didn't expect it either when I saw it for the first time.

Peter

Jul 19 '05 #2

P: n/a
Peter Otten wrote:
Pierre Rouleau wrote:

I'm trying to extend the functionality of the file object by creating a
class that derives from file. MyFile class re-implements __init__(),
write(), writelines() and close() to augment the capabilities of file.

All works fine, except for one thing: 'print >> myfile' does not
execute Myfile.write(), it executes the file.write(). If I execute
myfile.write() explicitly, then Myfile.write() is called as expected.

As a workaround, you can use delegation instead of inheritance:


Good idea, thanks!
Is it the expected behavior?

I certainly didn't expect it either when I saw it for the first time.

Peter


Is it something that will (or should) be changed in future version of
Python? I can't see any reason to keep the current behaviour.

Pierre
Jul 19 '05 #3

This discussion thread is closed

Replies have been disabled for this discussion.