[Python-Dev] Last chance to join the Summer of PyPy!
Hopefully by now you have heard of the "Summer of PyPy", our program for funding the expenses of attending a sprint for students. If not, you've just read the essence of the idea :-) However, the PyPy EU funding period is drawing to an end and there is now only one sprint left where we can sponsor the travel costs of interested students within our program. This sprint will probably take place in Leysin, Switzerland from 8th-14th of January 2007. So, as explained in more detail at: http://codespeak.net/pypy/dist/pypy/doc/summer-of-pypy.html we would encourage any interested students to submit a proposal in the next month or so. If you're stuck for ideas, you can find some at http://codespeak.net/pypy/dist/pypy/doc/project-ideas.html but please do not feel limited in any way by this list! Cheers, mwh ... and the PyPy team -- the highest calling of technical book writers is to destroy the sun -- from Twisted.Quotes ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] test_ucn fails for trunk on x86 Ubuntu Edgy
On 11/7/06, "Martin v. Löwis" <[EMAIL PROTECTED]> wrote: > Grig Gheorghiu schrieb: > > One of the Pybots buildslaves running x86 Ubuntu Edgy has been failing > > the unit test step for the trunk, specifically the test_ucn test. > > Something is wrong with the machine. I forced a clean rebuild, and > now it crashes in test_doctest2: > > http://www.python.org/dev/buildbot/community/all/x86%20Ubuntu%20Edgy%20trunk/builds/145/step-test/0 > > So either the compiler or some library has been updated in a strange > way, or there is a hardware problem. One would need access to the > machine to find out (and analyzing it is likely time-consuming). > > Regards, > Martin > Thanks for looking into it. I'll contact the owner of that machine and we'll try to figure out what's going on. Grig ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Importing .pyc in -O mode and vice versa
Martin v. Löwis wrote: > a) the directory cache is out of date, and you should >re-read the directory > b) the module still isn't there, but is available in >a later directory on sys.path (which hasn't yet >been visited) > c) the module isn't there at all, and the import will >eventually fail. > > How can the interpreter determine which of these it > is? It doesn't need to - if there is no file for the module in the cache, it assumes that the cache could be out of date and rebuilds it. If that turns up a file, then fine, else the module doesn't exist. BTW, I'm not thinking of cacheing individual directories, but scanning all the directories and building a single qualified_module_name -> pathname mapping. If the cache gets invalidated, all the directories along the path are re-scanned, so a new module will be picked up wherever it is on the path. -- Greg ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Importing .pyc in -O mode and vice versa
Greg Ewing schrieb: > Martin v. Löwis wrote: > >> a) the directory cache is out of date, and you should >>re-read the directory >> b) the module still isn't there, but is available in >>a later directory on sys.path (which hasn't yet >>been visited) >> c) the module isn't there at all, and the import will >>eventually fail. >> >> How can the interpreter determine which of these it >> is? > > It doesn't need to - if there is no file for the module > in the cache, it assumes that the cache could be out > of date and rebuilds it. If that turns up a file, then > fine, else the module doesn't exist. I lost track. I thought we were talking about creating a cache of directory listings, not a stat cache? If you invalidate the cache when a file name is not listed, you will invalidate it on nearly every import, and multiple times, too: Python looks for foo.py, foo.pyc, foo.so, foomodule.so. At most one of them is found, the others aren't. So if foo.so would be found, are you invalidating the cache because foo.py isn't? > BTW, I'm not thinking of cacheing individual directories, > but scanning all the directories and building a single > qualified_module_name -> pathname mapping. If the cache > gets invalidated, all the directories along the path > are re-scanned, so a new module will be picked up > wherever it is on the path. That won't work well with path import objects. You have to observe the order in which sys.path is scanned, for correct semantics. Regards, Martin ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] Using SCons for cross-compilation
Patch #841454 takes a stab at cross-compilation (for MingW32 on a Linux system, in this case), and proposes to use SCons instead of setup.py to compile extension modules. Usage of SCons would be restricted to cross-compilation (for the moment). What do you think? Regards, Martin ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Using SCons for cross-compilation
On Thursday 09 November 2006 16:30, Martin v. Löwis wrote: > Patch #841454 takes a stab at cross-compilation > (for MingW32 on a Linux system, in this case), > and proposes to use SCons instead of setup.py > to compile extension modules. Usage of SCons > would be restricted to cross-compilation (for > the moment). > > What do you think? So we'd now have 3 places to update when things change (setup.py, PCbuild area, SCons)? How does this deal with the problems that autoconf has with cross-compilation? It would seem to me that just fixing the extension module building is a tiny part of the problem... or am I missing something? Anthony -- Anthony Baxter <[EMAIL PROTECTED]> It's never too late to have a happy childhood. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
