A modest indentation proposal

[Andreas Kostyrka]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Am Montag, 3. Dezember 2001 06:20 schrieb Quinn Dunkan:
> On Sat, 1 Dec 2001 16:28:26 -0800 (PST), brueckd at tbye.com
> Hmm, can't think of whether I do this or not, but I'm no expert.  I do know
> there are a lot of clever dynamic things you can do in python, but with the
> exception of a few gettattr()s and setattr()s I've almost always regretted
> using them.
Well, actually I've discovered a pattern in my use of __getattr__ (and other 
clever features) over the years:
1.) newbie-mode: no __getattr__
2.) newbie-mode: __getattr__ conclusion: got burned multiple times
3.) experienced-mode: no __getattr__, it's satanic, where is my holy water?
4.) experienced-mode: __getattr__ use only when it makes sense.

Actually the "globalness" of __getattr__ is IMHO it's biggest drawback, as it 
makes writing correctly working ones (in the face of subclassing and other 
uses) quite difficult.
Additionally, it's rather trivial to kill the performance by one ill designed 
__getattr__ method in a program.

> support the operations (len() for instance).  You can seriously mess up
> your day by having __del__ and __getattr__ within 15 feet of each other.
Well, it's obviously that using __getattr__ in combination of some other 
__magic__ methods is rather something for "Advanced" Python developers.

> __del__ is understandably dangerous magic, but the other two are so useful
> I'm continually tempted to use them.  (minor complaint about __del__: it
> gets called if __init__ throws, so be careful about unlocking resources
> that were maybe never locked---there's no way to tell if they were or not).
Well, __del__ is not Jython compatible. Not that it would matter to me, but 
it's something to keep in back of one head.

> The latest changes in 2.2 do a lot to address this, I think.  At the cost
> of two kinds of classes and method lookup rules and a semi smalltalk style
Well, old style classes will be depracted some time in the future. Being so 
fundamental as it is, it will take a long time.

> And we already have more than enough magic method names, but there are more
> every day, I can barely keep up with them.  __all__, __dynamic__, __eq__
> vs. __cmp__, __help__ __I'm__ __losing__ __my__ __mind__.
Well, thats a problem. Especially if the documentation isn't perfect. 
(Actually, it's quite funny to discover what the __metaclass__ token does ;) )

> Since new magic attributes seem to pop up every day, what about existing
> __getattr__-using code that had all the holes patched up, but is now going
> to explode because suddenly python wants to look up an __eq__ method where
> it never did before?
well, I personally prefer this design:
def __getattr__(self,k):
  # special ones we need to deal with.
  if k=="__repr__":
    pass
  elif k.startswith("__"):
    raise AttributeError,k
  else:
    # deal here with the "normal" stuff
    pass

> Hmm, try this rule of thumb: avoid type().  Distinguishing between None and
> a value is very handy and valid in a reference oriented language.  But if
> you use type() only when you really mean it, you shouldn't have trouble
> with too-clever guess-what-you-mean functions.
Well, my rule of thumb: type() is only allowable for pure utility functions.

Andreas
- -- 
Andreas Kostyrka; Raiffeisenstr. 16/9; 2320 Zwölfaxing
Tel: +43/676/4091256; Fax: +43/1/7065299
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.6 (GNU/Linux)
Comment: For info see http://www.gnupg.org

iD8DBQE8C1KSHJdudm4KnO0RAk29AKCak0bjaoIQntDuNNuRT/ccX7YGgQCfSxw9
Y7NV4V+kEHlxUif1WXx1XoY=
=rxFc
-----END PGP SIGNATURE-----