Design Ideals Goals Python 3 - Forest for the trees

[flebber]

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.

 

[Tim Harig]

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:

if you haven't seen it already.

 

[Alice Bevan–McGregor]

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/

 

[flebber]

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?

 

[Alice Bevan–McGregor]

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

 

[Jean-Paul Calderone]

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