Category talk:Python

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 programming.reddit.com, 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

Bytecode?

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)