Talk:Python (programming language)

From Wikipedia, the free encyclopedia
Jump to: navigation, search

  YesY Merger complete.

Good article Python (programming language) has been listed as one of the Engineering and technology good articles under the good article criteria. If you can improve it further, please do so. If it no longer meets these criteria, you can reassess it.
Article milestones
Date Process Result
March 7, 2007 Good article nominee Listed
February 17, 2009 Peer review Reviewed
March 3, 2009 Good article reassessment Kept
Current status: Good article
          This article is of interest to the following WikiProjects:
WikiProject Computing (Rated GA-class, Mid-importance)
WikiProject icon This article is within the scope of WikiProject Computing, a collaborative effort to improve the coverage of computers, computing, and information technology on Wikipedia. If you would like to participate, please visit the project page, where you can join the discussion and see a list of open tasks.
 GA  This article has been rated as GA-Class on the project's quality scale.
 Mid  This article has been rated as Mid-importance on the project's importance scale.
 
WikiProject Free Software / Software / Computing  (Rated GA-class, Mid-importance)
WikiProject icon This article is within the scope of WikiProject Free Software, a collaborative effort to improve the coverage of free software on Wikipedia. If you would like to participate, please visit the project page, where you can join the discussion and see a list of open tasks.
 GA  This article has been rated as GA-Class on the project's quality scale.
 Mid  This article has been rated as Mid-importance on the project's importance scale.
Taskforce icon
This article is supported by WikiProject Software.
Taskforce icon
This article is supported by WikiProject Computing.
 
WikiProject Computer science (Rated GA-class, Mid-importance)
WikiProject icon This article is within the scope of WikiProject Computer science, a collaborative effort to improve the coverage of Computer science related articles on Wikipedia. If you would like to participate, please visit the project page, where you can join the discussion and see a list of open tasks.
 GA  This article has been rated as GA-Class on the project's quality scale.
 Mid  This article has been rated as Mid-importance on the project's importance scale.
 
WikiProject Software / Computing  (Rated GA-class, Mid-importance)
WikiProject icon This article is within the scope of WikiProject Software, a collaborative effort to improve the coverage of software on Wikipedia. If you would like to participate, please visit the project page, where you can join the discussion and see a list of open tasks.
 GA  This article has been rated as GA-Class on the project's quality scale.
 Mid  This article has been rated as Mid-importance on the project's importance scale.
Taskforce icon
This article is supported by WikiProject Computing.
 
WikiProject Netherlands (Rated GA-class)
WikiProject icon This article falls within the scope of WikiProject Netherlands, an attempt to create, expand, and improve articles related to the Netherlands on Wikipedia. If you would like to participate, visit the project page where you can join the project or contribute to the discussion.
 GA  This article has been rated as GA-Class on the project's quality scale.
 

Object-oriented vs. Object-orientation[edit]

Is this correct?

Python supports multiple programming paradigms, including object-oriented, imperative and functional programming styles. (emphasis mine)

I think it should say "object-orientation", not "object-oriented". I have made this adjustment before and it was changed back. Am I in the wrong here?

EDIT: Boy I feel stupid. I did not read the full sentence. I'm sorry for wasting your time.

External links modified[edit]

Hello fellow Wikipedians,

I have just added archive links to 3 external links on Python (programming language). Please take a moment to review my edit. If necessary, add {{cbignore}} after the link to keep me from modifying it. Alternatively, you can add {{nobots|deny=InternetArchiveBot}} to keep me off the page altogether. I made the following changes:

When you have finished reviewing my changes, please set the checked parameter below to true to let others know.

N Archived sources still need to be checked

Cheers. —cyberbot IITalk to my owner:Online 10:17, 27 August 2015 (UTC)

There is no word about the best GUI builder: Qt_Designer. Why?[edit]

I had been struggling for years with terrible Tkinter, wxPython, BOA, Glide, etc. until I discovered PyQt with its fantastic VISUAL Qt_Designer, which is free software. 85.193.214.150 (talk) 18:18, 12 October 2015 (UTC)

