Python and Boehm-Demers GC, I have code.

[Tim Peters]

[Markus Kohler]
> IMHO this is one of Pythons major design flaws.

[Tim]
>> What, specifically?

[Markus]
> That flaw is that loops are not implemented using closures.

Yet you later note too that functions in Python are unusually slow.  It's no
flaw for a language implementation to decline to build everything on its
least optimized constructs <wink>.

> Instead as far as I understand  oops in Python are implemented such that
> the loop counter is created and destroyed for each step of the loop.

Yes, "for" loops work this way in Python.

> Even if you optimize this heavily you will probably slower than
> with a design that "recycles" the loop variable.

The for/__getitem__ protocol requires passing a full-blown int object, and
int objects are immutable.  Trying to trick this is more trouble than it's
worth.

> You could compare this to tail recursive versus non-tail recursive
> functions.

Trust me on this one:  you don't want to get anywhere near this comparison
unless you want to see Guido running in the opposite direction <wink>.
Seriously, I agree it's a good comparison; Python was designed to favor
iteration over recursion, though, and for that reason too it's not like the
languages you appear to like better.

> Also closures make the implementation of efficient loops more
> difficult

Yet another killer reason to do it that way <wink>.

> they have the advantage that loops and other control structures can be
> better integrated into the OO concept. Smalltalk for example doesn't need
> Iterators for that reason.

I happen to like the CLU/Sather/Icon approach toward iterators
(semi-coroutines)better than Python's or Smalltalk's (or C++'s, or Perl's,
or ...); Python doesn't work that way under the covers either, but is
surprisingly *close* to being able to work that way.  So that way makes more
sense to me for Python; Python's implementation and its surface semantics
are very close in most areas.

>> Loop overhead is typically lareger in Python programs than in other
>> languages, but is also typically trivial all the same.

> Lately ee have had already some examples in this group where
> loop overhead was a major factor.

?  I don't recall that.  Last one I do recall, someone posted a pretty much
certifiably insane quadruply-nested numeric loop, recomputing range again at
each "for" level.  Several replies suggested floating the range calls out of
the loops to save time.  Christian Tismer quite properly pointed out that
this was pointless, since the loop overhead accounted for a tiny percent of
the runtime.  Someone else suggested an algorithmic change that chopped
orders of magnitude off the runtime.  An extreme outcome, but typical in
outline.

> I measured different kind of loops and even the more general
> while loop was faster in squeak than anything else in python.

Empty loops?  Or did they do something?  If empty, it's hard to care.  If
they did something, why do you think the difference is accounted for by the
loop mechanism rather than by the guts of what the loops did?  A specific
example would clarify matters.

> Functions calls seems also to be much slower in Python ...

Yes.  Even worse <wink>, when a (say) Scheme person comes to Python, one of
the surest ways to speed up their first programs is to encourage them to
rewrite their lambda-slinging code as explicit inline loops.  That is

    plus1 = map(lambda x: x+1, somelist)

runs much slower than

    plus1 = []
    for x in somelist:
        plus1.append(x+1)

> ...
> Another problem with loops could be reference counting.
> I'm wondering how often a reference count get's changed when
> running a loop ...

It really depends on the specifics of the loop body.  In general, each
instance of a name in a line of code causes at least one refcount operation
each time the line is executed.  There *is* a lot of refcount fiddling going
on, and nothing is ever exempted from it.  It's also the case that nothing
in Python is stack-allocated; every object may have indefinite extent,
there's no way to tell at compile-time, and so everything is heap-allocated
"just in case".  If you're looking for reasons why Python is slower than
many other languages, they're not hard to find <wink>.

darned-hard-to-change-though!-ly y'rs  - tim