RetroSearch Browse

Mon Apr 23 17:03:01 EDT 2001 · http://mail.python.org/pipermail/python-list/2001-April/105005.html

<James_Althoff at i2.com> wrote in message
news:mailman.988052255.6016.python-list at python.org...
>
>
> Alex Martelli wrote:
>
> Is it so 'costly' to give these statement suites a name?
>
> <jima>
> I think it is.  In Smalltalk, for example, you can write
> something like (approx.):
>
> collection do: [:item | item doThis. item doThat]
>
> This passes an arbitrary and unnamed block of code to
> the collection object for executing.

OK, it's unnamed.

> in Python this would be:
>
> def doThisAndDoThatToItem(item):
>     item.doThis()
>     item.doThat()
>
> collection.do(doThisAndDoThatToItem)

Sure -- it's named.  That's the one difference, right?

> Now suppose the call to collection.do(xxx) is in the middle of a
> very long class def.

OK, let's suppose that.

> Then I have to put the doThisAndDoThatToItem
> def before the class or after the class thereby separating the definition
> from its one and only use by possibly hundreds of lines of
> code.  This is not nice for readability.  Or I have to define
> doThisAndDoThatToItem
> as a method in my class which clutters my class with an unnecessary
> method.

Ah, I see, you're in the one and only case in Python where you
can't just immediately def a function for your purpose, because
doing that would magically make it into a method -- smack in
the middle of a class body.  Not to worry -- the cost in this
extremely rare case cannot possibly be "possibly hundreds of
lines" -- it's a BIT less than that...:

class Blobbo:
    # snipped: 745 lines of class-body code
    # now we need to call crucial collection.do...
    class DoThisAndThat:
        def __call__(self, item): item.dothis(); item.dothat()
    collection.do(DoThisAndThat())
    # snipped: 534 more ines of class-body code

See?  The overhead is ONE entire line (just because we can't
stick compound statement def on the same line as compound
statement class, durn:-).  In most cases, of course, we'll
save that line because we can just def DoThisAndThat as
a function, without the need do wrap it up in some other
kind of callable.

So, I ask again, *IS* it "so costly" to have to give things
a name...?  Most of the time I find the name _helps_ quite
a bit compared with the lambda alternative, and I do not
begrudge the extra line here and there (never had the need
to use two lines as above, but it's easy to figure it out from
first principles, of course).

> Or I have to resort to extracting the items of the
> collection for use in a for loop (for example) which means the collection
> must be written in such a way as to expose its items as a sequence
> (which the collection writer might not have wanted to do).

No need to distort your architecture -- just give a NAME to
the code you want to pass.  It's as easy as that.

> 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

Home - News ( United States | United Kingdom | Italy | Germany ) - Football scores

Showing content from http://mail.python.org/pipermail/python-list/2001-April/105005.html below:

Named code blockes