Talk:Python (programming language)/Archive 2

Archive 1

Archive 2

Archive 3

Archive 4

Archive 5

Discussion about Python Disadvantages

Why is it that the Python article doesn't go into detail about the idiosyncrasies, caveats, and disadvantages of using Python? The Critism Section of the Java article is rather well thought out, it would be nice to see something similar for Python. This would be especially useful for people deciding whether to use Java or Python. Some aspects that I would like to see put in:

• Necessity of tab delimited source
• Lack of consistant naming conventions in API
• Strong typing for types, but weak declarations for function arguments
• Not as widely adopted as other mainstream languages

Note: This is coming from predominantly a Java programmer. I don't quite have the "pythonic" mindset down so I've brought this over to the discussion page to not litter the main article. Overall I think it's a great language, I just think we'd do it more justice to evaluate disadvantages also.

I am strongly against the addition of such a section. This is not a "weigh the benefits" general article, but an encyclopedia description. The facts mentioned about Python are already indicated in the main text, there is nothing but POV added by lumping them into a "disadvantages" section (or similarly into an "advantages" section). Obviously, e.g., we need to mention that Python uses the off-side rule (which we do), but commenting on whether doing so is good or bad is not encyclopedic. Lulu of the Lotus-Eaters 18:40, 20 December 2005 (UTC)

There are already implicit mentionings of advantages and disadvantages throughout the entire article. I thought maybe a summary would be good. Your suggestion of a Computer Languages Compare article might be a better place for it. Seeing as though this article is already quite long I can give up arguing for another section. On a side note, maybe the Syntax section could be trimed, with references to the offical documentation for examples perhaps. That would shorten the article significantly yet not strip out any knowledge.--PittGac 19:56, 20 December 2005 (UTC)

Being an enthusiastic Pythonista (and Zopista) myself, I also agree that a Disadvantages section would be useful. I somehow felt "proud" that such an extensive article on Python didn't point out disadvantages as clearly as the articles on Java, UML, CMM and elsewhere do. Wikipedia is usually clear and concise, and "implicit mentionings" may not be as clear for newcomers. For the list proposed above, I would claim that the "whitespace issue" stops being an issue soon; and the gained readability makes the effort worth. On the other side, I would add the lack of software development tools (though this is slowly changing).Speaking of "Zopistas", I am a bit surprised Zope is not mentioned at all..-Freakin Capuccino Junkie

I have not edited (or even read) the Java, UML, or CMM articles. But if they have "disadvantages" sections, I feel that weakens those articles. It's just too much POV. None of the suggested points are unambiguously advantages or disadvantages. The "whitespace thing" is an advantage if you like it, a disadvantage if you dislike it. The lack of a formal API naming system is either (a) promoting confusion and inconsistency or (b) enhancing flexibility and rapid development. Weak declarations either (a) break encapsulation and error catching or (b) enable duck typing and powerful reuse. The relatively limited degree of use means either that its hard to find programmers or that Python has a tightly focussed developer community. And so on for just about anything you might name. It's good if you like it, and bad if you don't like it. Even the "Python warts" are argued to be great features by other users. Lulu of the Lotus-Eaters 18:51, 22 December 2005 (UTC)

The disadvantages section in Java programming language seems to be supported by negative comments from many famous people (Paul Graham, Bjarne Stroustrup). Is there such criticism to Python? I have never seen it. Maybe there are, objectively, no great disadvantages. ;-) (things noted above are, from a different POV, advantages) I think the greatest disadvantages at the moment are interpreter global lock and lack of good optimizing (or JIT) compiler. Samohyl Jan 19:48, 22 December 2005 (UTC)

What's ungood about Psyco as a JIT compiler? I'd agree the the GIL is a simple disadvantage. I tend to be on the side of it not being all that important, but I can't argue that is is an advantage (it probably is in terms of the clean design of the runtime itself, but not for programmers using Python). But one slightly obscure issue isn't exactly enough for a section. Lulu of the Lotus-Eaters 20:01, 22 December 2005 (UTC)

