Kirk McDonald wrote:
> There are still some issues: Passing an unconvertable type (e.g. giving the ctor a string when it expects an int) appears to have dire consequences (Python crashes), and I'm still tracking the precise problem down. (It's undoubtedly an uncaught exception; Python reacts quite badly when those go uncaught.)

Consider this problem done and gone. :-) Now I can move on to more interesting problems!

-- 
Kirk McDonald
Pyd: Wrapping Python with D
http://dsource.org/projects/pyd/wiki

Kirk McDonald wrote:
> Important things left to do:
> * Add the wrapped types to the conversion templates. This is fairly trivial, actually.
> 

Done! This greatly expands the usefulness of Pyd:

[testdll.d]
module testdll;

import pyd.pyd;
import std.stdio;

class Foo {
    int m_i;
    this() { }
    this(int i) { m_i = i; }
    this(int i, int j) { m_i = i + j; }
    void foo() {
        writefln("Foo.foo(): i = %s", m_i);
    }
    int i() { return m_i; }
}

Foo spam(Foo f) {
    f.foo();
    Foo g = new Foo(f.i + 10);
    return g;
}

extern (C)
export void inittestdll() {
    def!("spam", spam);

    module_init("testdll");

    auto Foo_ = wrap_class!("Foo", Foo)();
    Foo_.init!(ctor!(int), ctor!(int, int));
    Foo_.def!("foo", Foo.foo);
    Foo_.def!("i", Foo.i);
    finalize_class(Foo_);
}

And in Python:

>>> import testdll
>>> a = testdll.Foo(10)
>>> b = testdll.spam(a)
Foo.foo(): i = 10
>>> b.i()
20

:-)

-- 
Kirk McDonald
Pyd: Wrapping Python with D
http://dsource.org/projects/pyd/wiki

Kirk McDonald wrote:
> Important things left to do:
> * Exposure of properties (and maybe member variables, though that is harder).

Done!

[testdll.d]
class Foo {
    int m_i;
    this() { }
    this(int i) { m_i = i; }
    this(int i, int j) { m_i = i + j; }
    void foo() {
        writefln("Foo.foo(): i = %s", m_i);
    }
    int i() { return m_i; }
    void i(int j) { m_i = j; }
}

extern (C)
export void inittestdll() {
    module_init("testdll");

    wrapped_class!("Foo", Foo) f;
    f.init!(ctor!(int), ctor!(int, int));
    f.def!("foo", Foo.foo);
    f.prop!("i", Foo.i);
    finalize_class(f);
}
// EOF

(Also note the reworked class wrapping syntax.)

In Python:

>>> import testdll
>>> a = testdll.Foo(10)
>>> a.i
10
>>> a.i = 20
>>> a.i
20

-- 
Kirk McDonald
Pyd: Wrapping Python with D
http://dsource.org/projects/pyd/wiki

David Rushby wrote:
> In article <e7hp2l$1638$1@digitaldaemon.com>, Kirk McDonald says...
> 
>>Does that mean you want to merge Celerid and Pyd?
> 
> 
> Yes.  I think users will find it easier to deal with an integrated package.
> 
> I *would* like to see the current capabilities of CeleriD (the option to use the
> plain Python/C API rather than the object-oriented wrapper if desired, and the
> ability to compile with a familiar distutils setup.py style) preserved in the
> integrated CeleriD/Pyd, but I don't anticipate that that would be a problem, do
> you?
> 
> 

Done! I've essentially just crammed Pyd in the "infrastructure" directory of Celerid and informed the DMDDCompiler class about the Pyd source files.

I think I can now say that Pyd is in a state where you can actually use it for useful things. I think the next step is fleshing out the documentation, which I've let slide since I started writing the class wrapping features.

-- 
Kirk McDonald
Pyd: Wrapping Python with D
http://dsource.org/projects/pyd/wiki

I've just added some nifty things to Pyd:

[testdll.d]
module testdll;

import python;
import pyd.pyd;
import std.stdio;

// d_type testing
void foo() {
    writefln("Boo!");
}

void foo(int i) {
    writefln("You entered %s", i);
}

void baz(int i=10, char[] s="moo") {
    writefln("i = %s\ns = %s", i, s);
}

class Foo {
    int m_i;
    this() { }
    this(int i) { m_i = i; }
    this(int i, int j) { m_i = i + j; }
    void foo() {
        writefln("Foo.foo(): i = %s", m_i);
    }
    Foo opAdd(Foo f) { return new Foo(m_i + f.m_i); }
    int i() { return m_i; }
    void i(int j) { m_i = j; }
}

void delegate() func_test(Foo f) {
    return &f.foo;
}

