magic names in python
Diez B. Roggisch
deets at nospam.web.de
Mon Jun 4 11:23:05 CEST 2007
> On Jun 4, 9:11 am, Marc 'BlackJack' Rintsch <bj_... at gmx.net> wrote:
>> In <1180939436.862957.127... at p77g2000hsh.googlegroups.com>, per9000
>> > [...]
>> > 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
>> 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.)
More information about the Python-list