I admit I have not tried Psyco, but it must be used with care and it's not some sort of automated solution. I have more hope in PyPy, it does type inference, which I think is neccessary to get good performance. My impression (I may be wrong) is that Java or Smalltalk have better compilers, so then Python is at disadvantage. Samohyl Jan 20:27, 22 December 2005 (UTC)

Try Psyco, it's amazing! In an early version you needed to tweak the optimization of each function; but now you can just add two lines to the top of any script, and it figures out where to do the magic (at a moderate memory cost). That's just as automated as a Java JIT. Not everything is improved by Psyco, but the things that tend to be slowest, like tight numeric loops over large data sets can easily go 10x as fast. All with two lines of code enabling the JIT. I might agree that it would be nicer if Python itself shipped with Psyco, and allowed a "-psyco" switch rather than needing those two lines in the code itself. But as disadvantages go, it's thin. The breakages with Psyco are very few, and none in Python code itself, but only (rarely) in interfacing with 3rd party extension modules written in C. Lulu of the Lotus-Eaters 20:44, 22 December 2005 (UTC)

Thanks, that's nice to hear. BTW: Article doesn't mention Psyco at all. Samohyl Jan 06:36, 23 December 2005 (UTC)

I just took a look at the Java article, and its "criticisms" section. Per my initial intuition, I indeed feel that that article is worse for having that section. Many of the same points might be incorporated into the main flow, but as-is it reads like an uneasy concession to Java-disliking editors, rather than as a seamless description of the language. I'm not saying that makes the Java article bad overall, but it's somewhat less good than it might be without that conceit... not something we should strive to emulate here. Lulu of the Lotus-Eaters 20:09, 22 December 2005 (UTC)

I looked at Ruby (programming language) also, which is probably closest to the same ecological niche as Python, as well as similar in design concepts. There is no criticisms/disadvantages section there, though there is a "Possible surprises". That has things like "boolean values are strict" (i.e. 0 and "" are true values, only false or nil are not). Something like that is worth mentioning, but as with the things we've mentioned here, they are either advantages or disadvantages, depending on your own preference (didn't Guido even once suggest that Python3000 might use strict booleans? In any case, design choices are not "disadvantages"). Lulu of the Lotus-Eaters 20:23, 22 December 2005 (UTC)

About PyPy

A recent edit inserted an unencyclopedic disparagement of PyPy. Something to the effect that it "wanted to be faster than C, but that's absurd." The comment is not phrased appropriately, in any case, but as background, such a goal is actually not absurd. I'm not saying it will be accomplished, but it is not impossible in principle.

PyPy builds on the work in Psyco, which is a nice project. Specifically, Psyco can (and does) dynamically build machine code for execution of particular code paths and type constraints. Specializations can be quite highly optimized, and some of this optimization is only available at runtime, not during a static compilation (such as in a C program).

To take a small example, suppose you need to loop over a list of "thingamagigs"—e.g. a bunch of PyObject structures. A C program dealing with those structures would need to test some structure members during each pass through the loop, then branch to different actions based on those members; say do something different with a float, int, and string that were wrapped in a PyObject structure. Pscyo—and by extension PyPy—might be able to determine that during the next million passes through the loop, the structure always holds an int, and therefore skip the dereferencing and branching steps for those million passes. In other words, the specialization goes faster than the "generic" C code, based on state that can only be determined at runtime.

It may not work this way often enough to actually get "faster than C", but the possibility exists conceptually. Lulu of the Lotus-Eaters 17:31, 2005 May 22 (UTC)

It was most likely not intended to be a disparaging comment. "Rumors have it that the secret goal is being faster-than-C which is nonsense, isn't it?" is part of PyPy's tagline, and can be found on the website. Fredrik | talk 10:33, 24 May 2005 (UTC)

