From thane at magna-capital.com  Sat Apr  1 05:32:48 2006
From: thane at magna-capital.com (Thane Plummer)
Date: Fri, 31 Mar 2006 22:32:48 -0500
Subject: [Python.NET] Naming and resolution of generic types (complete!)
In-Reply-To: <65531D426735784F854EE658938A585302798CCA@MI8NYCMAIL03.Mi8.com>
Message-ID: <002c01c6553c$f378b250$6603a8c0@Dell9150>

My vote is to keep Python pure, i.e. import SomeGeneric_TT or foo =
TwoParamGeneric<<2 are simply un-Pythonic.

It is amusing that the .NET framework has incorporated a feature
--Generics-- that make it more useful, and indeed more like Python, and the
Python community is now trying to emulate a solution that has already been
solved in Python!  OK, I'm generalizing and I recognize that there are
exceptions; but by and large, Generics give .NET programmers the flexibility
that Python users have always had.  

The vast majority of programming objectives can be met using plain old
Python.  Really.  

A problem arises when there is a .NET system call or 3rd party library that
expects Generics in its interface.  In those cases, why not just coerce the
native Python type and throw an exception if the programmer did something
stupid?

>>> import generic_interface_lib
>>> int_list = [1, 2, 3, "Hey! A string!", 5, 6]
>>> result = generic_interface_lib.Plot(int_list)
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
Do_Not_Be_A_Bozo Exception: function requires a list of numbers.

Yes, I do know the answer to the previous question, but this seems to be a
more Pythonic solution.  Brian's question makes me wonder if Python can be
all things to all programmers, and my thinking is: no, it can't.  Trying to
make it so will just pollute the language.

--Thane


-----Original Message-----
From: pythondotnet-bounces at python.org
[mailto:pythondotnet-bounces at python.org] On Behalf Of Brian Lloyd
Sent: Friday, March 31, 2006 3:43 PM
To: pythondotnet at python.org
Cc: users at lists.ironpython.com
Subject: [Python.NET] Naming and resolution of generic types (complete!)


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

_________________________________________________
Python.NET mailing list - PythonDotNet at python.org
http://mail.python.org/mailman/listinfo/pythondotnet


From roman.yakovenko at gmail.com  Sat Apr  1 17:31:28 2006
From: roman.yakovenko at gmail.com (Roman Yakovenko)
Date: Sat, 1 Apr 2006 18:31:28 +0300
Subject: [Python.NET] Naming and resolution of generic types (complete!)
In-Reply-To: <65531D426735784F854EE658938A585302798CCA@MI8NYCMAIL03.Mi8.com>
References: <65531D426735784F854EE658938A585302798CCA@MI8NYCMAIL03.Mi8.com>
Message-ID: <7465b6170604010731t676cc9e7j911c867bfcdfd470@mail.gmail.com>

On 3/31/06, Brian Lloyd <Brian.Lloyd at revolution.com> wrote:
> 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.

Okay, I took some time to think about this issue. And here my thoughts:
Generic type could be mapped to some Python meta class. If user wants to
create some concrete instance he writes
Dictionary( int ) or Dictionary( MyClass )
This will create a "template instantiation", sorry for using C++, of
class Dictionary.

DictionaryInt = Dictionary( int )

Now what to do if user already have "template instantiation" in his code?
How to name it? I don't have good answer. You can not provide some mangler
that will satisfy all users. May be you should provide some hooks, in order
to allow users to write their own mangler.

> Thoughts?
>
>
> -Brian

--
Roman Yakovenko
C++ Python language binding
http://www.language-binding.net/

From brian.d.lloyd at gmail.com  Sat Apr  1 18:06:05 2006
From: brian.d.lloyd at gmail.com (Brian Lloyd)
Date: Sat, 1 Apr 2006 11:06:05 -0500
Subject: [Python.NET] Naming and resolution of generic types (complete!)
In-Reply-To: <002c01c6553c$f378b250$6603a8c0@Dell9150>
References: <65531D426735784F854EE658938A585302798CCA@MI8NYCMAIL03.Mi8.com>
	<002c01c6553c$f378b250$6603a8c0@Dell9150>
Message-ID: <1c0b4a390604010806x6d91fd64q6803febbc6e1e342@mail.gmail.com>

Well, I'd argue that its not about trying to be all things to all
programmers - its about finding the most reasonable way to handle one
of the (relatively few) ways that the meta-models of the CLR and
Python don't match up well.

In a way, this is not unlike the situation with methods. The fact that
Python doesn't have a concept of overloaded methods causes potential
ambiguity on the Python side, but luckily there is a relatively
elegant solution in that most of the time the runtime can do the Right
Thing on its own, and you can hint it with the [] syntax if you need
to.

