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,
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.
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
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
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
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.
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.
>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, 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. (Assuming
they're either built-in or registered via sitecustomize, that is.)
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.
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)
Dear fellow Pythonistas,
as you may have heard, Python is going to get a new documentation system
soon . 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
* 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
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!
 see http://pyside.blogspot.com/2007/06/introducing-py-rest-doc.html
for some details, and http://pydoc.gbrandl.de:3000/  for a demo.
(Commenting doesn't work yet, but it's worked upon fiercely...)
 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.
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:
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/)
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
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,
#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",
#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
#20 0x080d62de in PyImport_ImportModuleLevel (name=0xb7d23374 "gegl",
locals=0xb7de2acc, fromlist=0xfffffe00, level=-512) at Python/import.c:2066
#21 0x080b5658 in builtin___import__ (self=0x0, args=0xfffffe00,
#22 0x0805a8ac in PyObject_Call (func=0xbffa0974, arg=0xfffffe00, kw=0xfffffe00)
#23 0x080b9c39 in PyEval_CallObjectWithKeywords (func=0xfffffe00,
#24 0x080bc631 in PyEval_EvalFrameEx (f=0x81ebf24, throwflag=0) at
#25 0x080c133f in PyEval_EvalCodeEx (co=0xb7d9d968,
args=0x0, argcount=0, kws=0x0, kwcount=0, defs=0x0, defcount=0, closure=0x0)
#26 0x080c14c6 in PyEval_EvalCode (co=0xfffffe00, globals=0xfffffe00,
#27 0x080df9dc in PyRun_InteractiveOneFlags (fp=0xfffffe00,
flags=0xbffa3688) at Python/pythonrun.c:1293
#28 0x080dfbd0 in PyRun_InteractiveLoopFlags (fp=0xb7f37240,
flags=0xbffa3688) at Python/pythonrun.c:723
#29 0x080e030b in PyRun_AnyFileExFlags (fp=0xb7f37240,
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?
It's about that time of year again. We are starting to organize
Python sprints again this year hosted at Google (ie, there was a 5
minute conversation and a couple of emails). Nothing has solidified
yet, but here are our ideas:
* Hosted at Google's headquarters in Mountain View, CA USA
* From Wed, Aug 22 to Sat Aug 25 (4 days)
* Cost: free, but need to code for food and internet :-)
How does that work for people? You can attend for as little or as
much time as you want. I expect most people will focus on py3k--the
core language changes as well as tools to support the transition.
We'd like to start figuring out how many people would be attending.
If you are interested, please mail me privately. You don't need to
commit to anything. Just how likely you are to attend. Could someone
update the wiki we used for last years sprints:
If you would be interested in other locations/dates, let me know. I
don't know that we can accommodate anything else, but we can try.