Talk:Python (programming language)/Archive 4

message: We seem to be attracting a bit more of it lately.  I think the longstanding editors of this article (and new ones) should keep a particular eye for authors of commercial publications (or their advocates) trying to use the article as a means of free advertising.  I got an email from Atanas Radenski who appears to be the author of some commercial training materials called "Python First", and who tried to add such a link, and responded as below:
On 8/17/06, Radenski, Atanas <radenski@chapman.edu> wrote:
> Why do you delete my entry on Python First? It is commercial 
> is a sense but all book references that are still there are at 
> least as commercial as well. Can you help me understand your criteria?
It is commercial linkspam, exactly as my edit comment indicates.  All
the other materials listed are (or should be) freely available (at
very least free-of-cost; usually also free for reuse).  Wikipedia is
an encyclopedia, not a billboard.
> I just got an email by someone who tries to prove that the whole 
> Python project is commercial.
I can't account for what nonsense you might get in email, but Python
is and always has been a Free Software project. --David
Anyway, while Radenski's work is strongly on the commercial side of "commercial links", he also pointed out that we had an existing link to Python Programming for the Absolute Beginner, which is just an ad for a commercially available book.  The latter is slightly less "commercial" in the sense it's a regular book with an ISBN that is available from many book sellers.  But I think to be clear on the no-advertising standard, we should remove any links that are strictly to non-free texts... at very least things that are free-as-in-beer to everone: Radenski also later pointed out that "educators" might get special qualification for gratis instructor copies of his materials, but that's way shy of a URL to click on to read the material.  Still, I can perfectly easily get gratis review copies of pretty much any programming book I want, about as easily as I can order it from Amazon, so limited-purpose gratis fails to wow me (I'm somewhat special in that regard; I turn down a lot more such free-or-cost stuff than I accept). LotLE×talk 02:05, 18 August 2006 (UTC)
replies: text: For what it's worth, the relevant policy guide is over here:  Wikipedia:External links.  --Piet Delport 13:34, 19 August 2006 (UTC)
thread_title:  Commercial linkspam 

message: I'm not a big fan of this line:
"Python is notable amongst current popular high-level languages for having a philosophy that emphasizes the importance of the programmer over the importance of the computer (so that, for example, code is slower but easier to understand)"
Yes, Python can be slower at times than another language, but this statement suggests that it's just a slow language altogether. It certainly doesn't seem like a fair thing to say when you are introducing the language. Newcomers might see that, misunderstand, and move on before really understanding what is meant by "slow."
=== New speed section ===
I'm not particularly happy with the section called "speed" that an editor added.  In the main, it seems to be too much in the advocacy direction, but it also has a bit of an WP:OR-ish feel too it ("a common criticism"?)  We're not arguing the pros and cons of Python, but simply presenting its facts.  The fact it is an interpretive language is prominently stated already, and its neither the fastest nor the slowest interpreted language (overall it is on the fast end of them, I believe; but certainly not dramatically better than a number of others).  And explaining approaches to optimization might be too far into either advocacy or tutorial.
On the other hand, it seems possible to me that several speed issues might be addressed—very concisely—as part of Python's philosophy.  I.e. it's probably fast enough now, so don't optimize unless there is a specific problem.  If you do optimize, first profile.  After you profile, select one or more of: (a) improve algorithms; (b) improve data structures; (c) did we mention (a) and (b)?; (d) look for libraries that exist to do special tasks quickly; (e) run the program with Psyco (if you have an x86-ish platform); (f) rewrite some performance-critical part of code with Pyrex; (g) rewrite some criticial code with SWIG/C or other non-Python wrapped language. LotLE×talk 02:30, 27 August 2006 (UTC)
replies: text: I agree completely. This is part of my comment below. --JStalk 04:26, 30 August 2006 (UTC)
replies: text: My thinking behind the "Speed" section was that since people seem to criticize Python because of it, it's worth mentioning that that is a criticism, and the fact that there are methods of dealing with it. Could it be reworded to remove the "advocacy" aspect? As for the "original research," I don't know how that would be dealt with other than finding some Impressive Authority that accuses Python of slowness. Is it better to omit the issue entirely, or find some way of saying "this is kind of a problem but Python fans say it's not major?" --Kris Schnee 19:59, 5 September 2006 (UTC)
replies: text: Have you read the current version? If so, what do you see as missing? LotLE×talk 20:02, 5 September 2006 (UTC)