I'd like to find a similarly nice solution to this problem, but there
are more constraints here in that types are routinely named in import
statements. That makes a solution much harder in that you only have a
Python name to work with and not many sneaky tricks at your disposal
:^/

The more I think about it, I think the best solution might have to be
that given the following statement:

from System.Bunnies import Bunny

then the name 'Bunny' will be bound to something that is one of:

  - a (reflected) non-generic type (if there exists a non-generic type
of that name and no
    generic type definitions with the same base name). This type can
be instantiated with
    the standard () syntax.

  - a (reflected) generic type definition (if there exists a generic
type definition with the
    given base name, and no non-generic type with that name). This generic type
    definition can be bound into a closed generic type using the []
syntax. Trying to
    instantiate a generic type def using () raises a TypeError.

  - an object that represents more than one reflected type (if there
exists both a
    generic and a non-generic type with the same base name, or more than one
    generic type with the same base name). Calling this object with ()
would create
    an instance if there exists a non-generic type, else raise a
TypeError. Using the
    [] syntax would produce a closed type. There could be some sort of
syntax you
    could use to obtain a reference to a specific (but unbound and
uninstantiated)
    encapsulated type.

This seems like it retains the most simplicity for common uses, and
moves most of the
ambiguity into less common cases (mostly having to do with a
'reflection context', from
either the CLR or Python perspective). For example, what do you see if
you do dir() on
this pseudo-type? What would you pass to a System.Reflection method
that expected
a Type? Those still need to be answered, but I'd argue that for the
most part normal
users of the type from Python won't have to worry about it if we do the above.

explicit-is-better-than-implicit-except-when-its-not'ly,

  -Brian

On 3/31/06, Thane Plummer <thane at magna-capital.com> wrote:
> My vote is to keep Python pure, i.e. import SomeGeneric_TT or foo =
> TwoParamGeneric<<2 are simply un-Pythonic.
>
> It is amusing that the .NET framework has incorporated a feature
> --Generics-- that make it more useful, and indeed more like Python, and the
> Python community is now trying to emulate a solution that has already been
> solved in Python!  OK, I'm generalizing and I recognize that there are
> exceptions; but by and large, Generics give .NET programmers the flexibility
> that Python users have always had.
>
> The vast majority of programming objectives can be met using plain old
> Python.  Really.
>
> A problem arises when there is a .NET system call or 3rd party library that
> expects Generics in its interface.  In those cases, why not just coerce the
> native Python type and throw an exception if the programmer did something
> stupid?
>
> >>> import generic_interface_lib
> >>> int_list = [1, 2, 3, "Hey! A string!", 5, 6]
> >>> result = generic_interface_lib.Plot(int_list)
> Traceback (most recent call last):
>   File "<stdin>", line 1, in ?
> Do_Not_Be_A_Bozo Exception: function requires a list of numbers.
>
> Yes, I do know the answer to the previous question, but this seems to be a
> more Pythonic solution.  Brian's question makes me wonder if Python can be
> all things to all programmers, and my thinking is: no, it can't.  Trying to
> make it so will just pollute the language.
>
> --Thane
>
>
> -----Original Message-----
> From: pythondotnet-bounces at python.org
> [mailto:pythondotnet-bounces at python.org] On Behalf Of Brian Lloyd
> Sent: Friday, March 31, 2006 3:43 PM
> To: pythondotnet at python.org
> Cc: users at lists.ironpython.com
> Subject: [Python.NET] Naming and resolution of generic types (complete!)
>
>
> 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
>
> _________________________________________________
> Python.NET mailing list - PythonDotNet at python.org
> http://mail.python.org/mailman/listinfo/pythondotnet
>
> _________________________________________________
> Python.NET mailing list - PythonDotNet at python.org
> http://mail.python.org/mailman/listinfo/pythondotnet
>

From lalit.digari at st.com  Mon Apr  3 13:22:05 2006
From: lalit.digari at st.com (Lalit DIGARI)
Date: Mon, 3 Apr 2006 16:52:05 +0530
Subject: [Python.NET] Use of c++ dll in python
Message-ID: <00ca01c65710$d81f6ff0$d50cc70a@dlh.st.com>

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


From python at axtom.com  Mon Apr  3 17:42:06 2006
From: python at axtom.com (python at axtom.com)
Date: Mon,  3 Apr 2006 17:42:06 +0200
Subject: [Python.NET] installation on GNU/Linux
Message-ID: <1144078926.4431424eba2f8@ssl0.ovh.net>



Hi all,

I have installed pythonnet and thought it would be of interest
to send the outputs of the tests included in the library.

--
Jean Pierre


configuration
-----------------
Debian GNU/Linux 3.1
  kernel  2.6
python-2.4.2
mono-1.1.13.4
pythonnet-1.0-rc2-py2.4-clr1.1



axtom:/opt/pythonnet# mono python.exe

