per9000 wrote: > 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.
This is a completely different topic than the usage of "magic" names in python to allow e.g. operator overloading and the like. > 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.) Certainly RTFM. Diez -- http://mail.python.org/mailman/listinfo/python-list