Actually, I did see the updated PyPy page w/ the tagline after I made the change. In that context, it's humorous on Armin's (or maybe Christian's) part. However WP readers won't get that it is a self-deprecating joke, as opposed to just a deprecation. I would be OK with it if someone wanted to put "Whose tagline is: '...faster-than-C which is nonsense'". But that's probably a digression from the Python page, and better moved to the Psyco page. Lulu of the Lotus-Eaters 17:55, 2005 May 24 (UTC)

I wouldn't call it self-deprecating. Rather provocative. Fredrik | talk 18:26, 24 May 2005 (UTC)

Category:Monty Python

Are u sure this article is in proper categories? Liso 10:20, 24 May 2005 (UTC)

Maybe, maybe not. Python was named after Monty Python. Eric B. and Rakim 08:35, 15 Jun 2005 (UTC)

Dive into Python broken link

What's the story with someone(s) reinserting the broken and redundant link to Dive into Python. It's a fine book, but there's already an external link to it. Why the extra link to a removed Wiki page, without even putting the link into the grammatical context of the reference? Lulu of the Lotus-Eaters 06:17, 2005 Jun 7 (UTC)

• The page was not removed. The link was not broken - the page was incorrectly marked as being in violation of copyright. All steps to remedy the situation have already been taken and it now only awaits admin action to remove the bogus copyright violation edit done by Xcali. Removing the link was premature, you should have waited until the copyright issue was resolved. John Elder 18:44, 7 Jun 2005 (UTC)

Well, OK... but at least put the link into the grammatical context of the reference. As is, it sits as an ugly non-sentence after the actual description (and external link), and looks like some weird typo. Lulu of the Lotus-Eaters 20:45, 2005 Jun 7 (UTC)

I'll fix it, but please stop deleting it! John Elder 00:07, 8 Jun 2005 (UTC)

I did not delete it! I moved the Wiki link into the main body text, with the external link following that. Your (JohnElder) revision duplicated the Wiki link twice within the bullet. However, I changed it again to more closely match your desire for a separate sentence mentioning the Wiki link (and I made all the references into real sentences instead of dangling clauses). However, if the copyright matter on the WP page isn't resolved pretty soon, we should remove the Wiki link. I have no opinion on the copyright on that page... in fact, I've never even seen the page with anything except the copyright notice; but if it's OK, it's good to link to. Lulu of the Lotus-Eaters 02:09, 2005 Jun 8 (UTC)

Resolving copyright dispute

I'm sorry - I should have paid more attention to the diff. My bad - but go easy on me, I'm new at this. How does one resolve a copyright issue? I've taken all the steps that the message tells me to, but nothing seems to change. Am I supposed to revert the page myself? I've even rewritten it (the original had room for improvement) on the Dive into Python/Temp page ... I don't know what to do next.

I'm afraid I don't know the answer about fixing the copyright question. I've never dealt with that issue. I think I take it from your comment that you posted a review or summary that you had written of Pilgrim's book, then someone noticed you had also posted your review elsewhere, and thought that was suspicious. Is that the sequence? Maybe whoever challenged the copyright release of the page is familiar with the rules for proving it's released properly; you could try their talk page for clarification (I'm sure it's buried somewhere in the WP administrative documents too, but I don't know where). Lulu of the Lotus-Eaters 12:15, 2005 Jun 8 (UTC)

Tabs as whitespace removal?!

The idea of eliminating tabs for indentation has been floating around the Python community for at least 7 years. But it's never happened yet, nor been pronounced for the future by the BDFL anywhere I've seen. Does the editor who added it to the article have some specific evidence of this? Lulu of the Lotus-Eaters 15:46, 2005 Jun 10 (UTC)

I thought I had read it in Python In A Nutshell, but am unable to find it now. My appologies for not going back to my sources before editing. It won't happen again. --Flatline 14:59, 2005 Jun 13 (UTC)

Pythonistas