Python 2.4.2 (#2, Apr  1 2006, 11:19:10)
[GCC 3.3.5 (Debian 1:3.3.5-13)] on linux2
Type "help", "copyright", "credits" or "license" for more information.

>>> import sys
>>> sys.path.append('/opt/pythonnet/src/tests')
>>> import runtests

>>> runtests.main()
..................F. test_exceptions
======================================================================
FAIL: Test the str() representation of an exception.
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/opt/pythonnet/src/tests/test_exceptions.py", line 310, in
testStrOfException
    self.failUnless(str(e).find('at System.DateTime.Parse') > -1)
AssertionError

----------------------------------------------------------------------
Ran 20 tests in 0.271s

FAILED (failures=1)
.......F............ test_module
======================================================================
FAIL: Test implicit assembly loading via import.
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/opt/pythonnet/src/tests/test_module.py", line 177, in
testImplicitAssemblyLoad
    self.failUnlessRaises(ImportError, test)
AssertionError: ImportError not raised

----------------------------------------------------------------------
Ran 20 tests in 0.127s

FAILED (failures=1)
.................... test_conversion
----------------------------------------------------------------------
Ran 20 tests in 0.054s

OK
............... test_class
----------------------------------------------------------------------
Ran 15 tests in 0.017s

OK
.... test_interface
----------------------------------------------------------------------
Ran 4 tests in 0.003s

OK
.....E......... test_enum
======================================================================
ERROR: Test enumeration conversion with FlagsAttribute set.
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/opt/pythonnet/src/tests/test_enum.py", line 130, in
testEnumWithFlagsAttrConversion
    label = Label()
NullReferenceException: Object reference not set to an instance of an object
in <0x00013> System.Windows.Forms.Label:get_DefaultSize ()
in <0x001b3> System.Windows.Forms.Control:.ctor ()
in <0x0001b> System.Windows.Forms.Label:.ctor ()
in <0x00000> <unknown method>
in (wrapper managed-to-native) System.Reflection.MonoCMethod:InternalInvoke
(object,object[])
in <0x0008d> System.Reflection.MonoCMethod:Invoke (System.Object obj,
BindingFlags invokeAttr, System.Reflection.Binder binder, System.Object[]
parameters, System.Globalization.CultureInfo culture)

----------------------------------------------------------------------
Ran 15 tests in 0.099s

FAILED (errors=1)
.............................. test_field
----------------------------------------------------------------------
Ran 30 tests in 0.005s

OK
.......... test_property
----------------------------------------------------------------------
Ran 10 tests in 0.004s

OK
............................ test_indexer
----------------------------------------------------------------------
Ran 28 tests in 0.100s

OK
....................Mono System.Windows.Forms Assembly [Revision: 54007; built:
2005/12/6 14:35:24]
E....... test_event
======================================================================
ERROR: Test remove on an event sink implemented w/internalcall.
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/opt/pythonnet/src/tests/test_event.py", line 505, in
testRemoveInternalCallHandler
    f = Form()
TypeInitializationException: An exception was thrown by the type initializer for
System.Windows.Forms.XplatUI
in <0x00000> <unknown method>
in <0x00064> System.Windows.Forms.Form:get_CreateParams ()
in <0x00273> System.Windows.Forms.Control:.ctor ()
in <0x00011> System.Windows.Forms.ScrollableControl:.ctor ()
in <0x00010> System.Windows.Forms.ContainerControl:.ctor ()
in <0x00019> System.Windows.Forms.Form:.ctor ()
in <0x00000> <unknown method>
in (wrapper managed-to-native) System.Reflection.MonoCMethod:InternalInvoke
(object,object[])
in <0x0008d> System.Reflection.MonoCMethod:Invoke (System.Object obj,
BindingFlags invokeAttr, System.Reflection.Binder binder, System.Object[]
parameters, System.Globalization.CultureInfo culture)

----------------------------------------------------------------------
Ran 28 tests in 0.180s

FAILED (errors=1)
.....................E..... test_method
======================================================================
ERROR: Test subclass instance conversion in method call.
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/opt/pythonnet/src/tests/test_method.py", line 235, in
testSubclassInstanceConversion
    form = sub()
NullReferenceException: Object reference not set to an instance of an object
in <0x0001d> System.Windows.Forms.XplatUI:CalculateWindowRect (IntPtr handle,
System.Drawing.Rectangle ClientRect, Int32 Style, Int32 ExStyle,
System.Windows.Forms.Menu menu, System.Drawing.Rectangle WindowRect)
in <0x002b0> System.Windows.Forms.Control:.ctor ()
in <0x00011> System.Windows.Forms.ScrollableControl:.ctor ()
in <0x00010> System.Windows.Forms.ContainerControl:.ctor ()
in <0x00019> System.Windows.Forms.Form:.ctor ()
in <0x00000> <unknown method>
in (wrapper managed-to-native) System.Reflection.MonoCMethod:InternalInvoke
(object,object[])
in <0x0008d> System.Reflection.MonoCMethod:Invoke (System.Object obj,
BindingFlags invokeAttr, System.Reflection.Binder binder, System.Object[]
parameters, System.Globalization.CultureInfo culture)

----------------------------------------------------------------------
Ran 27 tests in 0.077s

FAILED (errors=1)
................ test_delegate
----------------------------------------------------------------------
Ran 16 tests in 0.006s

OK
....................................... test_array
----------------------------------------------------------------------
Ran 39 tests in 0.108s

OK
... test_thread
----------------------------------------------------------------------
Ran 3 tests in 1.112s

OK
... idem
----------------------------------------------------------------------
Ran 3 tests in 1.099s

OK
...
----------------------------------------------------------------------
Ran 3 tests in 1.099s

OK
...
----------------------------------------------------------------------
Ran 3 tests in 1.099s

OK
...
----------------------------------------------------------------------
Ran 3 tests in 1.098s

OK
...
----------------------------------------------------------------------
Ran 3 tests in 1.098s

OK
...
----------------------------------------------------------------------
Ran 3 tests in 1.099s

OK
...
----------------------------------------------------------------------
Ran 3 tests in 1.099s

OK
...
----------------------------------------------------------------------
Ran 3 tests in 1.099s

OK
...
----------------------------------------------------------------------
Ran 3 tests in 1.099s

OK
...
----------------------------------------------------------------------
Ran 3 tests in 1.099s

OK
...
----------------------------------------------------------------------
Ran 3 tests in 1.099s

OK
...
----------------------------------------------------------------------
Ran 3 tests in 1.100s

OK
...
----------------------------------------------------------------------
Ran 3 tests in 1.098s

OK
...
----------------------------------------------------------------------
Ran 3 tests in 1.098s

OK
...
----------------------------------------------------------------------
Ran 3 tests in 1.099s

OK
...
----------------------------------------------------------------------
Ran 3 tests in 1.099s

OK
...
----------------------------------------------------------------------
Ran 3 tests in 1.099s

OK
...
----------------------------------------------------------------------
Ran 3 tests in 1.099s

OK
...
----------------------------------------------------------------------
Ran 3 tests in 1.129s

OK
...
----------------------------------------------------------------------
Ran 3 tests in 1.100s

OK
...
----------------------------------------------------------------------
Ran 3 tests in 1.098s

OK
...
----------------------------------------------------------------------
Ran 3 tests in 1.099s

OK
...
----------------------------------------------------------------------
Ran 3 tests in 1.099s

OK
...
----------------------------------------------------------------------
Ran 3 tests in 1.099s

OK
...
----------------------------------------------------------------------
Ran 3 tests in 1.099s

OK
...
----------------------------------------------------------------------
Ran 3 tests in 1.099s

OK
...
----------------------------------------------------------------------
Ran 3 tests in 1.099s

OK
...
----------------------------------------------------------------------
Ran 3 tests in 1.099s

OK
...
----------------------------------------------------------------------
Ran 3 tests in 1.099s

OK
...
----------------------------------------------------------------------
Ran 3 tests in 1.099s

OK
...
----------------------------------------------------------------------
Ran 3 tests in 1.099s

OK
...
----------------------------------------------------------------------
Ran 3 tests in 1.099s

OK
...
----------------------------------------------------------------------
Ran 3 tests in 1.099s

OK
...
----------------------------------------------------------------------
Ran 3 tests in 1.100s

OK
...
----------------------------------------------------------------------
Ran 3 tests in 1.098s

OK
...
----------------------------------------------------------------------
Ran 3 tests in 1.099s

OK
...
----------------------------------------------------------------------
Ran 3 tests in 1.099s

OK
...
----------------------------------------------------------------------
Ran 3 tests in 1.099s

OK
...
----------------------------------------------------------------------
Ran 3 tests in 1.099s

OK
...
----------------------------------------------------------------------
Ran 3 tests in 1.099s

OK
...
----------------------------------------------------------------------
Ran 3 tests in 1.099s

OK
...
----------------------------------------------------------------------
Ran 3 tests in 1.099s

OK
...
----------------------------------------------------------------------
Ran 3 tests in 1.099s

OK
...
----------------------------------------------------------------------
Ran 3 tests in 1.099s

OK
...
----------------------------------------------------------------------
Ran 3 tests in 1.098s

OK
...
----------------------------------------------------------------------
Ran 3 tests in 1.099s

OK
...
----------------------------------------------------------------------
Ran 3 tests in 1.099s

OK
...
----------------------------------------------------------------------
Ran 3 tests in 1.099s

OK
...
----------------------------------------------------------------------
Ran 3 tests in 1.099s

OK
Total Time: 0.87


From roman.yakovenko at gmail.com  Mon Apr  3 19:17:30 2006
From: roman.yakovenko at gmail.com (Roman Yakovenko)
Date: Mon, 3 Apr 2006 20:17:30 +0300
Subject: [Python.NET] Use of c++ dll in python
In-Reply-To: <00ca01c65710$d81f6ff0$d50cc70a@dlh.st.com>
References: <00ca01c65710$d81f6ff0$d50cc70a@dlh.st.com>
Message-ID: <7465b6170604031017v2262f3dfl1faac19b0d681ac@mail.gmail.com>

On 4/3/06, Lalit DIGARI <lalit.digari at st.com> wrote:
> Hello All ,
> I have devloped a c++ dll named mydll in c++ how can I access it with in python script using ctype...

Hi. I think this is the wrong mailing list to ask. Any way, you can not do it.
There are 2 reasons:
1. functions name mangling
2. resource management

You have few choices:
1. To create thin wrapper to dll that will expose ".NET" interface
2. To use boost.python library ( or if you resist SWIG )

> Regard's
> Lalit

--
Roman Yakovenko
C++ Python language binding
http://www.language-binding.net/

From brian.d.lloyd at gmail.com  Mon Apr  3 21:37:52 2006
From: brian.d.lloyd at gmail.com (Brian Lloyd)
Date: Mon, 3 Apr 2006 15:37:52 -0400
Subject: [Python.NET] import changes for 2.x
Message-ID: <1c0b4a390604031237h35065d1ep1af123d837c9551c@mail.gmail.com>

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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.python.org/pipermail/pythondotnet/attachments/20060403/a7bf8568/attachment.html 

From lalit.digari at st.com  Tue Apr  4 06:36:52 2006
From: lalit.digari at st.com (Lalit DIGARI)
Date: Tue, 4 Apr 2006 10:06:52 +0530
Subject: [Python.NET] Use of c++ dll in python
In-Reply-To: <4187BAA24A3D094F925AEE0BE39B70770255575C@msgusaemb01.autodesk.com>
Message-ID: <00cb01c657a1$69588d40$d50cc70a@dlh.st.com>

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 at eur.autodesk.com] 
Sent: Monday, April 03, 2006 5:41 PM
To: Lalit DIGARI; pythondotnet at 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 at python.org
[mailto:pythondotnet-bounces at python.org] On Behalf Of Lalit DIGARI
Sent: Monday, April 03, 2006 7:22 AM
To: pythondotnet at 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 at python.org
http://mail.python.org/mailman/listinfo/pythondotnet



