Re: [Python-Dev] functional continuations
yes, well, as i suspected and as PJE pointed out, extension or builtin functions would make life difficult, but these are difficulties i would be willing to accept. however, my attempts are futile anyways, as the evaluation stack is cleared before the exception propagates up to the frames above... which would explain the NULL deref exceptions i was getting :) -tomer On Dec 16, 2007 12:54 AM, Greg Ewing <[EMAIL PROTECTED]> wrote: > tomer filiba wrote: > > the idea i came up with is, using exceptions for functional > > continuations: after all, the exception's traceback holds the entire > > context... > > The problem with this is that, if the call chain has passed > through a C-implemented function at some point, the traceback > *doesn't* contain the entire context -- some of it is in the > C stack frames that got unwound during the propagation of > the exception. > > So you may be able to make this work where all the code > involved is pure Python, but it can't work in general, > unless you redesign the whole interpreter the way the > original Stackless did. > > Having said that, it might still be a useful thing to > have, as the pure-Python case is probably fairly common. > But I'd want to know what the failure mode is like when > the pure-Python case doesn't hold. Do you get a clear > indication of what is wrong, or does it misbehave in > some obscure way? > > A test case for this would be to call map() with a > function that tries to suspend itself using this > mechanism. What happens when you try to resume it? > > -- > Greg > -- An NCO and a Gentleman ___ 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] functional continuations
> yeah, i did think native functions wouldn't fit well with it, but then > again, i don't plan to have any c-side functions invoking python > callbacks. i can live with that. Just in case it isn't clear - even if you can live with it, it makes it unsuitable for inclusion into the Python interpreter. 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
[Python-Dev] Tkinter problems with Tcl/Tk 8.5
Hello, I am a Tcl/Tk core developer. I'm trying to resolve some bugs that have surfaced in Tkinter with Tcl/Tk 8.5. 8.5.0 is very near release, and I'm hoping we can determine where the problem is, and resolve it soon. http://sourceforge.net/tracker/index.php?func=detail&aid=1851526&group_id=12997&atid=112997 It seems very peculiar how the text widget's bbox is returning a Python-like list and therefore breaking the Tcl callback. I haven't thus far been able to determine which python method is causing that, or if it's something related to the hooks you have added. The same problem doesn't occur with 8.4. It also has been suggested by some on the Tcl core team (during discussions about this bug) that you probably shouldn't be using Tcl_GetObjType and relying on the registered Tcl_ObjTypes, however I'm not sure of a way to get what you need otherwise. Tcl 8.5 now supports big integers, so I think some changes may be needed in _tkinter.c for that. The list internal rep has changed as well, and I'm not sure if that will affect you. Another developer also pointed out that the text widget is returning a Tcl_Obj with a list type, rather than a string for the bbox subcommand, so that could be related to this bug. I hope that we can work together to resolve the issues you may have with Tk. George -- http://www.xmission.com/~georgeps/ http://whim.linuxsys.net http://code.google.com/p/megapkg/ http://code.google.com/p/opennexx/ ___ 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] Tkinter problems with Tcl/Tk 8.5
> It also has been suggested by some on the Tcl core team (during > discussions about this bug) that you probably shouldn't be using > Tcl_GetObjType and relying on the registered Tcl_ObjTypes, however I'm > not sure of a way to get what you need otherwise. Hi George, I hope I can find some time next week to look into this in more detail, but please let me respond to this first. In Python, objects have a fixed type, given to them at the point of creation. Also, it is common in Python to use multiple types, not just a single one (say, string). So to convert between Tcl objects and Python objects, we would like to preserve type information as much as possible. To do that, _tkinter has two functions: AsObj (converting PyObject to Tcl_Obj), and FromObj (converting Tcl_Obj to PyObj). We map the well-known (registered) types 1:1 to appropriate Python types, and have a default for the rest. If Tcl_GetObjType was not available, I see no other way but to convert everything through strings, which would put the burden of typing things onto the Tkinter user (or perhaps on Tkinter, to type the well-known commands). 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
[Python-Dev] reStructuredText docs now printable
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. ___ 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
