using dict for data attributes instead of self

[Bengt Richter]

On Sun, 31 Oct 2004 03:52:10 -0400, Alexander Kervero <vegeta.z at gmail.com> wrote:

>
>
> Hi ,today i was reading diveinto python book,in chapter 5 it has a very
>generic module to get file information,html,mp3s ,etc.
>
>The code of the example is here : 
> http://diveintopython.org/object_oriented_framework/index.html 
>
>One thing that i have some doubs is this part : 
>
> class FileInfo(UserDict):
>    "store file metadata"
>    def __init__(self, filename=None):
>        UserDict.__init__(self)
>        self["name"] = filename
>
>
>So why does he wants a dictionary-like base class if he never uses any
>dictionary method,except for dict.clear which is not necesary.
>
He does use __setitem__ by way of self["name"] = filename, and he overrides __setitem__
in his subclass as a trick to trigger parsing of the file (and using __setitem__ by way of
self[somename]=somevalue some more) and then actually putting "name" and its filename value
in the base class dict. (IMO that __setitem__ subclass override trick is not a good substitute
for defining __init__ in the subclass. I'm surprised to find it.).

BTW, the above was probably written before you could subclass the builtin dict, but now
there's no need to use UserDict in place of dict, AFAIK.

>--
>could be done like this?
>
Not exactly. The subclass is needed for all the dict methods that get used implicitly. Plus
the empty () is bad syntax. And what would UderDict.__init__ do with a self that
wasn't even related?
>  class FileInfo():              
>    "store file metadata"
>    def __init__(self, filename=None):
>        UserDict.__init__(self)
>        self.name = filename
>
You could tack name on the instance as an attribute. It might not be a bad idea if
there was a risk of name clash with data keys.

>And the FileInfo subclasses could have the specific attributes that belongs
>to each file type,for example mp3.
I'm not sure what you want to do, but for a general framework you probably want to
avoid having to use only python-legal attribute names for things. No problem with
title, artist, genre, etc. But, e.g., artist-rep wouldn't fly. It depends on whether names
come automatically from data, or are just programmer choices.

>
>check the link to the full example. 
>--
>
>The only reason is to have a base class with arbitrary attributes ? so it
>can dinamicaly adquire attributes depending of its subclass or something
>like that?
No, but the example is very basic. All it does with the base directory ultimately is
list its key=value content, which is unsorted and doesn't show how alternative
subclasses might want to store and format data differently for listing, etc.,
which you could do by giving the subclasses __str__ methods or standardize on
some other method name, which might just show the name=file_path if the base class
method was not overridden. Etc. E.g., they might all have .html methods to generate
html snippets that could be concatenated for a nice listing. And you might have
a base class attribute for verbosity as a general control.

>
>Is there a clearer way to do it? Is there any benefits of going this way
>that i dont see? 
Think of the base class as common infrastructure. In the example it's just
a dict, but a dict is a very general storage mechanism. What it doesn't instrinsically
have is order or duplicate keys, but you can use it to preserve order and allow
duplicates if you need to. However, a list might be more suitable for some things.
A subclass could use lists as additional ways to store info if needed. And they could
be put in the base dict as values for certain keys, or they could be added as attributes,
keeping the base dict use cleanly separated.
>
>Maybe this is just a dummy example to just show some functionality related
>to the chapter? I am a bit confused.
Yes, I think it is a limited example, though I don't know the larger context,
only having looked at the page you provided the url for.

It's an example of a base class and one subclass that relates to specific (mp3)
file info, and suggests that other subclasses could be made according to the
same general pattern, but sharing methods of the base class.

Notice the way it will automatically integrate another subclass for another file extension.
E.g., why don't you try writing a Subclass for .py files? The name would be
class PYFileInfo(UserDict): ... since the name comes from prefixing uppercased extension
to FileInfo.

Maybe make it just read one line from the .py file and store
self['firstline']=<whatever the first line was>. You can just copy the MP3FileInfo class
and rework the pieces.

Then you may notice that you've duplicated generic things that you could put into base
class methods. And you'll see what the framework and inheritance is getting at.

You can then run the program with ['mp3','py'] as the file extension list, and see what
happens.

Have fun ;-)

Regards,
Bengt Richter