On Jun 4, 9:11 am, Marc 'BlackJack' Rintsch <[EMAIL PROTECTED]> wrote: > In <[EMAIL PROTECTED]>, per9000 wrote: > > > > [...] > > > > So another question emerges: > > * is the use of magic names encouraged and/or part of good coding > > practice. > > What do you mean by "use"? Implement them to override behavior? Yes, > that's their purpose. Invent new magic names? No of course not, they are > special for a reason: preventing name clashes with the user's names. >
[in my taste: UGLY] I think of something like this: Perhaps I create a class that works with a lot of files, and with inheritance new types of files can be opened and worked with. When it is time for an instance of this class to die the files need to be closed - perhaps "right now" and not when it is suitable for the garbage collector. To facilitate this I create a number of functions with names like close_*_file (f.x. close_indata_file, close_outdata_file, close_error_file etc). (compare with [PyTest| unittest] "test*" names.) If this class has been inherited to some other class that works with more than one indata file perhaps we want to magically close all files that are open by calling all function in this instance that has names matching "close_*_file". I would consider this an ugly way of solving it. [in my taste: NICER] I'd perhaps add file-handles to some list (and encourage inherited classes to use this list) and close everything in the list. I would not use magic wildcard names. So in other words: Do I need to go to yellow alert, and watch out for magic names in non-core add-on packages to python? Or should I just RTFM a little more? (I hate RTFM'ing.) Live long and prosper, Per -- Per Erik Strandberg home: www.pererikstrandberg.se work: www.incf.org also: www.spongswedencare.se -- http://mail.python.org/mailman/listinfo/python-list