digitalmars.D

digitalmars.D - Pyd

Kirk McDonald (17/17) Jun 23 2006 I just did the initial import of Pyd:

David Rushby (7/14) Jun 23 2006 My work on celerid has halted until DMD on Linux is fixed, so why don't ...

Kirk McDonald (4/27) Jun 23 2006 Does that mean you want to merge Celerid and Pyd? It does seem

David Rushby (7/8) Jun 24 2006 Yes. I think users will find it easier to deal with an integrated packa...

Kirk McDonald (13/27) Jun 24 2006 Certainly not. The raw Python/C API is still fully accessible by simply
Kirk McDonald (12/26) Jul 01 2006 Done! I've essentially just crammed Pyd in the "infrastructure"

Kirk McDonald (58/61) Jun 28 2006 http://dsource.org/projects/pyd/wiki

Daniel Keep (3/82) Jun 29 2006 To you, dear sir, I tip my hat.

David Rushby (2/8) Jun 29 2006 As do I. It's really cool stuff.

Kirk McDonald (33/46) Jun 29 2006 This is now done to some extent. There is currently one fairly serious

Don Clugston (12/69) Jun 29 2006 Great stuff, though I have very little experience with Python.
Kirk McDonald (7/12) Jun 30 2006 Consider this problem done and gone. :-) Now I can move on to more

Kirk McDonald (39/47) Jun 30 2006 Done! This greatly expands the usefulness of Pyd:
Kirk McDonald (32/40) Jul 01 2006 Done!

Kirk McDonald (61/69) Jul 05 2006 I've just added some nifty things to Pyd:

Don Clugston (14/53) Jul 07 2006 I think you should swap the order of the first two arguments to most of

Kirk McDonald (14/80) Jul 07 2006 I agree! Most certainly. I've just been planning on doing it whenever I

Don Clugston (13/75) Jul 07 2006 Actually, it really hasn't got anything to do with DDL. Meta doesn't use...

Kirk McDonald (13/13) Jul 12 2006 If anyone's interested, I just did some fairly major refactoring of how

ROB (8/18) Jun 03 2018 has there been any updates since July 2006 there does not seem to

Norm (4/13) Jun 03 2018 Try this repo:

Norm (3/19) Jun 03 2018 Sorry I meant to post this link for the wiki:
Laeeth Isharc (3/19) Jun 04 2018 https://github.com/kaleidicassociates/autowrap

Kirk McDonald <kirklin.mcdonald gmail.com> writes:

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

Jun 23 2006

David Rushby <David_member pathlink.com> writes:

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?

Jun 23 2006

Kirk McDonald <kirklin.mcdonald gmail.com> writes:

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

Jun 23 2006

David Rushby <David_member pathlink.com> writes:

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?

Jun 24 2006

Kirk McDonald <kirklin.mcdonald gmail.com> writes:

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

Jun 24 2006

Kirk McDonald <kirklin.mcdonald gmail.com> writes:

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

Jul 01 2006

Kirk McDonald <kirklin.mcdonald gmail.com> writes:

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

Jun 28 2006

Daniel Keep <daniel.keep.list gmail.com> writes:

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

Jun 29 2006

David Rushby <David_member pathlink.com> writes:

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.

Jun 29 2006

Kirk McDonald <kirklin.mcdonald gmail.com> writes:

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

Jun 29 2006

Don Clugston <dac nospam.com.au> writes:

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.

Jun 29 2006

Kirk McDonald <kirklin.mcdonald gmail.com> writes:

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

Jun 30 2006

Kirk McDonald <kirklin.mcdonald gmail.com> writes:

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

Jun 30 2006

Kirk McDonald <kirklin.mcdonald gmail.com> writes:

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

Jul 01 2006

Kirk McDonald <kirklin.mcdonald gmail.com> writes:

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

Jul 05 2006

Don Clugston <dac nospam.com.au> writes:

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

Jul 07 2006

Kirk McDonald <kirklin.mcdonald gmail.com> writes:

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

Jul 07 2006

Don Clugston <dac nospam.com.au> writes:

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.

Jul 07 2006

Kirk McDonald <kirklin.mcdonald gmail.com> writes:

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

Jul 12 2006

ROB <gameuprob yahoo.com> writes:

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.

Jun 03 2018

Norm <norm.rowtree gmail.com> writes:

On Monday, 4 June 2018 at 00:53:26 UTC, ROB wrote:
 On Wednesday, 12 July 2006 at 23:35:55 UTC, Kirk McDonald wrote:
 [...]

 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.

Try this repo:

https://github.com/ariovistus/pyd
https://github.com/ariovistus/pyd/wiki

Jun 03 2018

Norm <norm.rowtree gmail.com> writes:

On Monday, 4 June 2018 at 01:17:31 UTC, Norm wrote:
 On Monday, 4 June 2018 at 00:53:26 UTC, ROB wrote:
 On Wednesday, 12 July 2006 at 23:35:55 UTC, Kirk McDonald 
 wrote:
 [...]

 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.

 Try this repo:

 https://github.com/ariovistus/pyd
 https://github.com/ariovistus/pyd/wiki

Sorry I meant to post this link for the wiki:

https://wiki.dlang.org/Programming_in_D_for_Python_Programmers

Jun 03 2018

Laeeth Isharc <laeeth laeeth.com> writes:

On Monday, 4 June 2018 at 01:17:31 UTC, Norm wrote:
 On Monday, 4 June 2018 at 00:53:26 UTC, ROB wrote:
 On Wednesday, 12 July 2006 at 23:35:55 UTC, Kirk McDonald 
 wrote:
 [...]

 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.

 Try this repo:

 https://github.com/ariovistus/pyd
 https://github.com/ariovistus/pyd/wiki

https://github.com/kaleidicassociates/autowrap
makes using PyD a little simpler.

Jun 04 2018

D Programming

C/C++ Programming

Other

digitalmars.D - Pyd