2.4 news reaches interesting places
I was pleasantly surprised to find a pointer to this article in a news digest that the ACM emails me regularly (ACM TechNews). http://gcn.com/vol1_no1/daily-updates/28026-1.html One thing that bugs me: the article says 3 or 4 times that Python is slow, each time with a refutation ("but it's so flexible", "but it's fast enough") but still, they sure seem to harp on the point. This is a PR issue that Python needs to fight -- any ideas? -- --Guido van Rossum (home page: http://www.python.org/~guido/)
At 02:18 PM 12/8/04 -0800, Guido van Rossum wrote:
I was pleasantly surprised to find a pointer to this article in a news digest that the ACM emails me regularly (ACM TechNews).
http://gcn.com/vol1_no1/daily-updates/28026-1.html
One thing that bugs me: the article says 3 or 4 times that Python is slow, each time with a refutation ("but it's so flexible", "but it's fast enough") but still, they sure seem to harp on the point. This is a PR issue that Python needs to fight -- any ideas?
The only thing that will fix the PR issue is to have a Python compiler distributed as part of the language. It doesn't matter if it doesn't support the full generality of Python, or even if it doesn't speed many operations up much. The only real requirements are that it can be used to produce "native" executables, and that it be an official part of the language, not a separately-distributed tool like Psyco or Pyrex. Then, it will perhaps be a sufficient "security blanket" to stop people FUDding about it. I imagine you could speed up the Python interpreter until it's faster than half the Java JIT's out there, and people will still ask, "But can I compile to an .exe?" On the other hand, if you add a compiler, we'll see articles like the above talking about how Python can now be compiled and so therefore it's suitable for all kinds of things it wasn't before. :) Of course, it would be *really* useful if the compiler were coupled with optional type declarations for Python-the-language, because then we could ultimately dispense with the current syntax warts of Pyrex (and the runtime/distribution warts of ctypes) for interfacing with C. But I don't think that having the compiler actually be useful is a prerequisite for solving the PR issue. :)
The only thing that will fix the PR issue is to have a Python compiler distributed as part of the language. It doesn't matter if it doesn't support the full generality of Python, or even if it doesn't speed many operations up much. The only real requirements are that it can be used to produce "native" executables
I don't hink it's a matter of native executables. Hopefully all the real algorithms are already in native executables as builtins (dictionary lookup, etc). And generally, one can wrap all the tough code in C and take advantage of the flexibility of python at a higher level. pygame is the best example of this! Basic stuff from complexity theory: the real complex parts are few and isolated in C. For the other we can take advantage of a higher level dynamic language. Stelios
At 01:25 AM 12/9/04 +0200, Stelios Xanthakis wrote:
The only thing that will fix the PR issue is to have a Python compiler distributed as part of the language. It doesn't matter if it doesn't support the full generality of Python, or even if it doesn't speed many operations up much. The only real requirements are that it can be used to produce "native" executables
I don't hink it's a matter of native executables.
As I explained later in that message, "native" simply means, "has an .exe extension on Windows". For PR purposes, it would suffice to bundle py2exe with Python 2.5 and say that Python "now includes a compiler to produce executable files". This will then be picked up and misinterpreted by the trade press in exactly the same way that the article Guido cited picked up and misinterpreted what was said about 2.4. If you read the article carefully, you will notice that the author translated "we rewrote a few modules in C" into "we made Python faster by switching to C". If you ask anybody what language is faster, language X or C, most everybody will answer "C", regardless of what X is (unless it's assembly, of course). All of the discussion about *actually* improving Python's performance is moot for PR purposes. Public perception is not swayed by mere facts (as one might cynically observe of the U.S. political system). If the goal is to achieve a PR win, the important thing is to pick a meme that's capable of succeeding, and stay "on message" with it. The *only* meme that's organically capable of trumping "Python is slow because it's interpreted" is "Python is compiled now". Me, I don't really care one way or the other. I used to sell software I wrote in TRS-80 Basic, so Python's performance is fine for me, and I'm certainly not a compiler bigot. I'm just responding to Guido's inquiry about what might work to increase Python's *perceived* speed in popular consciousness, not its actual speed.
On Wed, Dec 08, 2004 at 08:30:02PM -0500, Phillip J. Eby wrote:
As I explained later in that message, "native" simply means, "has an .exe extension on Windows".
And very soon that strategy will backfire - people will start PRing "but those .exe's are nothing more than a python interpreter in disguise" which in my opnion is even worse.
All of the discussion about *actually* improving Python's performance is moot for PR purposes.
Hence we must stop spending our very valuable time thinking about PR and return to actually improving Python (not only performance).
If the goal is to achieve a PR win, the important thing is to pick a meme that's capable of succeeding, and stay "on message" with it.
Translating to a plain langauge: "PSF should spend money spreading around a counter-PR". I am afraid PSF doesn't have enough money, and even if it has - should we really run down that path? Oleg. -- Oleg Broytmann http://phd.pp.ru/ phd@phd.pp.ru Programmers don't die, they just GOSUB without RETURN.
At 01:17 PM 12/9/04 +0300, Oleg Broytmann wrote:
On Wed, Dec 08, 2004 at 08:30:02PM -0500, Phillip J. Eby wrote:
As I explained later in that message, "native" simply means, "has an .exe extension on Windows".
And very soon that strategy will backfire - people will start PRing "but those .exe's are nothing more than a python interpreter in disguise" which in my opnion is even worse.
ISTR that for a long time, Visual Basic actually did the same thing. A few magazines mentioned the fact, but nobody really cared. However, if this is really a concern, bundle Pyrex as well. Both Pyrex and py2exe are distutils-based, so at that point you have a complete solution, including the "C" meme as well as the ".exe" meme.
If the goal is to achieve a PR win, the important thing is to pick a meme that's capable of succeeding, and stay "on message" with it.
Translating to a plain langauge: "PSF should spend money spreading around a counter-PR". I am afraid PSF doesn't have enough money, and even if it has - should we really run down that path?
I'm not suggesting spending any money. Heck, I'm not suggesting *doing* anything. I just answered Guido's question about PR. Whether anybody wants to *do* anything about it is an entirely separate issue from discussing *what* would need to be done, if something was going to be done.
On Thu, 2004-12-09 at 10:30, Phillip J. Eby wrote:
ISTR that for a long time, Visual Basic actually did the same thing. A few magazines mentioned the fact, but nobody really cared. However, if this is really a concern, bundle Pyrex as well. Both Pyrex and py2exe are distutils-based, so at that point you have a complete solution, including the "C" meme as well as the ".exe" meme.
As an aside, I wonder if there's interest in collaborating on freeze tools among the various existing solutions here. I've recently needed to look at this and I chose cx_Freeze, primarily because it supported the platforms I needed. It's a very good tool. I've had some conversations with Anthony Tuininga on the cx_Freeze mailing list and there seems to be some interest in perhaps putting together a SIG or something. -Barry
On Dec 9, 2004, at 4:20 PM, Barry Warsaw wrote:
On Thu, 2004-12-09 at 10:30, Phillip J. Eby wrote:
ISTR that for a long time, Visual Basic actually did the same thing. A few magazines mentioned the fact, but nobody really cared. However, if this is really a concern, bundle Pyrex as well. Both Pyrex and py2exe are distutils-based, so at that point you have a complete solution, including the "C" meme as well as the ".exe" meme.
As an aside, I wonder if there's interest in collaborating on freeze tools among the various existing solutions here. I've recently needed to look at this and I chose cx_Freeze, primarily because it supported the platforms I needed. It's a very good tool.
I've had some conversations with Anthony Tuininga on the cx_Freeze mailing list and there seems to be some interest in perhaps putting together a SIG or something.
That's certainly worth doing. Currently we have, in general use, at least cx_Freeze, py2exe, and py2app. I have been abstracting away a lot of the dependency finding issues in py2app into a cross-platform module called modulegraph <http://svn.red-bean.com/bob/py2app/trunk/src/modulegraph/>. Modulegraph supercedes the standard library modulefinder. Because it uses a graph data structure, it gives you the flexibility say "pydoc doesn't *really* depend on Tkinter". It also has functionality that lets you specify implicit dependencies (via PyImport_.. or such), so that it plays nicely enough with C extensions. This code is basically at the point where py2exe and cx_Freeze could import it and use it instead of modulefinder (with a small amount of hacking, the API is different). -bob
On Wednesday 2004-12-08 22:39, Phillip J. Eby wrote: [Guido:]
One thing that bugs me: the article says 3 or 4 times that Python is slow, each time with a refutation ("but it's so flexible", "but it's fast enough") but still, they sure seem to harp on the point. This is a PR issue that Python needs to fight -- any ideas?
[Philip:]
The only thing that will fix the PR issue is to have a Python compiler distributed as part of the language. It doesn't matter if it doesn't support the full generality of Python, or even if it doesn't speed many operations up much. The only real requirements are that it can be used to produce "native" executables, and that it be an official part of the language, not a separately-distributed tool like Psyco or Pyrex. Then, it will perhaps be a sufficient "security blanket" to stop people FUDding about it.
Unfortunately, this may not be enough. Consider, by way of counterexample, Common Lisp, which - is compiled to native code - has optional type declarations - actually *does* run fast when compiled - has had all these properties for years and years but is still almost universally decried as "slow" by people who have never actually used it. It's true that it doesn't (as part of the standard, and in the free implementations I know of) have the ability to generate standalone executables with filenames ending in ".exe"; perhaps that's the key thing. The other thing that might work is to change the name of the language to "C" plus optional punctuation. -- g
At 04:39 PM 12/9/04 +0000, Gareth McCaughan wrote:
On Wednesday 2004-12-08 22:39, Phillip J. Eby wrote:
The only thing that will fix the PR issue is to have a Python compiler distributed as part of the language. It doesn't matter if it doesn't support the full generality of Python, or even if it doesn't speed many operations up much. The only real requirements are that it can be used to produce "native" executables, and that it be an official part of the language, not a separately-distributed tool like Psyco or Pyrex. Then, it will perhaps be a sufficient "security blanket" to stop people FUDding about it.
Unfortunately, this may not be enough. Consider, by way of counterexample, Common Lisp, which - is compiled to native code - has optional type declarations - actually *does* run fast when compiled - has had all these properties for years and years but is still almost universally decried as "slow" by people who have never actually used it. It's true that it doesn't (as part of the standard, and in the free implementations I know of) have the ability to generate standalone executables with filenames ending in ".exe"; perhaps that's the key thing.
Among the great unwashed masses of Windows programmers, it probably is. Look at the marketing for virtually any off-beat commercial language for Windows (that's still around to look at), and you will usually find a prominent bullet point about how it makes .exe's. This is an incredibly powerful meme, though I don't entirely understand why. I do agree that it still may not be enough; I'm just saying that it's not a coincidence that so many development tools for non-C languages on Windows all ended up deciding to feature that bullet point. My theory is that it's because it's a FAQ, and it's often found on the official FAQ's of open source languages as well. Granted, the scope of the question is much broader than just speed, since it also encompasses application distribution issues, and the social status of the developer. One of the subtexts of the question is, "Can I make a *real* program with this thing?", or put more honestly, "Will other programmers laugh at me when they see my program isn't an .exe?"
The other thing that might work is to change the name of the language to "C" plus optional punctuation.
Well, we could always just call it CPython, and bill it as a faster C implementation of that popular dynamic language for Java, Jython. That way, we can also leverage the meme that C is faster than Java. :) Isn't it funny, by the way, that people don't go around talking about how slow Jython is? At least, I haven't seen it to the extent that I've seen with CPython.
On Dec 9, 2004, at 1:31 PM, Phillip J. Eby wrote:
Isn't it funny, by the way, that people don't go around talking about how slow Jython is? At least, I haven't seen it to the extent that I've seen with CPython.
People talk about how slow CPython is, is because they are writing code targeted for it that traditionally would have been written in C. Python *is* slower than C. You can try to deny it, but it is simple fact. However, python is a really nice language to program in. So people use it anyways. It is "fast enough" for many things. Nobody talks about how slow Jython is, because nobody(1) is writing entire programs in it. Jython is used as a way to script Java programs, and as such, it is pretty much completely unimportant how fast it runs. Java has also traditionally got a lot of bad press for its lack of speed, and it was usually of the "not fast enough" variety, which is much worse than what's said of Python. However, a huge amount of progress has been made and Java really is quite speedy these days. It was not PR that made it faster, but hard work on the part of Sun. There is currently a lot of work going on in the python community to make Python faster, which indicates both that Python is too slow for some people, and that it will be faster in the future. This is a good thing, and not something that should be shoved under the rug to try to pretend python is ultra mega super fast already. James 1) Of course someone probably is, but you get the idea.
On Thu, 9 Dec 2004 14:16:18 -0500, James Y Knight <foom@fuhm.net> wrote:
On Dec 9, 2004, at 1:31 PM, Phillip J. Eby wrote:
Isn't it funny, by the way, that people don't go around talking about how slow Jython is? At least, I haven't seen it to the extent that I've seen with CPython.
People talk about how slow CPython is, is because they are writing code targeted for it that traditionally would have been written in C. Python *is* slower than C. You can try to deny it, but it is simple fact. However, python is a really nice language to program in. So people use it anyways. It is "fast enough" for many things.
I think you are exactly right. It's easy to get the impression that Python is slow when many programs written in Python *are* slowly than the same program written in C, C++, or Java. If you look are other "dynamic" languages, you'll find that IronPython is often faster than CPython and that Smalltalk and Common Lisp are often substantially faster than Python. Python isn't remarkably slow for a scripting language, but it is not fast.
There is currently a lot of work going on in the python community to make Python faster, which indicates both that Python is too slow for some people, and that it will be faster in the future. This is a good thing, and not something that should be shoved under the rug to try to pretend python is ultra mega super fast already.
I agree, although it's not clear to me how much faster it will be in the future. Making a *fast* Python based on our own virtual execution environment (as opposed to piggybacking a JVM or CLR) is a big project. It's not clear than anyone has enough resources to make credible effort, so we're left to piecemeal improvements. The improvement I see from 2.2 to 2.4 on my box is about 55% (measured using pystone) over almost three years. I think the right thing to do with PR is frame the question differently. We need to say that people use Python because it lets them right clear, simple code or that it is easy to maintain or that dynamic languages are excellent for prototyping -- whatever the message is -- and simply avoid talking about speed. There are a lot of issues that affect the selection of a programming language, and speed is not always the most important one. It is easy for a journalist to write about and it is easy to report (possibly meaningless) measurements of speed. Jeremy
Jeremy Hylton <jhylton@gmail.com> writes:
I agree, although it's not clear to me how much faster it will be in the future. Making a *fast* Python based on our own virtual execution environment (as opposed to piggybacking a JVM or CLR) is a big project. It's not clear than anyone has enough resources to make credible effort
I think the EU does! Cheers, mwh -- NUTRIMAT: That drink was individually tailored to meet your personal requirements for nutrition and pleasure. ARTHUR: Ah. So I'm a masochist on a diet am I? -- The Hitch-Hikers Guide to the Galaxy, Episode 9
On Wed, 2004-12-08 at 17:39 -0500, Phillip J. Eby wrote:
The only thing that will fix the PR issue is to have a Python compiler distributed as part of the language. It doesn't matter if it doesn't support the full generality of Python, or even if it doesn't speed many operations up much. The only real requirements are that it can be used to produce "native" executables, and that it be an official part of the language, not a separately-distributed tool like Psyco or Pyrex. Then, it will perhaps be a sufficient "security blanket" to stop people FUDding about it.
I am aware that Pyrex is still in flux, so perhaps it is too soon to propose this even for 2.5, but I think it's worth bringing up anyway: I would like Pyrex to be distributed with the Python core. I agree that it should be modified to produce full .exe files and not just .dlls on Windows, but many potential users *are* seriously concerned about efficiency and not just simplifying distribution. The main benefit would be imparting a Pythonesque flavor to optimized code. The thing which experienced Python-ers say is, technically, correct: "If you need speed, rewrite the hot-spots in C.". To someone already steeped in the Python way, this means, "write your application in Python, do your architecture in Python, profile it, and write the 300 lines or so of your 25000 line application that are *really* speed-critical in a faster language". There are a few, very very specialized areas where this approach is not the best one, but unfortunately C programmers do not hear this when you say it. What they hear is, "If speed is important to your application, write it in C, and only write the parts where you need flexibility in Python. They will all be deadly slow. If you notice that they are slow, you are going to have to rewrite them in C anyway." To wit, Python is only interesting to the people who are going to "script" your application. Although writing code in Pyrex ends up being a technically similar solution, politically it is radically different. If the Python-expert's answer were instead, "write the slow parts in Pyrex", then the C programmer's plan changes - instead of writing in C, because they know they are going to need to rewrite all the slow parts anyway, they realize that there is an explicitly Python way to rewrite the slow parts, that may leverage SOME of their existing C knowledge. They learn Python and appreciate Python secure in the knowledge that this effort will not be wasted. Finally, there are real benefits to Pyrex when making the transition between levels in your optimized code. All the common areas for mistakes when interfacing with Python - missing refcounts when getting, changing, or deleting attributes, calling Python callbacks, and using basic Python data structures - are all taken care of so that the dive into C is far less abrupt. The people this PR is geared to are those who would write in C because of efficiency concerns, so they would likely be looking at Pyrex before choosing to start a large project, and the simple code examples would be both familiar enough (hey, that's a 32 bit integer! I remember that!) but also different enough (wow, you can just call a script with "foo()"?) that they would be impressed.
At 04:11 PM 12/9/04 -0500, Glyph Lefkowitz wrote:
On Wed, 2004-12-08 at 17:39 -0500, Phillip J. Eby wrote:
The only thing that will fix the PR issue is to have a Python compiler distributed as part of the language. It doesn't matter if it doesn't support the full generality of Python, or even if it doesn't speed many operations up much. The only real requirements are that it can be used to produce "native" executables, and that it be an official part of the language, not a separately-distributed tool like Psyco or Pyrex. Then, it will perhaps be a sufficient "security blanket" to stop people FUDding about it.
I am aware that Pyrex is still in flux, so perhaps it is too soon to propose this even for 2.5, but I think it's worth bringing up anyway: I would like Pyrex to be distributed with the Python core. I agree that it should be modified to produce full .exe files and not just .dlls on Windows, but many potential users *are* seriously concerned about efficiency and not just simplifying distribution.
+1 on all the stuff you said, with one minor exception. Pyrex-the-language is often unpythonically ugly and verbose at present. If Python had an official syntax for optional static type declaration, Pyrex's syntax could be aligned with that, and that would at least eliminate most of the inline 'cdef' ugliness, leaving only C type declarations and Python property declarations as the main syntax issues to be resolved. (Maybe by using something like the 'ctypes' API, and having the compiler recognize that API, such that C is directly callable from Python anyway, so compiling or interpreting Python makes no difference to ability to access C... but I digress.) Of course, this would take some effort from the core developers, especially Guido, to consider the various syntax needs and formulate official solutions. But if it were done, the Python-vs.-Pyrex distinction could fade away altogether, replaced with the meme, "just add type declarations to slow parts, and tell Python you want the module compiled to C." IOW, if Pyrex is merely the name of a compiler, not a separate language, then our master plan for world domination is complete. :)
If I parse you correctly, this would be great. - Michael On Thu, 09 Dec 2004 16:37:59 -0500, Phillip J. Eby <pje@telecommunity.com> wrote:
At 04:11 PM 12/9/04 -0500, Glyph Lefkowitz wrote:
On Wed, 2004-12-08 at 17:39 -0500, Phillip J. Eby wrote:
The only thing that will fix the PR issue is to have a Python compiler distributed as part of the language. It doesn't matter if it doesn't support the full generality of Python, or even if it doesn't speed many operations up much. The only real requirements are that it can be used to produce "native" executables, and that it be an official part of the language, not a separately-distributed tool like Psyco or Pyrex. Then, it will perhaps be a sufficient "security blanket" to stop people FUDding about it.
I am aware that Pyrex is still in flux, so perhaps it is too soon to propose this even for 2.5, but I think it's worth bringing up anyway: I would like Pyrex to be distributed with the Python core. I agree that it should be modified to produce full .exe files and not just .dlls on Windows, but many potential users *are* seriously concerned about efficiency and not just simplifying distribution.
+1 on all the stuff you said, with one minor exception. Pyrex-the-language is often unpythonically ugly and verbose at present. If Python had an official syntax for optional static type declaration, Pyrex's syntax could be aligned with that, and that would at least eliminate most of the inline 'cdef' ugliness, leaving only C type declarations and Python property declarations as the main syntax issues to be resolved. (Maybe by using something like the 'ctypes' API, and having the compiler recognize that API, such that C is directly callable from Python anyway, so compiling or interpreting Python makes no difference to ability to access C... but I digress.)
Of course, this would take some effort from the core developers, especially Guido, to consider the various syntax needs and formulate official solutions. But if it were done, the Python-vs.-Pyrex distinction could fade away altogether, replaced with the meme, "just add type declarations to slow parts, and tell Python you want the module compiled to C."
IOW, if Pyrex is merely the name of a compiler, not a separate language, then our master plan for world domination is complete. :)
_______________________________________________ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/michael.walter%40gmail.com
On Thu, 2004-12-09 at 16:37 -0500, Phillip J. Eby wrote:
+1 on all the stuff you said, with one minor exception. Pyrex-the-language is often unpythonically ugly and verbose at present.
Personally I have no problem with Pyrex's current tradeoffs, but given the amount of effort that this is going to inevitably involve, I'm sure that at least some of the changes you suggested would be necessary. So... +0 on your suggestions, I suppose.
On Wed, 8 Dec 2004, Phillip J. Eby wrote:
At 02:18 PM 12/8/04 -0800, Guido van Rossum wrote:
I was pleasantly surprised to find a pointer to this article in a news digest that the ACM emails me regularly (ACM TechNews).
http://gcn.com/vol1_no1/daily-updates/28026-1.html
One thing that bugs me: the article says 3 or 4 times that Python is slow, each time with a refutation ("but it's so flexible", "but it's fast enough") but still, they sure seem to harp on the point. This is a PR issue that Python needs to fight -- any ideas?
The only thing that will fix the PR issue is to have a Python compiler distributed as part of the language. It doesn't matter if it doesn't
I suspect you're correct, but the suggestion elsewhere to bundle py2exe seems likely to be counterproductive to me: merely emphasizing the "interpreterness" of Python the moment the idea spreads that Python-built .exe's are so big because they're just an interpreter plus a script. I'm sure PyPy, if successful, will be a big win on both PR and technical fronts. On a seperate PR issue, I use the word 'script' above advisedly: At work, I've noticed technical employees of clients who use Java often seem to take some satisfaction in referring to our web applications (which of course, consist of who knows how many packages, modules and classes) as "CGI scripts". We do use CGI, but the CGI scripts themselves are always about five lines long and just contain boilerplate code and configuration to kick off our framework. You can see them imagining a great long script named doeverything.cgi... John
John J Lee wrote:
the idea spreads that Python-built .exe's are so big because they're just an interpreter plus a script.
that's why exemaker is so great, of course: all EXE files are 4 kilobytes. as for the PYC files, hide them in a ZIP archive named DAT, HLP, OCX, or even DLL, and you're done. </F>
Guido van Rossum wrote:
I was pleasantly surprised to find a pointer to this article in a news digest that the ACM emails me regularly (ACM TechNews).
http://gcn.com/vol1_no1/daily-updates/28026-1.html
One thing that bugs me: the article says 3 or 4 times that Python is slow, each time with a refutation ("but it's so flexible", "but it's fast enough") but still, they sure seem to harp on the point. This is a PR issue that Python needs to fight -- any ideas?
In public documents - documentation, release notes, etc etc.: Remove all references to the performance of Python. From now on, Python has always been extremely fast, has no need to get any faster, and any speed increases are of so little importance that they barely rate a mention (no percentage increases mentioned in release notes). If you must mention performance, do it in terms of the use of C modules such as numarray, and for benchmarks that other languages cant compete in. Write a benchmark which uses common C extensions, that Java cant compete with. Replace all references to a 'Python interpreter' with 'Python Virtual Machine' Ensure that the terms 'Python compiler' and 'compiled python' are liberally sprinkled around. Start emphasising the compilation step from python source to python bytecodes instead of making it transparent.
On Wed, Dec 08, 2004 at 02:18:48PM -0800, Guido van Rossum wrote:
This is a PR issue that Python needs to fight -- any ideas?
I'm not good at PR so I will continue to try to make it faster. In my copious free time I plan to: * finish the AST compiler (no performance benefit but makes other things easier) * optimize module namespaces as per the PEPs (whose numbers I cannot recall) * optimize function/method invocation (we must be able to do something better here, they are currently very expensive). Fredrik has mentioned "call-site caching". * write a new, register based VM
[Guido van Rossum Wed, Dec 08, 2004 at 02:18:48PM -0800]
I was pleasantly surprised to find a pointer to this article in a news digest that the ACM emails me regularly (ACM TechNews).
http://gcn.com/vol1_no1/daily-updates/28026-1.html
One thing that bugs me: the article says 3 or 4 times that Python is slow, each time with a refutation ("but it's so flexible", "but it's fast enough") but still, they sure seem to harp on the point. This is a PR issue that Python needs to fight -- any ideas?
What about doing a survey on c.l.py asking questions like: what do you find runs slowly in Python that should run faster? Could you help with some concrete - preferably real life examples with speed problems?". If python-dev takes the time to seriously debate (and debunk :-) upcoming code and suggestions then such a process could be very useful for all sides and also for PR purposes. IMO the biggest PR problem is that python programmers themselves [*] tend to say that Python is slow and it's interesting to find out why they think so, document and discuss the "answers" if any. I am not saying that such questioning/discussion doesn't already happen sometimes. But doing a survey in a more systematic way might let us find out how pervasive the perception of "Python is too slow" really is. Maybe it turns out that not many people have concrete problems to offer? Anyway, this would probably also be interesting for the various alternative Python implementations currently in the works. just an idea, holger [*] For example, something i stumbled upon today: http://unununium.org/articles/languages where it states (without providing any details!): But what about that fast system? Python isn't a slow language; it just has a slow implementation. There are many projects underway to correct this situation: Psyco, PyPy, Starkiller, IronPython, and Parrotcode are among them. It's likely these projects will be nearing completion when the time comes for Unununium to look at optimizations.
Well, for a lot of applications for Python, the performance that really counts is time from no code but a pile of data to code and processed data. Python shines at that because nearly always the time to write the code dominates, so it doesn't matter what the run time is. I wrote a little tool to translate a bunch of free data into scenery for the X-Plane flight simulator. If I'd tried to do it in C, I'd still be debugging it, whereas I released it and the scenery I was building six months ago. The run time of the C version would be, I speculate, about 5 times faster than the Python (given that psyco speeds it up about 8 times, and I would not have been so fancy with the algorithms in C). But a 5x improvement on a 24 hour runtime is not 6 months of improvement. The other thing we can do is finish the portable backend for psyco and make it a standard module. Then Python won't be slow, it will be compiled, and py2exe will be able to make a single-file executable. Andrew On 9/12/2004, at 11:18 AM, Guido van Rossum wrote:
I was pleasantly surprised to find a pointer to this article in a news digest that the ACM emails me regularly (ACM TechNews).
http://gcn.com/vol1_no1/daily-updates/28026-1.html
One thing that bugs me: the article says 3 or 4 times that Python is slow, each time with a refutation ("but it's so flexible", "but it's fast enough") but still, they sure seem to harp on the point. This is a PR issue that Python needs to fight -- any ideas?
-- --Guido van Rossum (home page: http://www.python.org/~guido/) _______________________________________________ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/ andrew%40indranet.co.nz
Hi Andrew, On Thu, Dec 09, 2004 at 03:32:10PM +1300, Andrew McGregor wrote:
The other thing we can do is finish the portable backend for psyco and make it a standard module. Then Python won't be slow, it will be compiled, and py2exe will be able to make a single-file executable.
You probably mean that Psyco can dynamically compile Python bytecodes even if they have been hidden into an .exe file by py2exe. At first reading, it appears that you are propagating the misconception "compiler == speed == .exe" i.e. Psyco could "compile your program into an .exe file". As far as I see, this is definitely not possible. Of course, for PR purposes the difference is small -- an .exe file that runs at compiled speed, or at least machine-level VM speed -- but advertising should work around and not build on top of existing confusion IMHO. A bientot, Armin
>> The other thing we can do is finish the portable backend for psyco >> and make it a standard module. Then Python won't be slow, it will be >> compiled, and py2exe will be able to make a single-file executable. Armin> You probably mean that Psyco can dynamically compile Python Armin> bytecodes even if they have been hidden into an .exe file by Armin> py2exe. I didn't read it that way. My impression was that py2exe be modified to include and enable psyco if it's available when building an .exe. You would, in theory, get a single file distribution as well as dynamic compilation. Skip
Skip Montanaro <skip@pobox.com> writes:
>> The other thing we can do is finish the portable backend for psyco >> and make it a standard module. Then Python won't be slow, it will be >> compiled, and py2exe will be able to make a single-file executable.
Armin> You probably mean that Psyco can dynamically compile Python Armin> bytecodes even if they have been hidden into an .exe file by Armin> py2exe.
I didn't read it that way. My impression was that py2exe be modified to include and enable psyco if it's available when building an .exe. You would, in theory, get a single file distribution as well as dynamic compilation.
I haven't tried it, but using psyco in a script and building an exe from it with py2exe should work right out of the box - but maybe this isn't what you had in mind? And single-file exes with py2exe are on my plan for a medium time range, although currently I'm not really sure which way to go. Thomas
Thomas> I haven't tried it, but using psyco in a script and building an Thomas> exe from it with py2exe should work right out of the box - but Thomas> maybe this isn't what you had in mind? I was thinking of implicitly mixing in psyco, even if the script didn't use it. Maybe I have too much faith in psyco. ;-) Skip
Hi Skip, On Fri, Dec 10, 2004 at 04:49:30AM -0600, Skip Montanaro wrote:
>> The other thing we can do is finish the portable backend for psyco >> and make it a standard module. Then Python won't be slow, it will be >> compiled, and py2exe will be able to make a single-file executable.
Armin> You probably mean that Psyco can dynamically compile Python Armin> bytecodes even if they have been hidden into an .exe file by Armin> py2exe.
I didn't read it that way. My impression was that py2exe be modified to include and enable psyco if it's available when building an .exe. You would, in theory, get a single file distribution as well as dynamic compilation.
Yes, I agree with this. What I meant is that when I first read the original paragraph (the 1st one quoted above), I thought it meant that in the future py2exe and Psyco could be combined in such a way that we'd essentially have a compiler from Python producing a "classical" compiled binary. A lot of people could read it that way. The question is if we should advertise a Psyco+py2exe combination using a similar wording, such that it superficially sounds like we are doing a "classical" compilation from .py to .exe, whereas it actually means that we are hiding Psyco with the bytecodes in a .exe. After all, from a user's (or journalist's) point of view the result is similar, performancewise. Whether Psyco is reliable enough for this is yet another issue... I'd classify Psyco as "mostly reliable" only... A bientot, Armin.
One thing that bugs me: the article says 3 or 4 times that Python is slow, each time with a refutation ("but it's so flexible", "but it's fast enough") but still, they sure seem to harp on the point. This is a PR issue that Python needs to fight -- any ideas?
* Ask a prominent PSF member, ESR, to stop bagging on that point in his book (python is much faster since he wrote it and Moore's law has made it less of an issue over time). Py1.5.2 running on a 133Mhz 386 is not the same beast as well designed Py2.4 code running on a 3Ghz Pentium IV (also I would argue that many apps are computationally bound anyway). * Have python.org prominently feature an article of Python's use in high-performance environments. IIRC, somebody wrote a realtime voice over internet system and found that with good design, there was no speed issue. Also, the cellphone apps may make a good example. * Another prominent developer and PSF member wrote a much publicized, unfavorable log entry basically saying that he was unimpressed with Py2.4. While that log entry was subsequently revised, it did serve as anti-advocacy. Also, my request was denied for better presentation of performance related benchmarks in the widely read What's New document. Right now, it features somewhat unimpressive and misleading pystone results. Were we to show comparative pybench results 2.0 to 2.1 to 2.2 to 2.3 to 2.4, it would become clear that some of the performance concerns are out of date. Parrotbench and test_decimal also reveal some modest gains over 2.3. * A ZDNet reporter had setup a phone interview with me but did not follow through. I had planned to nip the issue in the bud by focusing on the Py2.4's vastly improved scalability: - The trend toward use of iterators, generators, generator expressions, and itertools scale-up well because of their superb memory performance and ability to save state. Apps using generators and genexps save all the time that was formerly lost to accessing instance variables. And apps keying off of itertools can sometimes completely avoid interpreter overhead. IOW, Py2.4 provides a strong toolset for writing clean, high-performance apps with a minimum of development time. - Behind the scenes, almost every important building block has either improved algorithms, memory optimizations, speed optimizations, and/or has been rewritten in C (while still preserving their pure Python equivalents). The bytecodes get optimized for speed and readability, and the eval-loop itself is tighter. Lists initialize, append, pop, and extend much faster and are more conservative with memory. List comps are up to twice as fast. Dictionary iteration is speedier. Sets, bisect, and heaps now have C implementations like other basic building blocks. All of the fifo queues in the library now use an O(1) algorithm instead of O(n) -- this improves scalability for everything from threading and queues to mutexs and asynchat. * Any PR effort should also emphasize that no usability trade-offs were made along the way. A number of features make Py2.4 easier to use than 1.5.6: list comps, genexps, generators, sets, nested scopes, int/long unification, decorators, etc. Some might argue that it takes a modicum effort to learn listcomps, generators, and decorators, but they cannot make any bones about the cleanliness, simplicity, beauty, and speed of the resulting code. Python will always lead in maintainability and development time. * Python's website has traditionally been self-centered, leaving others to have to make the case for their own products. Perhaps, it is time to change that. Those who really care about speed cannot make a balanced decision about Python without considering psyco, pyrex, numpy, and the like as part of the total development environment. * There is another angle that is difficult to present but a reality never-the-less. It is easy to write toy C / C++ code that is blazingly fast. However, when you add error checking, fault tolerance, interaction with real world, etc, the code gets slower. Also because that code is harder to write, it is somewhat common to use crummy algorithms (linear searches for example). I really liked Tim's comment that code using Python's dictionaries runs 10,000 times faster than anything written in any other language. That seems to get to the point across well enough. * A bit of good news is that the upcoming Python cookbook will make a strong case for Py2.4 being a tool of choice for those who care speed, space, maintainability, and development time. It is a nice, highly visible bit of advocacy. * One last thought. Articles will always pick on something. It's not really a terrible thing to have someone say the superb productivity gains come at the price of running slower than C. I would much rather hear that than have people bag on the docs or standard library or launch into a diatribe @decocrator destroying the beauty of the language. Raymond
On Wed, Dec 08, 2004 at 10:55:59PM -0500, Raymond Hettinger wrote:
* Have python.org prominently feature an article of Python's use in high-performance environments. IIRC, somebody wrote a realtime voice over internet system and found that with good design, there was no speed issue. Also, the cellphone apps may make a good example.
+Games.
* Python's website has traditionally been self-centered, leaving others to have to make the case for their own products. Perhaps, it is time to change that. Those who really care about speed cannot make a balanced decision about Python without considering psyco, pyrex, numpy, and the like as part of the total development environment.
That's overreaction, I think. People always say this and that about python - python is slow, and python is not like java, and python does not have static type checks... And what? Should the webmasters adapt the site to every complain? Oleg. -- Oleg Broytmann http://phd.pp.ru/ phd@phd.pp.ru Programmers don't die, they just GOSUB without RETURN.
Oleg Broytmann wrote:
Raymond Hettinger wrote:
* Python's website has traditionally been self-centered, leaving others to have to make the case for their own products. Perhaps, it is time to change that. Those who really care about speed cannot make a balanced decision about Python without considering psyco, pyrex, numpy, and the like as part of the total development environment.
That's overreaction, I think. People always say this and that about python - python is slow, and python is not like java, and python does not have static type checks... And what? Should the webmasters adapt the site to every complain?
Perhaps a link on the main page to a "for even more speed" page where we can combine advice on how to improve application performance (measure, abstract, choose good data structures) with references to these other projects for particular applications. This is the place to say things like "operating on every character of a string is seldom efficient." -- -- Scott David Daniels Scott.Daniels@Acm.Org
On Thu, Dec 09, 2004 at 06:07:41AM -0800, Scott David Daniels wrote:
Oleg Broytmann wrote:
That's overreaction, I think.
Perhaps a link on the main page
Why on the main page? There are Topics Guide at http://python.org/topics/ that describes the ways Python can be used in some popular areas. Let's add another topic, "Making things fast". Let's even make it the first topic, though I personnaly dont see a need for this. Oleg. -- Oleg Broytmann http://phd.pp.ru/ phd@phd.pp.ru Programmers don't die, they just GOSUB without RETURN.
FWIW, I was planning on writing a tutorial (working title: "Making Python Code Not Suck") for some conference or another... talked to a bunch of people last week at OSDC, and it seems like something people are interested in. Got a bunch of stuff already down from various notes I've written in the past when helping coworkers and the like. Anthony -- Anthony Baxter <anthony@interlink.com.au> It's never too late to have a happy childhood.
On Thu, Dec 09, 2004 at 05:11:04PM +0300, Oleg Broytmann wrote:
some popular areas. Let's add another topic, "Making things fast". Let's even make it the first topic, though I personnaly dont see a need for this.
The topic guides are migrating into the Wiki, and there's already a Wiki page about this: http://www.python.org/moin/PythonSpeed --amk
On Fri, Dec 10, 2004 at 02:01:55PM -0500, A.M. Kuchling wrote:
On Thu, Dec 09, 2004 at 05:11:04PM +0300, Oleg Broytmann wrote:
some popular areas. Let's add another topic, "Making things fast". Let's even make it the first topic, though I personnaly dont see a need for this.
The topic guides are migrating into the Wiki, and there's already a Wiki page about this: http://www.python.org/moin/PythonSpeed
Thank you. Actually, I've thought about wiki when I was writing that email, but I was afarid that people who (in my very humble opinion) are overreacting - will not tolerate putting such an important topic into a wiki. My personnal opinion is that a good topic about the speed of Python in the wiki is enough. Oleg. -- Oleg Broytmann http://phd.pp.ru/ phd@phd.pp.ru Programmers don't die, they just GOSUB without RETURN.
On Fri, 10 Dec 2004 14:01:55 -0500, A.M. Kuchling <amk@amk.ca> wrote:
On Thu, Dec 09, 2004 at 05:11:04PM +0300, Oleg Broytmann wrote:
some popular areas. Let's add another topic, "Making things fast". Let's even make it the first topic, though I personnaly dont see a need for this.
The topic guides are migrating into the Wiki, and there's already a Wiki page about this: http://www.python.org/moin/PythonSpeed
The Wiki entry seems to reinforce the impression that bugged Guido to begin with. It provides a bunch of "but ..." explanations about why Python's speed isn't that important. Python is slow, but "speed of development is far more important." If you want to avoid people saying "Python is slow, but ..." you need to give them a different message. "Writing code quickly is crucial in today's marketplace." (whatever, that's not much of a message.) David's dynamic languages whitepaper has more of message, for example. Jeremy
The Wiki entry seems to reinforce the impression that bugged Guido to begin with. It provides a bunch of "but ..." explanations about why Python's speed isn't that important. Python is slow, but "speed of development is far more important."
I felt the same way when reading it. Also, it seemed to embody the political outlook that optimization is sinful. The document could be much more positive, fact based, and informative. Also, the wording seems somewhat outdated. A draft for a new entry is included below. Review and feedback are requested. Raymond Techniques for Improving Performance and Scalability ==================================================== Here are some coding guidelines for applications that demand peek performance (in terms of memory utilization, speed, or scalability). Use the best algorithms and fastest tools ----------------------------------------- . Membership testing with sets and dictionaries is much faster, O(1), than searching sequences, O(n). When testing "a in b", b should be a set or dictionary instead of a list or tuple. . String concatenation is best done with ''.join(seq) which is an O(n) process. In contrast, using the '+' or '+=' operators can result in an O(n**2) process because new strings may be built for each intermediate step. Py2.4 mitigates this issue somewhat; however, ''.join(seq) remains the best practice. . Many tools come in both list form and iterator form (map and itertools.imap, list comprehension and generator expressions, dict.items and dict.iteritems). In general, the iterator forms are more memory friendly and more scalable. They are preferred whenever a real list is not required. . Many core building blocks are coded in optimized C. Applications that take advantage of them can make substantial performance gains. The building blocks include all of the builtin datatypes (lists, tuples, sets, and dictionaries) and extension modules like array, itertools, and collections.deque. . Likewise, the builtin functions run faster than hand-built equivalents. For example, map(operator.add, v1, v2) is faster than map(lambda x,y: x+y, v1, v2). . List comprehensions run a bit faster than equivalent for-loops. . Lists perform well as fixed length arrays and as stacks. For queue applications using pop(0) or insert(0,v)), collections.deque() offers superior O(1) performance because it avoids rebuilding a full list for each insertion or deletion, an O(n) process. . Custom sort ordering is best performed with Py2.4's key= option or with the traditional decorate-sort-undecorate technique. Both approaches call the key function just once per element. In contrast, sort's cmp= option is called many times per element during a sort. For example, sort(key=str.lower) is faster than sort(cmp=lambda a,b: cmp(a.lower(), b.lower())). Take advantage of interpreter optimizations ------------------------------------------- . In functions, local variables are accessed more quickly than global variables, builtins, and attribute lookups. So, it is sometimes worth localizing variable access in inner-loops. For example, the code for random.shuffle() localizes access with the line, random=self.random. That saves the shuffling loop from having to repeatedly lookup self.random. Outside of loops, the gain is minimal and rarely worth it. . The previous recommendation is a generalization of the rule to factor constant expressions out of loops. Also, constant folding should be done manually. Inside loops, write "x=3" instead of "x=1+2". . Function call overhead is large compared to other instructions. Accordingly, it is sometimes worth in-lining code in the middle of a few time-critical loops. . Starting with Py2.3, the interpreter optimizes "while 1" to just a single jump. In contrast "while True" takes several more steps. While the latter is preferred for clarity, time critical code should use the first form. . Multiple assignment is slower than individual assignment. For example "x,y=a,b" is slower than "x=a; y=b". However, multiple assignment is faster for variable swaps. For example, "x,y=y,x" is faster than "t=x; x=y; y=t". . Chained comparisons are faster than using the "and" operator. Write "x < y < z" instead of "x < y and y < z". . A few fast approaches should be considered hacks and reserved for only the most demanding applications. For example, "x and True or False" is faster than "bool(x)". Take advantage of diagnostic tools ---------------------------------- . The hotshot and profile modules help identify performance bottlenecks. . The timeit module offers immediate performance comparisons between alternative approaches to writing individual lines of code. Performance can dictate overall strategy ---------------------------------------- . SAX is typically faster and more memory efficient than DOM approaches to XML. . Threading can improve the response time in applications that would otherwise waste time waiting for I/O. . Select can help minimize the overhead for polling multiple sockets.
Raymond Hettinger wrote:
guidelines for applications that demand peek performance (in terms of memory
Peak performance, perhaps? :) Anyway, it looks pretty good to me, but I have a few additional ideas. Add a section of Caveats (we know they exist - might as well be upfront about it): Caveats -------- . This document is based primarily on the CPython interpreter from www.python.org. However, most of the recommendations should apply to any Python interpreter that supports the mentioned feature. . For small data sets, some of the suggestions will perform more slowly than the approaches they are given as alternatives too. This is due to the fact that those suggestions introduce a little more fixed overhead in order to avoid overhead in processing each data item. The crossover point (where the more scaleable approach begins to show a net performance gain) is generally application specific. Use the diagnostic tools mentioned later to make an informed decision for your application.
Use the best algorithms and fastest tools ----------------------------------------- . Membership testing with sets and dictionaries is much faster, O(1), than searching sequences, O(n). When testing "a in b", b should be a set or dictionary instead of a list or tuple.
Should the bisect module be mentioned? If you have a sorted list already, using bisect may be faster than constructing an intermediate set. Also, you can use bisect if an item's *position* in the list is important. list.index(x) uses a linear search (since it can't assume a sorted list), whereas bisect expects the list to be pre-sorted.
intermediate step. Py2.4 mitigates this issue somewhat; however, ''.join(seq) remains the best practice.
I'd say 'The CPython 2.4 interpreter', rather than just Py2.4.
. List comprehensions run a bit faster than equivalent for-loops.
I'd move this to the next section (the algorithms are the same, but the interpreter can speed up one more than the other)
. Custom sort ordering is best performed with Py2.4's key= option or with the traditional decorate-sort-undecorate technique. Both approaches call the key function just once per element. In contrast, sort's cmp= option is called many times per element during a sort. For example, sort(key=str.lower) is faster than sort(cmp=lambda a,b: cmp(a.lower(), b.lower())).
If sorting is going to be performed repeatedly (e.g. maintaining a list in sorted order), it may be feasible to store the list of keys, rather than regenerating them every time. This also plays nicely with using the bisect module to update the list (as the list of keys is available to determine the correct index for insertion). I can't find a 'sorted list' recipe in the Cookbook, so I might have to create one.
Take advantage of interpreter optimizations ------------------------------------------- [snip]
. Prefer iteration (using for loops, list comprehensions, or generator expressions) over iterables to explicit invocation of .next()
Take advantage of diagnostic tools ----------------------------------
. The hotshot and profile modules help identify performance bottlenecks.
Currently profile is a fair bit more useful than hotshot, mainly due to the fact that it isolates time spent in C functions from the Python code that calls those functions. Perhaps another section for External Libraries? If you're doing serious number crunching in Python, using NumPy is practically a requirement. Cheers, Nick. -- Nick Coghlan | ncoghlan@email.com | Brisbane, Australia --------------------------------------------------------------- http://boredomandlaziness.skystorm.net
. Multiple assignment is slower than individual assignment. For example "x,y=a,b" is slower than "x=a; y=b". However, multiple assignment is faster for variable swaps. For example, "x,y=y,x" is faster than "t=x; x=y; y=t".
marginally faster in 2.4, a lot slower in earlier versions. maybe you should mark sections that rely on 2.4-specific optimizations, so that people who use earlier versions don't end up slowing their programs down... </F>
Raymond Hettinger wrote:
I felt the same way when reading it. Also, it seemed to embody the political outlook that optimization is sinful. The document could be much more positive, fact based, and informative. Also, the wording seems somewhat outdated.
A draft for a new entry is included below. Review and feedback are requested.
I would add a reference to __slots__, particularly for wrappers of objects. Regards, Nicolas
On 2004-12-09, at 15.07, Scott David Daniels wrote:
Oleg Broytmann wrote:
* Python's website has traditionally been self-centered, leaving others to have to make the case for their own products. Perhaps, it is time to change that. Those who really care about speed cannot make a balanced decision about Python without considering psyco, pyrex, numpy, and the like as part of the total development environment. That's overreaction, I think. People always say this and that about
Raymond Hettinger wrote: python - python is slow, and python is not like java, and python does not have static type checks... And what? Should the webmasters adapt the site to every complain?
Perhaps a link on the main page to a "for even more speed" page where we can combine advice on how to improve application performance (measure, abstract, choose good data structures) with references to these other projects for particular applications. This is the place to say things like "operating on every character of a string is seldom efficient."
+1 Many examples of common idioms and tasks and how to do them right in Python would also be useful for such a page. //Simon
Raymond> * Any PR effort should also emphasize that no usability Raymond> trade-offs were made along the way. A number of features Raymond> make Py2.4 easier to use than 1.5.6: list comps, genexps, Raymond> generators, sets, nested scopes, int/long unification, Raymond> decorators, etc. Not to mention which, such beasts aren't commonly available for C. What about C++? I found it interesting that a guy at work wrote a string caching class for our C++ programmers to use. He told me he got the idea from Python's int caching. Skip
On Thursday 09 December 2004 14:55, Raymond Hettinger wrote:
* Have python.org prominently feature an article of Python's use in high-performance environments. IIRC, somebody wrote a realtime voice over internet system and found that with good design, there was no speed issue. Also, the cellphone apps may make a good example.
That was me. I gave a keynote (45 minute) version of the talk last week at OSDC, and I believe it was videoed and will be available eventually. This is good propaganda. Anthony -- Anthony Baxter <anthony@interlink.com.au> It's never too late to have a happy childhood.
On Wed, 8 Dec 2004, Raymond Hettinger wrote:
> > One thing that bugs me: the article says 3 or 4 times that Python is
> > slow, each time with a refutation ("but it's so flexible", "but it's
> > fast enough") but still, they sure seem to harp on the point. This is
> > a PR issue that Python needs to fight -- any ideas?
[...]
> * Have python.org prominently feature an article of Python's use in
> high-performance environments. IIRC, somebody wrote a realtime voice
> over internet system and found that with good design, there was no speed
> issue. Also, the cellphone apps may make a good example.
[...]
IIRC, Alex Martelli mentioned a video application at last year's ACCU /
Python UK conference. He said the system never went into production, but
it sounded like a good meme from the speed point of view: it triggered
surprised and gleeful noises from the mixed Python / C++ / Java audience
;-).
John
On Wed, 8 Dec 2004, Guido van Rossum wrote:
One thing that bugs me: the article says 3 or 4 times that Python is slow, each time with a refutation ("but it's so flexible", "but it's fast enough") but still, they sure seem to harp on the point. This is a PR issue that Python needs to fight -- any ideas?
On PR side of the issue one idea would be to avoid using the words interpreted/intepreter less and use the words compiler/byte-compilation/virtual machine instead... On non-PR side of the issue (I do think that python slowness is a real problem for at least some people/domains): would bundling of Psyco with Python be a good idea? Ilya
Guido van Rossum wrote: [snip]
One thing that bugs me: the article says 3 or 4 times that Python is slow, each time with a refutation ("but it's so flexible", "but it's fast enough") but still, they sure seem to harp on the point. This is a PR issue that Python needs to fight -- any ideas?
One thing you could do is announce loudly that the European Union is actually funding a international consortium of scientists, industry and software engineers to speed up Python (among other things :) -- PyPy. I'm sure that a press release about this in the right channels could make quite a bit of positive noise. "Python, backed by the EU". Of course one worry is that the 'slow bureaucracy' meme would rub off on it. Of course any press release would need to be discussed with the PyPy people. Regards, Martijn
One thing that bugs me: the article says 3 or 4 times that Python is slow, each time with a refutation ("but it's so flexible", "but it's fast enough") but still, they sure seem to harp on the point.
fwiw, IDG's Computer Sweden, "sweden's leading IT-newspaper" has a surprisingly big Python article in their most recent issue: PYTHON FEELS WELL Better performance biggest news in 2.4 and briefly interviews swedish zope-developer Johan Carlsson and Python- Ware co-founder Håkan Karlsson. </F> PS. the heading is a play on the swedish phrase "må pyton", which means "feel like crap"...
Fredrik Lundh wrote: [snip]
fwiw, IDG's Computer Sweden, "sweden's leading IT-newspaper" has a surprisingly big Python article in their most recent issue:
PYTHON FEELS WELL Better performance biggest news in 2.4 [snip]
Perhaps the message getting out is actually that Python's performance is getting better, so nothing to worry about. The original article that Guido cited had a headline along the same lines: "Faster Python grabs programmers". So perhaps there really is nothing to worry about in this department: the headlines are saying "Python now faster". That to me sounds like an excellent way to combat "Python is slow" memes. :) Regards, Martijn
fwiw, IDG's Computer Sweden, "sweden's leading IT-newspaper" has a surprisingly big Python article in their most recent issue:
PYTHON FEELS WELL Better performance biggest news in 2.4
and briefly interviews swedish zope-developer Johan Carlsson and Python- Ware co-founder Håkan Karlsson.
Maybe we've done this to ourselves then. I'm sure the interviewer didn't know what was the biggest news until after Johan and Håkan told him. And this despite all the functional improvements that are much more interesting for most Python programmers: generator expressions, decorators, a ton of new modules... Ah, but several of those modules are rewrites in C of modules that were previously written in Python. Maybe we really *should* stop emphasizing speed so much to ourselves, and focus more on fixing bugs and adding features instead of looking for speedup opportunities. I think Python's message ought to be more something like "programming for the rest of us -- a child can learn Python, but Python's no toy." BTW I strongly disagree that making easy .EXE binaries available will address this issue; while not bundled, there are plenty of solutions for maning .EXEs for those who need them, and this is not something that typically worries managers. But the perception of Python as "slow" does worry managers. (Wish I could add more to this thread but my family is calling...) -- --Guido van Rossum (home page: http://www.python.org/~guido/)
On Sat, Dec 11, 2004 at 08:22:17AM -0800, Guido van Rossum wrote:
But the perception of Python as "slow" does worry managers.
Much more those managers are worried that Python isn't backed by a large corporation. For Java there is Sun, for Visual Basic there is the biggest and most powerful corporation. But who is for Python? Who is responsible? Whom to blame? Oleg. -- Oleg Broytmann http://phd.pp.ru/ phd@phd.pp.ru Programmers don't die, they just GOSUB without RETURN.
At 08:22 AM 12/11/04 -0800, Guido van Rossum wrote:
BTW I strongly disagree that making easy .EXE binaries available will address this issue; while not bundled, there are plenty of solutions for maning .EXEs for those who need them, and this is not something that typically worries managers. But the perception of Python as "slow" does worry managers.
The relevant memes are that "compiled == fast", and that ".exe == compiled". It's not about .exe as a distribution format, but rather that producing an .exe is supporting evidence of having a "real" compiler. IOW, if there exists a compiler, but it doesn't produce .exe's, it won't be considered a "real" compiler by many programmers.
Phillip J. Eby wrote:
At 08:22 AM 12/11/04 -0800, Guido van Rossum wrote:
BTW I strongly disagree that making easy .EXE binaries available will address this issue; while not bundled, there are plenty of solutions for maning .EXEs for those who need them, and this is not something that typically worries managers. But the perception of Python as "slow" does worry managers.
The relevant memes are that "compiled == fast", and that ".exe == compiled".
It's not about .exe as a distribution format, but rather that producing an .exe is supporting evidence of having a "real" compiler.
IOW, if there exists a compiler, but it doesn't produce .exe's, it won't be considered a "real" compiler by many programmers.
This is indeed an extremely common set of memes. It especially haunts people who have done some programming in the past but don't really have it as their main focus now. Many managers would be in this group. It's a PC-platform thing mostly. In the early days of the PC, you had BASIC, and you had compiled languages. Interpreted BASIC was considered to be unprofessional and slow. Distributing your program as a .bas file was considered to be a sign of amateurism. Besides, interpreters on that hardware *were* sometimes unacceptably slow. If you got a compiled .exe it was a sign of performance and more professionalism. Microsoft was quite aware of this meme: they did the trick with Visual Basic (packaging their interpreter in the .exe and called it 'compiled'. The "compiled == fast" meme is also very common among programmers themselves; I know I myself had to wrestle free of it (I didn't care about .exes by that time as I was on linux). That's probably why we have so many Python programmers saying, "well, yeah, Python is not as fast as compiled languages but it's fast enough"; that's the counter meme that replaced the "compilation is good" meme that was there in those people before. It's quite possible that some of these programmers influence managers. Regards, Martijn
Guido van Rossum wrote:
fwiw, IDG's Computer Sweden, "sweden's leading IT-newspaper" has a surprisingly big Python article in their most recent issue:
PYTHON FEELS WELL Better performance biggest news in 2.4
(hmm. I seem to have accidentally deleted a line here...)
and briefly interviews swedish zope-developer Johan Carlsson and Python- Ware co-founder Håkan Karlsson.
Maybe we've done this to ourselves then. I'm sure the interviewer didn't know what was the biggest news until after Johan and Håkan told him. And this despite all the functional improvements that are much more interesting for most Python programmers: generator expressions, decorators, a ton of new modules...
I don't know Johan, but I'm pretty sure Håkan didn't talk about performance; he's more interested in *development* speed... (and I don't think he's been following 2.4 that closely). Looking again, the article says: "Among the news in 2.4 is better performance, especially for new functions that were added in 2.3." and then mentions integer/long integer unification and the decimal type as notable additions, and continues "and so it continues, with a long list of improved details". The article also points to www.python.org/2.4, where the first link is: http://www.python.org/2.4/highlights.html which says: Here are the (subjective) highlights of what's new in Python 2.4. * Faster A number of modules that were added in Python 2.3 (such as sets and heapq) have been recoded in C. In addition, there's been a number of other speedups to the interpreter. (See section 8.1, Optimizations, of the "What's New" document for more [this lists a couple of thousand tweaks by Raymond, and Armin's string concatenation hack]). * New language features /.../ unification of integers and long integers /.../ decimal - a new numeric type that allows for the accurate representation of floating point numbers /.../ so I don't think you can blame Johan or Håkan... the writer simply read the python.org material, and picked a couple of things that he found interesting (decorators and generator expressions may be a big thing for an experienced pythoneer, but they are probably a bit too obscure for a general audience...)
Ah, but several of those modules are rewrites in C of modules that were previously written in Python. Maybe we really *should* stop emphasizing speed so much to ourselves, and focus more on fixing bugs and adding features instead of looking for speedup opportunities.
yes please.
(Wish I could add more to this thread but my family is calling...)
same here. more later. </F>
Fredrik Lundh wrote:
fwiw, IDG's Computer Sweden, "sweden's leading IT-newspaper" has a surprisingly big Python article in their most recent issue:
PYTHON FEELS WELL Better performance biggest news in 2.4
and briefly interviews swedish zope-developer Johan Carlsson and Python- Ware co-founder Håkan Karlsson.
...
so I don't think you can blame Johan or Håkan... the writer simply read the python.org material, and picked a couple of things that he found interesting (decorators and generator expressions may be a big thing for an experienced pythoneer, but they are probably a bit too obscure for a general audience...)
I'm a bit puzzled by the last paragraph, where Python is grouped together with PHP and Perl - names starting with p, being popular on Linux and not having big, commercial backers. The article then concludes "Since Python is copyrighted, it's not truly open. However, it can be freely used and redistributed, even commercially." Huh? Where did THAT come from? You might argue the merits of Python being associated with Perl/PHP, but it's a fact that it is. But when it is, it's seen as less free? Erik
On Sun, 12 Dec 2004 17:10:58 +0100, Erik Heneryd <erik@heneryd.com> wrote:
Fredrik Lundh wrote:
fwiw, IDG's Computer Sweden, "sweden's leading IT-newspaper" has a surprisingly big Python article in their most recent issue:
PYTHON FEELS WELL Better performance biggest news in 2.4
and briefly interviews swedish zope-developer Johan Carlsson and Python- Ware co-founder Håkan Karlsson.
...
so I don't think you can blame Johan or Håkan... the writer simply read the python.org material, and picked a couple of things that he found interesting (decorators and generator expressions may be a big thing for an experienced pythoneer, but they are probably a bit too obscure for a general audience...)
I'm a bit puzzled by the last paragraph, where Python is grouped together with PHP and Perl - names starting with p, being popular on Linux and not having big, commercial backers. The article then concludes "Since Python is copyrighted, it's not truly open. However, it can be freely used and redistributed, even commercially."
Huh? Where did THAT come from? You might argue the merits of Python being associated with Perl/PHP, but it's a fact that it is. But when it is, it's seen as less free?
The author was probably referring to the old (and as AFAIK already solved) CRNI copyright issue that ocurred into the 1.x to 2.x series transition. It's amazing how old memes from Python keep being remembered and repeated, even years after the fact. It also illustrates something very important - the community is not doing a good job at spreading the news; perhaps we talk too much between ourselves, and too little with the outside market. IMHO the website is a great part of this, its message being more important to "sell" Python than the standard library or native .exes. About the website, a note from my own experience: when I search for documentation on Python, I'm usually directed to some of the mirror of the main python.org site. To find it inside the main site, I have to use "site:python.org", or even "site:docs.python.org". Usually Google does a good job at ranking pages, and if it doesn't rank the main Python website very highly, it's because they're not being referred to. A campaign to ask people to put links back to the canonical documentation at the Python website would be nice. -- Carlos Ribeiro Consultoria em Projetos blog: http://rascunhosrotos.blogspot.com blog: http://pythonnotes.blogspot.com mail: carribeiro@gmail.com mail: carribeiro@yahoo.com
Hello all, Just to complement my previous remarks, I would like to point out how do a competing language defines itself in its own website. The perl.org website has a simple faq that is a good piece of marketing. What follows are direct quotes, just to point out how ot handle the market perception about their quality & speed. -- "Perl takes the best features from other languages, such as C, awk, sed, sh, and BASIC, among others." (A claim can't possibly be any more generic than this. Strangely enough, it mentions only older languages -- not Java, C++, or even Python (!). This is possibly a sign of an old quote, but anyway: it has a good marketing effect, specially for non-techies.) -- "Perl can be embedded into web servers to speed up processing by as much as 2000%." (BTW, this quote is embarrassing misleading -- it probably means that Perl is 20x slower when started on a request basis by the web server, and that embedding it will accelerate response by a huge factor. I'm sure non-techies will read it as "Perl is able to accelerate my server 20x!") Of course, the point here is not Perl-bashing. The point here is that we should be able to "sell" Python better than we do now, even without the need to resort to such poor measures. I'm sure the Python community does have good & creative people that can write a good "selling" FAQ for Python, emphasizing the main points of the language. For those who believe that a non-profit project should not do any marketing, a reminder. If the perception about Python is one of a slow language, it's much more difficult to find places where you can use Python. In the long run, many of us may be forced to work with other languages & tools, just because that's where the money is. I personally take it a matter of personal interest, because I know how hard it is to "sell" Python to companies here in Brazil. -- Carlos Ribeiro Consultoria em Projetos blog: http://rascunhosrotos.blogspot.com blog: http://pythonnotes.blogspot.com mail: carribeiro@gmail.com mail: carribeiro@yahoo.com
On Sun, 2004-12-12 at 12:32, Carlos Ribeiro wrote:
For those who believe that a non-profit project should not do any marketing, a reminder. If the perception about Python is one of a slow language, it's much more difficult to find places where you can use Python. In the long run, many of us may be forced to work with other languages & tools, just because that's where the money is. I personally take it a matter of personal interest, because I know how hard it is to "sell" Python to companies here in Brazil.
Actually, there's another problem in the corporate world that has nothing to do with Python's performance (at least not directly). When a manager has to hire 25 programmers for a project they think to themselves, "well, Java programmers are a dime a dozen so I'll have no problem finding warm bodies if we write it in Java. Can I even /find/ 25 Python programmers?" -Barry
On Sun, 12 Dec 2004 20:36:45 -0500, Barry Warsaw <barry@python.org> wrote:
On Sun, 2004-12-12 at 12:32, Carlos Ribeiro wrote:
For those who believe that a non-profit project should not do any marketing, a reminder. If the perception about Python is one of a slow language, it's much more difficult to find places where you can use Python. In the long run, many of us may be forced to work with other languages & tools, just because that's where the money is. I personally take it a matter of personal interest, because I know how hard it is to "sell" Python to companies here in Brazil.
Actually, there's another problem in the corporate world that has nothing to do with Python's performance (at least not directly). When a manager has to hire 25 programmers for a project they think to themselves, "well, Java programmers are a dime a dozen so I'll have no problem finding warm bodies if we write it in Java. Can I even /find/ 25 Python programmers?"
You're right, specially for big corporations. But in the end, we're just running in circles: it's hard to get new programmers to learn Python, partly because it's in low demand, and partly because the language has an totally undeserved fame of being slow. That's right - when I talk to fellow programmers that I'm writing software in Python, many of them are amazed and ask me, "but isn't it slow?". I've heard it more than once... having some place that I could point them out so they could check it for themselves (perhaps "www.pythonspeed.com"?) would be *great*. IMHO, Python performance is not an issue 99% of the time. I swear I can say the same about C++. The difference between C++ and Python is not how fast they are relatively to each other, but *where* the slow part is. Anyone who tried to write complex code in any other language knows that most programmers usually resort to slow but easy to implement algorithms for things such as sorting, list handling, etc; these parts of the code are naturally fast in Python, while others may be faster in C++... so we're just trading "6 for half a dozen", as we say in portuguese :-) -- Carlos Ribeiro Consultoria em Projetos blog: http://rascunhosrotos.blogspot.com blog: http://pythonnotes.blogspot.com mail: carribeiro@gmail.com mail: carribeiro@yahoo.com
On Mon, 13 Dec 2004, Carlos Ribeiro wrote:
On Sun, 12 Dec 2004 20:36:45 -0500, Barry Warsaw <barry@python.org> wrote:
Actually, there's another problem in the corporate world that has nothing to do with Python's performance (at least not directly). When a manager has to hire 25 programmers for a project they think to themselves, "well, Java programmers are a dime a dozen so I'll have no problem finding warm bodies if we write it in Java. Can I even /find/ 25 Python programmers?"
You're right, specially for big corporations. But in the end, we're just running in circles: it's hard to get new programmers to learn Python, partly because it's in low demand, and partly because the language has an totally undeserved fame of being slow.
The perception-of-speed issue is clearly important but we're definately not running in circles. There are quite a few signs that the Python user base is expanding substantially. For example, a September article in InfoWorld said "But the big winner this time around is the object-oriented scripting language Python, which saw a 6 percent gain in popularity, almost doubling last year's results." http://www.infoworld.com/article/04/09/24/39FErrdev_1.html?s=feature Also, there are companies that have hundreds of Python programmers, like some of those that have done success stories: http://www.pythonology.org/success That doesn't mean the perception that you can't hire 25 at once isn't a problem, but clearly some companies know that turning someone into a Python programmer is easy enough to offset the smaller available pool. To counter speed claims, look at articles like this one: http://www.pythonology.org/success&story=suzanne "Python helps AFNIC manage over 10,000 internet domain name registration requests per minute in a landrush for the ".fr" top-level internet domain" Yes it would be nice to have more of these, where performance is mentioned in the summary! Please contact me if you can contribute one. BTW, I can't resist my own favorite speed anecdote: I once wrote a one-off script to process down a couple of gigabytes of variously fragmented web logs into month-by-month files. I thought I was being naive doing f.readline() in a for loop with some date parsing code for each entry. But I was completely astounded how fast it processed -- and it just worked the first time around. - Stephan
On Mon, 13 Dec 2004 11:30:45 -0500 (EST), Stephan Deibel <sdeibel@wingware.com> wrote:
For example, a September article in InfoWorld said "But the big winner this time around is the object-oriented scripting language Python, which saw a 6 percent gain in popularity, almost doubling last year's results."
http://www.infoworld.com/article/04/09/24/39FErrdev_1.html?s=feature
Can we extrapolate from the numbers here to get an estimate of how many Python developers there are? I was asked for that number at workshop a few months ago and I didn't have any idea how to answer. Is there a good answer? Two possibilities come to mind. 1) 14% of developers in the survey work at companies that use Python. How many developers are there? Assume that 14% of them use Python. But what's a good estimate for "number of developers." Pretty rough -- number of survey respondents at company != number of Python programmers at company, and %age companies != %age of programmers. 2) 64% of companies use Java, 4.5 times more than Python. Find out how many Java programmers there are, divide by 4.5. Jeremy
On Mon, 13 Dec 2004, Jeremy Hylton wrote:
http://www.infoworld.com/article/04/09/24/39FErrdev_1.html?s=feature
Can we extrapolate from the numbers here to get an estimate of how many Python developers there are? I was asked for that number at workshop a few months ago and I didn't have any idea how to answer. Is there a good answer?
Two possibilities come to mind. 1) 14% of developers in the survey work at companies that use Python. How many developers are there? Assume that 14% of them use Python. But what's a good estimate for "number of developers." Pretty rough -- number of survey respondents at company != number of Python programmers at company, and %age companies != %age of programmers.
Supposedly there are 5-6 million developers world-wide (by various estimates; I've no idea whether to believe them). If you just multiply out naively you get 700K-840K Python programmers. There certainly are vastly more one person Python projects than large ones, so this may not be all that far off.
2) 64% of companies use Java, 4.5 times more than Python. Find out how many Java programmers there are, divide by 4.5.
I've seen claims of 3-4 million java programmers so that's 666K-888K Python programmers. Interestingly, this matches up with the above abuse of statistics. Independently by various other techniques of wildly guesstimating over the years, I've come to a current figure of about 350K serious Python projects world-wide. Many are single-person projects so this does mesh w/in an order of magnitude with the above. - Stephan
On Mon, 13 Dec 2004 13:11:38 -0500 (EST), Stephan Deibel <sdeibel@wingware.com> wrote:
On Mon, 13 Dec 2004, Jeremy Hylton wrote:
Two possibilities come to mind. 1) 14% of developers in the survey work at companies that use Python. How many developers are there? Assume that 14% of them use Python. But what's a good estimate for "number of developers." Pretty rough -- number of survey respondents at company != number of Python programmers at company, and %age companies != %age of programmers.
Supposedly there are 5-6 million developers world-wide (by various estimates; I've no idea whether to believe them). If you just multiply out naively you get 700K-840K Python programmers. There certainly are vastly more one person Python projects than large ones, so this may not be all that far off.
2) 64% of companies use Java, 4.5 times more than Python. Find out how many Java programmers there are, divide by 4.5.
I've seen claims of 3-4 million java programmers so that's 666K-888K Python programmers. Interestingly, this matches up with the above abuse of statistics.
Thanks! I didn't know the numbers from which to guestimate, and it's nice that they are in agreement. This seems like a satisfactory back-of-the-envelope answer. Jeremy
Stephan Deibel wrote:
BTW, I can't resist my own favorite speed anecdote: I once wrote a one-off script to process down a couple of gigabytes of variously fragmented web logs into month-by-month files. I thought I was being naive doing f.readline() in a for loop with some date parsing code for each entry. But I was completely astounded how fast it processed -- and it just worked the first time around.
I was doing the same thing today (well, processing system logs, not web logs) and was completely baffled when I found that a program that just worked the first time around on our development machine, crashed with a MemoryError on the production machine. oh well. </F>
That's right - when I talk to fellow programmers that I'm writing software in Python, many of them are amazed and ask me, "but isn't it slow?". I've heard it more than once...
I heard it last month. In the last couple of months, an acquaintance of mine has been trying out Python. He likes the language, particularly the support for character sets, but has (apparently) given up after benchmarking a typical (for him) task against Perl. The task is to use the "re" package to heavily modify a file by a sequence of re substitutions. Apparently the Python program, which applies the same re substitutions in the same order as the Perl program, takes 3 times as long to run. He thinks it's because of mutable strings in Perl -- that is, he thinks the string being modified (which is long, a whole file full of text) is modified in place in Perl, but has to be re-consed in Python. Bill
On Sun, Dec 12, 2004 at 03:32:03PM -0200, Carlos Ribeiro wrote:
Of course, the point here is not Perl-bashing. The point here is that we should be able to "sell" Python better than we do now, even without the need to resort to such poor measures. I'm sure the Python community does have good & creative people that can write a good "selling" FAQ for Python, emphasizing the main points of the language.
No one disagrees that Python needs better marketing material. At the last PyCon a group of people sat down in a pydotorg BoF and agreed that yes, we do need a management-friendly marketing site, and that we could put it on a separate hostname (something.python.org) so that the current www.python.org wouldn't have to be changed. However, no one has actually sat down and written such a site, or even outlined it. Let me encourage you to go ahead and do that. You could draft the outline on a Wiki page, and then later figure out an attractive design and organization for a new site. --amk
we should be able to "sell" Python better than we do now, even without the need to resort to such poor measures. I'm sure the Python community does have good & creative people that can write a good "selling" FAQ for Python, emphasizing the main points of the language.
No one disagrees that Python needs better marketing material. At the last PyCon a group of people sat down in a pydotorg BoF and agreed that yes, we do need a management-friendly marketing site, and that we could put it on a separate hostname (something.python.org) so that the current www.python.org wouldn't have to be changed.
However, no one has actually sat down and written such a site, or even outlined it. Let me encourage you to go ahead and do that. You could draft the outline on a Wiki page, and then later figure out an attractive design and organization for a new site.
suggested hostname: why.python.org
On Tue, Dec 14, 2004 at 10:21:58PM -0800, Gregory P. Smith wrote:
suggested hostname: why.python.org
It's only a matter of taste, probably, but that looks a bit ugly for my eyes. May be use.python.org? corp.python.org? Oleg. -- Oleg Broytmann http://phd.pp.ru/ phd@phd.pp.ru Programmers don't die, they just GOSUB without RETURN.
Oleg Broytmann wrote:
On Tue, Dec 14, 2004 at 10:21:58PM -0800, Gregory P. Smith wrote:
suggested hostname: why.python.org
It's only a matter of taste, probably, but that looks a bit ugly for my eyes. May be use.python.org? corp.python.org?
about.python.org? And if someone ends up playing with the DNS server, maybe they could add wiki.python.org while they're at it :) Cheers, Nick. -- Nick Coghlan | ncoghlan@email.com | Brisbane, Australia --------------------------------------------------------------- http://boredomandlaziness.skystorm.net
On Wed, 2004-12-15 at 07:32, Nick Coghlan wrote:
about.python.org?
And if someone ends up playing with the DNS server, maybe they could add wiki.python.org while they're at it :)
DNS changes have to go through pydotorg at python.org, since Thomas is the person currently able to add host names. -Barry
For a subsite aimed at businesses, business.python.org is obvious and easily remembered. Not all businesses are corporations. 'about' and 'why' are not specific at all. I think such a subsite, linked from the main site also, would be a good idea. It should explain both why (including success stories) and how (including employment/contracting) to use Python in business. Pieces could come from the existing site. I think the mere existence of such a site would constitute a message to businesses that Python is ready for business. I suspect the existence of even a skeletal site would attract contributions to build it further. Correspondingly, perhaps there should also be a science(or scitech or learning).python.org with pages on Astronomy, Bioscience, Chemistry, Mathematics, Education, etc. Perhaps the scipy and other science application groups would help. With two subsites for the main application areas, this would leave www.python.org to focus on the language itself. Terry J. Reedy
Ummm... I don't think that anyone looks for information by trolling subdomain names. If I am looking for python information, I go to www.python.org or python.org. I would never guess "business.python.org". Seems to me that what we need is content and let the search engines bring on the masses. On Wed, 15 Dec 2004, Terry Reedy wrote:
For a subsite aimed at businesses, business.python.org is obvious and easily remembered. Not all businesses are corporations. 'about' and 'why' are not specific at all.
I think such a subsite, linked from the main site also, would be a good idea. It should explain both why (including success stories) and how (including employment/contracting) to use Python in business. Pieces could come from the existing site.
I think the mere existence of such a site would constitute a message to businesses that Python is ready for business. I suspect the existence of even a skeletal site would attract contributions to build it further.
Correspondingly, perhaps there should also be a science(or scitech or learning).python.org with pages on Astronomy, Bioscience, Chemistry, Mathematics, Education, etc. Perhaps the scipy and other science application groups would help.
With two subsites for the main application areas, this would leave www.python.org to focus on the language itself.
Terry J. Reedy
_______________________________________________ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/allison%40sumeru.stanford....
On Tue, Dec 14, 2004, Gregory P. Smith wrote:
Attribution deleted:
No one disagrees that Python needs better marketing material. At the last PyCon a group of people sat down in a pydotorg BoF and agreed that yes, we do need a management-friendly marketing site, and that we could put it on a separate hostname (something.python.org) so that the current www.python.org wouldn't have to be changed.
However, no one has actually sat down and written such a site, or even outlined it. Let me encourage you to go ahead and do that. You could draft the outline on a Wiki page, and then later figure out an attractive design and organization for a new site.
suggested hostname: why.python.org
This is where the process always gets bogged down. :-( Once we have material, that's the time to start arguing about where it should go. -- Aahz (aahz@pythoncraft.com) <*> http://www.pythoncraft.com/ "19. A language that doesn't affect the way you think about programming, is not worth knowing." --Alan Perlis
On Wed, 15 Dec 2004, Aahz wrote:
On Tue, Dec 14, 2004, Gregory P. Smith wrote:
Attribution deleted:
No one disagrees that Python needs better marketing material. At the last PyCon a group of people sat down in a pydotorg BoF and agreed that yes, we do need a management-friendly marketing site, and that we could put it on a separate hostname (something.python.org) so that the current www.python.org wouldn't have to be changed.
However, no one has actually sat down and written such a site, or even outlined it. Let me encourage you to go ahead and do that. You could draft the outline on a Wiki page, and then later figure out an attractive design and organization for a new site.
suggested hostname: why.python.org
This is where the process always gets bogged down. :-( Once we have material, that's the time to start arguing about where it should go.
Absolutely. Content first, details later. Incidentally, I keep offering: Anyone that actually takes this on should feel free to rip off content from http://wingware.com/python -- I'm not saying this is the best content or the most complete but it's a start anyway (I wrote it in case that wasn't clear ;-) Incidentally, if someone does get excited about working on this, check with me or another PSF board member. - Stephan
A.M. Kuchling wrote:
On Sun, Dec 12, 2004 at 03:32:03PM -0200, Carlos Ribeiro wrote:
Of course, the point here is not Perl-bashing. The point here is that we should be able to "sell" Python better than we do now, even without the need to resort to such poor measures. I'm sure the Python community does have good & creative people that can write a good "selling" FAQ for Python, emphasizing the main points of the language.
No one disagrees that Python needs better marketing material. At the last PyCon a group of people sat down in a pydotorg BoF and agreed that yes, we do need a management-friendly marketing site, and that we could put it on a separate hostname (something.python.org) so that the current www.python.org wouldn't have to be changed.
However, no one has actually sat down and written such a site, or even outlined it. Let me encourage you to go ahead and do that. You could draft the outline on a Wiki page, and then later figure out an attractive design and organization for a new site.
Whatever it looks like, it should probably run on Zope plus Plone. 8-) You know... eat your own dog food. 8-) The kind folks over at Zettai! have provided some space for me. Perhaps they will be glad to host the main Python site, as well? -- \/ \/ (O O) -- --------------------oOOo~(_)~oOOo---------------------------------------- Keith Dart <kdart@kdart.com> vcard: <http://www.kdart.com/~kdart/kdart.vcf> public key: ID: F3D288E4 URL: <http://www.kdart.com/~kdart/public.key> ============================================================================
Keith Dart <kdart@kdart.com> writes:
A.M. Kuchling wrote:
On Sun, Dec 12, 2004 at 03:32:03PM -0200, Carlos Ribeiro wrote:
Of course, the point here is not Perl-bashing. The point here is that we should be able to "sell" Python better than we do now, even without the need to resort to such poor measures. I'm sure the Python community does have good & creative people that can write a good "selling" FAQ for Python, emphasizing the main points of the language. No one disagrees that Python needs better marketing material. At the last PyCon a group of people sat down in a pydotorg BoF and agreed that yes, we do need a management-friendly marketing site, and that we could put it on a separate hostname (something.python.org) so that the current www.python.org wouldn't have to be changed. However, no one has actually sat down and written such a site, or even outlined it. Let me encourage you to go ahead and do that. You could draft the outline on a Wiki page, and then later figure out an attractive design and organization for a new site.
Whatever it looks like, it should probably run on Zope plus Plone. 8-) You know... eat your own dog food. 8-)
This is SO not the problem that needs discussion...
The kind folks over at Zettai! have provided some space for me. Perhaps they will be glad to host the main Python site, as well?
Neither is this! Cheers, mwh -- Just point your web browser at http://www.python.org/search/ and look for "program", "doesn't", "work", or "my". Whenever you find someone else whose program didn't work, don't do what they did. Repeat as needed. -- Tim Peters, on python-help, 16 Jun 1998
On Wed, Dec 08, 2004 at 02:18:48PM -0800, Guido van Rossum wrote:
I was pleasantly surprised to find a pointer to this article in a news digest that the ACM emails me regularly (ACM TechNews).
http://gcn.com/vol1_no1/daily-updates/28026-1.html
One thing that bugs me: the article says 3 or 4 times that Python is slow, each time with a refutation ("but it's so flexible", "but it's fast enough") but still, they sure seem to harp on the point. This is a PR issue that Python needs to fight -- any ideas?
All high level dynamic languages need to fight this. Substitute python for perl, php, ruby, tcl and the statements in that article still apply. They'll all have slower execution times (on avg) their compiled or JITed bretheren. I suggest reading that article in a different light: The point of view of the people who are likely to believe what they read in government computer news is that it just confirmed that python is a useful languange for getting the job done easily. Not that one shouldn't use it because "its slow." -- All new Python 2.4, now with blue crystals!
[ Guido van Rossum <gvanrossum@gmail.com> ] ----------------------------------------------- | One thing that bugs me: the article says 3 or 4 times that Python is | slow, each time with a refutation ("but it's so flexible", "but it's | fast enough") but still, they sure seem to harp on the point. That reminds me of this joke: """Couple of guys find themselves being chased by a lion. The first one starts to strecth out preparing to run, the second one finds that ridicule. - No way you'll run faster than that lion. While, the other replies: - I don't need to run faster than the lion, I just need to run faster than you. """ I love to see Python getting faster and faster. Eventually (if...when PyPy succedes) faster-than-C ! But after over 4 years of making-ends-meet with Python, our Brazilian customers never complained of our Python solutions being slow. Perhaps because they were glad enough with projects delivered 5 to 10 times faster than usual. But, but to the joke: I believe Python must strive to run at least as fast as the crowd -- Java, Perl, Ruby, Lua, Boo, etc Maybe we could visit the language shootout sites, translate Python snipets to modern 2.4 idioms and rerun the test suites: http://www.bagley.org/~doug/shootout/ # classic http://shootout.alioth.debian.org/ # modern My 2 cents. best regards, Senra -- ,_ | ) Rodrigo Senra <rsenra |at| acm.org> |(______ ----------------------------------------------- _( (|__|] GPr Sistemas http://www.gpr.com.br _ | (|___|] IC - Unicamp http://www.ic.unicamp.br/~921234 ___ (|__|] L___(|_|] -----------------------------------------------
On Tue, 14 Dec 2004 01:05:09 -0200, Rodrigo Dias Arruda Senra <rsenra@acm.org> wrote:
But, but to the joke: I believe Python must strive to run at least as fast as the crowd -- Java, Perl, Ruby, Lua, Boo, etc
Maybe we could visit the language shootout sites, translate Python snipets to modern 2.4 idioms and rerun the test suites:
Bill Janssen <janssen@parc.com> wrote:
In the last couple of months, an acquaintance of mine has been trying out Python. He likes the language, particularly the support for character sets, but has (apparently) given up after benchmarking a typical (for him) task against Perl. The task is to use the "re" package to heavily modify a file by a sequence of re substitutions.
That might be a good idiom to review/translate/test. It's not a particularly natural thing to do in Python (REs are used much less in Python), but it's *very* natural in Perl, and a naive Perl->Python translation will make Python look slower. So a case study showing how you might "really" do a task like this in Python would be a useful resource. Also, it might point to somewhere where there are opportunities for optimisation within Python (for some reason this reminds me of the mutable byte buffer discussions from a while back). Paul
Guido van Rossum wrote:
I was pleasantly surprised to find a pointer to this article in a news digest that the ACM emails me regularly (ACM TechNews).
http://gcn.com/vol1_no1/daily-updates/28026-1.html
One thing that bugs me: the article says 3 or 4 times that Python is slow, each time with a refutation ("but it's so flexible", "but it's fast enough") but still, they sure seem to harp on the point. This is a PR issue that Python needs to fight -- any ideas?
I think that right now there is a promising ongoing happening that may be useful for this PR problem and Python perception in general, which is the Chandler project, because it's a piece of software that may end up in front of lot of people. It is both an opportunity and a risk. A not great success of Chandler especially if imputed to Python shortcomings would be bad. I think that people with long-time Python experience that feel like to contribute should try. A successful, responsive Chandler, I think, would be a good thing for Python.
participants (42)
-
A.M. Kuchling -
Aahz -
Andrew McGregor -
Anthony Baxter -
Armin Rigo -
Barry Warsaw -
Bill Janssen -
Bob Ippolito -
Carlos Ribeiro -
damien morton -
Dennis Allison -
Erik Heneryd -
Fredrik Lundh -
Gareth McCaughan -
Glyph Lefkowitz -
Gregory P. Smith -
Guido van Rossum -
hpk＠trillke.net -
Ilya Sandler -
James Y Knight -
Jeremy Hylton -
John J Lee -
Keith Dart -
Martijn Faassen -
Michael Hudson -
Michael Walter -
Neil Schemenauer -
Nick Coghlan -
Nicolas Fleury -
Oleg Broytmann -
Paul Moore -
Phillip J. Eby -
Raymond Hettinger -
Rodrigo Dias Arruda Senra -
Samuele Pedroni -
Scott David Daniels -
Simon Percivall -
Skip Montanaro -
Stelios Xanthakis -
Stephan Deibel -
Terry Reedy -
Thomas Heller