From brian.d.lloyd at gmail.com  Tue Apr  4 14:32:02 2006
From: brian.d.lloyd at gmail.com (Brian Lloyd)
Date: Tue, 4 Apr 2006 08:32:02 -0400
Subject: [Python.NET] Use of c++ dll in python
In-Reply-To: <00cb01c657a1$69588d40$d50cc70a@dlh.st.com>
References: <4187BAA24A3D094F925AEE0BE39B70770255575C@msgusaemb01.autodesk.com>
	<00cb01c657a1$69588d40$d50cc70a@dlh.st.com>
Message-ID: <1c0b4a390604040532h5728d14cx517518f242349046@mail.gmail.com>

Lalit,

If your C++ dll is a plain (unmanaged, machine-code) dll, you probably want to
take a look at ctypes:

http://starship.python.net/crew/theller/ctypes/

Python for .NET doesn't specifically help you use arbitrary unmanaged
dlls (but you
should have no problem using ctypes within Python for .NET).

-Brian

On 4/4/06, Lalit DIGARI <lalit.digari at st.com> wrote:
> 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 at eur.autodesk.com]
> Sent: Monday, April 03, 2006 5:41 PM
> To: Lalit DIGARI; pythondotnet at 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 at python.org
> [mailto:pythondotnet-bounces at python.org] On Behalf Of Lalit DIGARI
> Sent: Monday, April 03, 2006 7:22 AM
> To: pythondotnet at 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 at python.org
> http://mail.python.org/mailman/listinfo/pythondotnet
>
>
> _________________________________________________
> Python.NET mailing list - PythonDotNet at python.org
> http://mail.python.org/mailman/listinfo/pythondotnet
>

