Design Ideals Goals Python 3 - Forest for the trees

[flebber]

On Dec 26, 4:56 pm, Alice Bevan–McGregor <al... at gothcandy.com> wrote:
> > I was interested in what the design goals/philosphy was of Python 3
> > from a birds eye view, forest for the trees approach.
>
> I think I can safely point to the Zen of Python[1] as many of the
> points therein directly apply to the simplifiation, clarification, and
> goals of Python 3.  Most notably:
>
> :: Beautiful is better than ugly.
>
> E.g. dict.iteritems, dict.iterkeys, dict.itervalues?  Strip 'iter' and
> it's fixed.
>
> :: Special cases aren't special enough to break the rules.
>
> Ever get hung up on core Python modules with title caps?  Yeah, those
> are fixed.
>
> :: There should be one-- and preferably only one --obvious way to do it.
>
> E.g. urllib, urllib2, urllibX… yeah, that's been fixed, too.  :)
>
> :: Namespaces are one honking great idea -- let's do more of those!
>
> Numerous modules have been merged, or moved into more manageable (and
> logical) namespaces.
>
> > I can safely assume one goal was speed improvement as in the blog he
> > noted "Don’t fret too much about performance--plan to optimize later
> > when needed." So I assume that means that Python had developed to a
> > point where that was needed.
>
> The Python GIL (Global Interpreter Lock) has been getting a lot of
> negative attention over the last little while, and was recently fixed
> to be far more intelligent (and efficient) in Python 3.2.  There are
> numerous other performance improvements, for which yo ucan examine the
> change logs.
>
> > But performance wouldn't be the over-arching criteria for the change.
> > Just curious.
>
> Clarification, simplification, specivity, efficiency, … just be more
> "Pythonic".
>
> Note that I'm not a core Python contributor or have ever communicated
> with the BDFL: this is just the viewpoint of somoene doing her
> darnd'est to encourage Python 3 support.  ;)  All of the new projects I
> work on are Python 2.6+ and Python 3.1+ compatible.  (Arguments against
> dual-compatible polygot code can go to /dev/null for the purposes of
> this thread.)
>
>         - Alice
>
> [1]http://www.python.org/dev/peps/pep-0020/

So do the new changes(to the GIL) nullify concerns raised by David
Beazely here http://dabeaz.com/python/UnderstandingGIL.pdf

Some projects have been using and requiring psyco to gain speed
improvements in python http://psyco.sourceforge.net/introduction.html
however it seems that the developer is not active on this project
anymore and is more active on PyPy http://codespeak.net/pypy/dist/pypy/doc/

A program such as AVSP http://avisynth.org/qwerpoi/ which relies on
psyco what would be a good proposition to use when taking the project
to python 3.0 if psyco will remain unavailable?