Re: Design Ideals Goals Python 3 - Forest for the trees
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 -- http://mail.python.org/mailman/listinfo/python-list
Re: Design Ideals Goals Python 3 - Forest for the trees
On Dec 26, 5:34 am, Alice Bevan–McGregor al...@gothcandy.com 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 -- http://mail.python.org/mailman/listinfo/python-list
Design Ideals Goals Python 3 - Forest for the trees
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. -- http://mail.python.org/mailman/listinfo/python-list
Re: Design Ideals Goals Python 3 - Forest for the trees
On 2010-12-26, flebber flebber.c...@gmail.com 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. -- http://mail.python.org/mailman/listinfo/python-list
Re: Design Ideals Goals Python 3 - Forest for the trees
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/ -- http://mail.python.org/mailman/listinfo/python-list
Re: Design Ideals Goals Python 3 - Forest for the trees
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