text: The currently live quote marked as needing a citation "Speed is not a problem until it is a problem" should go.  While I like the sentiment I've never seen that particular quote on comp.lang.python or python-dev.  A search of google, groups.google, and gmane.org turns up squat.  Jack Diederich, Jan 10 17:58:03 EST 2007 —The preceding unsigned comment was added by 216.41.15.170 (talk) 22:57, 10 January 2007 (UTC)
thread_title:  Calling Python slow? 

message: I'm not particularly happy with the section called "speed" that an editor added.  In the main, it seems to be too much in the advocacy direction, but it also has a bit of an WP:OR-ish feel too it ("a common criticism"?)  We're not arguing the pros and cons of Python, but simply presenting its facts.  The fact it is an interpretive language is prominently stated already, and its neither the fastest nor the slowest interpreted language (overall it is on the fast end of them, I believe; but certainly not dramatically better than a number of others).  And explaining approaches to optimization might be too far into either advocacy or tutorial.
On the other hand, it seems possible to me that several speed issues might be addressed—very concisely—as part of Python's philosophy.  I.e. it's probably fast enough now, so don't optimize unless there is a specific problem.  If you do optimize, first profile.  After you profile, select one or more of: (a) improve algorithms; (b) improve data structures; (c) did we mention (a) and (b)?; (d) look for libraries that exist to do special tasks quickly; (e) run the program with Psyco (if you have an x86-ish platform); (f) rewrite some performance-critical part of code with Pyrex; (g) rewrite some criticial code with SWIG/C or other non-Python wrapped language. LotLE×talk 02:30, 27 August 2006 (UTC)
replies: text: I agree completely. This is part of my comment below. --JStalk 04:26, 30 August 2006 (UTC)
replies: text: My thinking behind the "Speed" section was that since people seem to criticize Python because of it, it's worth mentioning that that is a criticism, and the fact that there are methods of dealing with it. Could it be reworded to remove the "advocacy" aspect? As for the "original research," I don't know how that would be dealt with other than finding some Impressive Authority that accuses Python of slowness. Is it better to omit the issue entirely, or find some way of saying "this is kind of a problem but Python fans say it's not major?" --Kris Schnee 19:59, 5 September 2006 (UTC)
replies: text: Have you read the current version? If so, what do you see as missing? LotLE×talk 20:02, 5 September 2006 (UTC)

text: The currently live quote marked as needing a citation "Speed is not a problem until it is a problem" should go.  While I like the sentiment I've never seen that particular quote on comp.lang.python or python-dev.  A search of google, groups.google, and gmane.org turns up squat.  Jack Diederich, Jan 10 17:58:03 EST 2007 —The preceding unsigned comment was added by 216.41.15.170 (talk) 22:57, 10 January 2007 (UTC)
thread_title:  New speed section 

message: Python programming language → Python (programming language) – Conformance with WP naming conventions LotLE×talk 22:27, 1 September 2006 (UTC)
thread_title: Requested move

message: Since us Pythonistas are in here at the forefront of programming (and since it was discussed here early), I figured I'd go ahead with the needed move, per the rough consensus at Wikipedia talk:WikiProject Programming languages/Renaming poll.  I suspect that even though there will be rough consensus for the general move, the safest thing will be to start with the languages that have no objecting editors, and move on to the hold-outs a bit more slowly.  It looks like a few of the C folks are overly influenced by K&R's book, for example. LotLE×talk 15:18, 5 September 2006 (UTC)
replies: text: Do you mind fixing archived talk pages 1 and 2? They're still attached to the old name. I've piped them temporarily. Chris Cunningham 10:32, 1 October 2006 (UTC)
thread_title:  Ahead of the curve 

