Design Ideals Goals Python 3 - Forest for the trees

Discussion in 'Python' started by flebber, Dec 26, 2010.

  1. flebber

    flebber Guest

    Hi

    I was hoping someone could shed some (articles, links) in regards
    python 3 design ideals. I was searching guido's blog which has his
    overarching view of Python from an early development perspective
    http://python-history.blogspot.com/2009/01/pythons-design-philosophy.html
    ..

    I was interested in what the design goals/philosphy was of Python 3
    from a birds eye view, forest for the trees approach.

    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.

    But performance wouldn't be the over-arching criteria for the change.
    Just curious.
    flebber, Dec 26, 2010
    #1
    1. Advertising

  2. flebber

    Tim Harig Guest

    On 2010-12-26, flebber <> wrote:
    > I was hoping someone could shed some (articles, links) in regards
    > python 3 design ideals. I was searching guido's blog which has his
    > overarching view of Python from an early development perspective
    > http://python-history.blogspot.com/2009/01/pythons-design-philosophy.html
    > .
    >
    > I was interested in what the design goals/philosphy was of Python 3
    > from a birds eye view, forest for the trees approach.


    This is rather old; but you might watch:

    http://www.youtube.com/watch?v=1RjtT17WbcQ

    if you haven't seen it already.
    Tim Harig, Dec 26, 2010
    #2
    1. Advertising

  3. > 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/
    Alice Bevan–McGregor, Dec 26, 2010
    #3
  4. flebber

    flebber Guest

    On Dec 26, 4:56 pm, Alice Bevan–McGregor <> 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?
    flebber, Dec 26, 2010
    #4
  5. > So do the new changes(to the GIL) nullify concerns raised by David
    > Beazely here http://dabeaz.com/python/UnderstandingGIL.pdf


    Ah, good catch. I had watched the recorded presentation some time ago.
    Yes, the rewritten GIL should alleviate those problems. Instead of
    simply releasing and re-acquiring the GIL, it releases, then determines
    thread scheduling using the brainfuck algorithm instead of leaving it
    up to the kernel in the brief instant the GIL is unassigned (which
    often doesn't context switch to another thread, thus the performance
    penalty).

    (I beleive that algorithm, whose name -is- accurate, was the winner of
    the long, long discussion on the Python ticket.)

    > 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/


    I've never really attempted to use JIT optimizers due to the fact that
    all of my development and production environments are 64-bit, and I
    haven't found one yet that supports 64-bit properly. Relying on dead
    projects, however, is an issue of larger scope than mere portability.
    ;)

    > 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?


    I'd take the same approach Python 3 itself did; rewrite it for Python 3
    and take the opportunity to remove excessive backwards compatibility
    cruft, streamline algorithms, etc. With a suite of existing
    unit/functional tests, that possibility is the ultimate in test-driven
    development. ;) It would also follow the write clean code, then
    profile and optimize where actually needed philosophy.

    Obviously that recommendation won't be the "best" solution for every project.

    With all of the FOSS projects I really, really care about I'm writing
    from near-scratch (the code, if not the algorithms) with 2.6+ and 3.1+
    polygot (no conversion tools like 2to3, and no split packaging)
    compatibility as a primary design goal. So far it's working out quite
    well.

    - Alice
    Alice Bevan–McGregor, Dec 26, 2010
    #5
  6. On Dec 26, 5:34 am, Alice Bevan–McGregor <> wrote:
    >
    > I've never really attempted to use JIT optimizers due to the fact that
    > all of my development and production environments are 64-bit, and I
    > haven't found one yet that supports 64-bit properly.  Relying on dead
    > projects, however, is an issue of larger scope than mere portability.  
    > ;)
    >


    The PyPy JIT supports x86_64. It's still being improved, but it does
    provide real speedups in some cases already.

    Jean-Paul
    Jean-Paul Calderone, Dec 26, 2010
    #6
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Christoph Zwerschke

    General question about Python design goals

    Christoph Zwerschke, Nov 28, 2005, in forum: Python
    Replies:
    105
    Views:
    1,521
    Donn Cave
    Dec 3, 2005
  2. Jean-Paul Calderone

    Re: General question about Python design goals

    Jean-Paul Calderone, Nov 28, 2005, in forum: Python
    Replies:
    1
    Views:
    314
    Paul Rubin
    Nov 28, 2005
  3. News
    Replies:
    5
    Views:
    533
    Dennis Lee Bieber
    Apr 14, 2006
  4. jacob navia

    Binary search trees (AVL trees)

    jacob navia, Jan 3, 2010, in forum: C Programming
    Replies:
    34
    Views:
    1,394
    Dann Corbit
    Jan 8, 2010
  5. bpatton
    Replies:
    4
    Views:
    106
    Uri Guttman
    Aug 24, 2006
Loading...

Share This Page