pre-PEP: Simple Thunks

[Ron_Adam]

On 17 Apr 2005 01:46:14 -0700, "Kay Schluehr" <kay.schluehr at gmx.net>
wrote:

>Ron_Adam wrote:
>
>> I sort of wonder if this is one of those things that looks like it
>> could be useful at first, but it turns out that using functions and
>> class's in the proper way, is also the best way. (?)
>
>I think Your block is more low level. 

Yes, that's my thinking too.  I'm sort of looking to see if there is a
basic building blocks here that can be used in different situations
but in very consistent ways.  And questioning the use of it as well.  

>It is like copying and pasting
>code-fragments together but in reversed direction: ...

Yes, in a function call, you send values to a remote code block and
receive back a value.

The reverse is to get a remote code block, then use it.  

In this case the inserted code blocks variables become local, So my
point is you don't need to use arguments to pass values. But you do
need to be very consistent in how you use the code block.  (I'm not
suggesting we do this BTW)

The advantage to argument passing in this case would be that it puts a
control on the block that certain arguments get assigned before it
gets executed.

Is it possible to have a tuple argument translation independently of a
function call?  This would also be a somewhat lower level operation,
but might be useful, for example at a certain point in a program you
want to facilitate that certain values are set, you could use a tuple
argument parser to do so.  It could act the same way as a function
call argument parser but could be used in more places and it would
raise an error as expected.  Basically it would be the same as:

    def argset(x,y,z=1):
        return x,y,z

But done in a inline way.

    a,b,c = (x,y,z=1)    	# looks familiar doesn't it.  ;-)

As an inline expression it could use '%' like the string methods,
something like this?

	(x,y,z=1)%a,b,c			# point x,y,z to a,b,c (?)


And combined with code chunks like this.

    def chunk:				# code chunk, ie.. no arguments.
		# set (x,y)			# informal arguments commented
		return x+y			# return a value for inline use 

	value = (x,y)%a,b: chunk	# use local code chunk as body

I think this might resemble some of the suggested lambda replacements.


The altenative might be just to have functions name space imported as
an option.  

    def f(x,y):
        return x+y

    z = dolocal f(1,2)   #But why would I want to do this?

I think these pre-peps are really about doing more with less typing
and don't really add anything to Python.  I also feel that the
additional abstraction when used only to compress code, will just make
programs harder to understand.

>You have to change all the environments that use the thunk e.g.
>renaming variables. It is the opposite direction of creating
>abstractions i.e. a method to deabstract functions: introduce less
>modularity and more direct dependencies. This is the reason why those
>macros are harmfull and should be abandoned from high level languages (
>using them in C is reasonable because code expansion can be time
>efficient and it is also a way to deal with parametric polymorphism but
>Python won't benefit from either of this issues ).
>
>Ciao,
>Kay

I agree. If a code block of this type is used it should be limited to
within the function it's defined in. The advantage, if it's used in a
bare bones low level way with no argument passing, would be some
performance benefits over function calls in certain situations. That
is, a small reusable code block without the function call overhead.
But only use it in the local name space it's defined in.  Otherwise
use a function or a class.

Cheers,
Ron