Talk:Python (programming language)/Archive 10

Archive 5 Archive 8 Archive 9 Archive 10 Archive 11

Interpreted

The C language is compiled to assembly code, which is then interpreted. So, C is a compiled language. Python is compiled to bytecode, which is then interpreted. So, Python is an interpreted language? Plokmijnuhby (talk) 08:49, 6 August 2019 (UTC)

Assembly code (actually, the object code produced from assembly code) is executed by the CPU hardware which means it is not interpreted. Interpreted code is parsed by software which works out what instructions need to be executed by the CPU. Please ask any other questions (not directly related to improving the article) at the appropriate reference desk. Johnuniq (talk) 09:38, 6 August 2019 (UTC)

Python influenced GDScript

GDScript is the language of the Godot Game Engine. It's influenced from Python, so it should be added in the "from Python influenced" list. Reinthaler (talk) 08:48, 8 August 2019 (UTC)

Version history

I would very much like to see a version history, much like the one on the Perl article and like the one at https://github.com/PyCQA/pyflakes/issues/319 (Which looked like it came from wikipedia anyway).

Is there any reason why there isn't one? Copyright, etc? Also, I couldn't find one ever being created in the history of this page or the History of Python page.

Very happy to do the research and create it, as long as it doesn't get deleted the next day!

hrf (talk) 08:35, 9 August 2019 (UTC)

Perl is the basis

First-most, Python borrowed heavily from Perl, not the syntax, but the API functions, and conglomeration of awk, set, perl, etc functionality. Having much experience with Python in its first 2 years, the main take away is that it is like Perl in terms of getting things done without the convoluted syntax. — Preceding unsigned comment added by 2600:1700:D591:5F10:6DC4:DCDB:94D9:A227 (talk) 22:41, 26 August 2019 (UTC)

Can Python be considered dependently typed?

https://mypy.readthedocs.io/en/latest/literal_types.html

