Mailman 3 April 2006 - Python.NET

Naming and resolution of generic types (complete!)
by Brian Lloyd 22 May '06

22 May '06

Hi all - I'm cross-posting this to the IP list as the subject seems to be an open issue there too. I'm working on generics support for Python for .NET, and there a couple of thorny issues that could use some discussion regarding naming and resolution of generic types. In C# you can explicitly name a generic type, a la Dictionary<,>. That syntax won't work in Python, of course. Looking at IP, it seems to allow the apparent Python name to be the unmangled IL name so you can naturally use the name. The problem is that the mangled name is illegal as a python name, and the unmangled name isn't guaranteed to be unique - you can potentially have any number of generic types as well as a non-generic type with the same base name in the same namespace: namespace Spam { public class SpamCan {} public class SpamCan<T> {} public class SpamCan<T, V> {} ... } I imagine that maybe IP has enough information available at compile-time to do the right thing for some common usage (binding and instantiating the types), but the overloaded name can still be ambiguous. A real-life example of this is System.IComparable - in IP, it doesn't seem possible to get to the non-generic version of IComparable anymore (or at least it was not obvious to me how to do it): >>> import System >>> System.IComparable <type 'IComparable`1'> It seems like we need to figure out some acceptable way of spelling generic type names explicitly in Python (an equivalent to IComparable<> in C#) that works within the existing syntax. There don't appear to be a lot of great options :( It has to be a valid Python name to work in an import statement, so that rules out strange operator shenanigans akin to the [] hack used for generic type binding. One would be to mimic the existing IL mangling in some way, a la: >From System import IComparable # the non-generic type >From System import IComparable_1 # the 1-param generic # or from System import IComparable_T from System.Collections.Generic import Dictionary_TT These are all pretty gross, and still don't totally prevent hiding of legit non-generic classes with those names (though it makes it less likely that names will be hidden than the current approach). I suppose another approach would be to continue to have only one type end up with the simple name, but provide a way to disambiguate it after the fact: >>> import System >>> System.IComparable <type 'IComparable`1'> >>> # abandon all hope, ye who enter here... >>> NonGenericIComparable = System.IComparable<<0 >>> OneParamGenericIComparable = System.IComparable<<1 >>> TwoParamVersionIfThereWasOne = System.IComparable<<2 That feels to me like it violates Python Zen in several ways, though. Thoughts? -Brian

5 4

Re: [Python.NET] Use of c++ dll in python
by Mark McMahon 20 Apr '06

20 Apr '06

Hi Lalit, This is not really the group to ask this question - as it doesn't have anything to do with python.NET. But other then that I can answer your question I think :-) You say a "C++ DLL". First thing is you need to make sure that your functions are correctly exported in an 'unmangled' form. What I do for this is the following: // create a macro DLLEXPORT for those methods you want to export #define DLLEXPORT extern "C" __declspec(dllexport) // the following may be optional - but can make things easier #define VB __stdcall // add the macro to your function prototypes DLLEXPORT int VB InitDialogFromFile (char const *const fileName); // in the CPP file define your function as you would normally do int VB InitDialogFromFile(char const * const fileName) { //FUNC BODY } You may also need to create a .def file ; Declares the module parameters for the DLL. NAME MyCPPDll.dll DESCRIPTION 'Description of your DLL' EXPORTS // the following line can be used to rename exports //InitDialogFromFile_renamed = InitDialogFromFile InitDialogFromFile Once you add that to the project - it will make sure that no mangling happens (sometimes even after doing extern "C" you still get a leading underscore!) Mark -----Original Message----- From: pythondotnet-bounces(a)python.org [mailto:pythondotnet-bounces@python.org] On Behalf Of Lalit DIGARI Sent: Monday, April 03, 2006 7:22 AM To: pythondotnet(a)python.org Subject: [Python.NET] Use of c++ dll in python Hello All , I have devloped a c++ dll named mydll in c++ how can I access it with in python script using ctype... Regard's Lalit _________________________________________________ Python.NET mailing list - PythonDotNet(a)python.org http://mail.python.org/mailman/listinfo/pythondotnet

3 3

full IronPython test suite?
by Brian Lloyd 18 Apr '06

18 Apr '06

Apologies in advance for being inexcusably lazy -- does anyone out there know how to get an IP build with its full test suite? The public release seems like it doesn't include everything, and I'd like to get a better sense for the current state of code-compatibility... -Brian

1 0

deprecation of CLR module, implicit assembly loading
by Brian Lloyd 18 Apr '06

18 Apr '06

Hi all, The current SVN (and upcoming releases) includes changes to support a refactored, IronPython-compatible import syntax and assembly load behavior. Where in releases to date you had to use the magic 'CLR' module as the root of all CLR imports, now you can just say: from System import * The old 'CLR' syntax is deprecated but will continue to work until pythonnet 3.x. A second job of the artist-formerly-known-as-the-magic-CLR-module was to provide a way to bootstrap CLR support in an existing CPython installation (by providing a pseudo- C-extension). In other words, you had to say 'import CLR' before using .NET from an stock Python install. The next releases will continue to include an (upper-case) "CLR" extension for b/w compatibility, but it will also include a (lower-case) "clr" module that is call-compatible with the clr module from IronPython. The new "clr" module will provide the IP-compatible AddReference APIs to support explicit loading of assembly dependencies, and it will also become the officially supported way of bootstrapping CLR support in a stock Python install. So if you want to use .NET from an existing Python install or ensure that your code is portable between IP and PythonNet, you should either arrange for your app to 'import clr' before using .NET features, or to advise users to add 'import clr' to their sitecustomize.py. I've tried hard to look at this from every angle and make sure this is not a breaking change for 2.x (though it will be for 3.x), but if you're building on pythonnet and this will cause you any problems, please let me know soonest. - Brian

