Anonymus functions revisited

[bruno modulix]

Claudio Grondi wrote:
>> for x,y,z in some_iterator:
>>
>>If some_iterator produces at some time
>>a tuple with only two elements this
>>will raise an exception no matter
>>whether you assigned z already or not.
> 
> 
> So if I now understand it right, the core
> of the whole proposal is to find a way to
> make unpacking of tuples work also in case
> the tuples have not the appropriate
> number of elements, right?

That's the original problem at least. Kay seems to be wanting to extend 
a possible solution to this problem to a lambda replacement, which is 
IMHO another point.

> So to achieve the same effect I need
> currently (not tested):
> 
> for x,y,z in [getMyTargetTupleFrom(currentTuple) for currentTuple in
> tupleList]
> 
> where getMyTargetTupleFrom(currentTuple) is:
> 
> def getMyTargetTupleFrom(currentTuple):
>   if len(currentTuple) >= 3:
>     return (currentTuple[0], currentTuple[1], currentTuple[2])
>   if len(currentTuple) == 2:
>     return (currentTuple[0], currentTuple[1], 0)
> 
> right?

Yes

> Is it really worth it?

I think so. The problem of "unpacking tuple of the wrong size" is a 
common one (at least for me), and having to write a special function to 
handle the case, or use try:except blocks, dont make for more readable 
code IMHO. The possibility to clearly  and cleanly handle the case *when 
it's an expected case* and *as close as possible* to where it happens 
would (always IMHO) improve readability.

What do you find most readable: your version, with an ad-hoc function 
defined somewhere else, far away in the code, or a simpler:
for (x,y,z=0) in tupleList:
    do_whatever_with_it()

> Isn't it much easier to convert the list of tuples
> explicit to appropriate format, first?

This *is* an explicit conversion. Much more explicit than a function 
buried xxx lines of code away IMHO. (and BTW, It also avoid to have to 
build two lists.)

> It seems, that my attitude to the proposal
> is originated from bad experience with
> default values.
> 
>   To get it tracked down to the point:
> 
> In my opinion default values are evil and it
> is enough trouble that function defintions
> allow them.

Python would barely be usable without.

> I have seen already postings
> of confused newbies expecting the
> default values beeing set during
> function execution not during
> definition and I have also faced
> this problem starting on Python
> myself .

There are a lot of features in any language that are at first sight 
confusing, specially when these features look like features existing in 
another language but fail to behave like in the other language.

<half-troll>
Removing anything that could confuse anyone having only experience with 
language X or Y leads to Java - an average language designed for average 
programmers, where the lack of expressive power leads to overly 
complicated code to get simple things done.
</half-troll>

-- 
bruno desthuilliers
python -c "print '@'.join(['.'.join([w[::-1] for w in p.split('.')]) for 
p in 'onurb at xiludom.gro'.split('@')])"