Mailman 3 June 2009 - Python-Dev

CPython in the web browser under Native Client
by Mark Seaborn 17 Jun '09

17 Jun '09

I have been doing some work to extend Google's Native Client [1] to support dynamic linking [2]. 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 [3]. I haven't implemented accessing the DOM from Python yet - that's another project for later. :-) Mark [1] http://code.google.com/p/nativeclient/ [2] http://plash.beasts.org/wiki/NativeClient [3] http://lackingrhoticity.blogspot.com/2009/06/python-standard-library-in-nat…

4 3

Re: [Python-Dev] Functions that steal references (Re: [pygame] [patch] minor memory leaks...)
by Hrvoje Niksic 17 Jun '09

17 Jun '09

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 >>> oddity? >> >> 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.

1 0

Functions that steal references (Re: [pygame] [patch] minor memory leaks...)
by Greg Ewing 17 Jun '09

17 Jun '09

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 oddity? 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. -- Greg

3 3

Iterator version of contextlib.nested
by Hagen Fürstenau 15 Jun '09

15 Jun '09

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 (http://mail.python.org/pipermail/python-dev/2009-May/089359.html), that doesn't cover the case of a variable number of context managers, i.e. with contextlib.nested(*list_of_managers) as list_of_results: or with contexlib.nested(*iterator_of_managers): 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). - Hagen

6 16

Is the py3k mercurial mirror broken?
by Paul Moore 15 Jun '09

15 Jun '09

I get the following: >hg version 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 adding changesets transaction abort! rollback completed ** 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 Paul.

2 1

ctime: I don't think that word means what you think it means.
by Zooko Wilcox-O'Hearn 14 Jun '09

14 Jun '09

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 else: 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 following: 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. This is 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 . Regards, Zooko

4 3

Distributed computing & sending the interpreter
by Jeremy Cowles 14 Jun '09

14 Jun '09

Hi all, I apologize if this question is misplaced, I wasn't sure which list to post it in. 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 greatly appreciated. Thanks, Jeremy

2 2

Re: [Python-Dev] FINAL PROPULSION OPEN SOURCE ENGINE VARIANT FOR THE F-35 JOINT STRIKE FIGHTER
by OMEGA RED 13 Jun '09

13 Jun '09

Guido, 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? Thank You. W108dab --- 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. --Guido On Sat, Jun 13, 2009 at 7:27 AM, OMEGA RED<omega_force2003(a)yahoo.com> wrote: > Yes, > > 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, > > w108dab > > > 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> > wrote: >> >> >> 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. >> >> THANKS, >> >> W108DAB >> >> _______________________________________________ >> Python-Dev mailing list >> Python-Dev(a)python.org >> http://mail.python.org/mailman/listinfo/python-dev >> Unsubscribe: >> http://mail.python.org/mailman/options/python-dev/josepharmbruster%40gmail.… >> > > > -- --Guido van Rossum (home page: http://www.python.org/~guido/)

2 1

FINAL PROPULSION OPEN SOURCE ENGINE VARIANT FOR THE F-35 JOINT STRIKE FIGHTER
by OMEGA RED 13 Jun '09

13 Jun '09

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. THANKS, W108DAB

9 10

[RELEASED] Python 3.1 Release Candidate 2
by Benjamin Peterson 13 Jun '09

13 Jun '09

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 distribution. 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 http://bugs.python.org For more information and downloadable distributions, see the Python 3.1 website: http://www.python.org/download/releases/3.1/ See PEP 375 for release schedule details: http://www.python.org/dev/peps/pep-0375/ Enjoy, -- Benjamin Benjamin Peterson benjamin at python.org Release Manager (on behalf of the entire python-dev team and 3.1's contributors)

1 0