A better self

brueckd at tbye.com brueckd at tbye.com
Sat Jul 20 15:26:47 EDT 2002


On Sat, 20 Jul 2002, Louis M. Pecora wrote:

> > 3) Use the smarts of your editor - macros, special syntax highlighting, 
> > etc.
> 
> Not practical for me (not sure about others) since I tend to develop
> using an edit/run style.  Python is so quick that with the Macintosh
> IDE I just code a little, then quickly run a test.  Correct code until
> satisfied, then code more new stuff and test. etc. etc. etc.  But that
> eliminates the macros or fancy editor stuff.  It's a great way to code
> though (only with Python :-) )

I guess I don't understand what you mean - in my mind the two are 
independent. For example, if you're bothered by typing 'self.' then bind 
that text to a hotkey, e.g. Ctrl-s. The benefit doesn't depend on your 
coding style that much. If readability is your gripe, change the syntax 
highlighting to make 'self.' be lighter (so it doesn't jump out as much). 
Again, using an edit/run approach benefits.

> > 6) Have Python generate the function bodies for you, e.g:
> > 
> >    class SomeClass:
> >      method = MyCoolUnboundMethodMaker('arg:x = y*z + t*arg')
> 
> Hmmm...what's that?

Just an idea - since Python is so dynamic, instead of writing the 
function you write a string describing the function and have another 
function read it and generate a method that does all the 'self.' stuff. 
Obviously you'd have to think it through some, but this is definitely 
possible. 

In the above example, I assume MyCoolUnboundMethodMaker would read 
the string, and use it to generate a string like this:

'''def NewMethod(self, arg):
    self.x = self.y * self.z + self.t * arg
'''

after which it would exec the string and then do a 'return NewMethod', and 
bingo, your class now has a method that performs that operation. It'd take 
some work to get it right the first time, but from then on you could reuse 
it for all your numeric work.

> > 7) Change your design - if something is awkward it *may* be a flaw in the
> > language, but there's also a really, really good chance that a different
> > approach to your program would be best.
> 
> Not too relevant to the math required.  You have to write a math
> expression.

Sure it's relevant. For example, you have to specify 'self.' on all your
variables because through your design you have *chosen* to make them all
members of an object. I think that was a reasonable decision on your part,
but it's certainly not the only possibility.

-Dave






More information about the Python-list mailing list