I just did the initial import of Pyd:

http://dsource.org/projects/pyd/browser/trunk

Be warned: There are still some rough edges that need smoothing out, and it is barely documented. (Though I have been pretty good about putting in ddoc comments.) I also haven't thoroughly tested everything, so if anyone spots some bugs, I'd be interested to hear about it. It is also somewhat fiddly to build, requiring the use of various bits and pieces that are scattered here and there; maybe I'll write a "how to build" guide at some point.

In the easiest case, get David Rushby's Celerid (see the readme.txt file), replace its python.d with my python.d (included in Pyd's "header" directory), edit the build.bat and build_ddoc.bat files to give them your appropriate PATH info, and you should be good to go. I haven't bothered with a Linux solution yet as DMD can't compile dynamic libraries in Linux. I am very interested in adding this support once that has been fixed.

-Kirk McDonald

In article <e7hjv9$v03$1@digitaldaemon.com>, Kirk McDonald says...
> I just did the initial import of Pyd: http://dsource.org/projects/pyd/browser/trunk

I'm impressed by your work, Kirk.

> In the easiest case, get David Rushby's Celerid... (see the
> readme.txt replace its python.d with my python.d...
> I haven't bothered with a Linux solution yet as DMD can't
> compile dynamic libraries in Linux. I am very interested
> in adding this support once that has been fixed.

My work on celerid has halted until DMD on Linux is fixed, so why don't we officially agree that your python.d has superseded mine?  If in the future I want to do further work on the functionality that CeleriD contained, I'll try to contribute to Pyd rather than continuing with CeleriD.  Does that sound reasonable?

David Rushby wrote:
> In article <e7hjv9$v03$1@digitaldaemon.com>, Kirk McDonald says...
> 
>>I just did the initial import of Pyd:
>>http://dsource.org/projects/pyd/browser/trunk
> 
> 
> I'm impressed by your work, Kirk.
> 
> 
>>In the easiest case, get David Rushby's Celerid... (see the
>>readme.txt replace its python.d with my python.d...
>>I haven't bothered with a Linux solution yet as DMD can't
>>compile dynamic libraries in Linux. I am very interested in adding this support once that has been fixed.
> 
> 
> My work on celerid has halted until DMD on Linux is fixed, so why don't we
> officially agree that your python.d has superseded mine?  If in the future I
> want to do further work on the functionality that CeleriD contained, I'll try to
> contribute to Pyd rather than continuing with CeleriD.  Does that sound
> reasonable?
> 
> 

Does that mean you want to merge Celerid and Pyd? It does seem reasonable to have one project for all the D/Python compatability stuff.

-Kirk McDonald

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?

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?
> 
> 

Certainly not. The raw Python/C API is still fully accessible by simply saying "import python". (I've been careful to always say "private import python" in Pyd's source, so it isn't available by simply saying "import pyd.pyd".)

(As a matter of fact, mixing the Python/C API with Pyd is currently necessary as the whole thing hasn't been wrapped quite yet.)

As for compilation with the distutils-style setup.py, this is my preferred method. At the moment, the setup.py file itself needs to be told what Pyd's source files are. By integrating the two projects, compiling these files can be done automatically, perhaps with a flag in the setup.py to build in "classic," object-oriented-layer-free mode.

-Kirk McDonald

http://dsource.org/projects/pyd/wiki

As of revision 16, Pyd is now capable of the following:

[testdll.d]
module testdll;

import pyd.pyd;
import std.stdio;

// Function wrapping
char[] bar(int i) {
    if (i > 10) {
        return "It's greater than 10!";
    } else {
        return "It's less than 10!";
    }
}

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

// Inroads on class wrapping
class Foo {
    void foo() {
        writefln("Foo.foo()");
    }
}

extern (C)
export void inittestdll() {
    // Wrap function
    def!("bar", bar);
    // Wrap function with default arguments
    def!("baz", baz, 0);

    module_init("testdll");

    // Wrap class
    // (It sure says "Foo" a lot... I should do something about that.)
    auto Foo_ = wrap_class!("Foo", Foo)();
    Foo_.def!("foo", Foo.foo);
    finalize_class!("Foo", Foo);
}
// EOF

In Python:

>>> import testdll
>>> a = Foo()
>>> a.foo()
Foo.foo()

This class wrapping support offers little more than that at this point. This is mostly because there are now soooo many cool things I can do that I must pause and catch my breath.

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

* Support for constructors other than the default constructor. This is not trivial. I know how I am going to do it, but it is going to involve hammering out a bunch of code.

* Exposure of properties (and maybe member variables, though that is harder).

Nifty features I can implement:
* Automatic wrapping of overloaded operators. (If you overload opAdd, it will automatically do the same in Python.)

* Subclassing support. (The ability to write subclasses of your D classes in Python.) This is actually just a matter of being careful as I write the wrapping templates. If I do it right, this will simply Just Work.

-Kirk McDonald

Kirk McDonald wrote:
> http://dsource.org/projects/pyd/wiki
> 
> As of revision 16, Pyd is now capable of the following:
> 
> [testdll.d]
> module testdll;
> 
> import pyd.pyd;
> import std.stdio;
> 
> // Function wrapping
> char[] bar(int i) {
>     if (i > 10) {
>         return "It's greater than 10!";
>     } else {
>         return "It's less than 10!";
>     }
> }
> 
> // Default argument support
> void baz(int i=10, char[] s="moo") {
>     writefln("i = %s\ns = %s", i, s);
> }
> 
> // Inroads on class wrapping
> class Foo {
>     void foo() {
>         writefln("Foo.foo()");
>     }
> }
> 
> extern (C)
> export void inittestdll() {
>     // Wrap function
>     def!("bar", bar);
>     // Wrap function with default arguments
>     def!("baz", baz, 0);
> 
>     module_init("testdll");
> 
>     // Wrap class
>     // (It sure says "Foo" a lot... I should do something about that.)
>     auto Foo_ = wrap_class!("Foo", Foo)();
>     Foo_.def!("foo", Foo.foo);
>     finalize_class!("Foo", Foo);
> }
> // EOF
> 
> In Python:
> 
>  >>> import testdll
>  >>> a = Foo()
>  >>> a.foo()
> Foo.foo()
> 
> This class wrapping support offers little more than that at this point. This is mostly because there are now soooo many cool things I can do that I must pause and catch my breath.
> 
> Important things left to do:
> * Add the wrapped types to the conversion templates. This is fairly trivial, actually.
> 
> * Support for constructors other than the default constructor. This is not trivial. I know how I am going to do it, but it is going to involve hammering out a bunch of code.
> 
> * Exposure of properties (and maybe member variables, though that is harder).
> 
> Nifty features I can implement:
> * Automatic wrapping of overloaded operators. (If you overload opAdd, it will automatically do the same in Python.)
> 
> * Subclassing support. (The ability to write subclasses of your D classes in Python.) This is actually just a matter of being careful as I write the wrapping templates. If I do it right, this will simply Just Work.
> 
> -Kirk McDonald

To you, dear sir, I tip my hat.

	-- Daniel

Kirk McDonald wrote:
> http://dsource.org/projects/pyd/wiki
> 
> As of revision 16, Pyd is now capable of the following:
[snipped stuff about class wrapping]
> Important things left to do:
> * Support for constructors other than the default constructor. This is not trivial. I know how I am going to do it, but it is going to involve hammering out a bunch of code.

This is now done to some extent. There is currently one fairly serious limitation: You can't wrap two different constructors that take the same number of arguments. I can fix this eventually, but this is a good first step. Aside from this limitation, it works:

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);
    }
}

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

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