1. I ran across this little gem, How to Think Like a Pythonista. I don't think it necessarily merits inclusion, but it's a great discussion of a common n00b problem - one that still bites me a few times. Is it worth working into this page, linking to, or just leaving it alone?
2. The Pythonista page is a redirect to the Python programming language page. Why not define pythonista on its own page? If not, then this page shouldn't have any links to Pythonista. It's very annoying to click on a link only to get redirected to the page where you started!

• I'm willing to make these changes, but I'd like to get some other opinions before I start messing with something as well done as this. John Elder 00:37, 16 Jun 2005 (UTC)

I think Pythonista would be great as a separate entry. I was thinking of making it, but haven't got around to it. There's not a whole lot to put there, but at least a definition and a redirect back to Python programming language. Lulu of the Lotus-Eaters 02:08, 2005 Jun 16 (UTC)

Supported Platforms: Mac OS

This is "Mac Classic" rather than "Mac OS" for a reason. "Mac OS" includes the two disjoint subsets "Classic" and "Mac OS X". "Mac OS X" has already been listed as one of the most popular platforms Python runs on; now "Mac Classic" is listed as another platform it runs on. OK?

No. Classic is the compatibility environment within Mac OS X. There is no such thing as Mac OS Classic. There is Mac OS 9, Mac OS 8, etc. Please check the name in http://www.apple.com before inventing new names :)

Mac Classic is not an official name, no. However, it is a name widely used to refer collectively to those versions of the Macintosh OS prior to Mac OS X, something you might have discovered if you had checked what "Mac Classic" linked to before you altered the link. Care to correct the mistaken impression the passage now gives? -- Antaeus Feldspar 21:37, 25 Jun 2005 (UTC)

I would not use a widely used mistake here - only the official names. About older version then Mac OS 9, I don't know if they are supported. As far as I know, Python support Mac OS 9, and even that support is not complete or was problematic. Anyway, if older version are supported, we can use "Mac OS 9 (with some support for older versions)" or similar text. --Nir Soffer 07:18, 26 Jun 2005 (UTC)

Python IDEs and editors

I remove the sentence about the MacPython IDE, which was wrong. It belong to a section about IDEs and editors, if we need one. --Nir Soffer 07:36, 26 Jun 2005 (UTC)

using multi-line strings to comment out blocks

I removed the talk about this, its not important or interesting, and also not very effective. There is not much point in this kind of info in this page. The page is already too long, see the note when you edit the page.

Agreed on the first point; disagreed on the second.

Using multi-line strings as dummied-up comments has never been common practice among Python programmers or recommended in Python documentation or teaching materials. It is a bad practice, abusing a piece of program syntax to serve as a nonsyntactic element (a comment).

However, please do not take the Wikimedia software's length warnings as being normative. My understanding is that they were put in for the benefit of older, broken versions of Internet Explorer which were not capable of editing an HTML TEXTAREA larger than 32k. This has not been an issue for quite some time. Last I checked there was no consensus that 32k specified a reasonable limit for high-quality Wikipedia articles; many of our featured articles are longer. --FOo 6 July 2005 06:46 (UTC)

Continuations gone from Stackless Python

I wish to mention that Stackless Python has not supported continuations since early 2002, as I explain in Talk:Stackless_Python. Maybe Section 6, Other Features should be updated. --Lenard Lindstrom 18:47, 24 July 2005 (UTC)

I removed the mention. --Piet Delport 11:03, 7 March 2006 (UTC)

The size is not only a technical limit, see Wikipedia:Article_size.

Immutable Strings in java and .Net and comparisons to other languages in general

While it is true that both java and .Net have immutable String classes, I don't think it is worth mentioning in the context of the base types section, in the interest of keeping the article length down. Could I also suggest that comparisons to other languages are kept to languages that have share a lineage with python, at least when discussing specific language features? --Kenliu 20:32, 30 August 2005 (UTC)

