On Dec 26, 4:56 pm, Alice Bevan–McGregor <al...@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? -- http://mail.python.org/mailman/listinfo/python-list
