PEP movements

tip:: PEP updates by email are available as a topic from the Python-checkins mailing list.

PEP 246 was a major topic of discussion during the time period covered by this summary. This all stemmed from Guido's blog entries on optional type checking. This led to a huge discussion on many aspects of protocols, interfaces, and adaptation and the broadening of this author's vocabulary to include "Liskov violation".

"Monkey typing" also became a new term to know thanks to Phillip J. Eby's proto-PEP on the topic (found at http://peak.telecommunity.com/DevCenter/MonkeyTyping). Stemming from the phrase "monkey see, monkey do", it's Phillip version of taking PEP 246 logically farther (I think; the whole thing is more than my currently burned-out-on-school brain can handle right now).

Contributing threads:

• getattr and __mro__
• Son of PEP 246, redux
• PEP 246: lossless and stateless
• PEP 246: LiskovViolation as a name
• "Monkey Typing" pre-PEP, partial draft

Optional type checking: how to inadvertently cause a flame war worse than decorators

Guido's blog had comments on the idea of adding optional static type checking to Python. While just comments in a blog, it caused a massive response from people, mostly negative from what I gathered. After Guido discussed things some more it culminated in a blog entry found at http://www.artima.com/weblogs/viewpost.jsp?thread=87182 that lays out what his actual plans are. I highly recommend reading it since it suggests adding optional run-time type checking for function arguments along with some other proposals.

All of this led to PEP 246 getting updated. For some more details on that see the PEP movements section of this summary.

And if there is a lesson to be learned from all of this, it's that when Alex Martelli and Phillip J. Eby start a technical discussion it's going to be long, in-depth, complex, and lead to my inbox being brimming in python-dev email.

Let's get the AST branch done!

Guido posted an email to the list stating he would like to to make progress towards integrating "things like type inferencing, integrating PyChecker, or optional static type checking" into Python. In order to make that easier he put out a request that people work on the AST branch and finish it.

For those that don't know about Python's back-end, the compiler as it stands now takes the parse tree from the parser and emits bytecode directly from that. This is far from optimal since the parse tree is more verbose than needed and it is not the easiest thing to work with.

The AST branch attempts to fix this by taking a more traditional approach to compiling. This means the parse tree is used to generate an AST (abstract syntax tree; and even more technically could be considered a control flow graph in view of how it is implemented) which in turn is used to emit bytecode. The AST itself is much easier to work with when compared to the parse tree; better to know you are working with an 'if' guard thanks to it being an 'if' node in the AST than checking if the parse tree statement you are working with starts with 'if' and ends with a ':'.

While all of this sounds great, the issue is the AST branch is not finished yet. It is not entirely far off, but new features from 2.4 (decorators and generator expressions) need to be added along with more bug fixing and clean up.

This means the AST branch is going to get finished for 2.5 somehow. But help is needed. While the usual suspects who have previously contributed to the branch are hoping to finish it, more help is always appreciated. If you care to get involved, check out the AST branch (tagged as 'ast-branch' in CVS; see the python-dev FAQ on how to do a tagged branch checkout), read Python/compile.txt and just dive in! There will also be a sprint on the AST branch at PyCon.

Contributing threads:

• Please help complete the AST branch
• Will ASTbranch compile on windows yet?
• ast branch pragmatics
• Re: [Python-checkins] python/dist/src/Python pythonrun.c, 2.161.2.15, 2.161.2.16

Ditching unbound methods in Py3k

Guido suggested removing unbound methods from Python since their usefulness of checking their first argument and other slight differences from functions just didn't seem worth keeping around and complicating the language. So the idea seems sound.

But then people with uses for the extra information kept in unbound methods (im_func and im_self) popped up. To make the long thread short, enough people stepped up mentioning uses they had for the information for Guido to retract the suggestion in the name of backwards compatibility.

But unbound methods are now on the list of things to go in Python 3000.

Contributing threads:

• Let's get rid of unbound methods
• Getting rid of unbound methods: patch available
• PEP 246 - concrete assistance to developers of new adapter classes

Getting exceptions to be new-style classes

A patch to allow exceptions to be new-style classes is currently at http://www.python.org/1104669 . The plan is to get that patch in order, apply it, and as long as a ton of code does not break from exceptions moving from classic to new-style classes it will be made permanent in 2.5 .

This in no way touches on the major changes as touched upon in a previous summary which will need a PEP to get the hierarchy cleaned up and discuss any possible changes to bar 'except' statements.

Contributing threads:

• Exceptions *must*? be old-style classes?

Recent IBM patents and Python

note:: contributed by Jim Jewett

Current python policy is that all submissions must be unemcumbered by intellectual property claims. See http://www.python.org/psf/psf-contributor-agreement.html

IBM has recently released several patents for use in Open Source Software, with the restriction that they can revoke the grant if you sue to enforce any Intellectual Property rights against any Open Source project.

Is this an acceptable license restriction, or should code covered by these patents be rejected? No explicit decision was made.

Contributing threads:

• Recent IBM Patent releases