From guy at r-e-d.co.nz Fri May 6 00:44:54 2005 From: guy at r-e-d.co.nz (Guy Robinson) Date: Fri, 06 May 2005 10:44:54 +1200 Subject: [Python.NET] embedding python3net Message-ID: <427AA1E6.2010502@r-e-d.co.nz> Hello, Can anyone point me to an example of how to embed python4net in an application. Ideally using CS. Regards, Guy From tjeyasankar at gmail.com Fri May 6 14:42:27 2005 From: tjeyasankar at gmail.com (Jeyasankar T) Date: Fri, 6 May 2005 08:42:27 -0400 Subject: [Python.NET] PythonDotNet Digest, Vol 20, Issue 1 In-Reply-To: References: Message-ID: <4bf3cae40505060542543d9dcc@mail.gmail.com> You can look the code in "PythonNet-1.0-beta5\src\testing\ThreadTest.cs" which embeds the python engine in C# code > Hello, > > Can anyone point me to an example of how to embed python4net in an application. > Ideally using CS. > > Regards, > > Guy > > ------------------------------ > > _______________________________________________ > PythonDotNet mailing list > PythonDotNet at python.org > http://mail.python.org/mailman/listinfo/pythondotnet From pythondotnet at python.org Sat May 7 23:20:12 2005 From: pythondotnet at python.org (Collector: Python for .NET Issue ...) Date: Sat, 07 May 2005 17:20:12 -0400 Subject: [Python.NET] [PythonNet] 1/ 2 Resolve "Invalid free()s (probably GC-related)" Message-ID: <20050507212428.58D5D203342@mail.zope.org> Issue #1 Update (Resolve) "Invalid free()s (probably GC-related)" Status Resolved, General/bug medium To followup, visit: http://www.zope.org/Members/Brian/PythonNet/Collector/1 ============================================================== = Resolve - Entry #2 by Brian on May 7, 2005 5:20 pm Status: Pending => Resolved Figured this out: interop was trying to release the char * for strings returned from python ;( ________________________________________ = Request - Entry #1 by Brian on Dec 6, 2004 5:19 pm > Python For .NET beta 3 runs fine for me with Mono > version 1.01 on Linux. I do get "free(): invalid pointer" > messages, presumably from garbage collection (??) > but it does seem to run fine. > > James Phillips Thats great news ;) It also confirms that there is still a bug lurking somewhere in my interop-level memory mgmt (I've gotten reports of invalid frees under a debugger on win32 as well...) ============================================================== From michael.jonesw at rbos.com Sat May 7 23:22:35 2005 From: michael.jonesw at rbos.com (ZZJONES, Michael, FM Quantitative Research) Date: Sat, 7 May 2005 22:22:35 +0100 Subject: [Python.NET] Out of Office AutoReply: [PythonNet] 1/ 2 Resolve "I nvalid free()s (probably GC-related)" Message-ID: I have now left the company. Please refer all questions to Richard White 020 7085 1225. *********************************************************************************** The Royal Bank of Scotland plc. Registered in Scotland No 90312. Registered Office: 36 St Andrew Square, Edinburgh EH2 2YB. Authorised and regulated by the Financial Services Authority This e-mail message is confidential and for use by the addressee only. If the message is received by anyone other than the addressee, please return the message to the sender by replying to it and then delete the message from your computer. Internet e-mails are not necessarily secure. The Royal Bank of Scotland plc does not accept responsibility for changes made to this message after it was sent. Whilst all reasonable care has been taken to avoid the transmission of viruses, it is the responsibility of the recipient to ensure that the onward transmission, opening or use of this message and any attachments will not adversely affect its systems or data. No responsibility is accepted by The Royal Bank of Scotland plc in this regard and the recipient should carry out such virus and other checks as it considers appropriate. Visit our websites at: http://www.rbs.co.uk/CBFM http://www.rbsmarkets.com ******************************************************************************** From pythondotnet at python.org Sat May 7 23:24:44 2005 From: pythondotnet at python.org (Collector: Python for .NET Issue ...) Date: Sat, 07 May 2005 17:24:44 -0400 Subject: [Python.NET] [PythonNet] 4/ 2 Resolve "Need better way to inspect PythonException" Message-ID: <20050507212900.EC9BC203342@mail.zope.org> Issue #4 Update (Resolve) "Need better way to inspect PythonException" Status Resolved, General/bug medium To followup, visit: http://www.zope.org/Members/Brian/PythonNet/Collector/4 ============================================================== = Resolve - Entry #2 by Brian on May 7, 2005 5:24 pm Status: Pending => Resolved Type and Value should solve this... -BL ________________________________________ = Request - Entry #1 by Brian on Feb 8, 2005 11:06 am >From managed code. ============================================================== From pythondotnet at python.org Sat May 7 23:27:19 2005 From: pythondotnet at python.org (Collector: Python for .NET Issue ...) Date: Sat, 07 May 2005 17:27:19 -0400 Subject: [Python.NET] [PythonNet] 10/ 2 Resolve "Problem converting arrays" Message-ID: <20050507213135.84C44203342@mail.zope.org> Issue #10 Update (Resolve) "Problem converting arrays" Status Resolved, General/bug medium To followup, visit: http://www.zope.org/Members/Brian/PythonNet/Collector/10 ============================================================== = Resolve - Entry #2 by Brian on May 7, 2005 5:27 pm Status: Pending => Resolved This is implemented for rc1. -BL ________________________________________ = Request - Entry #1 by Anonymous User on Apr 12, 2005 3:37 pm Uploaded: "convert-sequences.patch" - http://www.zope.org/Members/Brian/PythonNet/Collector/10/convert-sequences.patch/view There's no generic conversion to object for Python arrays, so something like: > from CLR.System import Console > Console.WriteLine("{0}", [[1]]) will fail. Fix: convert to object[]. ============================================================== From pythondotnet at python.org Sun May 8 00:42:37 2005 From: pythondotnet at python.org (Collector: Python for .NET Issue ...) Date: Sat, 07 May 2005 18:42:37 -0400 Subject: [Python.NET] [PythonNet] 9/ 2 Resolve "TypeError when parameters added to derived constructor" Message-ID: <20050507224654.078F9203252@mail.zope.org> Issue #9 Update (Resolve) "TypeError when parameters added to derived constructor" Status Resolved, General/bug medium To followup, visit: http://www.zope.org/Members/Brian/PythonNet/Collector/9 ============================================================== = Resolve - Entry #2 by Brian on May 7, 2005 6:42 pm Status: Pending => Resolved Fixed for rc1. -BL ________________________________________ = Request - Entry #1 by Anonymous User on Mar 31, 2005 6:38 pm Uploaded: "bug1.py" - http://www.zope.org/Members/Brian/PythonNet/Collector/9/bug1.py/view A TypeError is thrown when trying to derive a Python class from a .NET class when the Python class constructor has parameters beyond "self". ============================================================== From pythondotnet at python.org Sun May 8 00:43:58 2005 From: pythondotnet at python.org (Collector: Python for .NET Issue ...) Date: Sat, 07 May 2005 18:43:58 -0400 Subject: [Python.NET] [PythonNet] 7/ 4 Resolve "crash caused by interaction between pythondotnet and CLR." Message-ID: <20050507224814.D0BA1203252@mail.zope.org> Issue #7 Update (Resolve) "crash caused by interaction between pythondotnet and CLR." Status Resolved, Threading/bug critical To followup, visit: http://www.zope.org/Members/Brian/PythonNet/Collector/7 ============================================================== = Resolve - Entry #4 by Brian on May 7, 2005 6:43 pm Status: Pending => Resolved Fixed for rc1. -BL ________________________________________ = Comment - Entry #3 by Anonymous User on Mar 31, 2005 2:43 am hello, I have skimmed the test case, and removed all dependancies toward the Simpy framework. Now it crashes once the python main loop is finished. If I comment out the code used to pass a python function as a delegate to the C# frame, it doesn't. here is the code: #test to show problem. import sys,time sys.path.append('.') from CLR.System.Reflection import Assembly a = Assembly.LoadWithPartialName("testpython") from CLR.testpython import MainForm, TestDelegate def test(): return "hop" if __name__ == '__main__': form = MainForm.GetInstance() form.TestDelegateProperty = TestDelegate(test) form.Start() time.sleep(1) print "done" Stan. the CLR sources are the same. Contact me if any more info is needed. ________________________________________ = Comment - Entry #2 by Anonymous User on Mar 30, 2005 11:18 am the python script to run is bin\Debug\test.py ________________________________________ = Request - Entry #1 by Anonymous User on Mar 30, 2005 11:18 am Uploaded: "testpython.zip" - http://www.zope.org/Members/Brian/PythonNet/Collector/7/testpython.zip/view hello, the following application (python/C#) is working properly, when I do not run simpy, a python framework. Once I enable, I get an immediate crash. See enclosed for runnable/compilable example. (run "python test.py"). To run, it needs the Simpy framework, GPL, that you can get there: http://simpy.sourceforge.net/ Simpy makes heavy uses of the "yield" construct. as soon as I uncomment that line in the script: #simulate() I get an immediate crash. I see no reason for this crash. Stan. ============================================================== From brian at zope.com Mon May 9 05:20:32 2005 From: brian at zope.com (Brian Lloyd) Date: Sun, 8 May 2005 23:20:32 -0400 Subject: [Python.NET] Announce: Python for .NET 1.0 RC1 released Message-ID: Hi all - I'm happy to announce the release of Python for .NET 1.0 RC1. You can download it from: http://www.zope.org/Members/Brian/PythonNet Highlights of this release: - Implemented a workaround for the fact that exceptions cannot be new-style classes in the CPython interpreter. Managed exceptions can now be raised and caught naturally from Python - Implemented support for invoking methods with out and ref parameters. Because there is no real equivalent to these in Python, methods that have out or ref parameters will return a tuple. The tuple will contain the result of the method as its first item, followed by out parameter values in the order of their declaration in the method signature. - Fixed a refcount problem that caused a crash when CLR was imported in an existing installed Python interpreter. - Added an automatic conversion from Python strings to byte[]. This makes it easier to pass byte[] data to managed methods (or set properties, etc.) as a Python string without having to write explicit conversion code. Also works for sbyte arrays. Note that byte and sbyte arrays returned from managed methods or obtained from properties or fields do *not* get converted to Python strings - they remain instances of Byte[] or SByte[]. - Added conversion of generic Python sequences to object arrays when appropriate (thanks to Mackenzie Straight for the patch). - Added a bit of cautionary documentation for embedders, focused on correct handling of the Python global interpreter lock from managed code for code that calls into Python. - PyObject.FromManagedObject now correctly returns the Python None object if the input is a null reference. Also added a new AsManagedObject method to PyObject, making it easier to convert a Python-wrapped managed object to the real managed object. - Created a simple installer for windows platforms. All known bugs have also been fixed - thanks to all who have sent in issue reports and patches for past releases. At this point, the only thing I plan to do before a 1.0 final is fix any new issues and add to the documentation (probably including a few specific examples of embedding Python for .NET in a .NET application). Enjoy! ;) Brian Lloyd brian at zope.com V.P. Engineering 540.361.1716 Zope Corporation http://www.zope.com From borice23 at yahoo.com Mon May 9 16:40:36 2005 From: borice23 at yahoo.com (Boris Capitanu) Date: Mon, 9 May 2005 07:40:36 -0700 (PDT) Subject: [Python.NET] PythonDotNet Digest, Vol 20, Issue 4 In-Reply-To: 6667 Message-ID: <20050509144036.57102.qmail@web51809.mail.yahoo.com> Please excuse my probably-inappropriate-but-highly-emotional language: Brian, you're the man! If you were a girl, I'd hug you! :) Honestly, thanks for this great work and for all your effort! It's really appreciated! Boris --- pythondotnet-request at python.org wrote: > Send PythonDotNet mailing list submissions to > pythondotnet at python.org > > To subscribe or unsubscribe via the World Wide Web, > visit > > http://mail.python.org/mailman/listinfo/pythondotnet > or, via email, send a message with subject or body > 'help' to > pythondotnet-request at python.org > > You can reach the person managing the list at > pythondotnet-owner at python.org > > When replying, please edit your Subject line so it > is more specific > than "Re: Contents of PythonDotNet digest..." > > > Today's Topics: > > 1. Announce: Python for .NET 1.0 RC1 released > (Brian Lloyd) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Sun, 8 May 2005 23:20:32 -0400 > From: "Brian Lloyd" > Subject: [Python.NET] Announce: Python for .NET 1.0 > RC1 released > To: , > > Message-ID: > > Content-Type: text/plain; charset="iso-8859-1" > > Hi all - > > I'm happy to announce the release of Python for .NET > 1.0 RC1. > You can download it from: > > http://www.zope.org/Members/Brian/PythonNet > > Highlights of this release: > > - Implemented a workaround for the fact that > exceptions cannot be > new-style > classes in the CPython interpreter. Managed > exceptions can now be > raised > and caught naturally from Python > > - Implemented support for invoking methods with > out and ref parameters. > Because there is no real equivalent to these > in Python, methods that > have out or ref parameters will return a > tuple. The tuple will contain > the result of the method as its first item, > followed by out parameter > values in the order of their declaration in > the method signature. > > - Fixed a refcount problem that caused a crash > when CLR was imported in > an existing installed Python interpreter. > > - Added an automatic conversion from Python > strings to byte[]. This > makes > it easier to pass byte[] data to managed > methods (or set properties, > etc.) as a Python string without having to > write explicit conversion > code. Also works for sbyte arrays. Note that > byte and sbyte arrays > returned from managed methods or obtained from > properties or fields > do *not* get converted to Python strings - > they remain instances of > Byte[] or SByte[]. > > - Added conversion of generic Python sequences > to object arrays when > appropriate (thanks to Mackenzie Straight for > the patch). > > - Added a bit of cautionary documentation for > embedders, focused on > correct handling of the Python global > interpreter lock from managed > code for code that calls into Python. > > - PyObject.FromManagedObject now correctly > returns the Python None > object > if the input is a null reference. Also added a > new AsManagedObject > method to PyObject, making it easier to > convert a Python-wrapped > managed > object to the real managed object. > > - Created a simple installer for windows > platforms. > > > All known bugs have also been fixed - thanks to all > who have sent in issue > reports and patches for past releases. > > At this point, the only thing I plan to do before a > 1.0 final is fix any > new issues and add to the documentation (probably > including a few specific > examples of embedding Python for .NET in a .NET > application). > > Enjoy! ;) > > > Brian Lloyd brian at zope.com > V.P. Engineering 540.361.1716 > Zope Corporation http://www.zope.com > > > > ------------------------------ > > _______________________________________________ > PythonDotNet mailing list > PythonDotNet at python.org > http://mail.python.org/mailman/listinfo/pythondotnet > > > End of PythonDotNet Digest, Vol 20, Issue 4 > ******************************************* > __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com From brian at zope.com Mon May 9 05:20:32 2005 From: brian at zope.com (Brian Lloyd) Date: Sun, 8 May 2005 23:20:32 -0400 Subject: [Python.NET] Announce: Python for .NET 1.0 RC1 released Message-ID: Hi all - I'm happy to announce the release of Python for .NET 1.0 RC1. You can download it from: http://www.zope.org/Members/Brian/PythonNet Highlights of this release: - Implemented a workaround for the fact that exceptions cannot be new-style classes in the CPython interpreter. Managed exceptions can now be raised and caught naturally from Python - Implemented support for invoking methods with out and ref parameters. Because there is no real equivalent to these in Python, methods that have out or ref parameters will return a tuple. The tuple will contain the result of the method as its first item, followed by out parameter values in the order of their declaration in the method signature. - Fixed a refcount problem that caused a crash when CLR was imported in an existing installed Python interpreter. - Added an automatic conversion from Python strings to byte[]. This makes it easier to pass byte[] data to managed methods (or set properties, etc.) as a Python string without having to write explicit conversion code. Also works for sbyte arrays. Note that byte and sbyte arrays returned from managed methods or obtained from properties or fields do *not* get converted to Python strings - they remain instances of Byte[] or SByte[]. - Added conversion of generic Python sequences to object arrays when appropriate (thanks to Mackenzie Straight for the patch). - Added a bit of cautionary documentation for embedders, focused on correct handling of the Python global interpreter lock from managed code for code that calls into Python. - PyObject.FromManagedObject now correctly returns the Python None object if the input is a null reference. Also added a new AsManagedObject method to PyObject, making it easier to convert a Python-wrapped managed object to the real managed object. - Created a simple installer for windows platforms. All known bugs have also been fixed - thanks to all who have sent in issue reports and patches for past releases. At this point, the only thing I plan to do before a 1.0 final is fix any new issues and add to the documentation (probably including a few specific examples of embedding Python for .NET in a .NET application). Enjoy! ;) Brian Lloyd brian at zope.com V.P. Engineering 540.361.1716 Zope Corporation http://www.zope.com -- http://mail.python.org/mailman/listinfo/python-announce-list Support the Python Software Foundation: http://www.python.org/psf/donations.html From mtraudt at quantifisolutions.com Thu May 12 06:24:12 2005 From: mtraudt at quantifisolutions.com (mtraudt) Date: Thu, 12 May 2005 00:24:12 -0400 Subject: [Python.NET] calling Finalize directly Message-ID: <20050512042414.602FA1E4003@bag.python.org> I realize that you cannot currently build on mono due to other limitations, but it seems that mcs also does not like the fact that you call Finalize() directly in some cases. The MS compiler does not complain, although on MSDN it says not to do this, and to use Dispose() instead. Is there any reason why you call Finalize() directly? Mark From mtraudt at quantifisolutions.com Thu May 12 07:17:44 2005 From: mtraudt at quantifisolutions.com (mtraudt@quantifisolutions.com) Date: Wed, 11 May 2005 22:17:44 -0700 Subject: [Python.NET] Mono Support Message-ID: <20050511221744.vy1khf8dn9og44gk@www.quantifisolutions.com> I must be missing something obvious. I have come across several references to Python.Net more or less working with Mono on Linux, although not reliably. The thing is, I don't understand how it can work. The interop assemblies (eg CLR.dll) are .NET assemblies, which means they are also PE format, not ELF. On Windows, the DLL is loaded and the CLR initialized automagically by the Windows/.NET loaders. But how does this work on Linux? From brian at zope.com Thu May 12 16:47:41 2005 From: brian at zope.com (Brian Lloyd) Date: Thu, 12 May 2005 10:47:41 -0400 Subject: [Python.NET] Mono Support In-Reply-To: <20050511221744.vy1khf8dn9og44gk@www.quantifisolutions.com> Message-ID: > I must be missing something obvious. I have come across several > references to > Python.Net more or less working with Mono on Linux, although not > reliably. The > thing is, I don't understand how it can work. The interop assemblies (eg > CLR.dll) are .NET assemblies, which means they are also PE > format, not ELF. > > On Windows, the DLL is loaded and the CLR initialized automagically by the > Windows/.NET loaders. But how does this work on Linux? The hack of getting CLR.dll to bootstrap Python for .NET into an existing running CPython does *not* work on Linux. It works on windows because there is a way to do 'unmanaged exports' from a managed dll that windows understands. I (ab)use this to trick CPython into thinking its just loading a normal C extension module. On linux, you have to run the managed version of python.exe that comes with the package. Brian Lloyd brian at zope.com V.P. Engineering 540.361.1716 Zope Corporation http://www.zope.com From brian at zope.com Thu May 12 16:54:52 2005 From: brian at zope.com (Brian Lloyd) Date: Thu, 12 May 2005 10:54:52 -0400 Subject: [Python.NET] calling Finalize directly In-Reply-To: <20050512042414.602FA1E4003@bag.python.org> Message-ID: > I realize that you cannot currently build on mono > due to other limitations, but it seems that mcs also > does not like the fact that you call Finalize() > directly in some cases. > > The MS compiler does not complain, although on > MSDN it says not to do this, and to use Dispose() > instead. Is there any reason why you call > Finalize() directly? All of the Finalize methods that are called directly are static methods (e.g., they are *not* destructor aliases and unrelated to the Dispose pattern). They match (also static) Initialize() methods for a few classes in the runtime that can't rely on static constructors (because they need to be run in a specific order). So I suspect that mcs is wrong in this case, but I'm not a CLI laywer ;) Does mcs give you an error, or just a warning? Brian Lloyd brian at zope.com V.P. Engineering 540.361.1716 Zope Corporation http://www.zope.com From mtraudt at quantifisolutions.com Thu May 12 17:12:18 2005 From: mtraudt at quantifisolutions.com (mtraudt) Date: Thu, 12 May 2005 11:12:18 -0400 Subject: [Python.NET] Mono Support In-Reply-To: Message-ID: <20050512151220.600591E4002@bag.python.org> Brian, Thanks. For some reason I made the assumption that the python.exe was a C binary. I should have looked more closely at the distribution. Did you consider going with a hosting/embedding approach instead of generating C exports via IL? We use the CLR Hosting API on Windows and it works well, although of course it forces you to do a bit of COM programming. I have not used the Mono Embedding API but from reading the docs it looks like it would be easy to use. One nice thing about this approach is that you can run all of your managed code in a separate (ie non-default) AppDomain, which can be useful. Mark Traudt Quantifi Inc. 20 Commerce Drive Cranford, NJ 07016 mtraudt at quantifisolutions.com http://www.quantifisolutions.com Phone: (908) 272-7740 Fax: (646) 304-3440 _______________________________________________________________________ This message is intended solely for the designated recipient(s) named above and may be legally privileged and/or confidential. If you are not the named addressee you should not disseminate, distribute or copy this message. > -----Original Message----- > From: Brian Lloyd [mailto:brian at zope.com] > Sent: Thursday, May 12, 2005 10:48 AM > To: mtraudt at quantifisolutions.com; pythondotnet at python.org > Subject: RE: [Python.NET] Mono Support > > > I must be missing something obvious. I have come across several > > references to Python.Net more or less working with Mono on Linux, > > although not reliably. The thing is, I don't understand how it can > > work. The interop assemblies (eg > > CLR.dll) are .NET assemblies, which means they are also PE > format, not > > ELF. > > > > On Windows, the DLL is loaded and the CLR initialized > automagically by > > the Windows/.NET loaders. But how does this work on Linux? > > The hack of getting CLR.dll to bootstrap Python for .NET into > an existing running CPython does *not* work on Linux. It > works on windows because there is a way to do 'unmanaged > exports' from a managed dll that windows understands. I > (ab)use this to trick CPython into thinking its just loading > a normal C extension module. > > On linux, you have to run the managed version of python.exe > that comes with the package. > > > Brian Lloyd brian at zope.com > V.P. Engineering 540.361.1716 > Zope Corporation http://www.zope.com > > > > > From mtraudt at quantifisolutions.com Thu May 12 17:31:22 2005 From: mtraudt at quantifisolutions.com (mtraudt) Date: Thu, 12 May 2005 11:31:22 -0400 Subject: [Python.NET] calling Finalize directly In-Reply-To: Message-ID: <20050512153125.02F691E4016@bag.python.org> Brian, It reports an error. It seems to not understand that your static Finalize() method is different than the one called by the GC. I agree that this is a bug, although you might be better off changing the name to Cleanup() or something else less likely to confuse compilers (and humans). Mark Traudt Quantifi Inc. 20 Commerce Drive Cranford, NJ 07016 mtraudt at quantifisolutions.com http://www.quantifisolutions.com Phone: (908) 272-7740 Fax: (646) 304-3440 _______________________________________________________________________ This message is intended solely for the designated recipient(s) named above and may be legally privileged and/or confidential. If you are not the named addressee you should not disseminate, distribute or copy this message. > -----Original Message----- > From: Brian Lloyd [mailto:brian at zope.com] > Sent: Thursday, May 12, 2005 10:55 AM > To: mtraudt; pythondotnet at python.org > Subject: RE: [Python.NET] calling Finalize directly > > > I realize that you cannot currently build on mono due to other > > limitations, but it seems that mcs also does not like the fact that > > you call Finalize() directly in some cases. > > > > The MS compiler does not complain, although on MSDN it says > not to do > > this, and to use Dispose() instead. Is there any reason > why you call > > Finalize() directly? > > All of the Finalize methods that are called directly are > static methods (e.g., they are *not* destructor aliases and > unrelated to the Dispose pattern). They match (also static) > Initialize() methods for a few classes in the runtime that > can't rely on static constructors (because they need to be > run in a specific order). > > So I suspect that mcs is wrong in this case, but I'm not a > CLI laywer ;) Does mcs give you an error, or just a warning? > > > Brian Lloyd brian at zope.com > V.P. Engineering 540.361.1716 > Zope Corporation http://www.zope.com > > > > From firemoth at gmail.com Fri May 13 00:02:32 2005 From: firemoth at gmail.com (Timothy Fitz) Date: Thu, 12 May 2005 18:02:32 -0400 Subject: [Python.NET] from import issues In-Reply-To: <972ec5bd0505121438510d823c@mail.gmail.com> References: <972ec5bd0505121438510d823c@mail.gmail.com> Message-ID: <972ec5bd05051215026382144c@mail.gmail.com> Under 1.0 release candidate 1 for python 2.4, the exe installer with the option to install into my current python install selected, I run python.exe and do a simple from CLR.System import String and get an ImportError, but the second time it works. Played around a bit, it happens for anything at from CLR.Something import foo, but not if I do from CLR import System or such. After the initial ImportError, it won't happen again from what I tried. Running the python.exe included in C:\Program Files\PythonNet\, I don't get any of these ImportErrors. Python 2.4 (#60, Nov 30 2004, 11:49:19) [MSC v.1310 32 bit (Intel)] on win32 Type "help", "copyright", "credits" or "license" for more information. >>> from CLR.System import String Traceback (most recent call last): File "", line 1, in ? ImportError: No module named System >>> from CLR.System import String >>> from CLR.System.Reflection import Emit >>> from CLR.Microsoft import Win32 >>> From roman.yakovenko at gmail.com Wed May 25 14:52:35 2005 From: roman.yakovenko at gmail.com (Roman Yakovenko) Date: Wed, 25 May 2005 15:52:35 +0300 Subject: [Python.NET] ANNOUNCE: Python for .NET beta 5 now available In-Reply-To: <424C10C2.4030400@phidani.be> References: <424C10C2.4030400@phidani.be> Message-ID: <7465b617050525055244bddd2c@mail.gmail.com> Hi. Bryan could you add __str__ function to all CLR exceptions ? It will improve usability of this exception with python unittest package. Thanks From roman.yakovenko at gmail.com Thu May 26 05:35:13 2005 From: roman.yakovenko at gmail.com (Roman Yakovenko) Date: Thu, 26 May 2005 06:35:13 +0300 Subject: [Python.NET] Small improvment for CLR exceptions In-Reply-To: <7465b617050525055244bddd2c@mail.gmail.com> References: <424C10C2.4030400@phidani.be> <7465b617050525055244bddd2c@mail.gmail.com> Message-ID: <7465b6170505252035152ae496@mail.gmail.com> Sorry this was posted in wring thread. On 5/25/05, Roman Yakovenko 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 From brian at zope.com Fri May 27 19:42:19 2005 From: brian at zope.com (Brian Lloyd) Date: Fri, 27 May 2005 13:42:19 -0400 Subject: [Python.NET] Small improvment for CLR exceptions In-Reply-To: <7465b6170505252035152ae496@mail.gmail.com> Message-ID: > Sorry this was posted in wring thread. > > On 5/25/05, Roman Yakovenko 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) '' >>> str(e) '' CLR exceptions currently have the same behavior: >>> e = CLR.System.NullReferenceException() >>> repr(e) '' >>> 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 at zope.com V.P. Engineering 540.361.1716 Zope Corporation http://www.zope.com From roman.yakovenko at gmail.com Sun May 29 05:02:18 2005 From: roman.yakovenko at gmail.com (Roman Yakovenko) Date: Sun, 29 May 2005 06:02:18 +0300 Subject: [Python.NET] Small improvment for CLR exceptions In-Reply-To: References: <7465b6170505252035152ae496@mail.gmail.com> Message-ID: <7465b61705052820025d6f6ad6@mail.gmail.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 wrote: > > Sorry this was posted in wring thread. > > > > On 5/25/05, Roman Yakovenko 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) > '' > >>> str(e) > '' > > CLR exceptions currently have the same behavior: > > >>> e = CLR.System.NullReferenceException() > >>> repr(e) > '' > >>> 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 at zope.com > V.P. Engineering 540.361.1716 > Zope Corporation http://www.zope.com > > > From bob at redivi.com Sun May 29 06:56:39 2005 From: bob at redivi.com (Bob Ippolito) Date: Sat, 28 May 2005 21:56:39 -0700 Subject: [Python.NET] Small improvment for CLR exceptions In-Reply-To: References: Message-ID: <206CE615-18B3-4E8F-B8F9-F2E9EFBE76AA@redivi.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 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 From guy at r-e-d.co.nz Mon May 30 05:21:53 2005 From: guy at r-e-d.co.nz (Guy Robinson) Date: Mon, 30 May 2005 15:21:53 +1200 Subject: [Python.NET] running .net with standard 2.4.1 installation Message-ID: <429A86D1.4070407@r-e-d.co.nz> Hello, I've put the CLR and runtime dll's in my standard windows 2.4.1 installation and I'm getting the following(see below) crash and error information. It appears the runtime dll isn't being found. Yet they're both in the python/dll directory. I did have the binary pythonDotNet installed. But have uninstalled it. Can anyone shed some light on what's going on? Regards, Guy Python 2.4.1 (#65, Mar 30 2005, 09:13:57) [MSC v.1310 32 bit (Intel)] on win32 Type "help", "copyright", "credits" or "license" for more information. >>> import CLR.System as System Unhandled Exception: System.IO.FileNotFoundException: File or assembly name Pyth on.Runtime, or one of its dependencies, was not found. File name: "Python.Runtime" at CLRModule.initCLR() === Pre-bind state information === LOG: DisplayName = Python.Runtime, Version=1.0.0.0, Culture=neutral, PublicKeyTo ken=null (Fully-specified) LOG: Appbase = e:\python24\ LOG: Initial PrivatePath = NULL Calling assembly : (Unknown). === LOG: Application configuration file does not exist. LOG: Policy not being applied to reference at this time (private, custom, partia l, or location-based assembly bind). LOG: Post-policy reference: Python.Runtime, Version=1.0.0.0, Culture=neutral, Pu blicKeyToken=null LOG: Attempting download of new URL file:///e:/python24/Python.Runtime.DLL. LOG: Attempting download of new URL file:///e:/python24/Python.Runtime/Python.Ru ntime.DLL. LOG: Attempting download of new URL file:///e:/python24/Python.Runtime.EXE. LOG: Attempting download of new URL file:///e:/python24/Python.Runtime/Python.Ru ntime.EXE. From brian at zope.com Tue May 31 15:51:04 2005 From: brian at zope.com (Brian Lloyd) Date: Tue, 31 May 2005 09:51:04 -0400 Subject: [Python.NET] running .net with standard 2.4.1 installation In-Reply-To: <429A86D1.4070407@r-e-d.co.nz> Message-ID: I'm pretty sure that Python.Runtime.dll will need to be in the same directory as your python.exe (because of .NET assembly probing rules). The CLR.dll can probably be either in the DLLs directory or in the root directory with python.exe. Brian Lloyd brian at zope.com V.P. Engineering 540.361.1716 Zope Corporation http://www.zope.com > -----Original Message----- > From: pythondotnet-bounces at python.org > [mailto:pythondotnet-bounces at python.org]On Behalf Of Guy Robinson > Sent: Sunday, May 29, 2005 10:22 PM > To: pythondotnet at python.org > Subject: [Python.NET] running .net with standard 2.4.1 installation > > > Hello, > > I've put the CLR and runtime dll's in my standard windows 2.4.1 > installation and > I'm getting the following(see below) crash and error information. > It appears the > runtime dll isn't being found. Yet they're both in the python/dll > directory. I > did have the binary pythonDotNet installed. But have uninstalled it. > > Can anyone shed some light on what's going on? > > Regards, > > Guy > > Python 2.4.1 (#65, Mar 30 2005, 09:13:57) [MSC v.1310 32 bit > (Intel)] on win32 > Type "help", "copyright", "credits" or "license" for more information. > >>> import CLR.System as System > > Unhandled Exception: System.IO.FileNotFoundException: File or > assembly name Pyth > on.Runtime, or one of its dependencies, was not found. > File name: "Python.Runtime" > at CLRModule.initCLR() > > === Pre-bind state information === > LOG: DisplayName = Python.Runtime, Version=1.0.0.0, > Culture=neutral, PublicKeyTo > ken=null > (Fully-specified) > LOG: Appbase = e:\python24\ > LOG: Initial PrivatePath = NULL > Calling assembly : (Unknown). > === > > LOG: Application configuration file does not exist. > LOG: Policy not being applied to reference at this time (private, > custom, partia > l, or location-based assembly bind). > LOG: Post-policy reference: Python.Runtime, Version=1.0.0.0, > Culture=neutral, Pu > blicKeyToken=null > LOG: Attempting download of new URL > file:///e:/python24/Python.Runtime.DLL. > LOG: Attempting download of new URL > file:///e:/python24/Python.Runtime/Python.Ru > ntime.DLL. > LOG: Attempting download of new URL > file:///e:/python24/Python.Runtime.EXE. > LOG: Attempting download of new URL > file:///e:/python24/Python.Runtime/Python.Ru > ntime.EXE. > > _________________________________________________ > Python.NET mailing list - PythonDotNet at python.org > http://mail.python.org/mailman/listinfo/pythondotnet > From brian at zope.com Tue May 31 15:54:14 2005 From: brian at zope.com (Brian Lloyd) Date: Tue, 31 May 2005 09:54:14 -0400 Subject: [Python.NET] Small improvment for CLR exceptions In-Reply-To: <206CE615-18B3-4E8F-B8F9-F2E9EFBE76AA@redivi.com> Message-ID: 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 at zope.com V.P. Engineering 540.361.1716 Zope Corporation http://www.zope.com > -----Original Message----- > From: Bob Ippolito [mailto:bob at redivi.com] > Sent: Saturday, May 28, 2005 11:57 PM > To: Brian Lloyd > Cc: Roman Yakovenko; pythondotnet at 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 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 > > From stan at phidani.be Tue May 31 15:59:34 2005 From: stan at phidani.be (Stan Pinte) Date: Tue, 31 May 2005 13:59:34 +0000 Subject: [Python.NET] Small improvment for CLR exceptions In-Reply-To: References: Message-ID: <429C6DC6.1040706@phidani.be> 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.