In Python:
>>> a = testdll.Foo()
>>> a.foo()
Foo.foo(): i = 0
>>> b = testdll.Foo(10)
>>> b.foo()
Foo.foo(): i = 10
>>> c = testdll.Foo(12, 30)
>>> c.foo()
Foo.foo(): i = 42

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.)

-Kirk McDonald

Kirk McDonald wrote:
> Kirk McDonald wrote:
>> http://dsource.org/projects/pyd/wiki
>>
>> As of revision 16, Pyd is now capable of the following:
> [snipped stuff about class wrapping]
>> Important things left to do:
>> * Support for constructors other than the default constructor. This is not trivial. I know how I am going to do it, but it is going to involve hammering out a bunch of code.
> 
> This is now done to some extent. There is currently one fairly serious limitation: You can't wrap two different constructors that take the same number of arguments. I can fix this eventually, but this is a good first step. Aside from this limitation, it works:
> 
> 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);
>     }
> }
> 
> extern (C)
> export void inittestdll() {
>     module_init("testdll");
> 
>     auto Foo_ = wrap_class!("Foo", Foo)();
>     Foo_.init!(ctor!(int), ctor!(int, int));
>     Foo_.def!("foo", Foo.foo);
>     finalize_class!("Foo", Foo);
> }
> 
> In Python:
>  >>> a = testdll.Foo()
>  >>> a.foo()
> Foo.foo(): i = 0
>  >>> b = testdll.Foo(10)
>  >>> b.foo()
> Foo.foo(): i = 10
>  >>> c = testdll.Foo(12, 30)
>  >>> c.foo()
> Foo.foo(): i = 42
> 
> 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.)
> 
> -Kirk McDonald

Great stuff, though I have very little experience with Python.
It's fascinating to me to see how many similarities there are between the front ends of Pyd and DDL. When I finish updating my meta.nameof module, I'll return to improving the DDL interface for class loading. Since I last worked on it, many DMD bugs have been fixed, and we now have IFTI. Some of the techniques will be transferable to Pyd.
Certainly it would AT LEAST be possible to do:

>     auto Foo_ = wrap_class!(Foo)();
>     Foo_.init!(ctor!(int), ctor!(int, int)); // could almost certainly improve this, too.
>     Foo_.def!(Foo.foo);
>     finalize_class!(Foo);

It may be possible to come up with a generic dynamic linking front-end which can be reused for a huge variety of programming languages; that's an exiting concept.

In article <e803al$240e$1@digitaldaemon.com>, Daniel Keep says...
>
>Kirk McDonald wrote:
>> http://dsource.org/projects/pyd/wiki
>> 
>> As of revision 16, Pyd is now capable of the following:
>> ...
>
>To you, dear sir, I tip my hat.

As do I.  It's really cool stuff.