I tend to agree with this. Additionally in support, there's always a selectivity about which languages serve as the comparisons (with people picking their couple "favorites" as the analogues). But a lot of languages that aren't listed also have immutable strings (or whatever other feature might be stated to be shared between Python and X). If some feature is truly rare, the comparison might be merited, since we could pretty much complete the list; for example, pretty much only Python and Haskell, among general programming languages, use the "offside rule". Lulu of the Lotus-Eaters 20:50, 2005 August 30 (UTC)

I agree. I thought about reverting the mention, but I wasn't sure and didn't thought it is a significant enough change to warrant an edit war. Btw, what is "offside rule"? Samohyl Jan 20:58, 30 August 2005 (UTC)

Read the Python article :-). Actually, I guess the article spells it off-side rule. Basically, it just means "the whitespace thing". Lulu of the Lotus-Eaters 21:57, 2005 August 30 (UTC)

Oh, I am silly. But I swear, I know Python... Thanks, Samohyl Jan 22:17, 30 August 2005 (UTC)

Believe me, I thought it would be stupid to start an edit war over something as trivial as this, but someone has to draw the line in the sand before someone goes off and starts comparing python to VB and PHP. (although python vs. ruby might be interesting). Besides, .NET isn't even a language, right? --Kenliu 19:01, 31 August 2005 (UTC)

I have decided to remove all other comparisons. Python page is long, and it's maybe better to compare the language features on the pages about each feature (that's why links are here for). But I won't enforce this. Btw, a good recent comparison of Python and Ruby is [1]. Samohyl Jan 20:37, 31 August 2005 (UTC)

At first, I thought this was too radical a change. But I've since reconsidered. It's worthwhile to let the language stand on its own. Good idea! --FOo 23:40, 31 August 2005 (UTC)

I would suggest reverting some of the edits that discuss language features that were directly influenced by other languages, such as list comprehensions from Haskell. Perhaps an alternative would be to discuss Python's lineage in the history section, or to add another section discussing comparisons with other languages in general. For instance, I think it would be useful for a WP reader to know that Python is often compared to perl, and now ruby. --Kenliu 11:46, 1 September 2005 (UTC)

As I said above, I think that Haskell influence is quite well elaborated on list comprehension. Why have any comparisons at all, shouldn't there be a list of features and link to these articles enough for reader? If there are n languages with some feature, then having comparisons on language pages means having n comparisons, instead of one, would the comparison be on the page about the feature. As for the fact that Python is compared to Perl and Ruby, it's in the leader, so maybe interested reader could read these articles as well and make his own opinion? But as I said above, you are free to change whatever you want. Samohyl Jan 14:50, 1 September 2005 (UTC)

I agree with Samohyl that features like this are pretty well discussed on linked pages, and the Python page is cleaner if it just provides the link. If you think the discussion on list comprehension misses something important, just add that content/discussion there.

However, what I think would be valuable would be a general Comparisons of programming language features page. As I have it in my mind, this would list maybe a dozen widely used or widely known programming languages, and have a checklist of various things that are true or false (or vary among more than two possibilities) for each language. Probably that page would be primarily tabular.

I think such tables should avoid contentious or complicated "features" like "Is easy to use" or "Runs at full native speed". Those are subjective and context-dependent. But you might have something like:

                 Python   Haskell     Perl   C/C++   Java   Pascal      Ruby    ...
 Block marking:  Offside  Offside/{}  {}     {}      {}     begin/end   begin/end,{}
 List compr      Yes      Yes         No*     No     No     No          No*
 ...
 [*] Code-blocks fill a similar role to listcomps in this language

If we had that, Python, along with various other languages, could each link to such a page. Lulu of the Lotus-Eaters 17:01, 2005 September 1 (UTC)

I think it is worthwhile to discuss the influence of other languages on the design of Python. I now think that this information is best left in the history section rather than cluttering up the rest of the article. I'll have to do some more research and add it later. The chart showing language comparisons is a good idea; however, I think you will have problems keeping the list of languages short - and there will undoubtedly be some debate about which languages to include in the chart. --Kenliu 13:45, 2 September 2005 (UTC)