You can add type annotations that depend on the value passed to a function (as long as they're simple literals of bools, ints, strs or bytes). Which kind of makes Python dependently typed, right? Akeosnhaoe (talk) 08:06, 22 October 2019 (UTC)

Python 3 upgrade fiasco

How can there be no more than a single, unassuming sentence, about the huge backlash and excruciatingly slow adoption process?134.160.214.17 (talk) 08:01, 19 March 2020 (UTC)

I agree the upgrade was slow, but have you got good refs for 'backlash', 'fiasco' or 'disaster'?
This is a reasonable ref on 'slow' [1]
I came up with this [2] and a few other similar ones, but that's more a bug or issues with standard library filename handling.
peterl (talk) 18:29, 19 March 2020 (UTC)
It is not clear that the "incredible-disaster-of-python-3" described in the second link is actually python doing something wrong. As [3] asks,
"Are you arguing that the zip implementation in Python should adhere to the zip(1) behavior instead of the zip specification?
An advantage of the Python implementation is that zip archives are portable across systems. This is not the case with the Linux implementation.
For example, using the example t.zip (created on a Linux system) I get this error if I attempt to extract it on my Mac:
error: cannot create test.txt Illegal byte sequence."
Python deciding to sacrifice an exact imitation of the way zip works in Linux in order to get zip archives that are portable between Linux and Mac appears to be a perfectly reasonable design decision. The author is, of course, free to disagree with that decision, but we as an encyclopedia should not take sides regarding that disagreement. If it is notable enough (which I doubt) we might want to describe the disagreement without taking sides. --Guy Macon (talk) 20:42, 19 March 2020 (UTC)
I agree. But that's all I could find, so I think that the original complaint has no real support. peterl (talk) 10:40, 20 March 2020 (UTC)
Pointless. Calling it a fiasco, or "a thing that is a complete failure, especially in a ludicrous or humiliating way", clearly seems like a strangely emotional opinion from a user that couldn't bother to create an account. Adoption was slow: the GCP command line tools just upgraded to Python 3 after Python 2 was officially deprecated if I am not mistaken. However, Python 2 got the security patches it needed and kept being a viable alternative for quite some time. BernardoSulzbach (talk) 21:17, 19 March 2020 (UTC)
I agree. peterl (talk) 10:40, 20 March 2020 (UTC)

Python implementation in GraalVM

I see that GraalPython https://github.com/graalvm/graalpython is missing from the list of implementations. It's a Python 3 implementation (in contrast to Jython which is Python 2 implementation). GraalPython has a low overhead Polyglot API to interact with other languages that GraalVM supports: https://www.graalvm.org/docs/reference-manual/polyglot/ That should be included somewhere. — Preceding unsigned comment added by 89.70.225.106 (talk) 10:45, 6 January 2020 (UTC)

"early-stage experimental" = WP:TOOSOON
peterl (talk) 05:06, 10 January 2020 (UTC)
Well, https://github.com/RustPython/RustPython is mentioned but it states the following:
Disclaimer
RustPython is in a development phase and should not be used in production or a fault intolerant setting.
Our current build supports only a subset of Python syntax.
— Preceding unsigned comment added by 89.70.180.143 (talk) 14:06, 21 March 2020 (UTC)
Agreed. Removed as WP:TOOSOON. Not yet a full implementation. I do note that MicroPython doesn't include the whole standard library, but would still be considered an implementation of Python, and is clearly notable peterl (talk) 17:19, 22 March 2020 (UTC)
MicroPython doesn't not include parts of Python because it isn't finished, but rather by design. MicroPython is intended for microcontrollers with orders of magnitude less performance and memory than desktop systems, and thus purposely leaves out features that won't fit. Thus MicroPython should be considered a subset of Python, not an implementation of Python. --Guy Macon (talk) 17:49, 22 March 2020 (UTC)

Pending changes protection

Can you Pending changes protect this page? Because many people will go here, and what if they get wrong info beacause this page got vandalized? You can verify the page, right? if you Pending changes protect this page? — Preceding unsigned comment added by Simulator-master (talkcontribs) 08:24, 9 July 2020 (UTC)

Pronunciation in US and UK

@Deacon Vorbis: Python is the name of a type of snake, and it is a specific word. see

https://www.lexico.com/definition/python

In English it has only two applications 1-Snake 2-Language. I really think that pronunciation should be placed there, because it is not common in English.

Thanks, Hooman Mallahzadeh (talk) 16:27, 16 October 2020 (UTC)

@Hooman Mallahzadeh: Did you not read MOS:LEADPRON? The word "Python" is about as standard as it gets in English pronunciation and it is very common in English if anything.--Jasper Deng (talk) 16:34, 16 October 2020 (UTC)
(edit conflict) Once again, please stop separating what should be one paragraph into four; it makes stuff a pain to read. MOS:LEADPRON says: "If the name of the article has a pronunciation that is not apparent from its spelling, include its pronunciation ... Do not include them for common English words ..." Python is a reasonably common word whose pronunciation is apparent from its spelling, so it shouldn't be included. –Deacon Vorbis (carbon • videos) 16:35, 16 October 2020 (UTC)
@Deacon Vorbis and Jasper Deng: Is the pronunciation difference in UK and US unimportant? See https://de.wikipedia.org/wiki/Python_(Programmiersprache) in German. They used pronunciation too for both of them.Hooman Mallahzadeh (talk) 16:41, 16 October 2020 (UTC)
No, the difference isn't important. That German WP gives a pronunciation is neither surprising nor relevant. –Deacon Vorbis (carbon • videos) 16:48, 16 October 2020 (UTC)
@Deacon Vorbis: Here MOS:LEADPRON says "If the name of the article has a pronunciation that is not apparent from its spelling," Ok? US: /ˈpθɒn/ really appears from spelling? Hooman Mallahzadeh (talk) 16:56, 16 October 2020 (UTC)
Did I stutter? –Deacon Vorbis (carbon • videos) 16:58, 16 October 2020 (UTC)
Hooman Mallahzadeh, there is absolutely nothing surprising or unusual about the pronunciation of this word. - MrOllie (talk) 17:10, 16 October 2020 (UTC)
Python is a common English word, and its pronunciation is not unusual. As already pointed out, per wikipedia policy, this pronunciation should not be in the lead. Wikipedia is not a dictionary (WP:ISNOT). Actually, there is a dictionary project here: [4]. That's where you go when you have doubts about the meaning or pronunciation of common words of the language. Fbergo (talk) 17:09, 16 October 2020 (UTC)
  • Python is a computer language from the Netherlands, named after a group of comedians in the UK, who are in turn named after a family of snakes found in Africa, Asia, and Australia. They chose that name because it sounds funny.
If you want to know how Python's Benevolent dictator for life, Guido van Rossum pronounces it, see Guido van Rossum - Python Language - PyCon 2016.
If you want to know how the UK comedians pronounce it, see Monty Python's Flying Circus (Intro) S2 (1970).
If you want to know how Wikipedia pronounces it, go to [ https://en.wiktionary.org/wiki/Python ].
If you want to insert any of the above pronunciations into this Wikipedia article, go away. We only add pronunciation for unusual words that the reader is unlikely to have heard before. --Guy Macon (talk) 21:55, 16 October 2020 (UTC)

Can we add something about the "six" libraries?

Everywhere I have worked people are using the "six" libraries to make code runnable under both python 2.x and 3.x. Can we say something, either in the introduction, or in the second that talks about the 2to3 library, about six? It seems too important to leave out of this overview of python. SystemBuilder (talk) 21:55, 3 December 2020 (UTC)

Please give us a link which describes these libraries and which we could use as a reference.-gadfium 00:55, 4 December 2020 (UTC)
Python 2 has been discontinued. There is no longer any need for any tool that "makes code runnable under both python 2.x and 3.x." We talk about the 2to3 library because it helps you to stop using Python 2 and start using Python 3. --Guy Macon (talk) 02:07, 4 December 2020 (UTC)
Okay, in a larger sense I think there should be a larger historical section about python 2.x->3.x migration. What motivated all these changes as some appear to be stylistic and possibly unnecessy? It is quite unusual to make so many backwards not-compatible changes in the next version of a language (for example I believe C/C++ and Fortran have never done it, and maybe not Java but I don't know.) That section would talk about from __future__ import xyz and the six.py libraries and the 2to3 library, etc. SystemBuilder (talk) 08:33, 4 December 2020 (UTC)
The reason why there are so many more changes is because the developers made what we now know was a bad decision, Python 2 was released in 2000. Python 3 was released in 2008. Python 2 was supposed to end in 2015. The bad decision was to postpone that to 2020, hoping that users would upgrade. Of course they didn't, and the two versions grew farther and farther apart. And, BTW, C did make a huge change; larger that Python's change. They just decided to call it C++ instead of just giving it a new version number. --Guy Macon (talk) 17:09, 4 December 2020 (UTC)
And as a side note, C++ has and continues to make backwardly-incompatible changes, e.g. to the keywords auto, register, volatile, single argument constructor initializer preference, and more. peterl (talk) 02:51, 5 December 2020 (UTC)
of course, you leave out the part where C++'s changes affect virtually 0 programs. A search of online repos like GIT Hub, etc., should that auto was only every used in compiler test code. The use of violate is implementation-specific by definition.

I assume by "single argument constructor initializer" you mean the new initializer_list. Since existing programs doen't use it, they aren't affected by it. And more, indeed...

Move section out or merge other page in here?

Merge the whole Syntax section out to Python syntax and semantics? Or merge it into here? This section may be too long and detailed to be included in this article. Please don't just blanket delete the section - there is useful information here. peterl (talk) 04:57, 20 January 2021 (UTC)

"Python Programming Language language" listed at Redirects for discussion

  A discussion is taking place to address the redirect Python Programming Language language. The discussion will occur at Wikipedia:Redirects for discussion/Log/2021 March 15#Python Programming Language language until a consensus is reached, and readers of this page are welcome to contribute to the discussion. - CHAMPION (talk) (contributions) (logs) 23:18, 15 March 2021 (UTC)

Typo

There is a typo in the part: "It has been suggested that this article be merged with Python syntax and semantics." I think "is merged" is better than "be merged".Please have a look at this.

Orlando 2006-2021 (talk) 12:52, 27 March 2021 (UTC)

That text is auto-generated by Template:Merge, so Template talk:Merge is the right place to discuss this. I see there's already people discussing rewording that text, you could add your thoughts as a non-native English speaker.
You're also wrong though. The "be" in "be merged" is used like "it will be merged". You don't say "it will is merged". "It has been suggested that this article is merged" would be saying the article is already merged, when it needs to say that someone has suggested the article "should be" merged in the future, once people agree that it should be merged and how to merge them. Akeosnhaoe (talk) 17:04, 27 March 2021 (UTC)

Run-on sentence

At the head of the article there's a sentence that reads, "Python 2.0 was released in 2000 and introduced new features, such as list comprehensions and a garbage collection system using reference counting and was discontinued with version 2.7.18 in 2020.". I believe this should be separated into two sentences to improve readability, but I'd like to hear opinions on the matter before changing anything.

Feel free to edit it however you want, someone will just revert it if it's bad, see WP:BOLD. The important part is to clearly say that it was version 2 that was discontinued, not the entire language. Akeosnhaoe (talk) 23:47, 12 May 2021 (UTC)

Supported Operating Systems

@Peterl: — I see you're a seasoned Wikpedian, so I have a question. You just reverted some edits I made yesterday regarding supported operating systems. In your note you mention that the repeated linking was over the top. I can maybe understand that, but where is that in the guidelines?

Additionally, in the act of undoing the edit you also remove the mentions of the other supported operating systems. This list seems relevant and useful, so why not just delete the repeated links versus undoing the entire edit? Looking forward to understanding the rationale here. -Dan

Supported OSes are given on CPython. Akeosnhaoe (talk) 18:46, 24 May 2021 (UTC)
Thanks Dan. From my perspective, the main supported OSes are at [5]. It lists "Windows, Linux/UNIX, Mac OS X" (should say MacOS), and "Other". (I'm not sure if the order always looks like this? That's how it is when I browse to it). We don't have to list everything on the wiki page. Supported OSes have and do change with reasonable regularity. So I say we go with what the main download page says. The guidelines don't list every case, but I'll go with WP:OVERLINK.
On a side note, you can sign your posts with ~~~~, and the engine will insert your signature. peterl (talk) 22:50, 24 May 2021 (UTC)

DOCTYPE Puzzle

Readers of this page may be interested in thw following discussion:

Python.org is mentioned a few paragraphs down. Did you know that RFC3151 uses python.org as an example? --Guy Macon (talk) 22:48, 1 June 2021 (UTC)

Python performance claims in Nature article

The goal of Wikipedia project is provide neutral point of view that is based on the notable references. In order to provide more balanced view, I have included the statement that is based on the following reference: Jeffrey M. Perkel. (2020) Why scientists are turning to Rust. Nature 588, 185-186. doi: https://doi.org/10.1038/d41586-020-03382-2 . Nature is a reputable journal, not a personal page, not a wiki, not a blog. I agree the statement is not very positive towards the subject of the article but this absolutely should not be the criteria of its inclusion. Audriusa (talk) 16:06, 3 June 2021 (UTC)

Nobody disputes that the source is reliable. The question is WP:WEIGHT. I can easily find reliable sources that show that (depending on what you want to do and your skill level) Rust is better than Python, Python is better than Rust, C++ in better than Python, Python in better than C++, Assembly language is better than any of them, etc.
It is WP:UNDUE to put material about the programming language wars into the Wikipedia pages of individual programming languages. Where does it end? Would you edit Emacs with material saying Vim is better? Would you add a claim that macs are better to an article on PCs?
Please continue discussing without edit warring. See WP:EW and WP:BRD.
--Guy Macon (talk) 16:41, 3 June 2021 (UTC)
It is a violation of WP:NPOV and WP:NOTADVOCACY to allow the sentences that Python is better than other languages and then disallow the similar sentences that it is worse, selectively picking references supporting a single side. I placed my rather negative sentence next to "An empirical study found that scripting languages, such as Python, are more productive than conventional languages, such as C and Java". This is also backed by the reference but it is highly biased if included alone. I think the WP:WEIGHT should be reserved for the obvious things like flat Earth hypothesis and comparable very alternative views. One or another kind of criticism of Python it is nothing unheard of. Audriusa (talk) 17:16, 3 June 2021 (UTC)
Let's see if anyone else agrees with you.
Note: The exact quote is
"An empirical study found that scripting languages, such as Python, are more productive than conventional languages, such as C and Java, for programming problems involving string manipulation and search in a dictionary, and determined that memory consumption was often 'better than Java and not much worse than C or C++' "
Claiming that the article says "more productive than conventional languages, such as C and Java" when it actually says "more productive than conventional languages, such as C and Java, for programming problems involving string manipulation and search in a dictionary" is misleading.
[6] makes no claims about Rust in the context of string manipulation or dictionary search, and freely admits that Python is more productive while Rust is faster at comparing millions of sequence reads against billions of genetic bases as fast as possible. So what?
I will wait to see if anyone agrees with you, but I suspect that you are going to have to come up with a better argument than "NPOV doesn't allow us to make well-sourced claims that some computer languages are better for some things."
Perhaps I should go to Rust (programming language) and add some citations showing how much slower it is than my favorite language -- assembly. :) --Guy Macon (talk) 19:13, 3 June 2021 (UTC)
I'd say, leave it out. It's an anecdotal account of why Köster switched to Rust; it's not an systematic study, despite being published in Nature. And while Nature is a reliable source for information on the biological sciences, I see no indication that it is an authority on computer science. This is an interesting side-article for its readers, not the typical account of a biomedical study, where Nature reigns.
The writer here, Jeffrey Perkel, doesn't appear to have been trying to set out anything other than an interesting side-piece, and I don't think pretends to any authority on this subject. I don't see any basis to conclude that he is a reliable source for the "level of computational performance that Python simply cannot deliver".
I would regard this much differently if it were from a reliable source on computer science, with an actual more-or-less rigorous analysis. But this is just an anecdote. TJRC (talk) 20:35, 3 June 2021 (UTC)
Agree. peterl (talk) 23:23, 3 June 2021 (UTC)
A link to the performance difference between Python and Rust is already in the article. See [7] vs. [8]. Where Audriusa goes off the rails is when they assume that "higher performance" equals "more productive". Productivity is how hard it is to learn a language and how long it takes to solve a problem once you become proficient. It has pretty much nothing to do with how fast the program runs. I myself program microcontrollers in assembly language. Assembly is much faster than Rust, Python, or C but it isn't very productive. You could literally die of old age before finishing a program that does the same thing as a python program that took an afternoon to write. --Guy Macon (talk) 15:40, 4 June 2021 (UTC)

This discussion has been dormant for a week, and no one but the editor proposing adding the Nature passage agrees that its exclusion is a POV issue, so I am removing the tag from the article. TJRC (talk) 17:27, 13 June 2021 (UTC)

True?

"Thus, the program's visual structure accurately represents the program's semantic structure." Is this sentence misleading? I ask that because two lines that look identical can function differently if one was indented manually and the other automatically. 79.134.37.73 (talk) 09:13, 16 July 2021 (UTC)

Hmmm. What do you mean "manually" or "automatically"? peterl (talk) 13:32, 16 July 2021 (UTC)

A Commons file used on this page or its Wikidata item has been nominated for deletion

The following Wikimedia Commons file used on this page or its Wikidata item has been nominated for deletion:

Participate in the deletion discussion at the nomination page. —Community Tech bot (talk) 20:25, 11 September 2021 (UTC)

Question under Popularity section

One thing caught my attention under the Popularity section, specifically in the last paragraph. Several large companies that have used Python as part of their daily work activities include Google, Facebook, and Spotify, as noted there already. However, two of them listed (Wikipedia and Amazon) lack references to back these up in case a reader is interested in knowing what specific functions Python is used within both companies. Is this a major concern, and if so, what sources should be added to back these up? Jvalle58 (talk) 15:35, 12 September 2021 (UTC)

SampleCode replaces Screenshot in this Infobox

@Gadfium: Hi, SampleCode argument is new and replaces the past argument screenshot. See, SampleCode has an abstract description of the total language. It conveys important information about remaining parts of this Infobox. So we should use this argument as the second rendering item, to successfully convey an overview of Python language. Thanks, Hooman Mallahzadeh (talk) 09:11, 3 February 2022 (UTC)

@Gadfium: Do you agree? Can I recover my edit? Hooman Mallahzadeh (talk) 09:29, 3 February 2022 (UTC)
I see you have just added that parameter to the infobox, and there has been no discussion about it. Such a discussion does not belong on the talk page of an individual programming language, but on the talk page of the infobox template (as you have done at Template talk:Infobox programming language#Change Screenshot to SampleCode) and you should wait for feedback. To increase the number of editors who are likely to see this, you might like to mention the discussion at a relevant WikiProject, e.g. at Wikipedia talk:WikiProject Computer science.-gadfium 18:23, 3 February 2022 (UTC)

Influenced by Java?

I question this association. Python has been released few years before Java, with very different roots and goals.

In this page about Python, the syntax of decorators is used as a reference for the “influenced_by” association. However, it is a later addition to the language; too late and certainly too weak to justify this kind of association.

This way, each language will be marked as “influenced_by” a very large number of other languages. Thus, we will have essentially an unuseful almost fully-connected graph of languages.

Tomamic (talk) 17:43, 11 February 2022 (UTC)