Mailman 3 July 2007 - Python-Dev

Add a -z interpreter flag to execute a zip file
by Andy C July 24, 2007

July 24, 2007

(resending this now that I'm subscribed, not sure it made it through the moderation the first time) I'd like to request comments on this patch I submitted: https://sourceforge.net/tracker/index.php?func=detail&aid=1739468&group_id=… There are many details given in the comments on that page. This can be used to deploy Python programs in a very lightweight and cross-platform way. You could imagine a cgi script or a light web app server being deployed like this. I have personally deployed Python programs using zip files and this would get rid of the need for boilerplate needed for each platform. The good thing about this is that it's extremely simple -- basically 20 lines of C code to add a -z flag that calls a 3-line Python function in the runpy module. I don't believe it overlaps with anything that already exists. py2exe and py2app are platform specific and bundle the Python interpreter. This will be a cross platform binary that doesn't bundle the Python interpreter. It doesn't require eggs but I think it would work fine with eggs, and could help fix a little bug as I mentioned on the patch page. Nick Coghlan has reviewed the patch and seems to think it's a good idea. Thomas Wouters also said he likes it, and I ran it by Guido earlier and he seemed to think the idea is good, although I don't think he has seen the implementation. thanks, Andy

13 26

Py3k: error byte-compiling with distutils
by Lisandro Dalcin July 24, 2007

July 24, 2007

I'm porting some of my code to py3k, and I started from the C size. After this, all extensions compiled fine, but after a 'setup.py install', I got the following: File "/usr/local/python/3.0/lib/python3.0/distutils/util.py", line 498, in byte_compile compile(file, cfile, dfile) File "/usr/local/python/3.0/lib/python3.0/py_compile.py", line 127, in compile py_exc = PyCompileError(err.__class__,err.args,dfile or file) File "/usr/local/python/3.0/lib/python3.0/py_compile.py", line 48, in __init__ tbtext = ''.join(traceback.format_exception_only(exc_type, exc_value)) File "/usr/local/python/3.0/lib/python3.0/traceback.py", line 196, in format_exception_only lines.append("%s: %s\n" % (stype, str(msg))) UnboundLocalError: local variable 'msg' referenced before assignment At this point, I had not updated my python code, so it surelly had some py3k-invalid things. Looking at 'traceback.py', it seems there is something wrong in 'format_exception_only', so this error. -- Lisandro Dalcín --------------- Centro Internacional de Métodos Computacionales en Ingeniería (CIMEC) Instituto de Desarrollo Tecnológico para la Industria Química (INTEC) Consejo Nacional de Investigaciones Científicas y Técnicas (CONICET) PTLC - Güemes 3450, (3000) Santa Fe, Argentina Tel/Fax: +54-(0)342-451.1594

2 1

Calling back into python from C
by Andrew McNamara July 24, 2007

July 24, 2007

I realise I'm going to get slapped for asking a userish question here - sorry in advance. I'm looking for an explanation for why things are the way they are, the doco and py source aren't providing the missing info, and it looks like I'm bumping into an old Python bug (fixed in r38830 by mwh on 2005-04-18). I'm working on an C extension that needs to call back into python. Generally the GIL has been released when I need to do the callback, but I can't be sure. So I need to save the GIL state, get the lock, then restore it at the end. As far as I can tell from the doco, the recommended way to do this is to use PyGILState_Ensure() and PyGILState_Release(), but prior to r38830, PyGILState_Release incorrectly used PyEval_ReleaseThread when it should have been using PyEval_SaveThread() (I think), and the result is SEGV. This poses a problem, as I need to support Python versions back to 2.3. Am I correct in using PyGILState_Ensure() and PyGILState_Release()? If so, how do I support back to Py 2.3? Copy the current fixed PyGILState_Release() into my code (ick)? -- Andrew McNamara, Senior Developer, Object Craft http://www.object-craft.com.au/

1 0

Re: [Python-Dev] Add a -z interpreter flag to execute a zip file
by Phillip J. Eby July 23, 2007

July 23, 2007

At 10:34 AM 7/23/2007 -0700, Guido van Rossum wrote: >There's an ambiguity -- a Zip file could start with a Python (or >shell, or Perl) script that bootstraps execution. This is used >regularly. Changing the semantics just because the file *ends* with >something funny sounds like asking for trouble. Actually, it isn't, because you can't start a zipfile with a Python script. Lord knows I've *tried*, but the Python interpreter just won't accept arbitrary binary data as part of a script. :) Second, unless you somehow managed to overcome that little obstacle, you're not going to be trying to run the zipfile with the Python interpreter, anyway. Instead, the #! line (or .exe header on Windows) will be invoking whatever interpreter or program actually works for that file. Third, if you mistakenly pass an existing such zipfile to a new Python interpreter that supports zipfiles, and there's no __main__.py* file in it, you're just going to get a different error message than the syntax error you'd have received from an older Python.interpreter to run it with -- but otherwise no difference. In other words, AFAICT there's really no ambiguity here.

5 4

Re: [Python-Dev] Add a -z interpreter flag to execute a zip file
by Phillip J. Eby July 23, 2007

July 23, 2007

At 09:55 AM 7/23/2007 -0700, Guido van Rossum wrote: >On 7/12/07, Daniel Stutzbach <daniel(a)stutzbachenterprises.com> wrote: > > On 7/11/07, Andy C <andychup(a)gmail.com> wrote: > > > The good thing about this is that it's extremely simple -- basically > > > 20 lines of C code to add a -z flag that calls a 3-line Python > > > function in the runpy module. > > > > Instead of requiring a -z flag, why not have the interpreter peak at > > the file to see if it starts with one of the ZIP magic numbers? > > > > That way it Just Works. > >I guess you wouldn't recognize a zip file if it hits you in the face. >Literally. :-) > >Zip files don't start with a magic number. I've actually started on a patch that uses the standard import hooks to figure out how to import __main__ from sys.argv[0], if it's something that an import hook can be found for (otherwise, it falls back to normal behavior). At this point, the problem is that __main__ is a builtin module and already exists when this processing is being done, so trying to reload it in a straightforward way doesn't work. (Nor does using the standard -m logic.) If I can figure out how to work around that bit, we won't need a -z flag, which means a #! line for zipfiles is possible on 'nix, and we can support arbitrary import hooks for sys.argv[0]. (Assuming they're either built-in or registered via sitecustomize, that is.)

1 0

Planned updates for cjkcodecs before 2.4a1
by Tae-Hee Kim July 23, 2007

July 23, 2007

Hello, I am e-mailing you because I am looking for a way to use the CJK codecs and the CJK module that I found for Python. I wasn't able to find any documentation on how to use it so I would appreciate it if you would let me know where I could find it. Thank you in advance. Taehee Kim ------------------ t.kim(a)mail.utexas.edu

2 1

Summary of Tracker Issues
by Tracker July 21, 2007

July 21, 2007

ACTIVITY SUMMARY (07/15/07 - 07/22/07) Tracker at http://bugs.python.org/ To view or respond to any of the issues listed below, click on the issue number. Do NOT respond to this message. 1646 open ( +0) / 8584 closed ( +0) / 10230 total ( +0) Average duration of open issues: 863 days. Median duration of open issues: 812 days. Open Issues Breakdown open 1646 ( +0) pending 0 ( +0)

1 0

[ANN] Python documentation team looking for members!
by Georg Brandl July 21, 2007

July 21, 2007

Dear fellow Pythonistas, as you may have heard, Python is going to get a new documentation system soon [1]. As part of that effort, and in order to maintain the excellent quality of the docs, we are looking for members of the maintainers team. This is your chance to get involved with Python development! There will be two main objectives of the group, or maybe two subgroups can be formed: * Maintaining the documentation contents: - processing user submitted comments, bugs and patches - helping out developers with docs-related matters, keeping an eye on commits to ensure quality - keeping the docs up-to-date, e.g. write new sections for new Python 3000 features The docs source will be in reStructuredText, which is already known to a relatively high percentage of Python developers. The new online version of the docs will contain features to add comments and suggest changes, so it is expected that there will be some amount of user involvement. * Development of the toolset: - fixing bugs in the package - adding new output formats, e.g. info or pdf - adding new features to the web application - adapting it to new docutils features The software is written in pure Python. It is currently located in the docutils Subversion repository, at http://svn.berlios.de/viewcvs/docutils/trunk/sandbox/py-rest-doc/ The README file gives you a rough idea what you find there and how to get started, all other questions can be directed to georg(a)python.org, I'll answer them gladly. An additional objective in the near future will, of course, be handling the switch to the new system. Okay, so you've read until here? And you're interested in joining the team? Wow! Write to the docs(a)python.org and become a documentation maintainer! cheers, Georg [1] see http://pyside.blogspot.com/2007/06/introducing-py-rest-doc.html for some details, and http://pydoc.gbrandl.de:3000/ [2] for a demo. (Commenting doesn't work yet, but it's worked upon fiercely...) [2] the demo server is a small vserver with the application served by a single wsgiref instance, and as such not fit to handle large amounts of requests, so it may well be that you don't get good reponse times. -- Thus spake the Lord: Thou shalt indent with four spaces. No more, no less. Four shall be the number of spaces thou shalt indent, and the number of thy indenting shall be four. Eight shalt thou not indent, nor either indent thou two, excepting that thou then proceed to four. Tabs are right out.

1 0

Need help fixing tests in str/unicode branch
by Guido van Rossum July 20, 2007

July 20, 2007

Thanks to all who helped fixing tests in the str/unicode branch! We're down to about 35 failing tests. I still need help -- especially since we're now getting into territory that I don't know all that well, for example the email package or XML support. The list of unit tests that need help is still on the wiki: http://wiki.python.org/moin/Py3kStrUniTests Instructions on how to help and how to avoid duplicate work are also there. Please help! Thanks to all those who already fixed one or more tests! -- --Guido van Rossum (home page: http://www.python.org/~guido/)

1 0

PyGEGL instant crash (Python regression?)
by David Gowers July 20, 2007

July 20, 2007

Has anyone tried PyGEGL, the Python interface to gegl (www.gegl.org), with SVN Python? When I 'import gegl', that causes an immediate crash with the following backtrace. ---- babl-db.c:100 babl_db_insert() Eeeeek Using host libthread_db library "/lib/tls/i686/cmov/libthread_db.so.1". [Thread debugging using libthread_db enabled] [New Thread -1210014016 (LWP 30914)] 0xffffe410 in __kernel_vsyscall () #0 0xffffe410 in __kernel_vsyscall () #1 0xb7e97933 in waitpid () from /lib/tls/i686/cmov/libc.so.6 #2 0xb7e413c9 in strtold_l () from /lib/tls/i686/cmov/libc.so.6 #3 0xb7f6e7dd in system () from /lib/tls/i686/cmov/libpthread.so.0 #4 0xb6e93df4 in babl_backtrack () at babl-internal.c:68 #5 0xb6e93e15 in babl_die () at babl-internal.c:74 #6 0xb6e8d352 in babl_db_insert (db=0x0, item=0x82bbff8) at babl-db.c:100 #7 0xb6e968be in babl_type_new (first_arg=0xb6ef90d6) at babl-type.c:135 #8 0xb6ef7dea in init () at CIE-Lab.c:427 #9 0xb7b191b3 in babl_extension_init () at babl-extension.c:194 #10 0xb7b16a2f in babl_init () at babl.c:40 #11 0xb7b3630e in gegl_post_parse_hook (context=0x0, group=0x0, data=0x0, error=0x0) at gegl-init.c:199 #12 0xb7b364d5 in gegl_init (argc=0xbffa1038, argv=0xbffa1034) at gegl-init.c:73 #13 0xb7f8494d in pygegl_register_classes (d=0xb7d27714) at gegl.override:139 #14 0xb7f82f21 in initgegl () at geglmodule.c:57 #15 0x080d742f in _PyImport_LoadDynamicModule (name=0xbffa2177 "gegl", pathname=0xbffa1103 "/usr/lib/python2.6/site-packages/geglmodule.so", fp=0xfffffe00) at ./Python/importdl.c:53 #16 0x080d5327 in load_module (name=0xbffa2177 "gegl", fp=0x0, buf=0xbffa1103 "/usr/lib/python2.6/site-packages/geglmodule.so", type=3, loader=0xbffa0974) at Python/import.c:1752 #17 0x080d578c in import_submodule (mod=0x81343c0, subname=0xbffa2177 "gegl", fullname=0xbffa2177 "gegl") at Python/import.c:2394 #18 0x080d59d1 in load_next (mod=0x81343c0, altmod=0x81343c0, p_name=<value optimized out>, buf=0xbffa2177 "gegl", p_buflen=0xbffa3178) at Python/import.c:2214 #19 0x080d5e0d in import_module_level (name=0x0, globals=0xb7de2acc, locals=<value optimized out>, fromlist=0x81343c0, level=-1) at Python/import.c:1995 #20 0x080d62de in PyImport_ImportModuleLevel (name=0xb7d23374 "gegl", globals=0xb7de2acc, locals=0xb7de2acc, fromlist=0xfffffe00, level=-512) at Python/import.c:2066 #21 0x080b5658 in builtin___import__ (self=0x0, args=0xfffffe00, kwds=0xfffffe00)c:1995 at Python/bltinmodule.c:47 #22 0x0805a8ac in PyObject_Call (func=0xbffa0974, arg=0xfffffe00, kw=0xfffffe00) at Objects/abstract.c:1860 #23 0x080b9c39 in PyEval_CallObjectWithKeywords (func=0xfffffe00, arg=0xb7ddecac, kw=0x0) at Python/ceval.c:3433 #24 0x080bc631 in PyEval_EvalFrameEx (f=0x81ebf24, throwflag=0) at Python/ceval.c:2071 #25 0x080c133f in PyEval_EvalCodeEx (co=0xb7d9d968, globals=0xb7de2acc, locals=0xb7de2acc, args=0x0, argcount=0, kws=0x0, kwcount=0, defs=0x0, defcount=0, closure=0x0) at Python/ceval.c:2840 #26 0x080c14c6 in PyEval_EvalCode (co=0xfffffe00, globals=0xfffffe00, locals=0xfffffe00) at Python/ceval.c:493 #27 0x080df9dc in PyRun_InteractiveOneFlags (fp=0xfffffe00, filename=0x8116d6e "<stdin>", flags=0xbffa3688) at Python/pythonrun.c:1293 #28 0x080dfbd0 in PyRun_InteractiveLoopFlags (fp=0xb7f37240, filename=0x8116d6e "<stdin>", flags=0xbffa3688) at Python/pythonrun.c:723 #29 0x080e030b in PyRun_AnyFileExFlags (fp=0xb7f37240, filename=0x8116d6e "<stdin>", closeit=0, flags=0xbffa3688) at Python/pythonrun.c:692 #30 0x08056dad in Py_Main (argc=0, argv=0xbffa3724) at Modules/main.c:527 #31 0xb7e20ea2 in __libc_start_main () from /lib/tls/i686/cmov/libc.so.6 #32 0x08056251 in _start () at ../sysdeps/i386/elf/start.S:119 ---- I'm pretty sure that the bug lies in either Python or the pygegl module, as I've ran the babl and gegl tests successfully (and the gegl editor works okay too) (btw, this is with both SVN python and SVN gegl -- PyGEGL is included in the gegl repository; in order to test this, you might also need the SVN version of babl. Lastly, in the gegl tree, you can find PyGEGL source in the bindings/pygegl/ dir.) I posted this report originally to the gegl-developer list. Kevin Cozens, the PyGEGL maintainer, said: > I have only tested pyGEGL with the 2.4 version of Python. It possible (or very > likely?) that something has changed in the 2.6 version of Python. I don't have > the 2.6 version installed at the moment so I can't investigate this further. Sven Neumann said: > Have you contacted the python developers then? This looks a lot like a > regression in Python and I guess they would like to hear about it before > the release the next version. Hence I'm posting it here. Perhaps someone can shed some light on what is happening here?

3 3