I understand that the standard Python distribution is considered the C-Python. Howerver, the current C-Python is really a combination of C and Python implementation. There are about 2000 Python files included in the Windows version of Python distribution. I'm not sure how much of the C-Python is implemented in C but I think the more modules implemented in C, the better performance and lower memory footprint it will get. I wonder if it's possible to have a Python that's completely (or at least for the most part) implemented in C, just like PHP - I think this is where PHP gets its performance advantage. Or maybe I'm wrong because the core modules that matter are already in C and those Python files are really a think wrapper. Anyhow, if would be ideal if Python has performance similar to Java, with both being interpreted languages. Jack

In article <G62dnbBDl_Y0x8HanZ2dnUVZ_gudnZ2d@comcast.com>, Jack <nospam@invalid.com> wrote: > >I understand that the standard Python distribution is considered >the C-Python. Howerver, the current C-Python is really a combination >of C and Python implementation. There are about 2000 Python files >included in the Windows version of Python distribution. I'm not sure >how much of the C-Python is implemented in C but I think the more >modules implemented in C, the better performance and lower memory >footprint it will get. Prove it. ;-) Seriously, switching to more C code will cause development to bog down because Python is so much easier to write than C. >I wonder if it's possible to have a Python that's completely (or at >least for the most part) implemented in C, just like PHP - I think >this is where PHP gets its performance advantage. Or maybe I'm wrong >because the core modules that matter are already in C and those Python >files are really a think wrapper. Anyhow, if would be ideal if Python >has performance similar to Java, with both being interpreted languages. Could you provide some evidence that Python is slower than Java or PHP? -- Aahz (aahz@pythoncraft.com) <*> http://www.pythoncraft.com/ "Typing is cheap. Thinking is expensive." --Roy Smith

>> I'm not sure >>how much of the C-Python is implemented in C but I think the more >>modules implemented in C, the better performance and lower memory >>footprint it will get. > > Prove it. ;-) I guess this is subjective :) - that's what I felt in my experience with web applications developed in Python and PHP. I wasn't able to find a direct comparison online. > Seriously, switching to more C code will cause development to bog down > because Python is so much easier to write than C. I understand. Python modules implemented in Python - this is how Python gets its really rich library. >>I wonder if it's possible to have a Python that's completely (or at >>least for the most part) implemented in C, just like PHP - I think >>this is where PHP gets its performance advantage. Or maybe I'm wrong >>because the core modules that matter are already in C and those Python >>files are really a thin wrapper. Anyhow, it would be ideal if Python >>has performance similar to Java, with both being interpreted languages. > > Could you provide some evidence that Python is slower than Java or PHP? I think most Java-Python benchmarks you can find online will indicate that Java is a 3-10 times faster. A few here: http://mail.python.org/pipermail/python-list/2002-January/125789.html http://blog.snaplogic.org/?p=55 Here's an article that shows the new version of Ruby is faster than Python in some aspects (they are catching up :) http://antoniocangiano.com/2007/11/28/holy-shmoly-ruby-19-smokes-python-away/

"Jack" <nospam@invalid.com> wrote in message news:G62dnbBDl_Y0x8HanZ2dnUVZ_gudnZ2d@comcast.com... |I understand that the standard Python distribution is considered | the C-Python. Howerver, the current C-Python is really a combination | of C and Python implementation. There are about 2000 Python files | included in the Windows version of Python distribution. About half or fewer are modules meant to be imported into programs. The rest comprise utility programs and test programs. The core interpreter is all C. | because the core modules that matter are already in C Correct. There are about 20 'builtin' modules written is C either because they need low level access to the machine or for speed concerns. Third party modules not included in the standard distribution but definitely part of the Python universe are also a mix. If people wrote everything in C for speed, there would be no need for Python!! And don't say that you want everyone else to write in C while you enjoy the pleasures of Python ;-). tjr

>> I think most Java-Python benchmarks you can find online will indicate >> that Java is a 3-10 times faster. A few here: >> http://mail.python.org/pipermail/python-list/2002-January/125789.html >> http://blog.snaplogic.org/?p=55 > > There are lies, damn lies and benchmarks. :) > > Pure Python code is not going to beat Java code until the Python core > gets a JIT compiler. If you want fair results you have to either > disable the JIT in Java or use Psyco for Python. Otherwise you are > comparing the quality of one language implementation to the quality of a > JIT compiler. The second articple does have a column for Psyco. It helps in some areas but still not good enough to stand up against Java. Plus, Psyco is not the main stream and has stopped development. I'm also wondering, if Psyco is the right way to do, any reason it's not being integrated into standard Python?

"Jack" <nospam@invalid.com> wrote in message news:vLadnbUkzunUHsHanZ2dnUVZ_judnZ2d@comcast.com... | The second articple does have a column for Psyco. It helps in some areas | but still not good enough to stand up against Java. Plus, Psyco is not the | main stream and has stopped development. It further development is effectively part of the PyPy project, which includes some jit work. | I'm also wondering, if Psyco is the right way to do, any reason it's not | being integrated into standard Python? It does not accelerate everything and may slow somethings, it was (is?) not compatible with everything, it bloats space requirements, it competes with C/Fortran coded extensions (such as NumPy), it was originally I386 specific, its development cycle was much faster than Python's release cycle, ... The cutoff between what goes in the core/stdlib is arbitrary in borderline cases, but some cutoff is necessary. tjr

In article <a324fa50-fde9-4173-81f3-f7e756bd46d7@l16g2000hsf.googlegroups.com>, sturlamolden <sturlamolden@yahoo.no> wrote: > >Donald Knuth, one of the fathers of modern computer science, is famous >for stating that "premature optimization is the root of all evil in >computer science." From my .sig database: "Premature optimization is the root of all evil in programming." --C.A.R. Hoare (often misattributed to Knuth, who was himself quoting Hoare) -- Aahz (aahz@pythoncraft.com) <*> http://www.pythoncraft.com/ "Typing is cheap. Thinking is expensive." --Roy Smith

In article <mailman.2374.1197592941.13605.python-list@python.org>, Christian Heimes <lists@cheimes.de> wrote: >Steven D'Aprano wrote: >> >> I'm not quite sure I understand that criticism. How is that different >> from things which are not properties? >> >> foo.baz = 2 # oops, I meant bar >> >> will succeed regardless of whether foo.bar is an attribute or a property. > >Unless it's a new style class with __slots__ [....] Naw, I'll skip the rant this time. ;-) -- Aahz (aahz@pythoncraft.com) <*> http://www.pythoncraft.com/ "Typing is cheap. Thinking is expensive." --Roy Smith