I have been doing some work to extend Google's Native Client  to
support dynamic linking . For those who haven't heard of it,
Native Client is a sandboxing system for running a subset of x86 code.
It is proposed as a way of running native code inside web apps.
One of my aims has been to get CPython working in the web browser
under Native Client without having to modify CPython.
I recently got to the point where modules from the Python standard
library are importable under Native Client, including (as a
demonstration) the Sqlite extension module. Sqlite also requires no
modification - it builds straight from the Debian package.
I've written a simple REPL to demonstrate Python running in the
browser. There are some screenshots on my blog . I haven't
implemented accessing the DOM from Python yet - that's another project
for later. :-)
Christian Heimes wrote:
>>>> I assumed that since PyModule_AddObject is documented as stealing a
>>>> reference, it always stole a reference. But in reality it only does so
>>>> conditionally, when it succeeds.
>>> As an aside, is this a general feature of functions
>>> that steal references, or is PyModule_AddObject an
>> IIRC, It's an oddity.
> But it is a convenient oddity nonetheless.
Stealing references is sometimes convenient, but Greg was referring to
functions that steal references *conditionally*, which is indeed an
oddity. Most functions and macros that steal references do so
unconditionally, typically because they can't fail anyway. Conditional
stealing of references requires very careful thinking on the side of
callers that care about not leaking references in the face of
exceptions. See http://bugs.python.org/issue1782 for an example.
Lenard Lindstrom wrote:
> I assumed that since PyModule_AddObject is documented as
> stealing a reference, it always stole a reference. But in reality it
> only does so conditionally, when it succeeds.
As an aside, is this a general feature of functions
that steal references, or is PyModule_AddObject an
I ask because I've been thinking about adding features
to Pyrex for dealing with stolen references, and it
could be important to know things like this.
Also, if it's an oddity, it would be a good idea
to mention this behaviour in the docs.
contextlib.nested has recently been deprecated on grounds of being
unnecessary now that the with statement accepts multiple context
managers. However, as has been mentioned before
doesn't cover the case of a variable number of context managers, i.e.
with contextlib.nested(*list_of_managers) as list_of_results:
It was suggested that in these use cases a custom context manager should
be implemented. However, it seems that such an implementation would be
an almost exact copy of the present code for "nested".
I'm proposing to add an iterator version of "nested" to contextlib
(possibly called "inested"), which takes an iterable of context managers
instead of a variable number of parameters. The implementation could be
taken over from the present "nested", only changing "def
nested(*managers)" to "def inested(managers)".
This has the advantage that an iterator can be passed to "inested", so
that each context managers is created in the context of all previous
ones, which was one of the reasons for introducing the multi-with
statement in the first place. "contextlib.inested" would therefore be
the generalization of the multi-with statement to a variable number of
managers (and "contextlib.nested" would stay deprecated).
I get the following:
Mercurial Distributed SCM (version 1.2)
Copyright (C) 2005-2008 Matt Mackall <mpm(a)selenic.com> and others
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
>hg clone http://code.python.org/hg/branches/py3k python-3k
requesting all changes
** unknown exception encountered, details follow
** report bug details to http://www.selenic.com/mercurial/bts
** or mercurial(a)selenic.com
** Mercurial Distributed SCM (version 1.2)
** Extensions loaded:
Traceback (most recent call last):
File "hg", line 27, in <module>
File "mercurial\dispatch.pyc", line 16, in run
File "mercurial\dispatch.pyc", line 25, in dispatch
File "mercurial\dispatch.pyc", line 41, in _runcatch
File "mercurial\dispatch.pyc", line 372, in _dispatch
File "mercurial\dispatch.pyc", line 247, in runcommand
File "mercurial\dispatch.pyc", line 417, in _runcommand
File "mercurial\dispatch.pyc", line 377, in checkargs
File "mercurial\dispatch.pyc", line 371, in <lambda>
File "mercurial\util.pyc", line 718, in check
File "mercurial\commands.pyc", line 603, in clone
File "mercurial\hg.pyc", line 215, in clone
File "mercurial\localrepo.pyc", line 2149, in clone
File "mercurial\localrepo.pyc", line 1492, in pull
File "mercurial\localrepo.pyc", line 2016, in addchangegroup
File "mercurial\revlog.pyc", line 1192, in addgroup
File "mercurial\changegroup.pyc", line 31, in chunkiter
File "mercurial\changegroup.pyc", line 15, in getchunk
File "mercurial\util.pyc", line 1674, in read
File "mercurial\httprepo.pyc", line 18, in zgenerator
zlib.error: Error -3 while decompressing: incorrect header check
The stat module uses the "st_ctime" slot to hold two kinds of values
which are semantically different and which are frequently
confused with one another. It chooses which kind of value to put in
there based on platform -- Windows gets the file creation time and all
other platforms get the "ctime". The only sane way to use this API is
then to switch on platform:
if platform.system() == "Windows":
metadata["creation time"] = s.st_ctime
metadata["unix ctime"] = s.st_ctime
(That is an actual code snippet from the Allmydata-Tahoe project.)
Many or even most programmers incorrectly think that unix ctime is file
creation time, so instead of using the sane idiom above, they write the
metadata["ctime"] = s.st_ctime
thus passing on the confusion to the users of their metadata, who may
not be able to tell on which platform this metadata was created.
the situation we have found ourselves in for the Allmydata-Tahoe
project -- we now have a bunch of "ctime" values stored in our
filesystem and no way to tell which kind they were.
More and more filesystems such as ZFS and Mac HFS+ apparently offer
creation time nowadays.
I propose the following changes:
1. Add a "st_crtime" field which gets populated on filesystems
(Windows, ZFS, Mac) which can do so.
That is hopefully not too controversial and we could proceed to do so
even if the next proposal gets bogged down:
2. Add a "st_unixctime" field which gets populated *only* by the unix
ctime and never by any other value (even on Windows, where the unix
ctime *is* available even though nobody cares about it), and deprecate
the hopelessly ambiguous "st_ctime" field.
You may be interested in http://allmydata.org/trac/tahoe/ticket/628
("mtime" and "ctime": I don't think that word means what you think it
means.) where the Allmydata-Tahoe project is carefully unpicking the
mess we made for ourselves by confusing ctime with file-creation time.
This is ticket http://bugs.python.org/issue5720 .
I apologize if this question is misplaced, I wasn't sure which list to post
I'm working on a distributed computing project (PyMW and BOINC) where we are
sending Python scripts to client machines. Currently, we make two very
unlikely assumptions: that Python 2.5 is installed and that the interpreter
is available on the PATH.
We are looking at our options to remove this assumption and the two most
likely are redistributing the entire Python installation (for each supported
platform) and embedding the interpreter in a custom executable and sending
select parts of the standard library with it (to reduce size).
It seems like we would have to pre-compile for each different platform,
which is a pain and sending the entire installation could be tricky.
I am looking for alternatives, comments and suggestions. Any help would be
The reason why I use a code name is that it would be dangerous to reveal my true name to the world since there are those who are radical liberals who would like to think that there is no need for a U.S. military and that people such as myself should be eliminated. Think of the U.S. military as the heroes that they truly are to protect its citizens from attack from other entities. The U.S. military is here to serve and protect people such as yourself, not to act as the terrorist organization as bin laden would like you to think. If any of you need any further evidence of the need of the U.S. military or the F-35 for that matter, then I would suggest that you all take a nice long trip to Manhattan island in New York City and take some time to notice the fact that there appears to be a large hole where many buildings used to be located.
Second, the biggest concern that I see in utilizing the python language in safety-critical systems is that it is a dynamically type language. Unlike Ada which is safety statically type language. These were just brainstorming ideas, but if you do not like those that brainstorm regarding the further development of python, then I guess I will be moving forward to some other language that is more capable to assist in the development of safety critical systems. These were just brainstorming ideas.
The idea being is to research onto the idea of developing a statically type variant of the python language for the development of software for safety critical systems. Is this possible? I am also wondering if it was possible to interface Ada programs with Python, similar to the method that has been utilized to interface FORTRAN with Python. Is this also possible?
--- On Sat, 6/13/09, Guido van Rossum <guido(a)python.org> wrote:
From: Guido van Rossum <guido(a)python.org>
Subject: Re: [Python-Dev] FINAL PROPULSION OPEN SOURCE ENGINE VARIANT FOR THE F-35 JOINT STRIKE FIGHTER
To: "OMEGA RED" omega_force2003(a)yahoo.com
Date: Saturday, June 13, 2009, 11:58 AM
I'm sorry, but I have so far three problems with your proposals.
(1) You use a code name.
(2) Your first message was ALL CAPS.
(3) You don't seem to know much about programming language design, or
you wouldn't propose such a vague non-starter as "adopt the
safety-critical charasteristics of the Ada programming language an
incorporate them into Python."
This is my last message to you.
On Sat, Jun 13, 2009 at 7:27 AM, OMEGA RED<omega_force2003(a)yahoo.com> wrote:
> I think that python developers would be great in the development of the
> FADEC controller as an open-source alternative to the propreitary FADEC
> controller software to the propulsion system for the F-35. The FADEC
> controller is Full Authority Flight Digital Electronic Controller.
> I know that the python community could never possibly create the mechanical
> aspects of this proposed engine, but that does not mean that we cannot
> create something else.
> I believe that what could be done is to create a safety-critical version of
> python. Such as adopt the safety-critical charasteristics of the Ada
> programming language an incorporate them into python.
> How about that as a project? Create the python equivalent of Ada?
> Thank You,
> Subject: Re: [Python-Dev] FINAL PROPULSION OPEN SOURCE ENGINE VARIANT FOR
> THE F-35 JOINT STRIKE FIGHTER
> To: "OMEGA RED" <omega_force2003(a)yahoo.com>
> Date: Saturday, June 13, 2009, 6:16 AM
> I'm reasonably confused here, are you searching for Python developers?
> On Fri, Jun 12, 2009 at 7:01 PM, OMEGA RED <omega_force2003(a)yahoo.com>
>> TO ALL,
>> I AM HAPPY TO SAY THAT I AM NOW IN THE PROCESS OF DEVELOPING A WEBSITE FOR
>> THE STATED PURPOSE OF COMBINING SOME OF THE BEST MINDS IN THE WORLD. THIS
>> PROJECT WILL BE A MEANS TO DEVELOP THE FIRST AND ONLY COMPLETELY OPEN SOURCE
>> VARIANT OF THE PROPULSION ENGINE FOR THE F-35 JOINT STRIKE FIGHTER. WHICH
>> MEANS THAT EVERYTHING ABOUT THE DESIGN, DEVELOPMENT, AND CONSTRUCTION OF THE
>> ENGINE WILL BE COMPLETELY AVAILABLE TO THE PUBLIC AND TO ANY ENGINE
>> MANUFACTURE FREE OF ANY REQUIREMENTS.
>> THIS ENGINE WILL BE CALLED THE PHOENIX NexT F-200 ENGINE.
>> THIS ENGINE WILL ALSO BE A POTENTIAL THIRD AND FINAL ALTERNATIVE ENGINE
>> FOR THE JOINT STRIKE FIGHTER.
>> THIS ENGINE WILL BE STATED AS BEING A COMPETITOR WITH BOTH THE F-135 AND
>> THE F-136 ENGINE, WHICH ARE PROVIDED BY BOTH PRATT-WHITNEY AND GENERAL
>> ELECTRIC/ ROLLS ROYCE.
>> THIS ENGINE WILL UTILIZE PYTHON FOR THE MAJOR PORTION OF THE SIMULATION,
>> RESEARCH AND DEVELOPMENT STAGES FOR THE DEVELOPMENT OF THE ENGINE. THE
>> CONSTRUCTION OF THE MATHEMATICAL PROCESSING OF THE REQUIRED NONLINEAR
>> CONTROLS WILL BE BASED ON A SPECIALIZED VERSION OF GROUP THEORY FOR THE
>> DESIGN AND CONSTRUCTION OF THE NONLINEAR CONTROL SYSTEMS.
>> THE PURPOSE OF THE DEVELOPMENT OF THE ENGINE WILL BE TO CONSTRUCT AN
>> ENGINE FOR THE F-35 THAT WILL BE AS RELIABLE AND CAPABLE AS THE F-135 AND
>> THE F-136.
>> HOWEVER, THE PHOENIX NexT ENGINE WILL ALSO BE STATED AS BEING ONLY AROUND
>> $20,000 TO $110,000 DOLLARS TO BEING PURCHASED BY AN OPERATOR OF THE F-35,
>> WHICH WILL BE AN INSIGNIFICANT COST COMPARED TO THE COST OF BOTH THE F-135
>> AND THE F-136 ENGINE (10 MILLION DOLLARS PER UNIT).
>> HOW MANY OUT THERE WANT TO HELP IN THIS ENDEAVOR ? I BELIEVE THAT WE
>> ALL CAN SUCCEED WHERE BOTH PRATT-WHITNEY AND GE/ROLLS ROYCE HAVE FAILED TO
>> DEVELOP AN INEXPENSIVE AND RELIABLE ENGINE FOR THE F-35.
>> Python-Dev mailing list
--Guido van Rossum (home page: http://www.python.org/~guido/)
I AM HAPPY TO SAY THAT I AM NOW IN THE PROCESS OF DEVELOPING A WEBSITE FOR THE STATED PURPOSE OF COMBINING SOME OF THE BEST MINDS IN THE WORLD. THIS PROJECT WILL BE A MEANS TO DEVELOP THE FIRST AND ONLY COMPLETELY OPEN SOURCE VARIANT OF THE PROPULSION ENGINE FOR THE F-35 JOINT STRIKE FIGHTER. WHICH MEANS THAT EVERYTHING ABOUT THE DESIGN, DEVELOPMENT, AND CONSTRUCTION OF THE ENGINE WILL BE COMPLETELY AVAILABLE TO THE PUBLIC AND TO ANY ENGINE MANUFACTURE FREE OF ANY REQUIREMENTS.
THIS ENGINE WILL BE CALLED THE PHOENIX NexT F-200 ENGINE.
THIS ENGINE WILL ALSO BE A POTENTIAL THIRD AND FINAL ALTERNATIVE ENGINE FOR THE JOINT STRIKE FIGHTER.
THIS ENGINE WILL BE STATED AS BEING A COMPETITOR WITH BOTH THE F-135 AND THE F-136 ENGINE, WHICH ARE PROVIDED BY BOTH PRATT-WHITNEY AND GENERAL ELECTRIC/ ROLLS ROYCE.
THIS ENGINE WILL UTILIZE PYTHON FOR THE MAJOR PORTION OF THE SIMULATION, RESEARCH AND DEVELOPMENT STAGES FOR THE DEVELOPMENT OF THE ENGINE. THE CONSTRUCTION OF THE MATHEMATICAL PROCESSING OF THE REQUIRED NONLINEAR CONTROLS WILL BE BASED ON A SPECIALIZED VERSION OF GROUP THEORY FOR THE DESIGN AND CONSTRUCTION OF THE NONLINEAR CONTROL SYSTEMS.
THE PURPOSE OF THE DEVELOPMENT OF THE ENGINE WILL BE TO CONSTRUCT AN ENGINE FOR THE F-35 THAT WILL BE AS RELIABLE AND CAPABLE AS THE F-135 AND THE F-136.
HOWEVER, THE PHOENIX NexT ENGINE WILL ALSO BE STATED AS BEING ONLY AROUND $20,000 TO $110,000 DOLLARS TO BEING PURCHASED BY AN OPERATOR OF THE F-35, WHICH WILL BE AN INSIGNIFICANT COST COMPARED TO THE COST OF BOTH THE F-135 AND THE F-136 ENGINE (10 MILLION DOLLARS PER UNIT).
HOW MANY OUT THERE WANT TO HELP IN THIS ENDEAVOR ? I BELIEVE THAT WE ALL CAN SUCCEED WHERE BOTH PRATT-WHITNEY AND GE/ROLLS ROYCE HAVE FAILED TO DEVELOP AN INEXPENSIVE AND RELIABLE ENGINE FOR THE F-35.
On behalf of the Python development team, I'm happy to announce the second
release candidate of Python 3.1.
Python 3.1 focuses on the stabilization and optimization of the features and
changes that Python 3.0 introduced. For example, the new I/O system has been
rewritten in C for speed. File system APIs that use unicode strings now handle
paths with undecodable bytes in them. Other features include an ordered
dictionary implementation, a condensed syntax for nested with statements, and
support for ttk Tile in Tkinter. For a more extensive list of changes in 3.1,
see http://doc.python.org/dev/py3k/whatsnew/3.1.html or Misc/NEWS in the Python
This is a release candidate, and as such, we do not recommend use in production
environments. However, please take this opportunity to test the release with
your libraries or applications. This will hopefully discover bugs before the
final release and allow you to determine how changes in 3.1 might impact you.
If you find things broken or incorrect, please submit a bug report at
For more information and downloadable distributions, see the Python 3.1 website:
See PEP 375 for release schedule details:
benjamin at python.org
(on behalf of the entire python-dev team and 3.1's contributors)