If you can come up with a reliable, third-party reference (or two) stating this, then feel free to add it in. Although I would say terms like 'the best' and 'terrible' and 'fantastic' are quite subjective. There are also issues around licensing: PyQT has GPL but not LGPL, which may affect some uses/users.
peterl (talk) 09:11, 13 October 2015 (UTC)

Proposed merge with CPython[edit]

The following discussion is closed. Please do not modify it. Subsequent comments should be made in a new section. A summary of the conclusions reached follows.
Not merged. -- Chamith (talk) 08:05, 5 January 2016 (UTC)

It's important to make the distinction between language and implementation, but I don't think we need separate articles to do so. For the bulk of its users, and in many of the sources, CPython is Python, unless otherwise specified. AFAIK, the language spec is "do what CPython does (or documents)".

Also, a look at the current material on CPython shows a discussion of the GIL, but little else of encyclopedic value that isn't also discussed in this article. I think a section in this article is a better place to discuss the main implementation than a separate article. QVVERTYVS (hm?) 19:40, 10 December 2015 (UTC)

Oppose. Python, more than other languages (maybe Java of 15 years ago), seems to have a community of developers who delight in nothing better than swapping between interpreters. The current article is a vacuous list of little more than version numbers, but there is scope for more interesting coverage on this topic (and the other interpreters).
I've got an all-day meeting on Monday that's likely to spend half of it talking about interpreter choices. If you're not good, I'll make you read the minutes! Andy Dingley (talk) 22:16, 10 December 2015 (UTC)
Oppose. There are many Python implementations, and almost all of them have their own page. CPython is by far the most commonly used Python implementation, so it wouldn't make sense for other implementations to have their own page, and CPython to not.
The main Python_(programming_language) is almost too long, and I'm not for putting more stuff in there. The Python_(programming_language)#Implementations section could probably be trimmed a little (too much detail that is then covered in sub-pages).
peterl (talk) 22:30, 10 December 2015 (UTC)
Oppose. I think the list of supported platforms does have some value - I wouldn't want to delete that (and definitely not want to merge it into the main article). However, I agree with you that CPython is by far the most popular implementation, so things like the GIL should be treated in this article as well (in addition to the CPython article) — Preceding unsigned comment added by 194.118.194.68 (talk) 10:07, 14 December 2015 (UTC)
Oppose. Python is the programming language, while CPython is the official implementation. Having separate articles is nice and gives a suitable place for content about the official implementation. I think CPython is useful in the same way that Ruby MRI is useful. It's true that CPython is the official implementation, so it's obviously very special, but conceptually we should consider it to be an implementation of the Python language. Best regards. Huihermit (talk) 12:30, 16 December 2015 (UTC)
Oppose consensus apparent. Removing merge tag.

The above discussion is closed. Please do not modify it. Subsequent comments should be made in a new section.

COI[edit]

I just linked to blogory.org after reading the policy guidelines.

Understandably Wikipedia is very sensitive about links, and so I want to be most respectful of the site. In case there is any concern about my posting, here is the background.

I run blogory.org. As of today, Jan 19, 2016 it has 169 links about Python, and 63 links about zodb.

Blogory.org is a site very similar to DMOZ or Yahoo Directory.

In contrast DMOZ, has 328 links about Python, and 1 link about zodb.

Really DMOZ is so out of date.

So I linked to the appropriate pages of my website from Wikipedia->Python blogory.org/python

and from Wikipedia->zodb blogory.org/zodb

I presume that is okay under the external links policy: "A well-chosen link to a directory of websites or organizations. Long lists of links are not acceptable. A directory link may be a permanent link or a temporary measure put in place while external links are being discussed on the article's talk page."

Please let me know if there is anything I should do to make this link more appealing to the Wikipedia community. Clozinski (talk) 14:07, 19 January 2016 (UTC)

Please see User talk:Clozinski#January 2016. --Guy Macon (talk) 14:15, 19 January 2016 (UTC)

