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

[Tim Peters]

Following up on just a couple points:

[Markus Kohler]
> ...
> IMHO it's [Python] very close to Smalltalk, also Guido probably wouldn't
> agree with me ...
> And It has all essential OO features.

Python is something of an ink blot test that way:  people coming from Scheme
think it's very close to that (and just needs macros and continuations and
lexical closures <wink>); people coming from pure functional languages have
a similar tale (and it just needs non-strict functions and a pile of
combinator notation); people coming from Perl -- well, let's stop before it
gets silly <wink>.

Python takes a lot of ideas from a lot of languages, but it has its own
worldview, and its own corresponding implementation.  It really isn't "like"
anything else at heart, in philosophy or implementation.

I'm looking forward to the day when I drop in on another comp.lang.* group
and read "you know, this language is very close to Python, and all it really
needs is namespaces modeled as explicit dicts" <wink>.

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

[Michael Hudson]
>> Really? When? Sorry, I don't want to sound disbelieving, but I don't
>> remember that.

[back to Markus]
> It was about reading a file and put the words into some hash table.
> As far as I can remember to loop overhead was a dominating factor.
> And Python was much slower than perl for example.

Ah, that one.  That's not loops.  It's input.  Line-at-a-time input on my
platform is about 3 times faster in Perl than Python; indeed, it's faster in
Perl than in C!  It's not loop mechanisms or even refcounting "to blame"
here (btw, Perl does refcounting too ...).  It's that Perl breaks into the
stdio abstraction, going under the covers in platform + compiler specific
ways, peeking and poking C stdio FILE structs directly.

Very clever, but a lot of work.  Most fgets implementations suck, and Perl
deserves all the credit for not settling for that.  I doubt Python will do
it too, not as a matter of principle, but because nobody capable of it will
make time to do it.

would-rather-have-faster-functions-myself-but-if-wishes-were-bananas-
    we'd-be-swimming-in-mushy-fruit-ly y'rs  - tim