Category talk:Python

From Rosetta Code

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).

Some examples that come to mind:

  • use with, where appropriate, in place of more explicit try...finally handling; particular to show the built-in support for file closing ad threading lock releases
    • show an example of using contextlib to create object classes the automatically perform their own lock releases and/or transactional commit or rollback when called in a with structure.
  • review all uses of threading for cases that would benefit from the use of the new multiprocessing to overcome the limitations of the GIL (global interpreter lock) on SMP/NUMA scaling.
    • In particular look for cases where Pool and Manager objects from multiprocessing would simplify code examples.
    • Look tasks related to distributed processing for examples that readily implemented using multiprocessing Manager objects and other 2.6 and Python 3 feaatures.
  • Look for examples in which Python's traditional % string formatting operator can be simplified, clarified or otherwise improved using the new format() methods on string (str) (and Unicode and similar) objects.
    • Show and example of how custom classes can implement their own __format__() special method such that they can be targets of formatting string interpolation directives.
  • Consider adding notes to any topics that focus on the use of the traditional print statement that this will be removed from Python3 ... it's slated to become a function (and thus required an argument list as per the normal Python function call syntax). This will probably become one of the most confusing issues for future adopters of Python3 (as it becomes the default) when they're trying to study and adapt from 15 years of Python 2.x examples.
  • Similar concerns might be raised about the changes from raw_input() to simply input() and the need, in Python3, to call eval(input()) to get the same semantics as the traditional input() built-in function (in relatively rare cases were the use of the old semantics really was warranted). However most use of the old input() function was unwarranted.
    • Look for cases where the ast.literal_eval() method would be a more secure or otherwise better alternative to eval().

The gist of all my suggestions is that we want the examples on RosettaCode to be exemplary --- to consistently show the best practices for each language thta we cover. These changes to Python, mostly preparatory to the release of Python3 (a.k.a. Python3000 or Python3k) represent significant advances in the standard libraries ... which should simplify and improve the Python entries for a number of the tasks covered on this site. JimD 22:50, 8 September 2008 (UTC)

Thanks to the Google Highly Open Participation contest for high-school students, Python has passed Perl as the language with the most solutions. Well done! --IanOsgood 18:33, 28 November 2007 (MST)

Heh. I was browing, and saw a request for small Python projects. I sent the guy an email, but didn't find out until today what it was about. You can see part of the email here. --Short Circuit 20:35, 4 December 2007 (MST)

Take a look at some of the interesting python code here, it could probably be integrated: Programming Language Examples Alike Cookbook StaticShock


Python's interpreted? I thought it was compiled to a bytecode... —Donal Fellows 23:17, 30 July 2009 (UTC)

You're right. I thought I knew. --Mwn3d 23:24, 30 July 2009 (UTC)
Does mean that we need to find an instance of a current language that's pure interpreted. —Donal Fellows 00:55, 31 July 2009 (UTC)
Ruby? --Mwn3d 01:09, 31 July 2009 (UTC)
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 is Perl). Java is compiled and has byte code (as is C#). Trying to categorize Lisp and Forth will force you to look deeper into what distinctions you want to make when you bin a language as either compiled or interpreted. (Does a mammal lay eggs)? --Paddy3118 04:40, 31 July 2009 (UTC)
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. —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 --Paddy3118 09:19, 31 July 2009 (UTC)
P.P.S: See 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". --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. —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.

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. --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. --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. --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. --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… –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. --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. --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 ? Hout (talk) 13:09, 4 March 2019 (UTC)

Anything useful in this, for example ? [1](A Large Scale Study of Programming Languages and Code Quality in Github) 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 :-( 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 ) 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.

Voidwitch (talk) 17:08, 24 February 2021 (UTC)