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.

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

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

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

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.

right.

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.