ANNOUNCE: Python for .NET beta 5 now available
Python for .NET 1.0 beta 5 is now available - you can download it from: http://www.zope.org/Members/Brian/PythonNet/ Python for .NET is a near-seamless integration of Python with the .NET common language runtime. For more details, see the README: http://www.zope.org/Members/Brian/PythonNet/README.html The beta 5 release features a refactoring of thread management support, making the runtime stable for multi-threaded applications, as well as several improvements and bug-fixes. Special thanks to all who sent in thread-related scenarios and test cases! I have tried to incorporate as many of these as possible into the unit tests - if you still have problems that you suspect may be related to threading or interpreter lock issues, please let me know asap. There is also now a mailing list for discussion, questions and issues related to Python for .NET at: pythondotnet@python.org. To subscribe to the mailing list or read the online archives, see: http://mail.python.org/mailman/listinfo/pythondotnet Brian Lloyd brian@zope.com V.P. Engineering 540.361.1716 Zope Corporation http://www.zope.com
Hi. First of all thank you. Second - I still have problems to call static function from a few threads. Is it intentional? Do you want I send you test case? Roman On Mar 29, 2005 5:31 AM, Brian Lloyd <brian@zope.com> wrote:
Python for .NET 1.0 beta 5 is now available - you can download it from:
http://www.zope.org/Members/Brian/PythonNet/
Python for .NET is a near-seamless integration of Python with the .NET common language runtime. For more details, see the README:
http://www.zope.org/Members/Brian/PythonNet/README.html
The beta 5 release features a refactoring of thread management support, making the runtime stable for multi-threaded applications, as well as several improvements and bug-fixes.
Special thanks to all who sent in thread-related scenarios and test cases! I have tried to incorporate as many of these as possible into the unit tests - if you still have problems that you suspect may be related to threading or interpreter lock issues, please let me know asap.
There is also now a mailing list for discussion, questions and issues related to Python for .NET at: pythondotnet@python.org.
To subscribe to the mailing list or read the online archives, see:
http://mail.python.org/mailman/listinfo/pythondotnet
Brian Lloyd brian@zope.com V.P. Engineering 540.361.1716 Zope Corporation http://www.zope.com
_________________________________________________ Python.NET mailing list - PythonDotNet@python.org http://mail.python.org/mailman/listinfo/pythondotnet
Yes, if you can send a test case that would help. Note that to be thread-safe and reentrancy-safe you also need to make sure that any managed code you have that uses Python.Runtime objects or methods is acquiring the Python lock first. For example: public class Example { public static int MethodThatCallsPython() { // have to acquire the GIL to safely call back into // Python!! IntPtr state = PythonEngine.AcquireLock(); PythonEngine.RunSimpleString("print 'hello'"); // done using python for now, so release the GIL... PythonEngine.ReleaseLock(state); } } Forgetting to manage the lock around a callback into Python is almost certain to cause a NullReferenceException (because there will be no valid thread state when the callback is made). Brian Lloyd brian@zope.com V.P. Engineering 540.361.1716 Zope Corporation http://www.zope.com
-----Original Message----- From: pythondotnet-bounces@python.org [mailto:pythondotnet-bounces@python.org]On Behalf Of Roman Yakovenko Sent: Thursday, March 31, 2005 12:52 AM Cc: pythondotnet@python.org Subject: Re: [Python.NET] ANNOUNCE: Python for .NET beta 5 now available
Hi. First of all thank you.
Second - I still have problems to call static function from a few threads. Is it intentional? Do you want I send you test case?
Roman
On Mar 29, 2005 5:31 AM, Brian Lloyd <brian@zope.com> wrote:
Python for .NET 1.0 beta 5 is now available - you can download it from:
http://www.zope.org/Members/Brian/PythonNet/
Python for .NET is a near-seamless integration of Python with the .NET common language runtime. For more details, see the README:
http://www.zope.org/Members/Brian/PythonNet/README.html
The beta 5 release features a refactoring of thread management support, making the runtime stable for multi-threaded applications, as well as several improvements and bug-fixes.
Special thanks to all who sent in thread-related scenarios and test cases! I have tried to incorporate as many of these as possible into the unit tests - if you still have problems that you suspect may be related to threading or interpreter lock issues, please let me know asap.
There is also now a mailing list for discussion, questions and issues related to Python for .NET at: pythondotnet@python.org.
To subscribe to the mailing list or read the online archives, see:
http://mail.python.org/mailman/listinfo/pythondotnet
Brian Lloyd brian@zope.com V.P. Engineering 540.361.1716 Zope Corporation http://www.zope.com
_________________________________________________ Python.NET mailing list - PythonDotNet@python.org http://mail.python.org/mailman/listinfo/pythondotnet
_________________________________________________ Python.NET mailing list - PythonDotNet@python.org http://mail.python.org/mailman/listinfo/pythondotnet
Forgetting to manage the lock around a callback into Python is almost certain to cause a NullReferenceException (because there will be no valid thread state when the callback is made).
Is this take care of when a C# instance calls a delegate, wich is a python function? Or do we need to take the same care? (i.e. wrap the call to the delegate in a AcquireLock/ReleaseLock section). thanks! Stan.
Forgetting to manage the lock around a callback into Python is almost certain to cause a NullReferenceException (because there will be no valid thread state when the callback is made).
Is this take care of when a C# instance calls a delegate, wich is a python function? Or do we need to take the same care? (i.e. wrap the call to the delegate in a AcquireLock/ReleaseLock section).
thanks!
Stan.
No, I was just starting to look at your report, and I don't _think_ its the same thing. When PythonNet creates a delegate with a Python implementation, it generates the actual managed wrapper delegate and includes the necessary calls to AcquireLock() and ReleaseLock(). There are a bunch of unit tests for delegates that don't exhibit this behavior - the main difference I can see is that your delegate runs on a different thread (which shouldn't matter, but its a place to start). Brian Lloyd brian@zope.com V.P. Engineering 540.361.1716 Zope Corporation http://www.zope.com
Brian Lloyd a écrit :
Forgetting to manage the lock around a callback into Python is almost certain to cause a NullReferenceException (because there will be no valid thread state when the callback is made).
Is this take care of when a C# instance calls a delegate, wich is a python function? Or do we need to take the same care? (i.e. wrap the call to the delegate in a AcquireLock/ReleaseLock section).
thanks!
Stan.
No, I was just starting to look at your report, and I don't _think_ its the same thing.
When PythonNet creates a delegate with a Python implementation, it generates the actual managed wrapper delegate and includes the necessary calls to AcquireLock() and ReleaseLock().
There are a bunch of unit tests for delegates that don't exhibit this behavior - the main difference I can see is that your delegate runs on a different thread (which shouldn't matter, but its a place to start).
be sure to take a look at the comment I have made, because I include a second python test case, much simpler, without dependancies to Simpy. thanks a lot Bryan!
Brian Lloyd brian@zope.com V.P. Engineering 540.361.1716 Zope Corporation http://www.zope.com
Hi. Bryan could you add __str__ function to all CLR exceptions ? It will improve usability of this exception with python unittest package. Thanks
Sorry this was posted in wring thread. On 5/25/05, Roman Yakovenko <roman.yakovenko@gmail.com> wrote:
Hi. Bryan could you add __str__ function to all CLR exceptions ? It will improve usability of this exception with python unittest package.
Thanks
Roman
Sorry this was posted in wring thread.
On 5/25/05, Roman Yakovenko <roman.yakovenko@gmail.com> wrote:
Hi. Bryan could you add __str__ function to all CLR exceptions ? It will improve usability of this exception with python unittest package.
Thanks
I guess I'm unclear on the goal. Looking at the built-in Python exceptions, they have a __repr__, but __str__ returns an empty string:
e = IndexError() repr(e) '<exceptions.IndexError instance at 0x07016AF8>' str(e) ''
CLR exceptions currently have the same behavior:
e = CLR.System.NullReferenceException() repr(e) '<CLR.System.NullReferenceException object at 0x070158B0>' str(e) ''
I'm happy to add things to make life easier for folks -- I just don't understand what you're asking for yet :) What would you want/expect to get from str(e) on a CLR exception? Brian Lloyd brian@zope.com V.P. Engineering 540.361.1716 Zope Corporation http://www.zope.com
Sorry for being unclear. My main usage of Python.Net is writing unittest for client \ server application. ( I have more then 330 unitests :-) ). CLR.Exception don't play nice with python unittest framework. If test fails with exception unitest framework will print error message for regular python exception. In case of CLR.Exception it can't print message of exception. Roman On 5/27/05, Brian Lloyd <brian@zope.com> wrote:
Sorry this was posted in wring thread.
On 5/25/05, Roman Yakovenko <roman.yakovenko@gmail.com> wrote:
Hi. Bryan could you add __str__ function to all CLR exceptions ? It will improve usability of this exception with python unittest package.
Thanks
I guess I'm unclear on the goal. Looking at the built-in Python exceptions, they have a __repr__, but __str__ returns an empty string:
e = IndexError() repr(e) '<exceptions.IndexError instance at 0x07016AF8>' str(e) ''
CLR exceptions currently have the same behavior:
e = CLR.System.NullReferenceException() repr(e) '<CLR.System.NullReferenceException object at 0x070158B0>' str(e) ''
I'm happy to add things to make life easier for folks -- I just don't understand what you're asking for yet :) What would you want/expect to get from str(e) on a CLR exception?
Brian Lloyd brian@zope.com V.P. Engineering 540.361.1716 Zope Corporation http://www.zope.com
On May 27, 2005, at 10:42 AM, Brian Lloyd wrote:
Sorry this was posted in wring thread.
On 5/25/05, Roman Yakovenko <roman.yakovenko@gmail.com> wrote:
Hi. Bryan could you add __str__ function to all CLR exceptions ? It will improve usability of this exception with python
unittest package.
Thanks
I guess I'm unclear on the goal. Looking at the built-in Python exceptions, they have a __repr__, but __str__ returns an empty string:
Only in the trivial case..
str(IndexError("reason here")) 'reason here'
-bob
Hi all - So to summarize this thread: we want to make __str__ of a CLR exception return self.Message, right? That would seem to match the behavior of the std Python exceptions. Brian Lloyd brian@zope.com V.P. Engineering 540.361.1716 Zope Corporation http://www.zope.com
-----Original Message----- From: Bob Ippolito [mailto:bob@redivi.com] Sent: Saturday, May 28, 2005 11:57 PM To: Brian Lloyd Cc: Roman Yakovenko; pythondotnet@python.org Subject: Re: [Python.NET] Small improvment for CLR exceptions
On May 27, 2005, at 10:42 AM, Brian Lloyd wrote:
Sorry this was posted in wring thread.
On 5/25/05, Roman Yakovenko <roman.yakovenko@gmail.com> wrote:
Hi. Bryan could you add __str__ function to all CLR exceptions ? It will improve usability of this exception with python
unittest package.
Thanks
I guess I'm unclear on the goal. Looking at the built-in Python exceptions, they have a __repr__, but __str__ returns an empty string:
Only in the trivial case..
str(IndexError("reason here")) 'reason here'
-bob
On 5/31/05, Brian Lloyd <brian@zope.com> wrote:
Hi all -
So to summarize this thread: we want to make __str__ of a CLR exception return self.Message, right? That would seem to match the behavior of the std Python exceptions.
Brian Lloyd brian@zope.com V.P. Engineering 540.361.1716 Zope Corporation http://www.zope.com
Yes. Thanks for your efforts. Roman
Brian Lloyd wrote:
Hi all -
So to summarize this thread: we want to make __str__ of a CLR exception return self.Message, right? That would seem to match the behavior of the std Python exceptions.
I would add the following: __str__ should display self.Message, then self.StackTrace....to be able to immediately point out the error in C# code... No? Stan.
participants (4)
-
Bob Ippolito -
Brian Lloyd -
Roman Yakovenko -
Stan Pinte