Mailman 3 December 2007 - Python-Dev

'with' __exit__ doesn't set sys.exc_info()
by Mike Stall 18 Dec '07

18 Dec '07

Can somebody confirm the following behavior is expected: When a 'with' statement invokes __exit__(), it looks like sys.exc_info() is not actually set. I know this may be a very pedantic detail, but I'm working on IronPython and would like to make it consistent with CPython's behavior. The PEP (http://www.python.org/dev/peps/pep-0343/ ) says that 'With' can be substituted as follows: mgr = (EXPR) exit = mgr.__exit__ # Not calling it yet value = mgr.__enter__() exc = True try: try: VAR = value # Only if "as VAR" is present BLOCK except: # The exceptional case is handled here exc = False if not exit(*sys.exc_info()): raise # The exception is swallowed if exit() returns true finally: # The normal and non-local-goto cases are handled here if exc: exit(None, None, None) and that "The details of the above translation are intended to prescribe the exact semantics.". This implies that sys.exc_info() would be set when exit is invoked. I'm finding in practice that sys.exc_info() is not set when __exit__() is invoked in the exceptional case. I attached a simple repro (repro.py) to demonstrate exactly what I mean. Can somebody confirm this is the expected behavior? Thanks, Mike http://blogs.msdn.com/jmstall

2 1

1-tuple trailing comma
by Calvin Spealman 18 Dec '07

18 Dec '07

I just had an issue brought up by another developer who had a trailing comma on an assignment causing a 1-tuple he did not expect. We were talking about it and came to the conclusion that it is at least worth bringing up the idea of enforcing a SyntaxError in the case of this. 1-tuple syntax is already an odd-man-out, so requiring more explicitness about it would catch some errors and be more readable. I think we could agree that a tuple of 2 or more elements is much easier to read without parens than a 1-tuple without parens. Aside from assignment I can't think of a single place when one would construct a 1-tuple without parens. This is the offending erroneous and hard-to-catch code: if foo: bar = 3, L = [1, 2, bar] Would there be any possibility in considering further refining the 1- tuple syntax to require parens because of its nature?

2 1

Deploying embedded Python
by Andreas Raab 17 Dec '07

17 Dec '07

Hi - [Apologies if this isn't the right list but I couldn't find any mailing list specifically dedicated to embedded Python. Does such a list exist?] I'm currently looking into a few deployment issues with our embedded Python interpreter and I'm looking for any information about deploying embedded Python that people may have. Specifically, I'm looking for the following information: 1) How to define a useful subset of the stdlib that can serve as an initial basis for the installation but later allows upgrade to the "full" library if desirable. In other words, I'd like to deploy a small subset of the stdlib to begin with (simply because of size constraints) which may later be extended to a full stdlib if this is desirable. Has someone done this before? I'd love to have a small "Python.zip" cross-platform stdlib surrogate that just gets shipped with the product. If not, what is the right starting point for analyzing the dependencies inside the stdlib? 2) How to isolate the embedded interpreter from environmental effects. I have found that on occasion, the interpreter would pick up "stray" installations which can cause weird problems. Which environmental settings affect the startup of an embedded Python interpreter? How does one work around/remove those dependencies? Is there any information available about how exactly the startup works? What is being read/loaded in which order etc? 3) General advice about deploying embedded Python. Pointers to web sites, general experience (good or bad) etc. are all very welcome. Thanks, - Andreas

2 2

PyTuple_Pack with NULL argument
by Lisandro Dalcin 17 Dec '07

17 Dec '07

Currently, PyTuple_Pack() does not check for NULL arguments, so it is going to segfault in this case. Is this intended for performance reasons? -- 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

Signals+Threads (PyGTK waking up 10x/sec).
by Sean Reifschneider 17 Dec '07

17 Dec '07

Overview (my reading of it): PyGTK wakes up 10x a second in it's main loop because signals may be delivered to another thread and will only get picked up if the mainloop wakes up. In the following thread: http://mail.python.org/pipermail/python-dev/2006-September/068569.html it sounds like the patch at: http://bugs.python.org/issue1564547 doesn't solve the problem. A recent gnome bug brings this issue back up: http://bugzilla.gnome.org/show_bug.cgi?id=481569 I went ahead and closed the python issue as "rejected" to hopefully get some more activity on it. I thought about this some, and I wondered if there was some way we could signal the sleeping thread when a signal came in on another thread. Like perhaps we could make some code to create a pipe, and put it someplace that all threads could get access to. Then, if a thread gets a signal, write on this pipe. The mainloop could include this file descriptor in the set it's watching, so it would wake up when the signal came in. Is this something Python should provide, or something PyGTK should do? If an approach like the above would work, we could make it so that select() always created this file descriptor and added it to one of the FD sets, so that it would do the right thing behind the scenes. I have no idea if this is a reasonable approach, but it's something that came to mind when I thought about the problem and was an approach I didn't see mentioned before in the discussion. Thanks, Sean -- I live my life like I type; Fast with lots of mistakes. Sean Reifschneider, Member of Technical Staff <jafo(a)tummy.com> tummy.com, ltd. - Linux Consulting since 1995: Ask me about High Availability Back off man. I'm a scientist. http://HackingSociety.org/

16 59

asyncore delayed calls feature
by Giampaolo Rodola' 17 Dec '07

17 Dec '07

I would ask if someone using asyncore could review this, please: http://bugs.python.org/issue1641

1 0

[patch] Improvements for float and math
by Christian Heimes 17 Dec '07

17 Dec '07

I've implemented several small improvements for floats and the math module. You can find a description and the patches in our bug tracker: http://bugs.python.org/issue1635 http://bugs.python.org/issue1640 Summary: * Full and platform independent round trip for +/-inf and nan. Before the patch the round trip didn't work on Windows and Windows returned different repr() for nan and inf (1.#INF and -1.#IND). >>> 1e500 inf >>> -1e500 -inf >>> 1e500 * 0. nan >>> float("nan") nan >>> float("inf") inf >>> float("-inf") -inf * math.isnan() and math.isinf() functions. The Py_IS_NAN and Py_IS_INFINITY macros now use isinf and isnan on platforms that support the functions. Although they are C99 functions they are also available on GNU89 (C89 + GNU extensions) and other platforms. We already use them on Windows. * math.sign() function >>> math.sign(42) 1 >>> math.sign(-42) -1 >>> math.sign(0) 0 On platforms with full IEEE 754 semantics and copysign() support: >>> math.sign(0.0) 1 >>> math.sign(-0.0) -1 * Py_MATH_PI and Py_MATH_E macros with long double precision for future use. * 1st and 2nd kind Bessel functions (j0, j1. jn, y0, y1, yn), error functions (erf, erfc) and gamma function (lgamma with sign). They are available in most libm libraries. Please review the patches and comment on them. Christian

1 0

Improved dyn mod load debug
by Neal Becker 17 Dec '07

17 Dec '07

I had mistakenly installed a module (Qsci.so) into the wrong directory. Debugging this was harder than it needed to be (c-level debug of shared lib). Currently, the only debug info is from importdl.c: m = PyDict_GetItemString(PyImport_GetModuleDict(), name); if (m == NULL) { PyErr_SetString(PyExc_SystemError, "dynamic module not initialized properly"); return NULL; } I wonder if it would be difficult to print out the name expected, and the name actually loaded? In this case, it would have said: expected: PyQt4/Qsci loaded: Qsci

2 1

reStructuredText docs now printable
by Georg Brandl 16 Dec '07

16 Dec '07

Hi, just wanted to let you know that I've added a LaTeX builder to the doctools, so that one can produce LaTeX source from the docs again. It uses the old python.sty package, for which I feel grateful. You should be able to build the PDFs with a "make latex" in Doc, and a "make all-pdf" in Doc/build/latex afterwards. Georg -- 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

Re: [Python-Dev] functional continuations
by Phillip J. Eby 16 Dec '07

16 Dec '07

At 01:04 AM 12/15/2007 -0800, tomer filiba wrote: >* do you suppose it will work? are there any drawbacks i didn't >anticipate? Yes. :) Specifically, think about what happens when a C function is in the call stack, e.g.: def f1(): return map(f2, [1,2,3]) def f2(ob): raise WaitFor(something) return ob print f1() If I understand you correctly, when this program is run, it will print "1", rather than "[1, 2, 3]", because there is no way for you to keep track of the internal state of the 'map()' call. And this isn't just a problem for map() -- even something as simple as a property access passes through C code whose state can get lost. I don't think this approach is practical; you'd be better off using a co-routine stack and trampoline, since the nature of generators naturally forces all the C code out of the picture.

3 2