Re: [Python-Dev] Recent experience with the _ast module
Collin Winter schrieb: > But Pass, Break, Continue and Ellipsis aren't in the same category as > Add, Mult, Div, etc.. The former stand alone That's not true. Pass, Break, Continue don't stand alone; they are members of the body sequence of some other statement (in particular for Break and Continue), you need some kind of loop around it. In any case, they are in the same category as they have no child nodes, which is a prerequisite for not creating objects. I can't see why the property "stand alone" should impact whether objects are created or not. > So: what if _ast.Add and co. were singleton instances of _ast.AST or > even of a subclass of AST, like _ast.Op? That way, we keep the > consistency that all AST nodes are instances of _ast.AST and I get the > nice property I'm looking for, ie, "node.op is _ast.Mult". I like this better. The base class you are looking for is _ast.operator; it should be already there (please do take a look at Python.asdl to see how I came to this conclusion, without studying the _ast module again). 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] urllib2 EP + decr. startup time
> Right -- most of your problem will be solved by creating
> 'C:\\WINDOWS\\system32\\python25.zip', containing the contents of
> C:\\Python25\\lib\\.
C:\\Python25\\lib\\. contain *many* packages with .dll files - i can't
just zip it.
wxPython,pyOpenGL,PIL,tk and so on. On Fedora 6 more than 40% dirs of
/usr/lib/site-packages contained .so files. Some of them add dirs to path
(wx,PIL,Gtk,...).
yum,apt and other will bee very angry if i zip site-packages directory.
I don't known any package manager which can properly work with
packages installed in archive.
Are setuptools can work properly with packages packed in one big zip archive
(i really don't known)?
And finally - if it's so easy why this don't done already? Python widely used
in many linux distros and i don't known any one which can install even
standard library
in zip archive. Most of users can't done it(because they don't known
about python at all).
Or this just because lack of time?
Yesterday i test some programs with strace and receive follow results:
command num of sys_calls num of FILE_NOT_FOUND
python -c "pass" 2807 619 ~20%
yum 20263 11282>50%
pychecker 61812527 ~40%
meld(nice GUI merge util)160758024 50%
ipython < exit.txt164488957 >50%
(exit txt contain "exit()\n")
(if filter some of FILE_NOT_FOUND
which are not produced by python modules search)
BTW. In trace results many call chain like this:
open("/usr/lib/python2.4/site-packages/Durus-3.6-py2.4-linux-i686.egg",
O_RDONLY|O_LARGEFILE) = 6
..
_llseek(6, 98304, [98304], SEEK_SET)= 0
read(6, "\340\377\224\322\373C\200\177.\245\367\205\0\307x\207\r"...,
4096) = 4096
_llseek(6, 102400, [102400], SEEK_SET) = 0
_llseek(6, 102400, [102400], SEEK_SET) = 0
_llseek(6, 102400, [102400], SEEK_SET) = 0
.
and so on. As i understand all
_llseek(6, 102400, [102400], SEEK_SET) = 0
calls after first are just heating air.
--
K.Danilov aka KoDer
___
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] urllib2 EP + decr. startup time
KoDer schrieb:
> open("/usr/lib/python2.4/site-packages/Durus-3.6-py2.4-linux-i686.egg",
> O_RDONLY|O_LARGEFILE) = 6
> ..
> _llseek(6, 98304, [98304], SEEK_SET)= 0
> read(6, "\340\377\224\322\373C\200\177.\245\367\205\0\307x\207\r"...,
> 4096) = 4096
> _llseek(6, 102400, [102400], SEEK_SET) = 0
> _llseek(6, 102400, [102400], SEEK_SET) = 0
> _llseek(6, 102400, [102400], SEEK_SET) = 0
> .
> and so on. As i understand all
> _llseek(6, 102400, [102400], SEEK_SET) = 0
> calls after first are just heating air.
If you want to implement a patch to eliminate unnecessary
system calls, please submit it to sf.net/projects/python.
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] generic async io (was: microthreading vs. async io)
On Fri, Feb 16, 2007 at 01:28:01PM +1300, Greg Ewing wrote: > Nick Maclaren wrote: > > > Threading > > - > > > > An I/O operation passes a buffer, length, file and action and receives a > > token back. > > You seem to be using the word "threading" in a completely > different way than usual here, which may be causing some > confusion. According to subsequent clarification, the kind of IO Nick is talking about is the sort of thing described recently on kerneltrap: http://kerneltrap.org/node/7728 (although he was referring specifically to POSIX async IO) Dustin ___ 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] urllib2 EP + decr. startup time
At 01:25 PM 2/17/2007 +0200, KoDer wrote:
>C:\\Python25\\lib\\. contain *many* packages with .dll files - i can't
>just zip it.
>wxPython,pyOpenGL,PIL,tk and so on. On Fedora 6 more than 40% dirs of
>/usr/lib/site-packages contained .so files. Some of them add dirs to path
>(wx,PIL,Gtk,...).
I'm not talking about the subdirectories under lib, just lib itself. That
is, the Python standard library. Stdlib DLLs are in a separate
subdirectory ('DLLs' on Windows, 'lib-dynload' most other places).
>Are setuptools can work properly with packages packed in one big zip archive
>(i really don't known)?
I don't follow you; this has nothing to do with setuptools. It's a feature
of Python since version 2.3, but as far as I know nobody's ever set up the
build machinery to create the necessary zipfile when Python is
installed. Perhaps that would be a nice place to begin your patch: a
script to create a stdlib zipfile in the platform-appropriate location,
that can run after the bytecode compilation of the stdlib modules, or that
users can run on older versions of Python to do the same thing.
___
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] Recent experience with the _ast module
On 2/17/07, "Martin v. Löwis" <[EMAIL PROTECTED]> wrote: > Collin Winter schrieb: > > But Pass, Break, Continue and Ellipsis aren't in the same category as > > Add, Mult, Div, etc.. The former stand alone > > That's not true. Pass, Break, Continue don't stand alone; they are > members of the body sequence of some other statement (in particular > for Break and Continue), you need some kind of loop around it. > > In any case, they are in the same category as they have no child > nodes, which is a prerequisite for not creating objects. I can't > see why the property "stand alone" should impact whether objects > are created or not. I phrased that poorly. If Pass, Break and Continue were made into singleton instances, they wouldn't be able to be handled by the same visitor dispatch routine as the other statement types. Taking Demo/parser/unparse.py as an example, Unparser.dispatch would have to change to handle Break, Pass and Continue specially from the others. Changing the operator and context nodes to be singleton instances involves just modifying the dispatch tables used by _BoolOp, _BinOp, etc. Collin Winter ___ 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] pypy-0.99.0: new object spaces, optimizations, configuration ...
= pypy-0.99.0: new object spaces, optimizations, configuration ... = Welcome to the PyPy 0.99.0 release - a major snapshot and milestone of the last 8 months of work and contributions since PyPy-0.9.0 came out in June 2006! Main entry point for getting-started/download and documentation: http://codespeak.net/pypy/dist/pypy/doc/index.html Further below you'll find some notes about PyPy, the 0.99.0 highlights and our aims for PyPy 1.0. have fun, the PyPy team, Samuele Pedroni, Carl Friedrich Bolz, Armin Rigo, Michael Hudson, Maciej Fijalkowski, Anders Chrigstroem, Holger Krekel, Guido Wesdorp and many others: http://codespeak.net/pypy/dist/pypy/doc/contributor.html What is PyPy? Technically, PyPy is both a Python Interpreter implementation and an advanced Compiler, actually a framework for implementing dynamic languages and generating virtual machines for them. The Framework allows for alternative frontends and for alternative backends, currently C, LLVM and .NET. For our main target "C", we can can "mix in" different Garbage Collectors and threading models, including micro-threads aka "Stackless". The inherent complexity that arises from this ambitious approach is mostly kept away from the Python interpreter implementation, our main frontend. Socially, PyPy is a collaborative effort of many individuals working together in a distributed and sprint-driven way since 2003. PyPy would not have gotten as far without the coding, feedback and general support from numerous people. Formally, many of the current developers are involved in executing an EU contract with the goal of exploring and researching new approaches to Language/Compiler development and software engineering. This contract's duration is about to end March 2007 and we are working and preparing the according final review which is scheduled for May 2007. Key 0.99.0 Features = * new object spaces: - Tainting: a 270-line proxy object space tracking and boxing sensitive information within an application. A tainted object is completely barred from crossing an I/O barrier, such as writing to files, databases or sockets. This allows to significantly reduce the effort of e.g. security reviews to the few places where objects are "declassified" in order to send information across I/O barriers. - Transparent proxies: allow to customize both application and builtin objects from application level code. Works as an addition to the Standard Object Space (and is translatable). For details see http://codespeak.net/pypy/dist/pypy/doc/proxy.html * optimizations: - Experimental new optimized implementations for various built in Python types (strings, dicts, lists) - Optimized builtin lookups to not require any dictionary lookups if the builtin is not shadowed by a name in the global dictionary. - Improved inlining (now also working for higher level backends) and malloc removal. - twice the speed of the 0.9 release, overall 2-3 slower than CPython * High level backends: - It is now possible to translate the PyPy interpreter to run on the .NET platform, which gives a very compliant (but somewhat slow) Python interpreter. - the JavaScript backend has evolved to a point where it can be used to write AJAX web applications with it. This is still an experimental technique, though. For demo applications see: http://play1.codespeak.net:8008/ * new configuration system: There is a new comprehensive configuration system that allows fine-grained configuration of the PyPy standard interpreter and the translation process. * new and improved modules: Since the last release, the signal, mmap, bz2 and fcntl standard library modules have been implemented for PyPy. The socket, _sre and os modules have been greatly improved. In addition we added a the pypymagic module that contains PyPy-specific functionality. * improved file implementation: Our file implementation was ported to RPython and is therefore faster (and not based on libc). * The stability of stackless features was greatly improved. For more details see: http://codespeak.net/pypy/dist/pypy/doc/stackless.html * RPython library: The release contains our emerging RPython library that tries to make programming in RPython more pleasant. It contains an experimental parser generator framework. For more details see: http://codespeak.net/pypy/dist/pypy/doc/rlib.html * improved documentation: - extended documentation about stackless features: http://codespeak.net/pypy/dist/pypy/doc/stackless.html - PyPy video documentation: eight hours of talks, interviews and features: http://codespeak.net/pypy/dist/pypy/doc/video-index.html - technical reports about various aspects
Re: [Python-Dev] Lack of sequential decompression in the zipfile module
On 2/16/07, Derek Shockey <[EMAIL PROTECTED]> wrote: > Since I was writing a script to work with potentially very large zipped > files, I took it upon myself to write an extract() method for zipfile, which > is essentially an adaption of the read() method modeled after tarfile's > extract(). I feel that this is something that should really be provided in > the zipfile module to make it more usable. I'm wondering if this has been > discussed before, or if anyone has ever viewed this as a problem. I can post > the code I wrote as a patch, though I'm not sure if my file IO handling is > as robust as it needs to be for the stdlib. I'd appreciate any insight into > the issue or direction on where I might proceed from here so as to fix what > I see as a significant problem. I ran into the same thing and made a patch a long while ago (the one Martin mentioned): https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1121142&group_id=5470 I am actually working on it this weekend; if you'd like to exchange code/test cases/whatever feel free to send me your stuff. I'll try to get a patch that works against the trunk posted today or tomorrow if you want to try it out. Cheers, Alan ___ 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
