Nicodemus wrote:

>  Nice, I didn't know that either. I think this mirrors the enum
>  behaviour of C++ better. How should Pyste support this? I believe it
>  is more interesting if Pyste always called export_values(), but this
>  would break backwards compability. Thoughts?

Command line switch. I'm pretty sure with time everyone will switch.

>  Niall, another solution would be to explicitly export the names to the
>  global namespace in the Python side (untested):
>  
>      # my_module.py
>      import _my_module  # this is the extension module
>  
>      for name, value in _my_module.unnamed.__dict__:
>          globals()[name] = value

It's alright - it's easier to customise pyste to make it do what I 
prefer now Dave has said how.

BTW, did you receive my extensive list of bugs & ideas I sent to your 
email address? I even supplied fixes! :)

Lastly, I just want to add what I'm doing for everyone's reference. 
I've spent the last week generating a SWIG solution and a 
boost.python based solution to try and evaluate which is the better 
for generating a set of bindings for my library TnFOX. Unfortunately, 
it would seem currently neither or else I'm missing something.

TnFOX is composed of FOX and my extensions. FOX itself is pretty 
straightforward though its headers most unfortunately aren't 
standalone. My extensions aren't using as many fancy tricks as Boost, 
but they do use policies, embedded classes and various object 
semantics which wouldn't be considered vanilla C++ (and hence SWIG 
has a rotten time). Furthermore as I only recently learned what 
templates can do (I bought Alexandrescu's book), I'm expecting my 
usage of these new tricks to increase.

Hence my instinct is telling me that Boost.Python is probably better 
in the long run. However, I am singularly failing thus far to get 
anything remotely resembling even a single working class - it's 
tempting to go back to writing more extensions, but shortly I'll be 
starting on the typelist based stuff and I wanted to see how the 
python bindings could cope first :-|

Cheers,
Niall


_______________________________________________
C++-sig mailing list
C++-sig@[...].org
http://mail.python.org/mailman/listinfo/c++-sig