[Python-Dev] Why did Fredrik leave the party?

Guido van Rossum guido@python.org
Tue, 04 Feb 2003 21:07:55 -0500


Hi Michael,

That's a slightly sneaky subject line for a feature request.  But I'll
forgive you because you got my attention. :-)

> It looks like Fredrik is drifting away from Python development
> because Python has been drifting away from the original
> small-is-beautiful design. The energy going into the thunks and
> Extended Function threads has me baffled.

No need to be baffled.  There are many different people here with
vastly different interests and ideas.  That's what I like about this
community: there's always something new being explored. Sometimes a
bunch of people get excited over a new idea and try to hash out what
the best way to implement is.  Sometimes they get a little too
excited; then it stops.  Sometimes it's decimal numbers, another time
it's thunks.

> Will the marginal gain in new applications that will be enabled by
> these features exceed the marginal loss in new Python programmers
> due to the increased learning threshold?  The creep is slow, but it
> is happening.

Understood.  I hope you also understand that the syntax extension
ideas being discussed are (a) far from sure to have any impact on
Python's design at all, and (b) certain not to affect Python 2.3.

> Generators are cool once you understand them, but they raise the bar
> for someone new to the language.

That all depends.  You don't have to teach generators at all in an
introductory course -- you don't even have to teach iterators.  But
all this has been discussed many times before here in numerous
threads.  My personal opinion is that generators make certain kinds of
code so much easier to write that the benefits far outweigh the cost.

> The same is true for list comprehension. And the proposed syntax
> changes I've seen in these thrreads are ugly. Please don't turn
> Python into Perl.

Maybe they're ugly because I had to withdraw (temporarily) from the
thread due to lack of time?  These days, I can only argue about
language changes in my spare time...

> I thought the focus of development was going to put more energy into
> improving the standard library. For instance, Zope often works with
> SQL databases and those databases often contain financial data. How
> well does Python support this numerical requirement? According to
> IBM Technical Report TR03.413 [1], the numeric column breakdown by
> data type is:
> 
>    Type    Columns  percent     
>  Decimal    251038   55.0    
>  SmallInt   120464   26.4    
>  Integer    78842    17.3    
>  Float      6180     1.4
> 
> The Decimal type is the overwhelming winner because the Decimal type
> is required for financial calculations. This is a huge and important
> IT market segment. I submitted a patch that added a native fixed
> type to Python using Tim Peter's FixedPoint module, but it was
> rejected because I added syntax support for the new type. Please at
> least add Tim's FixedPoint module to the 2.3 release. (The class
> should probably be renamed to something shorter like fpoint or fixed
> when it is added to the standard library.)
> 
> [1] http://www2.hursley.ibm.com/decimal/decifaq1.html#dbstats

Very sneaky, to start with a gripe about language growth and end with
a plea for your favorite language addition. :-)

I'm not convinced that decimal arithmetic is Python's next frontier or
that it would make a difference to improve Python's adoption.  I'm
also not convinced that it makes no difference, but as you know, you
can prove anything with statistics (not to mention the fact that 90%
of statistics are made up), and I note that the URL you quote mentions
commercial databases owned by major organizations.  This is a specific
segment of the IT market where it's no surprise that decimal numbers
are in the majority.

Let me counter with some more statistics.  The FixedPont module is
available from SourceForge.  It doesn't look like it's wildly popular
though: it has been downloaded 236 times since the first release last
August.  Some more statistics (that I swear I am not making up):
during the life of this project (since last August) a total of 3 bugs
were reported, zero patches, and one feature request.

I'll leave it to Tim to explain why he doesn't think this module
should be added to the standard library.  If he thinks it belongs
there, I certainly won't argue against it!

--Guido van Rossum (home page: http://www.python.org/~guido/)