Language change and code breaks

Tim Peters at
Thu Jul 26 06:14:11 CEST 2001

> I would gladly shell out hefty developer fees for a Python which
> performed within a small order of magnitude C speeds.

I'll expect the check shortly then -- or you should rephrase what is you're

> I'm keeping a close eye one QKS at the moment for just that reason.

If they're developing a faster version of Python, great.  Or you mean you
want "a fast language" regardless of brand?  Then I don't know why you're
waiting for QKS.  It shouldn't really be a challenge to find a $300
two-platform language that runs faster than Python <wink>.

> At work, I'd easily pull strings for a $1000 developer platform to do
> this; at home, I'd be willing to spend about $250.
> I know I'm not alone.

Indeed you aren't, but from where I sit there aren't *enough* others in your
family to avoid bankruptcy if someone were to bet a business on it.  Of all
the many things people ask for, "faster, faster!" is ongoing but almost down
in the noise.  Few people contribute toward it, either.

> You Python Labs dudes have lost sight of a major impediment to
> the maturation of Python, IMO.

Don't know what that means.

> And if the QKS folks are getting the performance improvements
> they say they are, it would appear that the allegation that
> Python speed was dependent on a first-class type system was just
> plain wrong.

I've never heard anyone at PythonLabs make that claim.  Have you?  BTW, I
stopped arguing about optimization on years ago, because it was
time-consuming but never bore fruit.

> Don't you guys work on Python all day long?

Sorry, that's not the arrangement, not even for Guido.  At least half the
time I do spend on Python is devoted to dealing with SourceForge bug reports
and patches, answering a torrent of email questions (but still only a
fraction of the ones I get), reviewing ideas & proposals, and just keeping
up with the Python newsgroups and mailing lists.  Barry is also lead
developer on the Mailman project, and Fred Drake also busy advancing the
state of

I have a good grasp of what it takes to undertake a major optimization
project (I made my living for 15 years writing optimizing compilers), and
the only way we have enough resource to tackle that successfully is in my
dreams.  We could certainly spend more time than we do making solid small
(localized and modest) performance improvements -- but only by dropping
other work.  IOW, the plate's already overflowing, Joe, and I'm sure you
have your ideas of what we should drop to work on what you want instead, but
everyone else does too, and the bulk of the pressures don't push in the
"faster" direction.

    y'rs  - tim

More information about the Python-list mailing list