List of statements: style of paragraph on "=" statement does not fit with other statements[edit]

Currently the paragraph on the "=" statement is very long and does not really go well with the explanations on other statements. For example the 'if' statement is described like this:

  • The if statement, which conditionally executes a block of code, along with else and elif (a contraction of else-if).

This is easy to understand for even for beginners. On the other hand the "=" statement is described like this:

  • The assignment statement (token '=', the equals sign). This operates differently than in traditional imperative programming languages, and this fundamental mechanism (including the nature of Python's version of "variables") illuminates many other features of the language. Assignment in C, e.g., "x = 2", translates to "typed variable name x receives a copy of numeric value 2". The (right-hand) value is copied into an allocated storage location for which the (left-hand) variable name is the symbolic address. The memory allocated to the variable is large enough (potentially quite large) for the declared type. In the simplest case of Python assignment, using the same example, "x = 2", translates to "(generic) name x receives a reference to a separate, dynamically allocated object of numeric (int) type of value 2." This is referred to as "binding" the name to the object. Since the name's storage location doesn't "contain" the indicated value, it is not proper to refer to it as a "variable." Names may be subsequently re-bound at any time to objects of wildly varying types, including strings, procedures, complex objects with data and methods, etc. Successive assignments of a common value to multiple names, e.g., "x = 2"; "y = 2"; "z = 2" result in allocating storage to (at most) three names and a single numeric object, to which all three names are bound. Since a name is a generic reference holder it is not reasonable to associate a fixed data type with it. However at a given time a name will be bound to some object, which will have a type; thus there is dynamic typing.

I think this is too complicated and doesn't fit with the rest of this list. My suggestion would be:

  • The assignment statement =, which assigns a value to a variable.

We could move the longer version to Python syntax and semantics.

What do you think? --Marko Knoebl (talk) 23:09, 1 February 2016 (UTC)

There is no point in a para that says "The assignment statement =, which assigns a value to a variable.", no more than there is in the statement "The if statement, which conditionally executes a block of code, along with else and elif (a contraction of else-if)." Both of these are trivially obvious to anyone with the rudimentary level of knowledge we would assume for a reader interested in an article on a specific programming language. Both fail WP:MANUAL (by not even reaching that level!). Is there a single reader who reads past the lead (which introduces Python as an unsurprising block-structured procedural language) and will then learn anything new from such a bland statement? If we are to have descriptions no more detail than that, then we might as well state nothing about the assignment operator or the if statement at all and just save the length.
Python's assignment operator is a little more than this though. This article goes into it in some depth. This is useful depth and generally to be commended. We need more like that, not less.
We could move it, as there is an article at Python syntax and semantics. Given the two levels of articles this is viable. It's not there as yet and it is needed there. This description is quite important for understanding Python behaviour.
So I'd be OK with moving it, but I'd prefer to keep it and maybe re-cast it as an explanation of a broader typing and instancing concept than just "explaining what assignment operators are". It shouldn't be lost though. I don't like the idea either of replacing it with the bland statement. Of the two, I'd rather delete the vacuous and pointless explanation of the if statement. We're not a manual, we don't have to list every feature. Our job is to explain Python and its characteristic features, not exhaustively document it for a beginner's lesson. Our readers already understand the basics of assignment and conditional branches. Viam Ferream (talk) 13:03, 2 February 2016 (UTC)
Thanks for your constructive comments. What bothers me about the section is that it somehow diminishes the article's readability as more and more (unrelated) stuff is put in the section "Statements and control flow". If you look at that section from 2007 you'll see that it just included five statements. (In my eyes these five statements are amongst the "central" ones in Python and give a quite good overview of the language). In the past this section has been expanded to include many other (less significant) statements and has also absorbed other topics like coroutines or (in the edit at hand) an explanation of dynamic typing and reference types.
I'm wondering if we should restructure the section entirely and get rid of the list of statements (presenting its current content in a more meaningful way) --Marko Knoebl (talk) 22:40, 4 February 2016 (UTC)