www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Pyd

reply 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
next sibling parent reply 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
parent reply 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
parent reply 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
next sibling parent 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
prev sibling parent 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
prev sibling next sibling parent reply 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()



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
next sibling parent reply 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
parent 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
prev sibling next sibling parent reply 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:

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



 b = testdll.Foo(10)
 b.foo()



 c = testdll.Foo(12, 30)
 c.foo()



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
next sibling parent 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:

 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 

     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
prev sibling parent 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
prev sibling next sibling parent 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)



 b.i()



:-) -- Kirk McDonald Pyd: Wrapping Python with D http://dsource.org/projects/pyd/wiki
Jun 30 2006
prev sibling parent 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



 a.i = 20
 a.i



-- Kirk McDonald Pyd: Wrapping Python with D http://dsource.org/projects/pyd/wiki
Jul 01 2006
prev sibling next sibling parent reply 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



 a = testdll.func_test(f)
 a()



 testdll.baz()



s = moo -- Kirk McDonald Pyd: Wrapping Python with D http://dsource.org/projects/pyd/wiki
Jul 05 2006
parent reply 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
parent reply 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
parent 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
prev sibling parent 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