Building sparc64 32/64-bit Python

library in a sparcv9 directory but shares the other Python libraries that are ELF-code independent. Is this possible or do I really have to install two complete but separate Pythons although most of the files are the same? -- Stefan Bellon -- http://mail.python.org/mailman/listinfo/python-list

Re: Building sparc64 32/64-bit Python

On Mon, 22 Oct, Diez B. Roggisch wrote: Stefan Bellon wrote: I can successfully build a 32-bit version in one directory and a 64-bit version in another directory. What I'd like to do is to build a version that has the 64-bit library in a sparcv9 directory but shares the other Python

Re: List search

in mylist if x == 'x11') -- Stefan Bellon -- http://mail.python.org/mailman/listinfo/python-list

Re: Python 3K or Python 2.9?

parameter (like in Ada 95) or you can call the method on the object (like in Java, C++, Python, ...) and the object is passed implicitly. -- Stefan Bellon -- http://mail.python.org/mailman/listinfo/python-list

Re: Destruction of generator objects

On Sat, 11 Aug, Kay Schluehr wrote: On Aug 9, 1:14 am, Stefan Bellon [EMAIL PROTECTED] wrote: Sorry, I forgot to mention that I am forced to using Python 2.4. It doesn't matter. You can use try...finally as well in Python 2.4. It's just not possible to use except and finally clauses in one

Re: Destruction of generator objects

. It seems I have not completely understood how generators work ... -- Stefan Bellon -- http://mail.python.org/mailman/listinfo/python-list

Re: Destruction of generator objects

is not called anymore. -- Stefan Bellon -- http://mail.python.org/mailman/listinfo/python-list

Re: Destruction of generator objects

On Sat, 11 Aug, Marc 'BlackJack' Rintsch wrote: On Sat, 11 Aug 2007 14:50:33 +0200, Stefan Bellon wrote: But then, even when terminating the interpreter, __del__ is not called. Because that is not guaranteed by the language reference. The reason why it is a bad idea to depend

Re: Destruction of generator objects

written without cluttering up the logic between consumer and producer? -- Stefan Bellon -- http://mail.python.org/mailman/listinfo/python-list

Re: Destruction of generator objects

On Wed, 08 Aug, MRAB wrote: Simple! :-) Sorry, I forgot to mention that I am forced to using Python 2.4. -- Stefan Bellon -- http://mail.python.org/mailman/listinfo/python-list

Destruction of generator objects

around this? Can I add some sort of __del__() to the generator object so that in case of an early destruction of the generator object, the external resource is freed as well? I'm looking forward to hearing your hints! -- Stefan Bellon -- http://mail.python.org/mailman/listinfo/python-list

Re: replacement for execfile

functions and execute a string with the content execfile('filename'). Is there a way to solve this problem with PyRun_File? -- Stefan Bellon -- http://mail.python.org/mailman/listinfo/python-list

Catching SystemExit in C API code when embedding Python?

. This is not the intended behaviour. As in Python itself you can catch SystemExit, I think this should be the way to go. But how do I catch this exception from within the C API? Thanks in advance for any hints. -- Stefan Bellon -- http://mail.python.org/mailman/listinfo/python-list

Re: Catching SystemExit in C API code when embedding Python?

First of all, I'm sorry to followup my own posting, but I can add a few things ... On Thu, 02 Aug, Stefan Bellon wrote: As in Python itself you can catch SystemExit, I think this should be the way to go. But how do I catch this exception from within the C API? I now installed an exception

Re: Catching SystemExit in C API code when embedding Python?

mean with Call python code. When installing an excepthook (see my other posting), then I can indeed catch all exceptions ... except for SystemExit which is the one I'm after. -- Stefan Bellon -- http://mail.python.org/mailman/listinfo/python-list

Re: Catching SystemExit in C API code when embedding Python?

On Thu, 02 Aug, Farshid Lashkari wrote: You cannot use PyRun_SimpleString, since it will automatically print and clear the error. You will need to use PyRun_String instead. Thanks, that helps a lot! -- Stefan Bellon -- http://mail.python.org/mailman/listinfo/python-list

Hooking __import__ when embedding the interpreter

that when a .pyc is available, then this is preferred. I'd like to get at the .py file itself. Is this available or do I just have to strip off the trailing 'c' (or 'o'?) if present (seems hacky to me). I am very much looking forward to your suggestions! Greetings, Stefan -- Stefan Bellon

Re: Hooking __import__ when embedding the interpreter

I think I solved all my three questions for myself now ... On Fri, 29 Jun, Stefan Bellon wrote: 1) The above code seems to work ok when using the import statement, but it does not when using the dynamic __import__ function. If using it that way, I get: sys=__import__(sys) Traceback

Re: Accessing variable from a function within a function

(most recent call last): File stdin, line 1, in ? File stdin, line 4, in inner UnboundLocalError: local variable 'a' referenced before assignment -- Stefan Bellon -- http://mail.python.org/mailman/listinfo/python-list

Embedding Python and command history

a lot for your hints in advance! -- Stefan Bellon -- http://mail.python.org/mailman/listinfo/python-list

Re: Embedding Python and command history

Stefan Bellon wrote: int main(void) { Py_Initialize(); PyRun_InteractiveLoop(stdin, stdin); Py_Finalize(); } How can I make use of command history when embedded Python via PyRun_InteractiveLoop? Sorry to follow up my own posting ... I found that when I do import readline