Talk:Python (programming language)

POV issues

There's a whole bunch of statements in this article that are dubious from a POV perspective, and some which are probably unverifiable. Most of them are vague peacock praise for Python that doesn't provide any actual evidence. I'm grouping the whole lot under POV because it comes down to people not being sufficiently careful about writing in a neutral style. It needs careful triage and editing, and would probably benefit from attention by editors who are not programmers at all and knows nothing about python (most of this is not specialist stuff, just statements that don't even pretend to be factual information, and it's easier to spot those if you aren't involved).

Things I spotted offhand, without really looking hard (intended as examples, not an exhaustive list of stuff to fix):

1. The philosophy behind Python is noteworthy among high-level programming languages

   Peacock phrase. "noteworthy" is an opinion, not a fact

2. The majority of Python's major features were present in this initial release

   Groan-worthy phrasing, and "major features" is at best unsourced, but sounds like an opinion to me - what makes those features major?

3. The Python programming language is actively used in industry and academia for a wide variety of purposes.

   Another peacock statement. Used by whom? For what purposes? There's a short list, but that doesn't substantiate "wide variety" and this statement adds no useful information to the article.

4. It aims toward an uncluttered visual layout, uses English keywords frequently where other languages use punctuation, and has notably fewer syntactic constructions than many structured languages such as C, Perl, or Pascal.

   Unsourced, and probably unverifiable - the decision of how to count "syntactic constructions" is essentially arbitrary. The reader can't learn anything much from this sentence.

5. This is a boon for those learning the language and experienced developers alike

   Poetic, grandiose... peacock.

6. As well, the Python shell is often used to interactively perform system tasks, such as modifying files.

   Unverifiable and mostly meaningless statement.

7. The codebase is written in compliant C89[26], and is thus easily portable to most operating systems, especially POSIX-compliant or Unix-like operating systems.

   The second part of this statement is unsourced, largely because it's wrong - merely writing something in compliant C89 does not make it "easily portable to most operating systems", even if you can agree on what qualifies as "most operating systems".

8. Several other experimental implementations have been created, but have not yet been widely adopted.

   Vague, unsourced, no useful information content.

I don't have the energy to fix this thing right now, so tagging POV-check. There's almost certainly more than I've listed here. Careful review is needed to find all the ones I didn't. Asuffield 09:54, 18 February 2007 (UTC)

Rewritten 1 and 2, removed 3, tagged 4 (this is a stated goal in the philosophy which needs linked), removed 5, rewritten 6 and 7, removed 8. Thanks. Chris Cunningham 16:02, 18 February 2007 (UTC)

avoiding naming collisions

This is not about the article itself, so to keep in line with wikipedia policy, I posted the question here instead. If anyone is watching this, pls help if you can. pls don't bite the noob. Thanks. NoClutter 17:39, 28 February 2007 (UTC)

Good Article Nomination Good morning (GMT time); I have reviewed this article on 2007-03-11 in accordance with the Good Article (GA) criteria. There are seven main criteria that the article must comply with to pass: Well-written: Pass Factually accurate: Pass Broad: Pass Neutrally written: Pass Stable: Pass Well-referenced: Pass Images: Pass I have concluded that, in my opinion, the article has passed all categories and I therefore award it GA status. Congratulations to the lead editors, and keep up the excellent work! Kindest regards, anthonycfc [talk] 06:04, 11 March 2007 (UTC)

Spelling

At the moment, the article uses a hodge-podge if -ise and -ize spellings. This should be made consistent. The question is, which way? Python's style guides don't specify, and it's used on both sides of the Atlantic. So it seems to depend on which editor actually does the task. If I do it, I will move towards -ise spellings, but I will not complain if someone goes ahead and makes it all use -ize before I do this. I'll do it tomorrow, providing no-one beats me to the punch or provides a strong argument otherwise. 88.111.218.237 21:07, 16 March 2007 (UTC)

Also, it's Random Useless Statistic Time: there are 3 genuine -ize/ization/izing words, versus 7 genuine -ise/isation/ising words in the current version. Make of that what you will. 88.111.218.237 21:21, 16 March 2007 (UTC)

Yes, but four of those are variants of "optimise" in a single paragraph, and there are two -ized/izes words you may have missed :p. FWIW, the Python documentation heavily prefers American spellings, except for a few modules in the standard library. But I don't feel strongly about it. — Miles (Talk) 02:13, 17 March 2007 (UTC)