1 0

NAnt as a build solution
by Brian Lloyd 18 Apr '06

18 Apr '06

Hi all, I'd like to move to using NAnt as a build solution for Python for .NET. Realizing that toolchains are always somewhat controversial, I think this would be the best solution because: - it will be a lot easier than trying to replicate my quirky toolchain ;) - it will handle *most* of the pain of building for different platforms, framework versions, python versions, etc. - it should work under Mono w/o problems - free as in beer, to keep the bar low for those who want to experiment or contribute Silence is assent, but I wanted to send a note before it was a fait accompli... -Brian

1 0

Delegates and Dictionaries
by Mark Anderson 04 Apr '06

04 Apr '06

Hi all, I'm using .NET to implement a UI for some python code, and am updating various UI components using a .NET function. The .NET based UI calls the python based back end with an argument set which includes a delegate to the .NET UI update function. The python code then periodically invokes the delegate (passing it "a bunch of updated information") which is then used to update the UI. The problem is this: when "a bunch of updated information" is an integer, or a tuple, everything functions correctly. when "a bunch of updated information" is a python Dictionary, I receive the dreaded "TypeError: no method matches given arguments" message. I've tried explicitly typing the delegate argument as a PyDict, to no avail. Any suggestions? Thanks, Mark Anderson

2 1

FYI: Switch to Subversion
by Brian Lloyd 04 Apr '06

04 Apr '06

Hi all - For those that track between-release changes, I've switched the pythonnet code base over to Subversion: https://sourceforge.net/svn/?group_id=162464 There is a branch '1.0-branch' that reflects the last 1.0 release, and the trunk is where 2.x development is happening (though I have to get some tests to pass again before I can checkin on that). I'll probably leave the CVS around for a few days until I'm comfy with SF's subversion server, but it will eventually go away. -Brian

1 0

Re: [Python.NET] Use of c++ dll in python
by Mark McMahon 04 Apr '06

04 Apr '06

Hi Lalit, import ctypes (or maybe windll instead of cdll below) ctypes.cdll.YourDllName.InitDialogFromFile("InitFromThisFile.txt") Simple, no? :-) For anything more complex - please look at the ctypes help. Ctypes helps you a lot - but there is no substitute for reading the help or googling around the 'net for some examples. Mark -----Original Message----- From: Lalit DIGARI [mailto:lalit.digari@st.com] Sent: Tuesday, April 04, 2006 12:37 AM To: Mark McMahon Cc: pythondotnet(a)python.org Subject: RE: [Python.NET] Use of c++ dll in python Thanks mark, How could I use dll's exposed function with in python script? Reagrd's lalit -----Original Message----- From: Mark McMahon [mailto:mark.mcmahon@eur.autodesk.com] Sent: Monday, April 03, 2006 5:41 PM To: Lalit DIGARI; pythondotnet(a)python.org Subject: RE: [Python.NET] Use of c++ dll in python Hi Lalit, This is not really the group to ask this question - as it doesn't have anything to do with python.NET. But other then that I can answer your question I think :-) You say a "C++ DLL". First thing is you need to make sure that your functions are correctly exported in an 'unmangled' form. What I do for this is the following: // create a macro DLLEXPORT for those methods you want to export #define DLLEXPORT extern "C" __declspec(dllexport) // the following may be optional - but can make things easier #define VB __stdcall // add the macro to your function prototypes DLLEXPORT int VB InitDialogFromFile (char const *const fileName); // in the CPP file define your function as you would normally do int VB InitDialogFromFile(char const * const fileName) { //FUNC BODY } You may also need to create a .def file ; Declares the module parameters for the DLL. NAME MyCPPDll.dll DESCRIPTION 'Description of your DLL' EXPORTS // the following line can be used to rename exports //InitDialogFromFile_renamed = InitDialogFromFile InitDialogFromFile Once you add that to the project - it will make sure that no mangling happens (sometimes even after doing extern "C" you still get a leading underscore!) Mark -----Original Message----- From: pythondotnet-bounces(a)python.org [mailto:pythondotnet-bounces@python.org] On Behalf Of Lalit DIGARI Sent: Monday, April 03, 2006 7:22 AM To: pythondotnet(a)python.org Subject: [Python.NET] Use of c++ dll in python Hello All , I have devloped a c++ dll named mydll in c++ how can I access it with in python script using ctype... Regard's Lalit _________________________________________________ Python.NET mailing list - PythonDotNet(a)python.org http://mail.python.org/mailman/listinfo/pythondotnet

1 0

import changes for 2.x
by Brian Lloyd 03 Apr '06

03 Apr '06

Hi all - One of the things I'd like the 2.x-compatible version of PythonNet to do is be code-compatible as much as possible with IronPython. A part of that is reconciling import syntax. Currently, you have to use the 'CLR.xxx' form to import modules in PythonNet, where in IronPython you can just say things like 'from System import *'. For the 2.x release, I propose to: - deprecate, but still support, the 'CLR.' syntax, so current code would continue to work until an eventual 3.x, at which point that support would be removed - implement and guide people toward using the direct syntax I also want to implement the 'clr' (lower-case) module and move toward IronPython's explicit assembly loading model and deprecate implicit loading (though that too would continue to work until 3.x). I've got this all basically working now (even evil old 'from x import *'), but wanted to run it up the flagpole for feedback before I get too far, and particularly to see how people feel about deprecation warnings (should we? shouldn't we?) -Brian

2 1

Use of c++ dll in python
by Lalit DIGARI 03 Apr '06

03 Apr '06

Hello All , I have devloped a c++ dll named mydll in c++ how can I access it with in python script using ctype... Regard's Lalit

2 1