There wouldn't be any need to keep it short, I think. If 8-10 columns would fit comfortably, we could simply copy the whole table with a new set of headers to add more languages to the matrix. If editors had info on more than those initial 10 languages, the several tables might be arranged by some principle (scripting vs. compiled? OOP vs. functional vs. imperative? decade of creation?), and each subtable could contain all in one type. It's true that you don't get as easy of a side-by-side for some comparisons with multiple tables, but I think that's livable. Lulu of the Lotus-Eaters 17:49, 2005 September 2 (UTC)

Tweaks to python.org links

I've made a couple of changes to the Web references section that I hope aren't stepping on any toes, but if anyone disagrees I'll put my rationale here and we can discuss:

• Sublist for python.org links - I agree that these are useful to hightlight the wiki and doc page. I've never seen a second-level list used for this in WP, but I think it's clearer so that someone who's already scoured python.org and is looking for other sites can easily jump to non-python.org links. Ditto Vaults of Parnassus.

• Removal of past doc versions - I don't see that this merits highlighting. /doc is useful to everyone who cares about Python; /doc/versions.html probably isn't, and for those who do care it's linked fairly conspicuously from /doc.

• Addition of Cheese Shop - This is a very important python.org subdivision so I think it bears emphasis.

• Move of wiki to top of sublist - I think giving other subject-matter wikis emphasis, when such wikis are active and informative, is a good idea.

• Move of wiki page PythonSpeed/PerformanceTips - I'm not crazy about listing this among all the possible wiki pages, but someone thought it merited inclusion so that's fine. However, I moved it to be with the wiki. Thought about making a third-level list, but with only one item that seemed overkill.

Please let me know of any disagreement. Thanks, PhilipR 14:48, 23 September 2005 (UTC)

Removal of functional builtins?

An editor added this text:

Guido van Rossum has stated that the next major release of Python will no longer support functional programming constructs such as lambda, map, filter or reduce, the rationale being that map and filter are equivalent to list comprehensions in power, lambda is irrelevant with the advent of nested functions, and that reduce is incomprehensible to the majority of programmers who do not have a functional programming background.

However, this idea of removing lambda/map/filter/reduce has been floating around since at least Python 1.5.2. It's always been suggested as something that "many people would like", but I have never seen an actual pronouncement on this (except in the hypothetical context of the great, incompatible, Python 3000; that's a half joking way to talk about some distant future).

If the editor can provide a citation to a specific statment by GvR, I'm fine with including that. Otherwise, it's just speculation. Lulu of the Lotus-Eaters 05:49, 29 September 2005 (UTC)

Please consult the link I added to the External links section. Straight from the BDFL's mouth. Jogloran 08:50, 29 September 2005 (UTC)

• The project that the moniker Python 3000 stands for may be dead, but the article indicates that his is a contemporary opinion.
• I've included the text back in, changing the verb to suggested - a little bit less affirmative than before. I've also included an inline reference, although as Jogloran noted, the reference was provided at the bottom of the page. Also, I note that this article is getting a little long, and would benefit from using a good system of footnoting: Wikipedia:Footnote3. Enochlau 09:11, 29 September 2005 (UTC)

Python 3000 is everything but dead. There's been plenty of discussion and updates to PEP 3000 in the last few months. Fredrik | talk 10:54, 29 September 2005 (UTC)

About map, filter and reduce: The article states that Python 3000 "will not support" them, but i'm pretty sure the official plan has always been merely to remove them from the builtin namespace, not from the language entirely. In other words, they're being moved to the standard library, which is very different to what the article is suggesting.