extern (C)
export void inittestdll() {
    module_init("testdll");

    def!("foo", foo);
    // Python does not support function overloading. This allows
    // us to wrap an overloading function under a different name.
    def!("foo2", foo, 1, void function(int));
    // Default argument support is now automatic.
    def!("baz", baz);
    // Functions and delegates can be returned into Python. (Stay
    // tuned for the reverse operation of converting a Python
    // callable into a function/delegate.)
    def!("func_test", func_test);

    wrapped_class!("Foo", Foo) f;
    // opAdd is wrapped automatically
    f.init!(ctor!(int), ctor!(int, int));
    f.def!("foo", Foo.foo);
    f.prop!("i", Foo.i);
    finalize_class(f);
}
// EOF

In Python:

>>> import testdll
>>> f = testdll.Foo(20)
>>> g = testdll.Foo(30)
>>> h = f + g
>>> h.i
50
>>> a = testdll.func_test(f)
>>> a()
Foo.foo(): i = 20
>>> testdll.baz()
i = 10
s = moo

-- 
Kirk McDonald
Pyd: Wrapping Python with D
http://dsource.org/projects/pyd/wiki

Kirk McDonald wrote:
> I've just added some nifty things to Pyd:
> 
> [testdll.d]
> extern (C)
> export void inittestdll() {
>     module_init("testdll");
> 
>     def!("foo", foo);
>     // Python does not support function overloading. This allows
>     // us to wrap an overloading function under a different name.
>     def!("foo2", foo, 1, void function(int));
>     // Default argument support is now automatic.
>     def!("baz", baz);
>     // Functions and delegates can be returned into Python. (Stay
>     // tuned for the reverse operation of converting a Python
>     // callable into a function/delegate.)
>     def!("func_test", func_test);
> 
>     wrapped_class!("Foo", Foo) f;
>     // opAdd is wrapped automatically
>     f.init!(ctor!(int), ctor!(int, int));
>     f.def!("foo", Foo.foo);
>     f.prop!("i", Foo.i);
>     finalize_class(f);
> }

I think you should swap the order of the first two arguments to most of these functions. The function being wrapped is more fundamental than the name. If you did this, you could (for example) use my newly-updated meta.nameof module to change the definition of def!() to:

private import meta.nameof;

template def(alias fn, char[] name = symbolnameof!(fn), uint MIN_ARGS = NumberOfArgs!(typeof(&fn)), fn_t = typeof(&fn))
{....}

so that users would write

def!(baz);
f.def!(Foo.foo);
f.prop!(Foo.i);

Equally valid if D ever gets a built-in equivalent to symbolnameof!().



>

> 
>  >>> import testdll
>  >>> f = testdll.Foo(20)
>  >>> g = testdll.Foo(30)
>  >>> h = f + g
>  >>> h.i
> 50
>  >>> a = testdll.func_test(f)
>  >>> a()
> Foo.foo(): i = 20
>  >>> testdll.baz()
> i = 10
> s = moo
> 

Don Clugston wrote:
> Kirk McDonald wrote:
> 
>> I've just added some nifty things to Pyd:
>>
>> [testdll.d]
>> extern (C)
>> export void inittestdll() {
>>     module_init("testdll");
>>
>>     def!("foo", foo);
>>     // Python does not support function overloading. This allows
>>     // us to wrap an overloading function under a different name.
>>     def!("foo2", foo, 1, void function(int));
>>     // Default argument support is now automatic.
>>     def!("baz", baz);
>>     // Functions and delegates can be returned into Python. (Stay
>>     // tuned for the reverse operation of converting a Python
>>     // callable into a function/delegate.)
>>     def!("func_test", func_test);
>>
>>     wrapped_class!("Foo", Foo) f;
>>     // opAdd is wrapped automatically
>>     f.init!(ctor!(int), ctor!(int, int));
>>     f.def!("foo", Foo.foo);
>>     f.prop!("i", Foo.i);
>>     finalize_class(f);
>> }
> 
> 
> I think you should swap the order of the first two arguments to most of these functions. The function being wrapped is more fundamental than the name. If you did this, you could (for example) use my newly-updated meta.nameof module to change the definition of def!() to:
> 
> private import meta.nameof;
> 
> template def(alias fn, char[] name = symbolnameof!(fn), uint MIN_ARGS = NumberOfArgs!(typeof(&fn)), fn_t = typeof(&fn))
> {....}
> 
> so that users would write
> 
> def!(baz);
> f.def!(Foo.foo);
> f.prop!(Foo.i);
> 
> Equally valid if D ever gets a built-in equivalent to symbolnameof!().
> 
> 

I agree! Most certainly. I've just been planning on doing it whenever I get around to requiring (and installing :-) DDL. The definition of def!() will actually be:

template def(alias fn, char[] name = symbolnameof!(fn), fn_t = typeof(&fn), uint MIN_ARGS = MIN_ARGS!(fn))

(I can derive MIN_ARGS automatically now, so I now view specifying it as more anomolous than specifying fn_t.)

I think I'll make this change in the next revision, though I'm not adding the support for symbolnameof /quite/ yet.

