I'm coming from Tcl-world ...

[Andreas Leitgeb]

Heiko Wundram <heikowu at ceosg.de> wrote:
> On Fri, 2002-08-02 at 18:48, Andreas Leitgeb wrote:
>> Here, I think, I didn't make my concern clear enough:
>>  in C/C++ (and similar in Tcl) I can do the following:
>>  [ non-trivial for-loop with continue snipped]
> There is no way to do anything like that in Python, there just isn't.
Although some other posters contradicted this statement, it seems 
to be true. 
There are some approximations, though, as I've learnt in this thread.

> for x in range(0,42):
>    s *= 2    [\n>    ...]
This is not the same:
  C(and Tcl)-for's  increment-part is executed _after_ the body, and 
  _before_ evaluating the condition. _And_ it is the point where 
  'continue' jumps to)
  Placing the increment-part after the end of the body will cause it 
    to be skipped by a 'continue' which I'd need to prevent.
  Using Iterators prohibits me of altering the loop-variables inside
    the body, which is no good style anyway ;-)

> Dictionaries aren't functions as they are in Tcl
Dictionaries aren't functions in Tcl, either.  But Tcl uses
paranthesis to access the values from a dictionary, so for a 
non-Tcl'er it may have looked like function-calls :-)
  $dict(key) in Tcl -->  dict['key'] in Python, and 
  $dict($keyvar) in Tcl --> dict[keyvar] in Python.

What I was referring to with "cluttering namespace with functions" was,
that others had suggested the following:
 def handle_this(...): ...
 def handle_that(...): ...
 table['this']=handle_this; table['that']=handle_that; ...
 # and then:
 table[switchvar]()
which would have required a separate function for each branch, 
which sometimes happens anyway (if the switch-branches would have 
  called the functions), but is not always the right thing.

> If you need to access a global name from within a function, 
I wasn't speaking about global vars, but vars in the caller's 
context.  (accessing them is an important idiom in Tcl to 
get a "call by reference"), but sometimes it seemed to be 
quite useful even apart from that idiom.

[ mutating arguments passed to a function ]
> This is based on the concept that Python always passes variables by
> reference, and that there are some types that are simply not mutable
> (such as tuples, integers, floats). This makes the language cleaner, as
> you don't have all that mess you have in C/C++ where you have to watch
> out about pointers, and the like.
I've meanwhile recognized python's "call-by-reference"-mechanism
to be similar to java's (and completele unlike C/C++'s)

Assignment to parameter-vars inside a function get lost, but
mutations on arguments are visible outside.
There are some inconsistencies between the builtin types, whether
 +=, etc. will replace or mutate the object on its left-hand-side.

> You can pass out more than one argument just by wrapping it in a tuple.
I know, but I'd like to have the choice, especially when dealing with
list-objects containing >million entries :-)  (even though the referenced
objects are shared, the list itself would need to be copied)

> Well, hope this makes you look a little more favorable at Python than
> what was suggested by your post. ;)
Currently I'm in the phase of getting to know, what I can do and
what I need to do differently. 
Once I think I've got some idea, I'll try to translate some of
my scripts to python and see, whether they become clearer or
obfuscated'er :)

Anyway, Python has some bonus' that make me even accept some other
shortcomings.
But the same still holds for Tcl, and lotsa other langs (even perl), 
too ;-)

> someone-put-me-on-python-advocacy-'ly yours,
:-)

-- 
Newsflash: Sproingy made it to the ground !
  read more ... <http://avl.enemy.org/sproingy/>