Talk:Python (programming language)/Archive 10
![]() | This is an archive of past discussions about Python (programming language). Do not edit the contents of this page. If you wish to start a new discussion or revive an old one, please do so on the current talk page. |
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)
- 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,
- 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)
- Well, https://github.com/RustPython/RustPython is mentioned but it states the following:
- 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 (talk • contribs) 08:24, 9 July 2020 (UTC)