Named code blockes

James_Althoff at i2.com James_Althoff at i2.com
Mon Apr 23 19:34:52 EDT 2001


Alex Martelli writes:

> Unnamed blocks are a very powerful programming device.  As far as I can

But where's the extra power in making them UNNAMED?  It's
so easy to name them, after all.

> tell, the main reason that Python does not support them is that no one
> has figured out how to handle the indentation issues -- the syntax thing
;

Sure, naming something and passing the name as a stand-in
for the thing itself IS syntax at some level.  So what?  Do you
often use, say, unnamed classes, or modules, or attributes of
class instances, or feel that being able to leave them unnamed
would be "a very powerful programming device" wrt having
to name them?!  So what's so different about code blocks...?


Alex


<jim response>

Granted, it is "easy" to name a code block, but I don't think it
is very graceful (personal preference, obviously).

Again taking an example from Smalltalk, there is no difference
in syntax between:

x < y ifTrue: [
    line1 of code
    ...
    lineN of code]

which is the basic "if then" control structure, and

collection do: [
   line1 of code
   ...
   lineN of code]

which is an "iteration control structure" that I define.

In Python,

if x < y:
    line1 of code
    ...
    lineN of code

which is the basic "if then" control structure, and

def namedFunction():
    line1 of code
    ...
    lineN of code

collection.do(namedFunction)

obviously look very different.  This is just my experience, but I find --
in
the Python code that I see -- very few examples of "collection.do()" -type
methods, whereas in Smalltalk, this is a very common design pattern
(see "Smalltalk Best Practice Patterns", Kent Beck, page 146, for example).
I'm just postulating that the extra -- very small though it might
seem -- burden of defining named functions
along with the diffence in syntax between method calls versus built-in
control structures along with the "confusing-or-non-obvious-for-beginners"
notion of nested functions defined within other functions is sufficient
enough to discourage many programmers from using this design pattern very
much in Python code.

It's just a theory.

</jim response>






More information about the Python-list mailing list