Also, the reason given for the lambda syntax's deprecation ("lambda is irrelevant with the advent of nested functions") sounds entirely non-sensical to me: the advent of nested scopes affected lambda and def functions equally (both map to the same underlying implementation, anyway). Instead, the reason lies primarily with the fact that the syntax is ugly and unpythonic, and/or limited to a single expression (depending on who you ask).

I think the general feeling is that if a good syntax for anonymous functions is found, it will replace lambda, possibly before Python 3000, even. (Compare this situation to the conditional expression syntax that was recently decided upon, after being kicked around for years in online discussion.)

--Piet Delport 10:53, 27 January 2006 (UTC)

Update: Guido has more or less officially given up on finding a replacement syntax for lambda; PEP 3000 has already been updated. --Piet Delport 13:05, 28 February 2006 (UTC)

Page size

This article is in need of shortening. I can think of a couple of segments that could (and should) be trimmed, but there is also much useful detail that definitely can't be removed. Clearly, at least one daughter article needs to be created. One on Python syntax might be a good idea. And maybe another page on semantics, the object system, idioms, or some combination thereof... but I'm not sure how it should be named and focused. List of Python software is obvious, though. Thoughts? Fredrik | talk 21:19, 29 September 2005 (UTC)

There's some unnecessary detail in the Collection types section, in Comments and docstrings, possibly the whole erroneous example in Closures, and possibly some of the links. We need to remember that we are not writing a tutorial to teach Python .... --FOo 23:13, 29 September 2005 (UTC)

I think most of the syntax section should be moved to Python syntax, analogically to C syntax. Karol 23:18, 29 September 2005 (UTC)

I Think that it should stay in Wikibooks: Python -Epl18 8 January 2006 (UTC)

I think that the list of things that use python software should be deleted, or at least moved. Doing this would shorten the length by a lot. Epl18 20:41, 8 January 2006 (UTC)

I agree. The "Software written in Python" list can be moved to a separate article, or possibly be replaced with a link to an directory of Python software on the internet (anyone know of one?). Personally, i don't see the usefulness of the exhaustive "Supported platforms" list (as opposed to a link to somewhere on python.org), and wouldn't miss it. --Piet Delport 12:26, 9 January 2006 (UTC)

I don't agree with removing the python usage section. Okay, maybe we don't need a long list full of bullets; but a couple of examples would be nice. This should be a section that non-programmers understand as well.

It was not removed. It was refactored to a sibling article, with prominent links back and forth between the two. If you'd like to expand upon Python software or provide more narrative context, that would be great. But splitting pages as they grow is just part of the normal flow of editing. Lulu of the Lotus-Eaters 19:09, 25 January 2006 (UTC)

The section on syntax, on the other hand, should get its own article. That is something one is only interested in if you're specifically looking for it. It should not be in the main article. Of course, there could be a shorter section explaining e.g. the indentation stuff and how it is different from other languages, something anyone could understand. No examples please, nothing technical. That would be for the syntax article.--Michaël 16:14, 25 January 2006 (UTC)

I don't think it would be bad to have another sibling/child for syntax. But what we present now about syntax is pretty short, and doesn't really seem to merit an article as-is. Still, if you planned on expanding it considerably, refactoring in that manner might make sense (but get some other opinions on this talk page before you do it). Lulu of the Lotus-Eaters 19:09, 25 January 2006 (UTC)

Minor vanity

Pythonistas who are WP editors might be interested in Wikipedia:Articles for deletion/David Mertz. Yeah, that's me under a non-Wikipedia name; but I think my noteriety is most significant in the Python community. Folks who know (of) me could "do me a solid".

Btw. While we're at it, we could really use articles Tim Peters (computer guy), Alex Martelli, Mark Pilgrim, Fredrik Lundh, Uche Ogbuji, Cameron Laird, and others whom I'm forgetting just now. Lulu of the Lotus-Eaters 06:03, 10 October 2005 (UTC)

Should pywikipedia be mentioned?