From brian.d.lloyd at gmail.com  Tue Apr  4 21:03:30 2006
From: brian.d.lloyd at gmail.com (Brian Lloyd)
Date: Tue, 4 Apr 2006 15:03:30 -0400
Subject: [Python.NET] FYI: Switch to Subversion
Message-ID: <1c0b4a390604041203g15a4da1bvd5a6fcb7d9df8aff@mail.gmail.com>

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

From brian.d.lloyd at gmail.com  Tue Apr  4 22:00:02 2006
From: brian.d.lloyd at gmail.com (Brian Lloyd)
Date: Tue, 4 Apr 2006 16:00:02 -0400
Subject: [Python.NET] Delegates and Dictionaries
In-Reply-To: <44203FEE.5010700@walkereconomics.com>
References: <44203FEE.5010700@walkereconomics.com>
Message-ID: <1c0b4a390604041300l7aafa587ncf062fad31cd3ae8@mail.gmail.com>

Sorry, I'm way behind on mail ;)

If I'm reading this right, the issue is that a Python dictionary does
not automatically convert to any particular .NET type (where your
tuples and ints were likely auto
converted to arrays and int32s). Generally speaking, you can't really
meaningfully
pass an arbitrary Python object to .NET code unless it is (a) directly
convertible to
a primitive .NET type or (b) an instance of a .NET type.

