Loops and stuff (was Re: Python and Boehm-Demers GC, I have code.)

[Michael Hudson]

On 21 Jul 1999, Markus Kohler wrote:
> "Tim Peters" <tim_one at email.msn.com> writes:
> 
> > [Tim]
> > >     for i in xrange(10000000):
> > >         pass
> > > [and RC vs GC implications]
> > 
> > [Markus Kohler]
> > > True.
> > > IMHO this is one of Pythons major design flaws.
> > 
> > What, specifically?
> 
> That flaw is that loops are not implemented using closures. 

Sorry, how would that help?

> Instead as far as I understand   loops in Python are implemented such that
> the loop counter is created and destroyed for each step of the loop. 
> 
> You could compare this to tail recursive versus non-tail recursive functions. 
> 
> Also closures make the implementation of efficient loops more
> difficult 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.

Python is not a functional programming language. As I understand it, you
can't really have convenient closures because it is not lexically scoped
(I can give you inconvenient closures...) and there were lengthy
discussions about that some months back. I didn't follow it too closely
because I didn't know what lexically scoped meant then, but the upshot was
(I think) that lexical scoping isn't really the "Python way".

Python isn't really an OO language either, in the sense of something like
Smalltalk or Eiffel.

I have heard it said that Python is a language that "gets it's compromises
exactly right" and that about sums it up for me.

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

Really? When? Sorry, I don't want to sound disbelieving, but I don't
remember that.

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

Python, as I said, is neither functional nor purely OO; it's not
particularly fast either. Fast enough, generally.

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

*That* I believe. Not clear what to do about it though.

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

Not vastly more often than in regular code, I'd guess. It's true that
executing

1+1

spends longer twiddling refcounts than doing the work, but that's Python.

I can't decide which Peters-style ending I want here, so you're all
getting two:

not-OO-functional-or-fast-but-still-great-ly y'rs
it's-not-OO-or-functional-it's-Python-ly y'rs

Michael