<references /> columns

Unfortunately, it is not only low screen resolutions affected by this. If I were to try to print this article with two columns of references with full-size text (hey, reading a too-small printout is awful!), with some only marginally longer than average URLs, they bleed into the next column too. (On Firefox at least, this can be simulated by clicking the 'Printable version' link in the toolbox, and selecting File -> Print preview. At 100% text size, it happens on several URLs, and even at 70% (which, IMHO, is about the minimum size that's actually usable for me), there's one link that spills over.)

Seeing as this has been changed twice in the past few days, I'm taking this to talk to solicit feedback and rationales. Ideally, there'd be some magical template that can detect the screen width being used, and automatically compute the width needed for its reference list, but as far as I know there's no such thing. Abednigo 16:02, 29 March 2007 (UTC)

Merging

I think the two should be cross referenced (each link the other) and have the main page perhaps mention other language implementations. ...or perhaps have translations in various languages. But if there be too much content, the folks won't read. The article is already long and mentioning every possible fact has to be balanced against the possibility of loosing readers. Mention, cross link, but do not merge. ...my opinion. Larry 71.197.217.229 08:48, 15 April 2007 (UTC)

DO NOT MERGE I have same opinion as Larry. Also note that ChinesePython page is using non roman scripts, it's another drawback.Vivek 10:30, 1 May 2007 (UTC)

Thoughts on reference

Someone added:

• Computing in Science & Engineering, a peer-reviewed technical magazine, recently devoted a special issue to Python.

It seems fairly relevant, but the link is a to a collection of "give us money" links to read the actual content. I'm inclined to think such a list of commercial content falls under "advertising", and we should leave it out. LotLE×talk 15:31, 8 May 2007 (UTC)

Even worse, the link is now dead. I've removed it. --AdamGomaa 11:41, 6 July 2007 (UTC)

List of IDEs (where?)

An anonymous editor added the below list of IDEs. Such a list feels like a worthwhile resource, but it equally feels out of place here (especially tacked on after all the footnotes and external references. Anyone have an idea where this list might better live? LotLE×talk 15:09, 29 May 2007 (UTC)

Python IDEs and GUI Builders

• Dabo
• PythonCard
• Kexi
• Rekall
• Gemello
• Kiwi/Gazpacho
• TinyERP
• GNUe
• BoaConstructor
• UliPad

Some more:

• SPE
• IDLE (most important, since bundled with Python)
• Eric
• Kate, Vim, Emacs, Notepad++, KDevelop are the other editors that I used and have some python support

When we are at it, if we add the list to the article (and I hope we will), we should definitely mention that a lot of Python developers (me at least) use a normal text editor (maybe with some extra features like auto-indentation and syntax highlighting), run their code and other tools (version control, for example) via command line and use the interactive python shell (or, IPython, the enhanced frontend) for discovering (Code completion!) and testing (interactive, right?) commands. --89.61.123.52 (talk) 17:26, 30 December 2007 (UTC)

Influenced:

Can we add Groovy to the list? —Preceding unsigned comment added by 91.148.97.24 (talk)

Certainly (and done): the article already mentions it. --Piet Delport 20:25, 11 June 2007 (UTC)

Python is an imperative programmin language?

Like Perl and PHP. Python is an aimperative programming languge. So we should add it to the imperative languages Category ? --- Fırat KÜÇÜK

Shed Skin

I'm concerned about the mention of Shed Skin in the derived languages/implementations section. My main concern is that this project is early-alpha, and I have real doubts it yet merits inclusion in the Python article. Lots of folks have tried interesting things, but I'm not convinced this one will have legs (more power to it if it does; I said the same thing of Vyper back in 2000 though, magic bullets come and go).

But in particular, the claim about being much, much faster than Psyco seems contentious to me. Someone added a citation, but that citation was to the project creator's site, with no obvious benchmarks or methodology given there, just a general claim. Lies, damned lies, and benchmarks... as they say. Except there aren't even any specific benchmarks to point to. LotLE×talk 05:18, 9 July 2007 (UTC)

Here was the version I made more neutral:

Shed Skin is an experimental compiler that can translate smallish, statically typed programs into C++. When it works the obtained speedup is typically much larger than when using Psyco.

"Limited functional"

The addition about Python lacking anonymous closures is rather odd. In any common sense, of course Python has anonymous closures, e.g.:

>>> (lambda x: lambda y: x*y)   # A function that returns a closure   
<function <lambda> at 0x12b00f0>
>>> (lambda x: lambda y: x*y)(3)  # A closure on x=3
<function <lambda> at 0x1318170>
>>> (lambda x: lambda y: x*y)(3)(5)
15

Actually, I'm thinking of taking out the tail-call elimination thing too. There's a decorator at the online Python cookbook to do exactly that (http://aspn.activestate.com/ASPN/Cookbook/Python/Recipe/474088). Yes it's external code, but the fact it's so relatively simple to do makes the point correct in only the most contorted and pedantic sense. LotLE×talk 18:09, 20 July 2007 (UTC)

Please note that the previous version called it "multi-expression anonymous closures", which Python does not support. lambdas are only a single statement (which is how the article probably should read). There is no way to encode, eg:

def foo():
    if bar:
        while baz:
            qux()
    else:
        try:
            spam()
        finally:
            eggs()

using a single lambda (or if there is, it's too hacky to even contemplate). —Preceding unsigned comment added by 79.72.86.95 (talk) 2007-07-20 19:13:27

But of course that block statement can be replaced with an equivalent single expression by using boolean shortcutting. I won't argue that it is non-hacky... however, given I've published some widely read articles on "FP in Python" that show the details, it clearly has been contemplated. Actually, using the new ternary if in Python 2.5, it's not even unnatural: e.g., qux() if bar else spam().

Moreover, in Lisp (which is used as the "baseline") every program is a single expression (or close enough for these purposes). Making a statement so convoluted as to actually be true is nearly impractical for what you are trying to put in this article: e.g. "Multi-expression anonymous closures that don't use hackish boolean shortcutting and that work in Python versions <2.5". Claims that are kinda-sorta true, in principle, with sufficient caveats and exceptions, aren't good stuff for a WP article. LotLE×talk 20:55, 20 July 2007 (UTC)

Agreed; the details are finicky and particular, and don't improve the paragraph. I think "offers limited support for functional programming [...]" is a sufficient summarization for the context. —Piet Delport 02:07, 21 July 2007 (UTC)

No Strengths vs Weaknesses or Criticisim Topic

Some programming language articles have a Strengths vs Weaknesses or Criticisim Topic which I think many readers find helpful in comparing different languages and understanding why one language is better than another for a particular application or program implementation. I realize this might be a sensitive issue but think the added content would be helpful. Wam067 07:30, 25 July 2007 (UTC)

Criticism sections are generally disfavored per WP style guidelines and neutrality policy. (See e.g., WP:NPOV#Article_structure). Despite this, sometimes sections dealing with general review and critique are considered acceptable, at least by some (See e.g., Xml#Critique_of_XML).

The problem with putting these sections into a programming language article is it invites partisanship, because few people universally agree on what makes one language "better than another". Indeed, most programming languages in popular use today evolved because someone considered the closest alternative language to be unacceptable, so they designed something new. Consequently, the definition of "better" is subject to dispute.

You might also want to consult Comparison of programming languages. See also [1], [2]. dr.ef.tymac 08:17, 25 July 2007 (UTC)

Criticism is fine, as long as it is balanced, not original research, and attributable to a reliable source: you can't go and write down your own opinions. —Piet Delport 13:53, 25 July 2007 (UTC)

Readability vs. Speed and Expressiveness

Nowhere in the executive summary is Python said to value readability at the expense of speed or expressiveness. I assume the original author of that sentence considered the summary to have inferred such a philosophy, which is not factually supported. Changing this about a bit. Reb42 05:53, 28 July 2007 (UTC)

Python 3 article merge

Any interested editors, please see Talk:Python 3: i'm looking for consensus on what to do with that article. —Piet Delport 05:00, 29 July 2007 (UTC)

Better code example?

I think we should update the sidebar image labeled "Syntax-highlighted Python code" with something a little more Pythonic. The example reads more like Java or C# ported to Python than like something written in Python. For example, it uses isinstance() rather than duck-typing; and uses a getter. I don't have the means of generating this, or else I'd volunteer. Terry Carroll 21:45, 17 August 2007 (UTC)

For the sake of posterity, I'm referring to this image: Terry Carroll 21:50, 17 August 2007 (UTC)

I can assure you that I wrote that code in Python (and moreover, isinstance() really is the way to do what it does). And as someone who's never written a line of C#, only a moderate number in Java, and wrote a book about Python. Duck typing is nice enough... but when you are examining a multi-typed value returned from a specific standard-library module, there's no sense of asking if the value "quacks like a duck". LotLE×talk 00:50, 18 August 2007 (UTC)

Oh yeah, and what the heck would you use in place of .get()? You could wrap an ugly try/except, but that would be verbose and hard to read:

try:
  label = symbol.sym_name[int(ast[0])]
except KeyError:
  label = ast[0]

Do you really want to avoid a perfectly good method, .get()? (There is a bit clever way to do this in Python 2.5 and DefaultDict, but that's sneaky, and newer than my code sample.LotLE×talk 01:01, 18 August 2007 (UTC)

I would also vote for providing more "pythonic" code, the current one (add5) even does not follow python coding standards. Mykhal 20:40, 13 September 2007 (UTC)

.. maybe the code could use the default ID(L)E highlighting. What about something like this http://img187.imageshack.us/img187/3213/wikipythonexample1yi9.png ?

.. I know I could use the with statement, but that could be somewhat confusing

Mykhal 11:46, 8 November 2007 (UTC)

What is the copyright status on that image? And why isn't it uploaded to WP? Also, can you create an image that doesn't have such an ugly and thin looking font? LotLE×talk 20:03, 8 November 2007 (UTC)

The copyright is for now all rights reserved :) - it's just a proposal. here is the updated version (note that in there was a bug) with the larger font. Mykhal 22:32, 8 November 2007 (UTC)

Looks better, what about an SVG version like the old code? LotLE×talk 04:27, 9 November 2007 (UTC)

That's a much better, clearer code example than what we've got. rspeer / ɹəədsɹ 05:49, 9 November 2007 (UTC)

I think there should be some more discussion, my code is not absolutely OK, because I do not close the file explicitly. I think the final code should be short, using good programming practices, and exposing several nice python features/syntax. The final image/svg then may would look nicer using some light on dark scheme, like this.. Here it is in text format:

import sys

def list_file(fname):
    """Prints the file content,
    with the line numbers prepended"""
    try:
        f = open(fname)
    except:
        sys.exit("Error opening file %s" % fname)
    # the numbering may be done
    # better with enumerate()
    lineno = 1
    for line in f:
        print str(lineno)+':', line.rstrip('\n')
        lineno += 1

if len(sys.argv) != 2:
    sys.exit('Incorrect number of arguments')
filename = sys.argv[1]
list_file(filename)

Mykhal 11:51, 9 November 2007 (UTC)

Bare references

These look really ugly. I like that the article uses the footnote references, but each one should have a meaningful name (probably the actual title of the linked document) rather than just a URL. Readers looking at the footnotes shouldn't need to jump back and forth or guess why a certain URL is used.

I know you're all thinking that I should therefore clean it up. True enough, but I invite any help that might be offered in the project :-). LotLE×talk 02:50, 19 August 2007 (UTC)

Too much bibliography

There are too many, and too quickly growing, books listed in the external references. Moreover, even at too many, only about 1/4 of the available titles are listed. There's no particular logic to what is there or not there, other than "some editor liked that particular book".

What I would very strongly prefer is leaving in those titles that are freely available electronically, and removing all of those that are not. There is absolutely nothing wrong with buying a commercial title on nicely bound paper... but WP ain't a book review or recommendation site either. Book buyers can browse their local or online stores. What sayeth others? LotLE×talk 07:32, 3 September 2007 (UTC)

I concur. We cannot list all, so those complete books that are available freely seems reasonable.

What, however, happens after Py3K is released; when it could be argued that those free books based on pre-Py3k are inappropriate? --Paddy 08:16, 3 September 2007 (UTC)

There will be parallel maintenance and (minor) updates of the 2.x series for at least two years after the release of 3.0. So we have a while to worry about that issue. LotLE×talk 19:14, 3 September 2007 (UTC)

Afd on Python philosophy

Readers of the general Python article might be interested to notice that the child article Python philosophy was nominated on AfD at Wikipedia:Articles for deletion/Python philosophy. Please opine there if you have something to contribute. Thanks. LotLE×talk 05:39, 16 October 2007 (UTC)

Criticism, redux

I just removed the very recently added Criticism section from the article. I'm putting it here, in the hope that we can distil some useful additions to the article.

Point:

• Python OO is often considered non-native to the language by OO purists as class member functions force the user to have self as its first parameter, in a similar way to Perl. Also, instance variables within a member function also need to be accessed always through self, leading to much more verbose (and often hard to read) code. Other OO languages such as C++, D, Ruby, etc. consider self implicit, force the use of accessors or use sigils for this.

Response:

A discussion of Python's treatment of 'self' is already in the article, in more NPOV terms. Redundant.

Point:

• Python was originally born as an OO language where its built-in classes could not be modified. While much of this problem was addressed in 2.2, most of the standard library has not been updated to try to take advantage of this. Modification of built-in classes within the Python community is still perceived as dangerous.

Response:

Discussed in the History section, though not in as much depth (of opinion as well as of detail). Perhaps could be worked in there.

Point:

• Lack of native regular expressions syntax like Perl or Ruby forces code involving them to be more verbose than in those languages.

Reponse:

A criticism of the standard library, not of the language itself. If there is a solid reference for this, it should be but in the 'Philosophy' section, after the part about Python's core-language minimalism.

Point:

• Use of indentation is often a problem when sharing code through Internet forms or other methods that do not respect indentation. Even cutting and pasting code from other python sources where the tabulation level is different can often require careful editing to avoid syntax or subtle logic errors.

Reponse:

Covered in depth both in this article and in Python syntax. Redundant.

Point:

• Use of indentation and the need to use modules for several basic operations makes Python often not that well suited for one-liners as sed, awk, Ruby or Perl are for system administrators.

Response:

See above, though I don't think this is mentioned explicitly. This is a fair point, so perhaps should be added to Python syntax. Actually, isn't there something about Python golf, and how it specifically doesn't work, already?

Point:

• Tuples are often considered an unneeded addition to the language as lists provide a similar functionality. Alternatively, the immutability of tuples not being available to other primitives is also perceived as an inconsistency in the language.

Response:

Infested with weasel words. Stripped of these, the argument is: "Tuples are just immutable lists and thus not needed. Their immutability is inconsistant with other built-in types." The first part is sometimes brought up on c.l.py, and is sometimes dispatched by Pythonistas using arguments such as tuples not being lists, but being records (a la Pascal); and lists being unsuitable for use as dictionary keys. A mention (again in Python syntax) of this could be good. The latter part is simply wrong (cf str, frozenset).

But, without cites, all this is moot. I don't have the time right now to cite any of the potentially valid addendums I've just rooted out, so I'm leaving them here for an interested editor to quest for. 79.75.188.124 17:02, 9 November 2007 (UTC)

These sort of rambling WP:OR violations definitely have no place in a PL article. In fact, "Criticism" sections almost never have any place in any article. It is a foolish and false sense of "balance" that seems to encourage some readers to put in random insults of a topic, as if that presented "both sides" of an already neutral article. I am definitely strongly opposed to any criticism section, even one that were written far better than this thankfully deleted one. LotLE×talk 17:45, 9 November 2007 (UTC)

Point:

• Methods on objects are functions attached to the object's class; the syntax instance.method(argument) is, for normal methods and functions, syntactic sugar for Class.method(instance, argument). Python methods have an explicit self parameter to access instance data, in contrast to the implicit self in some other object-oriented programming languages (for example, Java, C++ or Ruby).

Response:

This is not really true of Ruby. Instance attributes in Ruby must be accessed with a special scoping sigil and can not be accessed with a self. Instance methods may be accessed without an explicit self but only those that are already defined and not the ones that will be defined at some future point in time (and meta programming is often used in Ruby so the explicit self become necessary).

None of this is relevant to a discussion about Python so keeping Ruby as an example only leads to missinformation. I'll be removing it unless someone can see a reason it has to stay. —Preceding unsigned comment added by Het (talk • contribs) 05:43, 30 January 2008 (UTC)

Typical Tunnel Vision Problem

A long article. The work that went it to it is evident. Commendable! So please take my criticism to heart without losing heart.

As with many expert type articles, this articles suffers from an overly narrow view of its customers. One almost gets the idea it is written exclusively for the same group of enthusiasts as are doing the writing! The article would certainly benefit by a step back from this notion of the readership. For instance, the target readership should be expanded to include (at least) people with experience programming in any other language, but explicitly lacking Python background.

A simple example to show what I mean: Right at the start, I'd like to see an answer to the question "Why Python?", i.e., what types of applications Python is especially designed to handle, and why it is better at these problems than other languages. (This information would be much more relevant to the stranger to Python than, for instance, cute anecdotes about a founder nominating himself as dictator for life.) In the same context, I'd also expect guidance as to what type of problems Python is not well adapted to dealing with (that is, less well adapted than other languages). Together, these define the relevant user group.

Philopedia (talk) 17:05, 16 November 2007 (UTC)

Any simple story about what Python is/is not good at very quickly strays into improper advocacy. I suppose a small number of well cited details would be OK. But this article does a much better job than many PL articles of avoiding that advocacy... I don't want to make it worse for what seems to me to be an ill-defined purpose.

It seems OK to observe "Python has construct X (while PL Foo does not)", but not to further claim X is better/worse than other languages' approximations. However, that has the problem that there are thousands of languages in which construct X does or does not exist. A comparison with a particular PL might seem "obvious" to users of that particular other language (e.g. Perl vs. Python), but not to the users of all the other PLs. What the article does now is much better: just list features of Python w/o trying to compare to every other option, nor to heap praise or blame on each feature. LotLE×talk 19:25, 16 November 2007 (UTC)

First on Google

I find it humorous that Python (programming language), rather than Python is the first result on Google for wikipedia+python.71.167.32.238 (talk) 18:58, 6 December 2007 (UTC)

Wikimedia Python Examples?

Hi, (please excuse me if this is not the right place for my entry). In the near future and for at least a couple of years it seems we will be having mainstream Python2.x and Python 3.y Python distributions with divergent syntax. What happens to the number of Python examples throughout Wikipedia?

I would favour a solution that would keep Python examples as meaning 2.x examples as it is now, and for Python 3.y examples to be explicitly stated as such, (including the syntax highlighter). I think examples in both versions should co-exist for a time. --Paddy (talk) 07:34, 8 December 2007 (UTC)

Modified the intro a bit

I edited the line in the intro that said "Python...emphasizes the importance of programmer effort over computer effort." I understand what this is trying to say, but it's ambiguous short-hand programmer-speak. A newbie could even interpret it as meaning that Python emphasizes that it's important for programmers to put in more effort. See what I mean? The tradeoff with execution time may be relevant, but doesn't need to be in the intro. C1932 (talk) 04:46, 24 January 2008 (UTC)

Good call. Chris Cunningham (talk) 10:20, 24 January 2008 (UTC)

Python (mythology), the oracular serpent of Delphi (pun intended?)

Hello everyone,

I hope not to disturb your work, but here is a small curiosity:

I just did a search for Python and got to the disambiguation page, where it says:

 Python (mythology), the oracular serpent of Delphi

While on the Borland Delphi-page is stated about the name of the programming language:

 "If you want to talk to [the] Oracle, go to Delphi"

..I'm confused! ;) 139.91.179.210 (talk) 18:55, 31 January 2008 (UTC)

It is a coincidence. The name of the Python language comes from Monty Python's Flying Circus and has nothing to do with nasty reptiles.[3]  --Lambiam 06:54, 1 February 2008 (UTC)

At least that's the surface association. If you look at any documentation, source files, system resources or third-party references or books written on the subject matter of this article, you will see serpents. dr.ef.tymac (talk) 16:20, 1 February 2008 (UTC)

The association is after-the-fact; the name of the language is older than any of these.[4] The keywords "Spanish Inquisition" and "SPAM" should tell you something. The first O'Reilly book with a snake on the cover is from 2003.  --Lambiam 03:30, 2 February 2008 (UTC)

None of this contradicts my earlier statement. One might also question the conclusions of "coincidence" and "after-the-fact", since even if the association were purely recent, that does not negate that associations, just like programming languages, change over time.

See also What is python? which states in relevant part: python, (Gr. Myth. An enormous serpent that lurked in the cave of Mount Parnassus and was slain by Apollo). (date: may 1997). dr.ef.tymac (talk) 04:11, 4 February 2008 (UTC)

What makes you think this quote is relevant to the issue of where the name of the programming language came from?  --Lambiam 10:21, 4 February 2008 (UTC)

Please re-see the prior posts to this thread (including yours). You'll notice the word association. Consider how this concept is distinct from origination. The stated intent in establishing a term is not necessarily the exclusive (or even primary) source of current meaning for that term.

This is *especially* true when the person credited with the original intent does nothing to disclaim (indeed, endorses) alternate interpretations. dr.ef.tymac (talk) 13:27, 4 February 2008 (UTC)

I only see the word association in this thread, starting with your "surface association". I maintain that the association between the Delphi snake and the language is after-the-fact. Being an association that is made later does not negate the association by itself, but it is still an association that is made later. Where do you find such endorsements of "alternate" interpretations? For a disclaimer, see http://www.python.org/search/hypermail/python-1992/0001.html.  --Lambiam 21:26, 4 February 2008 (UTC)

I've never seen a quote by GvR stating "the name python has nothing to do with ... reptiles". Do you know of one? I'd be happy to read it. An unequivocal repudiation of reptile references (as well as the de-facto "mascot") by GvR would bolster your original assertion quite a bit. Terse quasi-disclaimers such as the one you cited above, I respectfully suggest, do not. dr.ef.tymac (talk) 00:24, 5 February 2008 (UTC)

There is also no unequivocal repudiation by the Pope of the association of Roman Catholicism with the Rose Cross. So does this mean we are at liberty to herald that Roman Catholicism is associated with Rosicrucianism, using the lack of a solemn papal disavowal as corroborating evidence? The disclaimer I cited may be terse, but it is by no means a quasi-disclaimer. Your use of that terminology amounts to innuendo that the BDFL is lying in his response that there is nothing deep about it.  --Lambiam 09:41, 5 February 2008 (UTC)

No, it amounts to the very simple point that your assertion could use some direct substantiation, as it would enhance the credibility of your apparent claim. This really has zero to do with irrelevant speculation about GvR's integrity or abstruse analogies. "Nothing deep about it" != "has nothing to do with reptiles". "Nothing deep" could mean anything, it doesn't clarify the issue. Language itself is "deep" (programming, natural, or otherwise).

If you've anything more specific, feel free to drop it at my user space, as this thread is getting a bit long in the tooth. Regards, dr.ef.tymac (talk) 11:31, 5 February 2008 (UTC)

Quoting the python.org website:

“ By the way, the language is named after the BBC show ``Monty Python's Flying Circus'' and has nothing to do with nasty reptiles.[5] ”

For me this is an authoritative direct substantiation, with or without GvR's assertion.  --Lambiam 16:43, 5 February 2008 (UTC)

Yes, that is pretty direct alrighty! Perhaps now we should get together and tell them their website has been hacked, as someone has replaced their Favicon with this: Image:Python org favicon.png! ... Oh wait, perhaps that isn't a nasty reptile, just a cute and cuddly friendly reptile, or perhaps it's a green stick with a tongue, or ... (insert fanciful explanation here). dr.ef.tymac (talk) 05:08, 6 February 2008 (UTC)

Follow up: Yes, I know, I don't dispute your claim about the origin story for the language name (and never did), but the irony was just too good to pass up. Cheers. dr.ef.tymac (talk) 05:12, 6 February 2008 (UTC)

hello world?

don't want to be annoying, but shouldn't a page on a programming language include the traditional "hello, world!" program example thing? i mean it's a standard for presenting a programming language 89.123.249.91 (talk) 17:39, 15 February 2008 (UTC)

Phillip J Eby Search

I searched for Phillip J Eby on Wikipedia: http://en.wikipedia.org/wiki/Special:Search?search=%22Phillip+J+Eby%22&go=Go

One of the results was:

1. Python (programming language)

...Guido | last = van Rossum | coathors = Phillip J. Eby | work = Python Enhancement Proposals | publisher...

Relevance: 88.6% - 44 KB KiB (6330 words) - 14:31, March 12, 2008

I've followed the link to this page and there's no text anything like that. I checked recent history, too. What gives?

Thanks --Irrevenant [ talk ] 03:05, 13 March 2008 (UTC)

Look at the page source; it's in a cite. TJRC (talk)

I've fixed a typo in the field name "coauthors", which caused the name of Phillip J. Eby not to appear.  --Lambiam 19:43, 13 March 2008 (UTC)

Influences

There seems to be some back and forth on languages that influenced Python. I'm not sure the best way to come to an agreement (as I'm a newbie here). I offered a recent change based on first-hand experience as a Python developer. In the example in question, I amended the description of list comprehension influences to include SETL, because SETL and Haskell were the two languages with list comprehensions that the developers discussed when designing the feature. Should I document my own recollections elsewhere, then cite them as a reference? That seems like a tedious thing to do for all changes, but perhaps is useful for changes where there is disagreement.

Thanks --Jeremy Hylton —Preceding comment was added at 23:02, 21 March 2008 (UTC)

I participated in those discussions as well. SETL was mentioned, but very passingly as an aside; Haskell was the direct inspiration for the syntax and usage. In any case, whatever the factual answer, it needs to be documented and cited... WP isn't aiming at true, it's aiming at verifiable (many new editors miss this important distinction). If some PEP mentiones SETL, great. Or if you have some statement by the BDFL to this effect (or by some other core developer involved in implementing the feature). Give a concrete citation for the (slightly) controversial claim you wish to add. LotLE×talk 14:33, 22 March 2008 (UTC)

A quotation from http://wiki.python.org/moin/PythonVsHaskell, which may be considered an authoritative source in this context:

"Python's list comprehension syntax is taken (with trivial keyword/symbol modifications) directly from Haskell."

There are several indirect influences of SETL. One goes along the line SETL → ABC → Python. It regards the design decision to have a small set of powerful high-level datatypes.[6] Likewise, there is the line SETL → Haskell → Python [7]. Jeremy may be remembering seeing that message.

So it is true in some sense that SETL was an influence, but it is not doable in general to start listing indirect influences; almost everything that Python's designers borrowed from other languages has a pedigree.  --Lambiam 21:57, 22 March 2008 (UTC)

Thanks for the extended discussion. I agree that I was worried about writing something true rather than verifiable. Unfortunately, lots of the reasons for the design decisions took place in office conversations that didn't make it to email. Python development circa 2000 involved a fair amount of face-to-face conversation among the core developers.

The problem with the claim that Haskell was the direct influence is that it wasn't. Tim Peters captured it well in an email:

"He decided listcomps "were Pythonic" before knowing anything about Haskell (or SETL, from which Haskell took the idea). Given that he *already* liked them, the value in looking at Haskell is for its actual experience with them. It would be pretty stupid *not* to look at experience with other languages that already have it!"[8]

We had been interested in the list comprehensions idea for a while. The email thread on python-dev was about syntax for a feature already in the works. At that point, knowing the Haskell and SETL had both used it successfully was encouraging. Other languages used the same basic feature with this syntax. I recall downloading the SETL docs to take a look. The reason Haskell seems to have entered history as *the* influence is that it is the most modern language that has a similar syntax.--Jhylton —Preceding comment was added at 03:52, 24 March 2008 (UTC)

The main point, in my mind, of mentioning Haskell as an influence is more about its influence on itertools than on listcomps. Raymond Hettinger explicitly studied the Haskell prologue to evaluate which itertools were important to support. But perhaps we do not mention Haskell's influence in the best way or context (let me go look again). LotLE×talk 05:39, 24 March 2008 (UTC)

The text in the history section talks about list comprehensions rather than itertools.--72.14.228.89 (talk) 17:04, 24 March 2008 (UTC)

external links

I am adding a link to my website where I show how to install Python on Windows Vista. It is not intuitive and I think it is a useful addition to this page. (Neuralwiki (talk) 04:13, 24 March 2008 (UTC))

immuteable strings?

For the data type str and unicode it says it's "An immutable sequence of characters". I'm not a python expert but this seems incorrect to me. You can definitely change a string or unicode. —Preceding unsigned comment added by 74.61.6.82 (talk) 21:20, 13 April 2008 (UTC)

Actually, you can't change a string or unicode. You can create a new one and bind it to the same name as the old one; and then the old one is discarded. TJRC (talk) 19:25, 14 April 2008 (UTC)

>>> s = "foo"
>>> id(s)
3792352
>>> s = s+"bar"
>>> id(s)
3792320

LotLE×talk 04:40, 15 April 2008 (UTC)

This might be a tricky concept for users coming from some languages, such as C. Maybe we can come up with a way to cover it. The poster above appears to have confused "immutable" with "constant" (as in C const variables). --FOo (talk) 07:27, 15 April 2008 (UTC)

I agree with David, the example he shows indicates that the strings are not immutable, at least not in the sense that a functional programming language would consider immutability.

Python's colon is the appendix of the language.

The colon serves no useful purpose in the syntax parsing of the language. Why is it then required by the parser? It inhibits the natural expression of logic as part of program flow by adding a nonsensical characters for block delineation. See the following links for a discussion of the issue, [9] [10]. —Preceding unsigned comment added by 24.142.120.234 (talk) 07:39, 1 May 2008 (UTC)

Is there a reason to bring this up on Wikipedia? rspeer / ɹəədsɹ 08:06, 1 May 2008 (UTC)