[C++-sig] (Fwd) Previous email to Nicodemus

Niall Douglas s_sourceforge at nedprod.com
Sun Aug 3 17:45:10 CEST 2003

------- Forwarded message follows -------
From:           	Niall Douglas <xxx at xxxxxxx.com>
To:             	xxxxxxxx at xxxxxxxxx.com.br
Subject:        	Whoops, found newer version of pyste!
Date sent:      	Sat, 2 Aug 2003 20:16:50 +0100

Hi again,

Sorry, it only occurred to me after sending the previous email that
Boost was probably on CVS.

However, the latest version still has the problem with passing 
backslashes to Win32 GCCXML. It's GCCXML that barfs (and I got the
precompiled binary off its web site).

Also, unnamed enums don't trap properly, at least here. Changing the
line in EnumExporters.Export to:

            if rename[0:2] == "$_" or rename == '._0':

This fixes it. I've looked through the Boost.Python source and I 
think the changes necessary to make passing "" as the scope name to 
enter into the upper-most scope are probably quite easy. I'll send an 
email to Dave Abrahams and see what he says.  

Next extension: my .pyste file is actually a full blown script which
reads the contents of a directory for the header files and then
dynamically creates the variable = AllFromHeader(filepath). Hence it
needs to know where it lives which currently it can't. I propose
adding the following to pyste.py:

def CreateContext(interfacepath):
    'create the context where a interface file will be executed'
    context = {}
    # location
    context['mylocation'] = interfacepath
    # infos

... and simply have CreateContext()'s invocation also pass the path 
of the .pyste file. Now the .pyste file knows where it is, which will 
be relative to where the header files will be.  

Next idea: couldn't pyste automatically recognise properties via a 
get/set method combo and use .add_property()? It would need to be 
optional on the command line because some people would consider it 
too dissimilar from the C++ library original.  

Next point: pyste seems to want inherited members return policy set
for each and every subclass. So if I bind FXWindow and FXTopWindow
which inherits FXTopWindow, I must reapply set_policy() for all
FXTopWindow's inherited methods from FXWindow. To be honest, this
doesn't bother me too much because you can create functions in the
.pyste file called applyFXWindow(var) and applyFXTopWindow(var) and
the latter simply calls applyFXWindow() on its var before adding its
own unique stuff - unfortunately in this case pyste adds too many

Anyway, I just wanted to say that the new version is much better and
my thanks to you for it. Time for bed now :)


------- End of forwarded message -------
------- End of forwarded message -------

More information about the Cplusplus-sig mailing list