I saw that the link to the Python wikipedia bot was kept before on the grounds it's not just a self-reference. However: if we weren't editing Wikipedia right now, would we care at all that pywikipedia existed? Why not include, for example, IRC bots written in Python?

pywikipedia, when you come down to it, is just another tool that's written in Python. on the level of many thousands of others. It doesn't even have a Debian package. I can't see any motivation to include it in this article besides the self-reference.

RSpeer 17:45, 11 October 2005 (UTC)

The Python interface to CVS is mentioned as a Python tool. That would probably have been a better analogy for me to make in the edit history than Google was, since it's about interfacing with a computer service, rather than the service itself being written in Python. Even as a dedicated Pythonista, I've never used pywikipedia myself (nor PyCVS, for that matter). But strictly from a Python perspective, I find it informative that people have written these interface tools to well-known servers. I know, of course, that WP is a particular site, and CVS a type of server, but I think the concepts are still close; at this point, more people might use WP than CVS, given newer revision control systems.

P.S. I have no idea what the state of Python interfaces to IRC are. But if any are well developed and widely used, yeah, we should mention them. Lulu of the Lotus-Eaters 18:21, 11 October 2005 (UTC)

I partially glossed over Rspeer's comment, specifically about no Debian package for pywikipedia. Admittedly knowing little about the tool, maybe I have the wrong impression. If it really is a very "in-house" type thing, it's inclusion is less obvious (not excluded, Google's use is "in-house" too, but interesting). How many people actually do anything with pywikipedia? How important is what it does? I'll defer to other editors on the answer, and whether to remove it. Lulu of the Lotus-Eaters 18:31, 11 October 2005 (UTC)

Shouldn't a little more on class notation be presented?

First of all, my congratulations for the Pythonists for such an interesting and enlightening article about Python.

I'm considering to extend the text on the object-oriented side of Python to include the class notation. Some comparisons of Python's features with the ones from C++ and Java may help enlight the newcomer to Python.

I'm afraid the article will become a little too long. Should a new article be started to discuss this ?

Regards, --Hgfernan 17:31, 15 October 2005 (UTC)

As Lulu of the lotus eaters suggests above, that would fit into a comparison if one is made. I think its also mentioned in wikibooks:Python_Classes. Epl18 20:52, 8 January 2006 (UTC)

About Python use in videogames

I've added reference to Vampire: The Masquerade - Bloodlines which uses python for scripting. Because the game is based on Valve's Source engine used in Half-Life 2, I'm not sure if this is specific to the Vampire game, or is it part of the engine. If someone knows the latter is true, please change my addition to reference the engine instead of the mentioned game. --Arny 03:46, 23 October 2005 (UTC)

Text editors/IDEs

I would rather avoid listing text editors in this already over-long article. It's extremely peripheral to the topic of Python as a programming language that some particular text editor (or IDE, inasmuch as there is a difference) happens to have some bindings to customize it for Python. In most cases, editors likewise have bindings for many other languages. Some other article on "programming editors" or the like would be a more appropriate place to list such things. Lulu of the Lotus-Eaters 03:29, 26 October 2005 (UTC)

Section "Logical operators" incomprehensible

The section "Logical operators" is hard to understand to me. I'm new to Python though I know a handful of other languages quite well. I'll check back once I know Python better. Benni B. 00:43, 20 November 2005 (UTC)

It is far too technical for an encyclopedia article. The enumeration of false values, for instance, is entirely inappropriate here -- it's sufficient to say that all zero numeric values are false, without listing every possible zero literal! If I weren't in a rush I'd pare it down right now. --FOo 05:04, 20 November 2005 (UTC)

Project links

I was trying to trim the section on projects that use Python, especially now that there's a spam warning. I think game systems are overrepresented, so I wanted to leave what seemed to be the most notable examples. OpenRPG only has a stub for a Wikipedia article. Solipsis sounds highly experimental and not used yet. So those are the ones I took out. Was I wrong? rspeer 18:54, 23 November 2005 (UTC)