Python dumps core with this.. how come?
Michael Hudson
mwh21 at cam.ac.uk
Sat Jan 22 16:44:37 EST 2000
"Tim Peters" <tim_one at email.msn.com> writes:
> [Interrupting Michael Hudson's fine advice to inject a nit]
>
> [Roey Katz]
> > this brings up another concern. Given
> > the following definition:
> >
> > class A:
> >
> > def __getattr__( self, name ):
> > return -1
> > def __setattr__( self, name, val ):
> > self.__dict__[ name ] = val
> >
> > I see that self.__dict__ must be a special variable
> > in that setting it somehow avoids a recursive call
> > to __setattr__()?
>
> [Michael]
> > Yup. Look in Objects/classobject.c around about line 580
> > if you want the gory details.
>
> While true, it doesn't apply to Roey's example: he's not setting __dict__.
> He's binding a key *of* self.__dict__; self.__dict__ itself is merely
> referenced. So Roey should really be wondering why the reference to
> self.__dict__ isn't invoking __getattr__ (&, of course, that's also due to
> special-case __dict__ magic, but in __getattr__'s implementation).
Actually I noticed this; line 580 is in instance_getattr1.
> I don't mean to be overly picky; it's just that the excruciating details are
> vital when mucking with __getattr__/__setattr__, and *any* small
> misconception about them will eventually bite hard.
Oh yes, that much is true.
[schnipp]
> Yes, pointing him to the most bizarre endcases of Python behavior will
> surely aid him in "resetting his brain" <wink>.
Sorry. I get carried away in situations like that. As you might well
know, if you remember where the bytecodehacks started...
> Guido gave some excellent semi-exasperated advice (similar in spirit to
> parts of Michael's advice that I've snipped) many moons ago, when the whole
> newsgroup was temporarily filled with msgs of this character: he invited
> people to just *try* writing a Python program without using any __xxx__
> hooks. I expect some people were amazed at how much easier their lives got!
> If he were to get that exasperated again today, I bet he'd expand his
> invitation to include avoiding map, filter, reduce and lambda too.
I'd expect so to; most of the Python code that I ever had trouble
understanding used map & co extensively. Rewriting it to use Python
loops definitely helps.
> you're-not-ready-to-use-them-in-python-before-you're-
> happy-without-them-ly y'rs - tim
What follows is pure opinionated speculation (or drivel, if you like).
Python makes it soooo easy to write readable code that I think it's
harder than in many languages to spot good practise. In C++ or Lisp or
Haskell or many other languages, if your logic's getting confused it's
generally obvoius (becuase the code has become nauseatingly hard to
read). Python is more subtle.
Things I find that almost uniformly improve code readability and
reliability include:
writing short functions
using Python loops
avoiding lambdas
never *ever* using "import *"
using classes where I might use a fake closure
remebering that I'm programming Python, and that using an idiom from
another programming language is *not* necessarily a good idea
I'm gradually forming the opinion that writing *really* good code in
Python is no easier than in any other language, it's just that writing
merely very good code is much easier.
thanks-for-listening-ly y'rs
Michael
More information about the Python-list
mailing list