Seriously, there's some slick code in myfile.py, but Python newbies
shouldn't be scared into thinking their lines have to be half underscores
to get things done in Python! Playing with the internals can be loads of
fun, but-- honest --you rarely need to.
> _sysfile = sys.stdin
> ...
> class File:
> for _M in _sysfile.__methods__ :
> [robocode to duplicate all the std file methods]
I _really_ liked that section! Got the job done -- nice, Steve.
> __builtin__.ps1 = 'Enter a line of text : '
> __builtin__.ps2 = 'More/End with ^D ... : '
> ...
> # Ok - maybe the above is OVERKILL, but I wanted to try it out! ;-)
Polluting the builtin namespace?! Go, & sin no more <smile/snarl>.
> [guido]
> ...
> Here's an exercise: practice programming for a while without using
> self.__class__, self.__dict__, or <class>.__bases__. Come to think of
> it, __main__ and __name__ are also out, *except* to differentiate
> between a script and an imported module. All these attributes are
> there mostly for debuggers and other tools, not to pervert Python into
> Scheme!
>
> (I wonder if I should've made a distinction between these and, say,
> __init__ and __del__ which are perfectly legal to use...)
I think the distinction is clear: __xxx__ is fine to use if _you're_ the
one who binds its name (users define __init__, __del__, etc). But
referring to __xxx__ is dubious style if Python binds the name by magic
(covering __class__, __dict__, __bases__, __name__, and, like it or not,
__methods__).
The only way I _routinely_ break those guidelines is when I need to know
whether an object belongs to a specific user-defined class. I don't know
a better way to do that than
if type(object) is type(_Some_UserDefinedClassInstance) and \
object.__class__ is TheSpecificUserDefinedClassOfInterest:
# object is an instance of TheSpecificUserDefinedClassOfInterest
striving-to-be-a-model-for-the-young<ahem>-ly y'rs - tim
Tim Peters tim@ksr.com
not speaking for Kendall Square Research Corp