Re: [Python-Dev] Minipython
Thank you people. I'm going to try to strip unneeded things and let you know the result. Along with running Python on an embedded system, I am considering two more things. Suppose the system to be a small Linux router, which, after the kernel starts, merely configures lots of parameters of the kernel and then runs some daemons for gathering statistics and allowing remote control of the host. Python helps mainly in the startup phase of configuring kernel according to a human-readable confgiuration files. This has been solved by shell scripts. Python is not as suitable for running external processes and process pipes as a shell, but I'd like to write a module (at least) helping him in the sense of scsh (a "Scheme shell", http://www.scsh.net). A more advanced solution is to replace system's init (/sbin/init) by Python. It should even speed the startup up as it will not need to run shell many times. To avoid running another processes, I want to "port them" to Python. Processes for kernel configuration, like iproute2, iptables etc. are often built above its own library, which can be used as a start point. (Yes, it does matter, at startup, routers run such processes hundreds times). Milan On Sun, Sep 24, 2006 at 06:49:34AM +0200, "Martin v. Löwis" wrote: > Milan Krcmar schrieb: > > Can you give me any information to start with? I would prefer stripping > > current version of Python rather than returning to a years-old (but > > smaller) version and remembering what of the new syntax/functionality to > > avoid. > > I would start with dropping support for dynamic loading of extension > modules, and link all necessary modules statically. > > Then, do what Michael Hudson says: find out what is taking up space. > > size */*.o|sort -n > > should give a good starting point; on my system, I get > > [...] > 293561416 156 3092878d0 Objects/classobject.o > 30663 0 0 3066377c7 Objects/unicodectype.o > 33530 480 536 3454686f2 Python/Python-ast.o > 336241792 616 360328cc0 Objects/longobject.o > 36603 16 288 36907902b Python/ceval.o > 367102532 0 39242994a Modules/_sre.o > 3916994731032 49674c20a Objects/stringobject.o > 52965 0 36 53001cf09 Python/compile.o > 661974592 436 71225 11639 Objects/typeobject.o > 7411197791160 85050 14c3a Objects/unicodeobject.o > > Michael already mentioned you can drop unicodeobject if you want > to. compile.o would also offer savings, but stripping it might > not be easy. Dropping _sre is quite easy. If you manage to > drop compile.o, then dropping Python-ast.o (along with the > rest of the compiler) should also be possible. > unicodectype will go away if the Unicode type goes, but can > probably be removed separately. And so on. > > When you come to a solution that satisfies your needs, > don't forget to document it somewhere. > > Regards, > Martin ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] PyErr_CheckSignals error return value
int PyErr_CheckSignals() Documentation for PyErr_CheckSignals [1] says "If an exception is raised the error indicator is set and the function returns 1; otherwise the function returns 0.". But the code I see tells me the function returns -1 on error. What to do? Fix the code, or the documentation? [1] http://docs.python.org/api/exceptionHandling.html#l2h-115 -- Gustavo J. A. M. Carneiro "The universe is always one step beyond logic." ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Python 2.5 bug? Changes in behavior of traceback module
Michael Glassford wrote: > In Python 2.4, traceback.print_exc() and traceback.format_exc() silently > do nothing if there is no active exception; in Python 2.5, they raise an > exception. Not too difficult to handle, but unexpected (and a pain if > you use it in a lot of places). I assume it was an unintentional change? This was certainly an unintentional change while restructuring some internal traceback routines. It's now fixed in SVN. Georg ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Signals, threads, blocking C functions
-> http://www.python.org/sf/1564547 -- Gustavo J. A. M. Carneiro "The universe is always one step beyond logic." ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] list.discard? (Re: dict.discard)
> When I want to remove something from a list I typically write: > > while x in somelist: > somelist.remove(x) An O(n) version of removeall: somelist[:] = [e for e in somelist if e != x] Raymond ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Typo.pl scan of Python 2.5 source code
"Neal Norwitz" <[EMAIL PROTECTED]> wrote in message news:[EMAIL PROTECTED] > I ignored these as I'm not certain all the platforms we run on accept > free(NULL). > That sounds like exactly what the autotools are designed for. You simply use free(), and have autoconf check for support of free(NULL). If free(NULL) is broken then a macro is defined: "#define free(p) (p==NULL)||free(p)" Or something like that. Note that this does not clutter up the main program any. In fact it simplifies it. It also potentially speeds up platforms with a working free, without any negative speed implications for other platforms. The only downside is a slight, presumably negligible, increase in build time. ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