In this case, you might want to create a Hashtable or something and pass that,
as that would be visible on the .NET side.

-Brian

On 3/21/06, Mark Anderson <mark at walkereconomics.com> wrote:
> 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
>
> _________________________________________________
> Python.NET mailing list - PythonDotNet at python.org
> http://mail.python.org/mailman/listinfo/pythondotnet
>

From guy at r-e-d.co.nz  Mon Apr  3 21:53:35 2006
From: guy at r-e-d.co.nz (Guy Robinson)
Date: Tue, 04 Apr 2006 07:53:35 +1200
Subject: [Python.NET] import changes for 2.x
In-Reply-To: <1c0b4a390604031237h35065d1ep1af123d837c9551c@mail.gmail.com>
References: <1c0b4a390604031237h35065d1ep1af123d837c9551c@mail.gmail.com>
Message-ID: <44317D3F.7090700@r-e-d.co.nz>

Perfect!

Guy

Brian Lloyd wrote:
> 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
> 
> 
> ------------------------------------------------------------------------
> 
> _________________________________________________
> Python.NET mailing list - PythonDotNet at python.org
> http://mail.python.org/mailman/listinfo/pythondotnet

-- 


Robinson eDesign,            P/F: +64 7 866 0626
Rings Beach,                 M: 021 238 0839
RD2,                         E: guy at r-e-d.co.nz
Whitianga.
New Zealand

The contents of this e-mail maybe CONFIDENTIAL OR LEGALLY PRIVILEGED, &
is intended only for the persons named above. If this e-mail is not
addressed to you, you must not use, read, distribute or copy this
document. If you have received this document by mistake, please call us
and destroy the original.  Thank you


From brian.d.lloyd at gmail.com  Wed Apr 19 02:04:43 2006
From: brian.d.lloyd at gmail.com (Brian Lloyd)
Date: Tue, 18 Apr 2006 20:04:43 -0400
Subject: [Python.NET] NAnt as a build solution
Message-ID: <1c0b4a390604181704k1361e39emb0131ee01f5ed8c8@mail.gmail.com>

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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.python.org/pipermail/pythondotnet/attachments/20060418/64564347/attachment.htm 

From brian.d.lloyd at gmail.com  Wed Apr 19 02:29:17 2006
From: brian.d.lloyd at gmail.com (Brian Lloyd)
Date: Tue, 18 Apr 2006 20:29:17 -0400
Subject: [Python.NET] deprecation of CLR module, implicit assembly loading
Message-ID: <1c0b4a390604181729k64be06b5g21d6a4a631f182d@mail.gmail.com>

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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.python.org/pipermail/pythondotnet/attachments/20060418/5ce66f34/attachment.html 

From durango at mail2world.com  Sat Apr  1 07:25:33 2006
From: durango at mail2world.com (Mr  X)
Date: Sat, 01 Apr 2006 05:25:33 -0000
Subject: [Python.NET] Python, VB math simple problem
Message-ID: <0d5701c65545$660c8a00$70cb010a@mail2world.com>



Hi looking for help with what should be a fairly simple Python problem,
relating to VB inter-operability.
Got a great response from a fellow named Matt at help at python.org,
pointed me in some good directions - some areas, concerns still foggy
on, the below thread is included.... any feedback on this simple dilemma
would be very appreciated.

Thanks,

D

thread follows below;

------------------------------------

To: help at python.org 
Subject: Problem with Python math functions and VB 
Date: 3/30/2006 9:39:28 PM 
Download Message Display Headers Printer Friendly 
Previous | Next 

Wondering if you might either know how to solve the following.

I've a background in Visual Basic, and am using an old version, 4.0, it
compiles to a smaller executable which I prefer. I find myself in an odd
situation, needing a very simple yet powerful capability of Python for a
VB app
Im working on.

Simply, a large 300 digit number is divided by a smaller number ranging
from 1 to 3 digits. I.e;

This large 300 digit number is generated as a string from the VB app,
and I want to input this somehow
from the VB app directly to Python for simple math operations.

Where; x = 300 digit number, y = divisor ( say '37')


