Anonymous user
Category talk:Python: Difference between revisions
→Translating existing Python 2 implementations to Python 3: new section
(→Bytecode?: Distinction?) |
(→Translating existing Python 2 implementations to Python 3: new section) |
||
| (19 intermediate revisions by 4 users not shown) | |||
Line 1:
== New Python 2.6 and 3.0 ==
The upcoming releases of Python 2.6 and Python3 suggest that we should adjust many of the Python code snippets to exemplify the best programming practices that are available in the standard libraries. (We can, of course, leave the most backwards compatible examples as is and merely add the comparison to the simpler code that's available with newer releases).
Line 29 ⟶ 30:
:Python is both. Interpreted and bytecode. Just like C (interpreted (see [[wp:CINT]]) and compiled (machine code)).
:Like most things in life, it is very hard to find a clean distinction when you look closer. Python is interpreted and has byte code; (as
:: I was asking specifically so that the language could be categorized. It's ''primarily'' bytecoded, and it doesn't have the poor performance of a purely interpreted language. (FWIW, I believe Tcl's the same in this regard; mainly bytecoded with the potential to go interpreted in some awkward highly dynamic cases.) And mammals are defined by having mammary glands. —[[User:Dkf|Donal Fellows]] 07:49, 31 July 2009 (UTC)
:::Hi Donal, Python is ''both'' interpreted ''and'' byte coded.It doesn't have to be either-or. Whilst the internal byte code is normally stored as a file for any modules used, this is an optimisation. Python will work if they are not present. If, (but only if), your categorization of Python as being byte-coded precludes it from also being interpreted then the categorization scheme is faulty.
::: P.S. The classifiers had to drop the rule that mammals gave birth to live young when made aware of animals like the Duck-Billed Platypus --[[User:Paddy3118|Paddy3118]] 09:19, 31 July 2009 (UTC)
:::P.P.S: See [[wp:Interpreter (computing)|this]] description of an interpreter. Especially points two and three which state (an interpreter) "translates source code into some efficient intermediate representation (code) and immediately executes this" (or) "explicitly executes stored precompiled code[1] made by a compiler which is part of the interpreter system". --[[User:Paddy3118|Paddy3118]] 09:49, 31 July 2009 (UTC)
:::: I told you, Tcl's in exactly the same boat except that it is less common to save the bytecodes from one execution to another (our compiler's fast enough that we don't bother normally). The interpreter is mainly used for cases where it is known that the code cannot be executed again (i.e., certain kinds of callbacks) and for handling legacy code. The primary point of mine is that the main way that people experience both languages is as bytecoded systems. —[[User:Dkf|Donal Fellows]] 10:15, 31 July 2009 (UTC)
::::: Hi Donal, things are similar in Python, (and Perl and Ruby), but in the Python community, Python is known as an interpreter even though the interpreter generates byte codes. It would be a mistake to call Python a compiled language without much more explanation about what is meant by the term and contrasting it with what is the extended meaning of an interpreter. If in TCL your community refers to TCL as being a compiler then both communities could well be right when they explain their meanings.<br>
Beginners in Python are told to experiment in the interactive shell. Newcomers to TCL are often in the command line shell of some Electronic Design Automation tool where they both experience the interactive environment of a typical interpreter. I guess decisions on compiler or interpreter are also coloured by other distinctions such as dynamic vs static typing. --[[User:Paddy3118|Paddy3118]] 11:22, 31 July 2009 (UTC)
== Time to use Python 3.x by default ==
I think that because of the small size, and very little legacy dependencies of most Python examples for RC tasks; that it is time to '''always give Python 3 answers in new entries'''. I carefully haven't said anything about existing entries or about showing support for Python 2.x. I personally think that new entries might have Python 2.x translations for some time, but what I would like to see is Python 3.x examples become the norm, only omitted when an external 3.x compliant library cannot be found. --[[User:Paddy3118|Paddy3118]] 07:19, 23 February 2010 (UTC)
:I'd like to see 2.x support remain for a few years at least. There is a lot of legacy Python code around. For example, Mac OS X was using 2.3 for a long time, and their latest release is still only shipping with 2.6. --[[User:IanOsgood|IanOsgood]] 17:04, 23 February 2010 (UTC)
::Hi Ian, What do you think of always having Python 3 though? I think it is the future - if we make it so, and Rosetta Code has hardly any of the reasons to stick with 2.x '''as a default'''. --[[User:Paddy3118|Paddy3118]] 19:53, 23 February 2010 (UTC)
:Going through and adding 3.x answers to where there are only 2.x answers would seem to be a worthy task. Keep the old style ones for a while though; some readers might be learning so they can work with old code. You never really know… –[[User:Dkf|Donal Fellows]] 23:27, 23 February 2010 (UTC)
::That is more work than what I was proposing, which was to have Python 3 solutions for '''new''' tasks. --[[User:Paddy3118|Paddy3118]] 00:22, 24 February 2010 (UTC)
Time has passed, and I find that making the same code work for 2.X ''and'' 3.X to be not too hard. When pushed, I might favour just a 3.X solution. If anyone finds the deviations from good Python style that are used to make an example work on both 3.X and 2.X to be a bad thing, then please discuss. --[[User:Paddy3118|Paddy3118]] 05:37, 15 August 2010 (UTC)
==Motto magic ?==
Not much turns on this – I don't want to press it – but I do wonder whether the eager explanation (in line three) that a motto makes it easy to create bug-free programs doesn't sound a little quaint ?
I'm sure we have all seen buggy Python code (on RC as much as elsewhere in the wild, as it happens), so perhaps, for reassurance of the reader, we could at least reference a few of the experiments which have established confidence in (our ?) view that that memorisation or incantation of mottos does have a statistically detectable impact on bug-rates ?
Or should such papers prove elusive, perhaps we could cite any experimental confirmation of our hope that bug-rates in Python code might in fact be significantly lower than in comparable corpora written in other languages ? [[User:Hout|Hout]] ([[User talk:Hout|talk]]) 13:09, 4 March 2019 (UTC)
: Anything useful in this, for example ? [http://web.cs.ucdavis.edu/~filkov/papers/lang_github.pdf](A Large Scale Study of Programming Languages and Code Quality in Github) [[User:Hout|Hout]] ([[User talk:Hout|talk]]) 13:15, 4 March 2019 (UTC)
:: A quick glance at Table 6 suggests that adoption of Python may, if anything, be associated with slightly '''increased''' rates of defects :-( [[User:Hout|Hout]] ([[User talk:Hout|talk]]) 14:34, 4 March 2019 (UTC)
:::( Though on the bright side, the Python effect doesn't seem quite as bad as that of C++ or PHP ) [[User:Hout|Hout]] ([[User talk:Hout|talk]]) 14:39, 4 March 2019 (UTC)
== Translating existing Python 2 implementations to Python 3 ==
Python 2 has now been completely end-of-life for over a year, and the discussion about moving to Python 3 here happened over a decade ago. Despite that, most of the Python task implementations I've found here have been Python 2, and either don't work at all with 3 (because of something like the print keyword) or break in much more subtle ways.
A lot of people use Rosettacode to learn or better understand a language, and it's frustrating to find an example that seemingly should work, but doesn't. I know I've tested a few implementations here that broke, and it took me a bit to understand that they were using Python 2 standard library APIs that had subtly changed in Python 3. Because of that, I think it's time to start an initiative to go through the Python tasks, and test them on a modern version of Python 3. Those that break (or clearly don't work) should be added to a special sub-heading of [[Reports:Tasks_not_implemented_in_Python#Requiring_Attention]] until someone can get around to changing them.
I realize this is probably a massive undertaking, but I feel that it's necessary, since having examples that no longer work defeats the purpose of having those examples on Rosettacode at all.
[[User:Voidwitch|Voidwitch]] ([[User talk:Voidwitch|talk]]) 17:08, 24 February 2021 (UTC)
| |||