message: Anyone care to give a quick sketch of what this means in plain English? If not, it would appear to warrant removal. Comments? Thanks! dr.ef.tymac 00:02, 22 December 2006 (UTC)
replies: text: If you look at languages like BCPL and the C programming language, you had text books showing the kind of instruction sequences that corresponded to the languages statements. Several of their compiler allowed the mixing of assembler statements in with the higher level programming constructs too. Datatypes were much more directly tied to the datatypes of the underlying machine code, (bytes, words).Forth and some varieties of BASIC similarly 'close to the metal'. Pythons has many datatypes such as object, dict, list, tuple, set, string, that are at a higher level of abstraction than what is directly handled by an assembler, and have methods that are easier for the programmer to understand and use. --Paddy 02:56, 22 December 2006 (UTC)
replies: text: Needs re-wording for clarity: Your summary makes sense, now the issue is how to reword the current phrasing so it conveys the issue more clearly. The current phrasing is close to meaningless. dr.ef.tymac 03:23, 22 December 2006 (UTC)

text:  I have just re-read , which shows some of the concerns that do drive Python language features, but you are right. the phrase from the article isn't right. --Paddy 08:53, 22 December 2006 (UTC)
thread_title:  emphasizes programmer effort over computer effort 

message: Should we also add PEP 0020, AKA the zen of Python? It's a little easter egg, shown if you type 
 import this
in python. --Roelt 17:08, 5 January 2007 (UTC)
thread_title:  Python Humor 

message: In the Python 1 section, there is the sentence "CNRI and the FSF interacted to develop enabling wording changes to the Python's free software license that would make it GPL-compatible.". The "develop enabling wording changes" bit seems oddly worded. It seems that "enabling" is redundant, but I'd like confirmation, or some indication of enabling means in this context if not. Silverfish 10:52, 9 January 2007 (UTC)
replies: text: It's bureaucratic bafflegab, but what's clearly meant is that the FSF and the Python copyright holders had a chat, and the Python copyright holders decided to change the license to make it GPL-compatible. --FOo 20:41, 9 January 2007 (UTC)
replies: text: I've delved a bit further, and it looks like the wording (as well as some other content in this article, is taken from the Python 2.0.1 license  (and subsequence licenses, the same or similar wording is in the Python 2.5 License). Silverfish 00:18, 10 January 2007 (UTC)
thread_title:  Odd Wording 

message: While python does indeed come with "batteries included", the image Python_batteries_included.jpg doesn't really communicate anything and looks somewhat amateur. That image, which was originally on www.python.org, is no longer displayed there (at least I couldn't find it). I propose that we also remove the image from this page. Comments?   Chrike 03:58, 26 January 2007 (UTC)
thread_title:  Image: Python comes with "batteries included" 

message: How is PEP a unique aspect of Python? As far as I know, many communities has similar processes. It's already described elsewhere in the article, so perhaps it should be removed from that particular section? Debolaz 21:20, 27 January 2007 (UTC)
replies: text: I'd be fine with that.  I put the PEP thing back in the "unique aspects" section, but had overlooked its earlier mention.  I think the first mention of PEPs is adequate to cover the concept (it's a little different from other programming communities, but not that different). LotLE×talk 22:53, 27 January 2007 (UTC)
replies: text: I believe that PEPs influenced tcl's community to do something similar (TEPs?), so, perversely, a mention may now be appropriate under the new header namings. 88.111.227.171 15:35, 28 January 2007 (UTC)
replies: text: I would be ok with that. Debolaz 23:00, 28 January 2007 (UTC)
thread_title:  PEP