> 
>  >
> 
>>
>>  >>> import testdll
>>  >>> f = testdll.Foo(20)
>>  >>> g = testdll.Foo(30)
>>  >>> h = f + g
>>  >>> h.i
>> 50
>>  >>> a = testdll.func_test(f)
>>  >>> a()
>> Foo.foo(): i = 20
>>  >>> testdll.baz()
>> i = 10
>> s = moo
>>


-- 
Kirk McDonald
Pyd: Wrapping Python with D
http://dsource.org/projects/pyd/wiki

Kirk McDonald wrote:
> Don Clugston wrote:
>> Kirk McDonald wrote:
>>
>>> I've just added some nifty things to Pyd:
>>>
>>> [testdll.d]
>>> extern (C)
>>> export void inittestdll() {
>>>     module_init("testdll");
>>>
>>>     def!("foo", foo);
>>>     // Python does not support function overloading. This allows
>>>     // us to wrap an overloading function under a different name.
>>>     def!("foo2", foo, 1, void function(int));
>>>     // Default argument support is now automatic.
>>>     def!("baz", baz);
>>>     // Functions and delegates can be returned into Python. (Stay
>>>     // tuned for the reverse operation of converting a Python
>>>     // callable into a function/delegate.)
>>>     def!("func_test", func_test);
>>>
>>>     wrapped_class!("Foo", Foo) f;
>>>     // opAdd is wrapped automatically
>>>     f.init!(ctor!(int), ctor!(int, int));
>>>     f.def!("foo", Foo.foo);
>>>     f.prop!("i", Foo.i);
>>>     finalize_class(f);
>>> }
>>
>>
>> I think you should swap the order of the first two arguments to most of these functions. The function being wrapped is more fundamental than the name. If you did this, you could (for example) use my newly-updated meta.nameof module to change the definition of def!() to:
>>
>> private import meta.nameof;
>>
>> template def(alias fn, char[] name = symbolnameof!(fn), uint MIN_ARGS = NumberOfArgs!(typeof(&fn)), fn_t = typeof(&fn))
>> {....}
>>
>> so that users would write
>>
>> def!(baz);
>> f.def!(Foo.foo);
>> f.prop!(Foo.i);
>>
>> Equally valid if D ever gets a built-in equivalent to symbolnameof!().
>>
>>
> 
> I agree! Most certainly. I've just been planning on doing it whenever I get around to requiring (and installing :-) DDL.

Actually, it really hasn't got anything to do with DDL. Meta doesn't use DDL, DDL doesn't use meta. It's just that the DDL project has such great code, it's nice to be associated with it, and pragma wrote a compile-time regexp engine that's in meta. Now enki is in DDL too, and it also seems to be quite independent.

 The definition of
> def!() will actually be:
> 
> template def(alias fn, char[] name = symbolnameof!(fn), fn_t = typeof(&fn), uint MIN_ARGS = MIN_ARGS!(fn))
> 
> (I can derive MIN_ARGS automatically now, so I now view specifying it as more anomolous than specifying fn_t.)

Cool!

> I think I'll make this change in the next revision, though I'm not adding the support for symbolnameof /quite/ yet.

No, it's not quite well enough tested yet.
If you just swap the template arguments, it will be something you can seamlessly drop in later. I really think it's just that single reference to symbolnameof!(), the import of nameof, and the three meta files. So it shouldn't be a big deal.

If anyone's interested, I just did some fairly major refactoring of how Pyd wraps functions. I've essentially written my own tuple/metaprogramming library. (Well, at least a limited one.) I'm not sure if the new code is any shorter, but it is at least split into smaller, more easily read and reused chunks.

And I do realize that the code is a bit of a mess in places (the tuples library could use some weed-whacking and documenting: http://dsource.org/projects/pyd/browser/trunk/infrastructure/pyd/tuples.d), but I'm not sure how motivated I am to reorganize it. :-)

-- 
Kirk McDonald
Pyd: Wrapping Python with D
http://dsource.org/projects/pyd/wiki

On Wednesday, 12 July 2006 at 23:35:55 UTC, Kirk McDonald wrote:
> If anyone's interested, I just did some fairly major refactoring of how Pyd wraps functions. I've essentially written my own tuple/metaprogramming library. (Well, at least a limited one.) I'm not sure if the new code is any shorter, but it is at least split into smaller, more easily read and reused chunks.
>
> And I do realize that the code is a bit of a mess in places (the tuples library could use some weed-whacking and documenting: http://dsource.org/projects/pyd/browser/trunk/infrastructure/pyd/tuples.d), but I'm not sure how motivated I am to reorganize it. :-)

has there been any updates since July 2006 there does not seem to be any new msg's since unless you have forked this forum to a new location.  if you have please provide I am new to D I have been learning python for some time and thought Python and D would work well together.

Also are there any Projects using it yet I would like to get involved and contribute if possible.