x / 37

I want to divide x by y but I want the remainder of this division to at
least 3 or 4 decimal places, so my Python script at the command line;

x %y /y. = z

So now I want to take the resultant, the full number plus its remainder,
and I want to round this number up
to the next highest number and divide it by the same constant;

z rounded up to next highest number (never the lowest)

so

z /y = z Long

Remove the 'L' at the end, round up the last digit of z = Z

Then;

Z %y /y. = a

Then I want the last five digits of z (not Z) and a truncated at the
end, so the last digit before
the decimal point and the four digits past the decimal point printed to
a text file.

I want to be able to open the text file with the VB app and use this
data as inputs.
==========

Ok, so here is my dilemma, I know VERY litle about Python and a fair bit
about VB.

Ideally, I'd love to be able to simply have some extremely small
executable that just accepts inputs
does the calculations above and then spits out the outputs. If it were
possible to write some
simple lines of math code in Python and then compile these scripts in
Python to a Windows
compatible executable,that would be fantastic.

If I could simply have my VB app, 'call' the name of the tiny Python
executable, and then the Python executable
just automatically looked for a named text file (created by the VB app)
and extracted the 300 digit number from this, then performed the calcs,
then spit this data out as a new text file name it created, which I
could then use the VB app to open and read from, THAT would be ideal.

However, I don't know if Python can compile scripts to an exe? If it can
how could I find out how to do this?

If it doesn't, how could I get VB to directly pass commands to the
Python command line and then automatically
extract the outputs? Shelling out from VB to Python would be tough to
the command line I think, since the Python command line uses the 'Edit /
Mark, Paste' approach to inserting, copy inputs, outputs and this would
be virtually untenable, as far as I can tell to automate in a VB shell
out routine.

So basically, how the heck can I access Pythons ability to perform
simple calculations on very large numbers, easily, from within VB 4.0 ?
There must be a way, it seems like such a simple think to do, especially
since the actual math operations are so simple, straight forward, and
would never change.....

Any ideas?



------
Matthew, thanks for your response. 

<-----Original Message-----> 
>From: Matthew Dixon Cowles
>Sent: 3/31/2006 9:41:18 AM
>To: durango at mail2world.com
>Cc: help at python.org
>Subject: Re: [Python-Help] Problem with Python math functions and VB

>I'm sure that there's a way to do that, but I'm not familiar with 
>Visual Basic and I don't know what inter-process communication 
>facilities it offers. 

Is there a person or group you might direct me to that has worked with
this 
inter-process communication between VB and Python?

>I don't think that Python is going to be able to do that for you out 
>of the box. Hundreds of digits of floating-point precision is a lot. 

Could you explain that a bit more, sorry Im not sure what you mean
by 'out of the box' ? If I run the Python command line screen in windows
and manually type out a very large number, say 180 digits; where 'X' =
very large number;

X %37 /37.

returns what Im after, value wise..... but of course I don't want to do
this manually each time
for every dividend.

>You might find that one of the Python modules that let you use an 
>extended-precision library would do what you want. GMPY is one: 

>http://gmpy.sourceforge.net/ 

Hey, thats interesting, wonder if these modules can be operated on with
VB.....

>> So now I want to take the resultant, the full number plus its 
>> remainder, and I want to round this number up 
>> to the next highest number and divide it by the same constant; 
>
>That's easy enough. 
>
>> I want to be able to open the text file with the VB app and use this 
>> data as inputs. 
>
>Python can write to a file without any trouble, so it that form of 
>inter-process communication suits you, you shouldn't have much 
>trouble. I assume that Visual Basic has an easy way to start a 
>program and supply it with arguments, so you could have your Python 
>program get its inputs from sys.argv. 

What is sys.argv ? Thats really good news. In fact, all I really need
for the moment is
a python executable that;

================
PYTHON ALGORITHM ABSTRACT

a) opens a text file
b) reads a string from the file, which is a very large number
c) performs simple arithmetic operations;

