Just one non-argument in this vein for now:
> [bennett]
> Perl seems (in my experience) to be weak for implementing large
> systems, and having them run efficiently and be clear and easy to
> maintain.
Rest assured that your experience is universal in these respects! Perl
shines at other things.
> [stoffel]
> ...
> for ch in lowercase:
> if ch not in a2z:
> print ch, 'not found!'
> break
> else: print 'All letters found.'
>
> [is misunderstood by a reviewer]
This fooled me too at first, but because the 2nd 'print' is aligned to
the column of the code controlled by the 'if'. I bet the Python-aware
would be much less likely to misread it written this way:
for ch in lowercase:
if ch not in a2z:
print ch, 'not found!'
break
else:
print 'All letters found.'
Not that this would help the Python non-aware ...
> ... in the language that he is busy implementing the above could have
> been written as:
>
> a2z := `The quick brown fox jump over the lazy dog'
>
> put first([all ch in {`a' .. `z'} | ch not in a2z])+` not found!' ?
> `All letters found.'
>
> (You'll notice some SetL and Icon influences ;-)
No offense to your colleague, but people with glass languages should not
toss boulders <grin>.
> [guido]
> ...
> I personally think that the optional else clause on loops is so rarely
> used that it's better to remove it altogether ... On the other hand, it
> doesn't hurt much, and some code will undoubtedly be broken and have to
> be rewritten in a more clumsy manner.
When I first saw the "else" clause on loops, I thought "hey -- neat
idea!", and although I've kept it in mind I don't believe I've ever used
it in a real program. Certainly not Python's best idea, and "else:" is
certainly not the best keyword here, but it's such a small extravagance
it's probably more harmful to change it now.
> [steven miale]
> Right now, all class methods have to be defined in the "class"
> structure.
Not really, Steve -- the method _name_ simply has to get bound in the
class namespace. The code defining the method can appear (almost)
anywhere. Section 9.4 of the Tutuorial has examples of this. E.g.,
after
def common_obnoxious_error_handler( self, message ):
print message
raise DeathByError
class Example:
error = common_obnoxious_error_handler
objects of class Example will have an 'error' method that works the way
you expect.
However, I just noticed the following works too, & I don't think it
should:
def error( self, message ):
print message
raise DeathByError
class Example:
error = error
Guido, since 'error' is bound in the class namespace, I expected Python
to consider 'error' to be a local name, and so expected a NameError when
Python attempted to look up the RHS of 'error = error'. Instead, Python
appears to be looking up the RHS 'error' in the global NS, and binding to
the LHS 'error' in the local (class) NS.
If this _is_ a bug, maybe you could call it a feature <wink>.
Steve, ignoring that possible problem, you might like this example
better, because it illustrates a reliable way of getting the same effect,
and a way to put the method definition (textually) after the class
definition:
class Example:
def dumpattr( self ):
print self.attr
def set( self, value): pass # real definition comes later
def fiddleattr( self, value ):
self.attr = value
Example.set = fiddleattr # fill in (redefine) the 'set' method
After doing that, the following prints '666':
x = Example()
x.set( 666 )
x.dumpattr()
Indeed, so does the following, showing that you can add methods to
an object's class even after the object has been created:
class Example:
pass
x = Example() # create an object
# and give the class some methods later
def fiddleattr( self, value ):
self.attr = value
def dumpattr( self ):
print self.attr
Example.set = fiddleattr
Example.dumpattr = dumpattr
x.set( 666 )
x.dumpattr()
So Python is already flexible to an extreme wrt when, how, & where class
methods can be defined. Forgetting the neat (but insane <wink>) tricks
you can do with this, stylized simple uses can fake the C++ style if you
like.
> ...
> How difficult would it be to incorporate a simple macro expander in
> Python? I remember experimenting with calling the c preprocessor, and
> it seemed to work most of the time.
What uses do you have in mind? I've often wanted to expand teensy
functions inline, but (A) couldn't figure out how to fool cpp into
getting the indentation correct in context (& had the same problem with
m4, of course), and (B) don't like wrestling with macro semantics for
this purpose regardless.
For #define'ing constants, or #include'ing files, I've usually ended up
happier crafting a solution using Python modules and 'import' instead.
if-macros-are-the-solution-what's-the-problem<heh-heh>?-ly y'rs - tim
Tim Peters tim@ksr.com
not speaking for Kendall Square Research Corp