[Python-Dev] Toward Python's future article

[Carlos Ribeiro]

On Thu, 7 Oct 2004 19:55:03 -0400, Raymond Hettinger <python at rcn.com> wrote:
> Where there are multiple, competing third party solutions, Guido has
> historically resisted ending exploration by locking in a single
> solution.  Instead, he said he prefers "category killers" such as the
> unittest and logging modules.  Martin has also been clear that community
> acceptance and a commitment to on-going maintenance are also important
> considerations.

I see the reasoning behind this position. But I fear it can lead to
lack of standardization in some areas. There is at least one area
where a firm position would greatly clarify things: standard
interfaces for modules where multiple providers are always the norm,
such as the DB API and WSGI. WSGI is working is way out, but it's
still too early to tell if they will be successful. But the DB API
could really take advantage of a BDFL-style intervention to settle
things. (it does not *need* to be Guido, but it has to be someone with
power enough to take a firm stand and enforce it; but I don't know
anyone who could assume this role as the undisputed leader of the
DB-API effort).
 
> For the core, python-dev discussions indicate that several things are
> still in the works and will probably happen depending on who has the
> time, interest, and ability:
> 
> * Someday, decimal may become a built-in type.
> * The AST version of the compiler may get finished.
> * A mutable bytes type may emerge on the road to all strings being
> Unicode.
> * Someday, C99 may rule the roost and cmath will be updated.
> * One of three proposals may be accepted for optimized attribute lookup.
> * A bytecode verifier seems to have a chance.
> * reST support may be added when it becomes mature enough.
> * The project to transition to unittests and increase coverage is
> continuing.
> * If the class/instance semantics get worked out, exceptions may become
> new style classes along the road to Py3.0.

Nice summary.

> FWIW, there is a trend toward providing pure python equivalents to
> CPython implementations (such as that for compiler, sets, bisect, heapq,
> deques, itertools, decimal, etc).  The thought is that these may outlive
> their C counterparts.
 
That's great -- I mean, taken to its maximum expression, Python would
be able to bootstrap itself this way (a Python VM written in Python?).
It's a sign of maturity, don't you think?
 
> > i am personaly very interested in improving the stdlib which is very
> messy
> > in my
> > opinion right now.
> 
> It's not clear whether you're volunteering or just making a vague
> blanket request/criticism.  If it is the former, then the backlog of bug
> reports and patch reviews is a good place to start.

I still need to find my way there (docs/sourceforge stuff). Depending
on the way my current projects go, I may still be able to dedicate
some time to it. I'm really looking forward to it...

-- 
Carlos Ribeiro
Consultoria em Projetos
blog: http://rascunhosrotos.blogspot.com
blog: http://pythonnotes.blogspot.com
mail: carribeiro at gmail.com
mail: carribeiro at yahoo.com