X %37 /37. = y (four digit remainder after decimal point)
X /37 = w (quotient as long, the resulting output is stored as a
variable, the 'L' suffix tagged on the end of this resultant then gets
removed.
then the last digit in the quotient resultant string is increased in
value by one, rounded upwards = 'Z'

then 

Z %37 /37. = a

then, y and a are printed to a text file with hard returns between them.
Thats it, thats all I need to do.
===================
>Alas, it's not going to be extremely small. There isn't a compiler 
>from Python to machine code. Py2exe will bundle a Python program, 
>with everything that it needs to run, into a single executable 
>archive. But the archive isn't small. Py2exe is at: 
>
>http://www.py2exe.org/ 

the most important thing is the functionality, I'll sacrifice size if I
have to. My guess is this should work based on your comments, because
perhaps all I really have to do is have VB dump out the value of the
Very large number, `180 to 300 digits or so', to a text file, which then
becomes the input data for the Python executable, and then if I simply
call the name of the Python executable from VB as an instance,
then the Python App runs, spits out the data as a new text file, then
the VB app goes and opens the new text file and reads in the values,
and voila! There it is. I'm pretty sure I can call the Python app from
VB....... the alternative to all this would be to try and feed Python
scripts
directly to Python from VB, which I have NO idea how to do or where to
begin.... and am guessing would be much more messy...

I haven't programmed in Python, how would the "PYTHON ALGORITHM
ABSTRACT" I describe above look like, code wise? 
Is this fairly easy for you to describe?

>It may be that Python isn't the best solution for you here. Are there 
>extended-precision libraries for Visual Basic? 

Alas, none that I know of that are reliable and not incredibly
expensive, been looking for years, plus Im hooped because I have to work
with VB 4.0 instead of 6 +, guh.... 

>Regards, 
>Matt 

Matt..... good name, why do I always seem to get along with Matts, you
people keep popping up in my life and its always a blast!

Best regards,

D 


<span id=m2wTl><p><font face="Arial, Helvetica, sans-serif" size="2" style="font-size:13.5px">_______________________________________________________________<BR>Get the FREE email that has everyone talking at <a href=http://www.mail2world.com target=new>http://www.mail2world.com</a><br>  <font color=#999999>Unlimited Email Storage &#150; POP3 &#150; Calendar &#150; SMS &#150; Translator &#150; Much More!</font></font></span>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.python.org/pipermail/pythondotnet/attachments/20060401/7db63de0/attachment.htm 

From mark.mcmahon at eur.autodesk.com  Mon Apr  3 14:11:31 2006
From: mark.mcmahon at eur.autodesk.com (Mark McMahon)
Date: Mon, 03 Apr 2006 12:11:31 -0000
Subject: [Python.NET] Use of c++ dll in python
Message-ID: <4187BAA24A3D094F925AEE0BE39B70770255575C@msgusaemb01.autodesk.com>

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 at python.org [mailto:pythondotnet-bounces at python.org] On Behalf Of Lalit DIGARI
Sent: Monday, April 03, 2006 7:22 AM
To: pythondotnet at 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 at python.org
http://mail.python.org/mailman/listinfo/pythondotnet


From mark.mcmahon at eur.autodesk.com  Tue Apr  4 13:55:35 2006
From: mark.mcmahon at eur.autodesk.com (Mark McMahon)
Date: Tue, 4 Apr 2006 07:55:35 -0400
Subject: [Python.NET] Use of c++ dll in python
Message-ID: <4187BAA24A3D094F925AEE0BE39B7077025D1007@msgusaemb01.autodesk.com>

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 at st.com] 
Sent: Tuesday, April 04, 2006 12:37 AM
To: Mark McMahon
Cc: pythondotnet at 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 at eur.autodesk.com] 
Sent: Monday, April 03, 2006 5:41 PM
To: Lalit DIGARI; pythondotnet at 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 at python.org
[mailto:pythondotnet-bounces at python.org] On Behalf Of Lalit DIGARI
Sent: Monday, April 03, 2006 7:22 AM
To: pythondotnet at 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 at python.org
http://mail.python.org/mailman/listinfo/pythondotnet




From brian.d.lloyd at gmail.com  Wed Apr 19 02:44:29 2006
From: brian.d.lloyd at gmail.com (Brian Lloyd)
Date: Tue, 18 Apr 2006 20:44:29 -0400
Subject: [Python.NET] full IronPython test suite?
Message-ID: <1c0b4a390604181744m42920dbp5c2ea10e1e494c9e@mail.gmail.com>

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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.python.org/pipermail/pythondotnet/attachments/20060418/77def79e/attachment.html 

From lalit.digari at st.com  Thu Apr 20 13:52:53 2006
From: lalit.digari at st.com (Lalit DIGARI)
Date: Thu, 20 Apr 2006 17:22:53 +0530
Subject: [Python.NET] Python compare string fucntion
In-Reply-To: <4187BAA24A3D094F925AEE0BE39B70770255575C@msgusaemb01.autodesk.com>
Message-ID: <00d301c66470$f564da60$d50cc70a@dlh.st.com>


Helllo guys,
Is there any pyhthon function as c's  strcmp function

Regard's
Lalit
-----Original Message-----
From: Mark McMahon [mailto:mark.mcmahon at eur.autodesk.com] 
Sent: Monday, April 03, 2006 5:41 PM
To: Lalit DIGARI; pythondotnet at 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 at python.org
[mailto:pythondotnet-bounces at python.org] On Behalf Of Lalit DIGARI
Sent: Monday, April 03, 2006 7:22 AM
To: pythondotnet at 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 at python.org
http://mail.python.org/mailman/listinfo/pythondotnet