pygccxml-development

Re: [pygccxml-development] USE_CALLDEF_ORGANIZER

[Berserker <ber...@ho...>]

> I also changed the methods names, so they will not be private. All 
you
> need is to redefine "cmp_calldefs" and to introduce your 
logic. Both
> functions have same number of required arguments. 
You can take a look
> on pygccxml.declarations.type_traits module,
 which contains many
> useful functions.
> 
> Enjoy.

Shouldn't algorithm.registration_order.select_problematics be changed
according to this patch?Actually it's:

def select_problematics( calldef ):
"""Return list of problematic functions for function "calldef" """
if 1 != len( calldef.required_args ):
   return []
...


 		 	   		  
_________________________________________________________________
Velocità, sicurezza e...tanto spazio! Scopri le novità di Hotmail
http://www.windowslive.it/hotmail/Home_novita.aspx

Re: [pygccxml-development] USE_CALLDEF_ORGANIZER

[Berserker <ber...@ho...>]

>  http://pygccxml.svn.sourceforge.net/pygccxml/?rev=1821&view=rev
> 
> I committed a change, which extends the algorithms to work with
> functions, that has any number of arguments. It doesn't take into
> account implicit conversion, cause it could break backward
> compatibility.
> 
> I also changed the methods names, so they will not be private. All you
> need is to redefine "cmp_calldefs" and to introduce your logic. Both
> functions have same number of required arguments. You can take a look
> on pygccxml.declarations.type_traits module, which contains many
> useful functions.
> 
> Enjoy.

Thanks I'll play with it ;)
 		 	   		  
_________________________________________________________________
Non sei a casa? Prova il nuovo Web Messenger
http://www.messenger.it/web/default.aspx

Re: [pygccxml-development] USE_CALLDEF_ORGANIZER

[Roman Y. <rom...@gm...>]

On Thu, Jan 28, 2010 at 11:53 AM, Roman Yakovenko
<rom...@gm...> wrote:
> On Thu, Jan 28, 2010 at 11:45 AM, Berserker <ber...@ho...> wrote:
>>> That's okey. You will be able to define your own sort criteria.
>>
>> Thanks, what about the "implict conversion" problem?
>> I'm looking at the Py++ sources and maybe I think that "is_convertible"
>> method among t1, t2 should do the job when organizer_t_wrapper
>> compares the two types.
>
> May be. It takes into account the conversion operators too. I am not
> sure whether you want it or not.
>
> struct A{}
>
> struct B{
>    operator A() const;
> }
>
> I suggest you to start prepare a ton of test cases, so when you will
> done with algorithm, you will be able to check the result.

 http://pygccxml.svn.sourceforge.net/pygccxml/?rev=1821&view=rev

I committed a change, which extends the algorithms to work with
functions, that has any number of arguments. It doesn't take into
account implicit conversion, cause it could break backward
compatibility.

I also changed the methods names, so they will not be private. All you
need is to redefine "cmp_calldefs" and to introduce your logic. Both
functions have same number of required arguments. You can take a look
on pygccxml.declarations.type_traits module, which contains many
useful functions.

Enjoy.

-- 
Roman Yakovenko
C++ Python language binding
http://www.language-binding.net/

Re: [pygccxml-development] USE_CALLDEF_ORGANIZER

[Roman Y. <rom...@gm...>]

On Thu, Jan 28, 2010 at 11:45 AM, Berserker <ber...@ho...> wrote:
>> That's okey. You will be able to define your own sort criteria.
>
> Thanks, what about the "implict conversion" problem?
> I'm looking at the Py++ sources and maybe I think that "is_convertible"
> method among t1, t2 should do the job when organizer_t_wrapper
> compares the two types.

May be. It takes into account the conversion operators too. I am not
sure whether you want it or not.

struct A{}

struct B{
    operator A() const;
}

I suggest you to start prepare a ton of test cases, so when you will
done with algorithm, you will be able to check the result.

> O.T.: this is ours "preliminary" Python documentation
> http://osiris.kodeware.net/python/0.13/
> Thanks again Roman for your great job with Py++!

You are welcome.


-- 
Roman Yakovenko
C++ Python language binding
http://www.language-binding.net/

Re: [pygccxml-development] USE_CALLDEF_ORGANIZER

[Berserker <ber...@ho...>]

> That's okey. You will be able to define your own sort criteria.

Thanks, what about the "implict conversion" problem?
I'm looking at the Py++ sources and maybe I think that "is_convertible"
method among t1, t2 should do the job when organizer_t_wrapper 
compares the two types.


O.T.: this is ours "preliminary" Python documentation
http://osiris.kodeware.net/python/0.13/
Thanks again Roman for your great job with Py++!
 		 	   		  
_________________________________________________________________
Un mondo di personalizzazioni per Messenger, PC e cellulare
http://www.pimpit.it/

Re: [pygccxml-development] USE_CALLDEF_ORGANIZER

[Roman Y. <rom...@gm...>]

On Thu, Jan 28, 2010 at 11:18 AM, Berserker <ber...@ho...> wrote:
> I forgot to report another important problem about calldef_organizer_t.
> I have a case like this:
>
> class Foo
> {
> public:
>    void setValue(bool v);
>    void setValue(int v);
>    void setValue(double v);
> };
>
> Actually, enabling USE_CALLDEF_ORGANIZER, the "bool" override is registered
> after the "int" one but before "double" and so the python code:
>
> f = Foo()
> f.setValue(True)
>
> invokes the "double" override.
> The problem is that "is_related" method invokes is_integral and not
> is_arithmetic
> as I expected: I think that this is another reason to implement a custom
> "is_related"
> method in calldef_organizer_t.

That's okey. You will be able to define your own sort criteria.

-- 
Roman Yakovenko
C++ Python language binding
http://www.language-binding.net/

Re: [pygccxml-development] USE_CALLDEF_ORGANIZER

[Berserker <ber...@ho...>]

I forgot to report another important problem about calldef_organizer_t.
I have a case like this:

class Foo
{
public:
   void setValue(bool v);
   void setValue(int v);
   void setValue(double v);
};

Actually, enabling USE_CALLDEF_ORGANIZER, the "bool" override is registered
after the "int" one but before "double" and so the python code:

f = Foo()
f.setValue(True)

invokes the "double" override.
The problem is that "is_related" method invokes is_integral and not is_arithmetic
as I expected: I think that this is another reason to implement a custom "is_related"
method in calldef_organizer_t.

 		 	   		  
_________________________________________________________________
25 Gygabite gratis online. Archivia e condividi i tuoi file!
http://www.windowslive.it/skyDrive.aspx

Re: [pygccxml-development] USE_CALLDEF_ORGANIZER

[Roman Y. <rom...@gm...>]

On Thu, Jan 28, 2010 at 11:10 AM, Berserker <ber...@ho...> wrote:
>> No. I can't change the algorithm, because it will break backward
>> compatibility.
>>
>> As I said, if you have such problems you'd better avoid them by
>> changing the alias of the exposed functions. As you can see, a
>> developer can add a new constructor and as the result other function
>> will be called. This is hard to find problem.
>>
>> Don't you think so?
>
> I understand the "backward compatibility" problem, but why can't you
> simply implement a new method in calldef_organizer_t
> (to avoid backward compatibility issues) instead of using the actual
> "decl_wrappers.algorithm.registration_order.is_related"?
> In my opinion I would remove the "one param only" limit in every case,

I can and will do this.

> but I think that the second problem that I have reported is what users
> "expect" when USE_CALLDEF_ORGANIZER is enabled.
> If you decide to not implement this change, can you help me in writing that?

definitely :-).


-- 
Roman Yakovenko
C++ Python language binding
http://www.language-binding.net/

Re: [pygccxml-development] USE_CALLDEF_ORGANIZER

[Berserker <ber...@ho...>]

> No. I can't change the algorithm, because it will break backward compatibility.
> 
> As I said, if you have such problems you'd better avoid them by
> changing the alias of the exposed functions. As you can see, a
> developer can add a new constructor and as the result other function
> will be called. This is hard to find problem.
> 
> Don't you think so?

I understand the "backward compatibility" problem, but why can't you
simply implement a new method in calldef_organizer_t 
(to avoid backward compatibility issues) instead of using the actual 
"decl_wrappers.algorithm.registration_order.is_related"? 
In my opinion I would remove the "one param only" limit in every case, 
but I think that the second problem that I have reported is what users
"expect" when USE_CALLDEF_ORGANIZER is enabled.
If you decide to not implement this change, can you help me in writing that?
 		 	   		  
_________________________________________________________________
25 Gygabite gratis online. Archivia e condividi i tuoi file!
http://www.windowslive.it/skyDrive.aspx

Re: [pygccxml-development] USE_CALLDEF_ORGANIZER

[Roman Y. <rom...@gm...>]

On Wed, Jan 27, 2010 at 5:45 PM, Berserker <ber...@ho...> wrote:
>> It is not going to be too difficult. But, If I were you, I would not
>> go this way. I would drop "overloading" and gave the functions
>> different name.
>
>> The interface exposed to the user is fragile and could be easily
>> broken with addition/deletion of a function.
>
>> Let me know if you still want the change.
>
> I have another issue related to this topic :)
>
> Please consider this case:
>
> C++ code
>
> class Bar
> {
> public:
>    Bar(const std::string &str);
> };
>
> class Foo
> {
> public:
> void set(const std::string &name, bool value);
> void set(const std::string &name, int value);
> void set(const std::string &name, const std::string &value);
> void set(const std::string &name, const Bar &value);
> };
>
>
> Python code
>
> f = Foo()
> f.setAttribute("alfa")
>
>
> The problem here is that boost::python calls the overload with
> "Bar" as argument because is the last (available) registered.
> What's your opinion about this? Shouldn't the registration order
> be:
>
> -> Foo::set(const std::string &name, const Bar &value);
> -> Foo::set(const std::string &name, const std::string &value);
> -> Foo::set(const std::string &name, int value);
> -> Foo::set(const std::string &name, bool value);
>
> As "general rule" Bar is dependent/related from std::string because
> of it's implicit convertibility?
> Maybe decl_wrappers.algorithm.registration_order.is_related must
> be updated according to this rule.

No. I can't change the algorithm, because it will break backward compatibility.

As I said, if you have such problems you'd better avoid them by
changing the alias of the exposed functions. As you can see, a
developer can add a new constructor and as the result other function
will be called. This is hard to find problem.

Don't you think so?

-- 
Roman Yakovenko
C++ Python language binding
http://www.language-binding.net/

Re: [pygccxml-development] USE_CALLDEF_ORGANIZER

[Berserker <ber...@ho...>]

There was a mistake in my previous post, Foo class must be:

class Foo
{
public:
void set(bool value);
void set(int value);
void set(const std::string &value);
void set(const Bar &value);
};
Sorry
 		 	   		  
_________________________________________________________________
Non sei a casa? Prova il nuovo Web Messenger
http://www.messenger.it/web/default.aspx

Re: [pygccxml-development] USE_CALLDEF_ORGANIZER

[Berserker <ber...@ho...>]

> It is not going to be too difficult. But, If I were you, I would not
> go this way. I would drop "overloading" and gave the functions
> different name.
 
> The interface exposed to the user is fragile and could be easily
> broken with addition/deletion of a function.
 
> Let me know if you still want the change.

I have another issue related to this topic :)
Please consider this case:

C++ code

class Bar
{
public:
   Bar(const std::string &str);
};

class Foo
{
public:
void set(const std::string &name, bool value);
void set(const std::string &name, int value);
void set(const std::string &name, const std::string &value);
void set(const std::string &name, const Bar &value);
};


Python code

f = Foo()
f.setAttribute("alfa")


The problem here is that boost::python calls the overload with
"Bar" as argument because is the last (available) registered.
What's your opinion about this? Shouldn't the registration order 
be:

-> Foo::set(const std::string &name, const Bar &value);
-> Foo::set(const std::string &name, const std::string &value);
-> Foo::set(const std::string &name, int value);
-> Foo::set(const std::string &name, bool value);

As "general rule" Bar is dependent/related from std::string because 
of it's implicit convertibility? 
Maybe decl_wrappers.algorithm.registration_order.is_related must
be updated according to this rule.


 		 	   		  
_________________________________________________________________
Un mondo di personalizzazioni per Messenger, PC e cellulare
http://www.pimpit.it/

Re: [pygccxml-development] USE_CALLDEF_ORGANIZER

[Berserker <ber...@ho...>]

> It is not going to be too difficult. But, If I were you, I would not
> go this way. I would drop "overloading" and gave the functions
> different name.
> 
> The interface exposed to the user is fragile and could be easily
> broken with addition/deletion of a function.
> 
> Let me know if you still want the change.

In my option one or more params doesn't make any difference when
someone choose to use USE_CALLDEF_ORGANIZER, but it's my opinion :)
I managed to write a working solution in ugly python code :D

class my_calldef_organizer_t(object):
    def __init__( self ):
        object.__init__( self )
        #preserve order in which functions where defined
        self.__cmp_unrelated = lambda d1, d2: cmp( d1.location.line, d2.location.line )

    def __build_groups( self, decls ):
        groups = { None: [] }
        for d in decls:
            # First patch here
            if not isinstance( d, declarations.calldef_t ) or len( d.required_args ) == 0:
                groups[ None ].append( d )
            else:
                if not groups.has_key( d.name ):
                    groups[ d.name ] = []
                groups[ d.name ].append( d )
        return groups

    def __cmp_types( self, t1, t2 ):
        return decl_wrappers.algorithm.registration_order.is_related( t1, t2 )

    def __cmp( self, f1, f2 ):
        # Second patch here
        result = None    
        args = len(f1.arguments)
        if args == len(f2.arguments):
                i = 0
                while i < args and result is None:
                        if not declarations.is_same(f1.arguments[i].type, f2.arguments[i].type):
                                result = self.__cmp_types(f1.arguments[i].type, f2.arguments[i].type)
                        i = i + 1

        if result is None:
                result = self.__cmp_unrelated( f1, f2 )
        return result

    def __sort_groups( self, groups ):
        for group in groups.keys():
            if None is group:
                continue
            groups[ group ].sort( self.__cmp )

    def __join_groups( self, groups ):
        decls = []
        sorted_keys = groups.keys()
        sorted_keys.sort()
        for group in sorted_keys:
            decls.extend( groups[group] )
        return decls

    def sort( self, decls ):
        groups = self.__build_groups( decls )
        self.__sort_groups(groups)
        result = self.__join_groups(groups)
        return result

def sort_calldefs_wrapper( decls ):
    return my_calldef_organizer_t().sort(decls)
    
creators_factory.sort_algorithms.sort_calldefs = sort_calldefs_wrapper




I think it would make sense to apply this patch in svn.
Thank you as usual ;)
Bye
 		 	   		  
_________________________________________________________________
Sei bravo con le parole? Gioca su Typectionary
http://typectionary.it.msn.com/

Re: [pygccxml-development] USE_CALLDEF_ORGANIZER

[Roman Y. <rom...@gm...>]

On Wed, Jan 27, 2010 at 3:51 PM, Berserker <ber...@ho...> wrote:
> As described in the documentation I have registration order problems :)
> USE_CALLDEF_ORGANIZER seems the ideal solution to me but as far as
> I understard it works only for functions with one param right? I have
> methods
> like these:
> class Foo
> {
> public:
>    void setAttribute(const std::string &name, bool value);
>    void setAttribute(const std::string &name, int value);
>    void setAttribute(const std::string &name, const std::string &value);
> };
>
> Would be easy to support situations like this?

It is not going to be too difficult. But, If I were you, I would not
go this way. I would drop "overloading" and gave the functions
different name.

The interface exposed to the user is fragile and could be easily
broken with addition/deletion of a function.

Let me know if you still want the change.


-- 
Roman Yakovenko
C++ Python language binding
http://www.language-binding.net/

[pygccxml-development] USE_CALLDEF_ORGANIZER

[Berserker <ber...@ho...>]

As described in the documentation I have registration order problems :)
USE_CALLDEF_ORGANIZER seems the ideal solution to me but as far as
I understard it works only for functions with one param right? I have methods
like these:
class Foo
{
public:
   void setAttribute(const std::string &name, bool value);
   void setAttribute(const std::string &name, int value);
   void setAttribute(const std::string &name, const std::string &value);
};

Would be easy to support situations like this?

 		 	   		  
_________________________________________________________________
25 Gygabite gratis online. Archivia e condividi i tuoi file!
http://www.windowslive.it/skyDrive.aspx

Re: [pygccxml-development] AttributeError: 'Boost.Python.StaticProperty' object attribute '__doc__' is read-only

[Natschläger T. <Tho...@sc...>]

Hi Roman!

Actually I just got it working using Boost 1.41 instead of Boost 1.40 :))

So it's definitely a Boost.Python problem (Btw I'm using Py++ 1.0).

Regards

  -thomas


-----Original Message-----
From: Roman Yakovenko [mailto:rom...@gm...] 
Sent: Dienstag, 26. Jänner 2010 13:14
To: Natschläger Thomas
Cc: pyg...@li...
Subject: Re: [pygccxml-development] AttributeError: 'Boost.Python.StaticProperty' object attribute '__doc__' is read-only

2010/1/26 Natschläger Thomas <Tho...@sc...>:
> Hi!
>
> In the past we have developed (under Linux) a python wrapper to PCSIM and I
> was quite lucky using Py++.
>
> Now I have ported this to Windows and where I am using Python 2.6.4
> (r264:75708, Oct 26 2009, 08:23:19) [MSC v.1500 32 bit (Intel)] on win32 as
> well as Boost 1.40 ( installer from http://www.boostpro.com/download)
>
> Compiling an linking is fine but when loading the module I get:
>
>>>> import pypcsim
>
> Traceback (most recent call last):
>
>   File "<stdin>", line 1, in <module>
>
> AttributeError: 'Boost.Python.StaticProperty' object attribute '__doc__' is
> read-only
>
>
> I googled  to find a solution and found some hints that def_readlonly( ... )
> may cause this (see e.g.
> http://mail.python.org/pipermail/cplusplus-sig/2009-August/014767.html). So
> I manually removed all the def_readlonly from the generated code but the
> problem still remains!

Hmm.
Can you say what version of boost and Py++ you use?
According to the link
(http://mail.python.org/pipermail/cplusplus-sig/2009-August/014767.html),
the problem has nothing to do with Py++. The code is valid
Boost.Python one. Can you  create a small example which reproduce your
problem?

Thanks.



-- 
Roman Yakovenko
C++ Python language binding
http://www.language-binding.net/

Re: [pygccxml-development] AttributeError: 'Boost.Python.StaticProperty' object attribute '__doc__' is read-only

[Roman Y. <rom...@gm...>]

2010/1/26 Natschläger Thomas <Tho...@sc...>:
> Hi!
>
> In the past we have developed (under Linux) a python wrapper to PCSIM and I
> was quite lucky using Py++.
>
> Now I have ported this to Windows and where I am using Python 2.6.4
> (r264:75708, Oct 26 2009, 08:23:19) [MSC v.1500 32 bit (Intel)] on win32 as
> well as Boost 1.40 ( installer from http://www.boostpro.com/download)
>
> Compiling an linking is fine but when loading the module I get:
>
>>>> import pypcsim
>
> Traceback (most recent call last):
>
>   File "<stdin>", line 1, in <module>
>
> AttributeError: 'Boost.Python.StaticProperty' object attribute '__doc__' is
> read-only
>
>
> I googled  to find a solution and found some hints that def_readlonly( … )
> may cause this (see e.g.
> http://mail.python.org/pipermail/cplusplus-sig/2009-August/014767.html). So
> I manually removed all the def_readlonly from the generated code but the
> problem still remains!

Hmm.
Can you say what version of boost and Py++ you use?
According to the link
(http://mail.python.org/pipermail/cplusplus-sig/2009-August/014767.html),
the problem has nothing to do with Py++. The code is valid
Boost.Python one. Can you  create a small example which reproduce your
problem?

Thanks.



-- 
Roman Yakovenko
C++ Python language binding
http://www.language-binding.net/

[pygccxml-development] AttributeError: 'Boost.Python.StaticProperty' object attribute '__doc__' is read-only

[Natschläger T. <Tho...@sc...>]

Hi!

 

In the past we have developed (under Linux) a python wrapper to PCSIM and I was quite lucky using Py++.

Now I have ported this to Windows and where I am using Python 2.6.4 (r264:75708, Oct 26 2009, 08:23:19) [MSC v.1500 32 bit (Intel)] on win32 as well as Boost 1.40 ( installer from http://www.boostpro.com/download)

 

Compiling an linking is fine but when loading the module I get:

 

>>> import pypcsim

Traceback (most recent call last):

  File "<stdin>", line 1, in <module>

AttributeError: 'Boost.Python.StaticProperty' object attribute '__doc__' is read-only

>>> 

 

I googled  to find a solution and found some hints that def_readlonly( ... ) may cause this (see e.g. http://mail.python.org/pipermail/cplusplus-sig/2009-August/014767.html). So I manually removed all the def_readlonly from the generated code but the problem still remains!

 

Any Ideas?

 

Regards

 

  -thomas

 

-------------------------------------------------------------------------------------

Dr. Thomas Natschläger

Software Competence Center Hagenberg

Softwarepark 21, A-4232 Hagenberg, Austria

UID: ATU 48056909 - FN: 184145b, Landesgericht Linz

Tel: ++43 7236 3343-868 Fax: ++43 7236 3343-888

tho...@sc... <mailto:tho...@sc...> , www.scch.at <http://www.scch.at>  

 

Re: [pygccxml-development] Indexing suite and Python containers

[Berserker <ber...@ho...>]

> Did you consider the performance penalties? At least in my cases such
> "marshaling" is very expensive and time consuming operation. If your
> case is different you can solve the problem in a few ways:
> * give a better name to the class "std_map_std_string_to_std_string"
> * create "factory" :
>     def cppdict( type_ ):
>         if type_ == ( str, str ):
>             return std_map_std_string_to_std_string()
>         ...
>     m = cppdict( (str,str) )
> 
> * expose the functions under different name and create a function
> wrapper in Python:
> 
>    from <your module> import foo_impl
> 
>    def foo( x ):
>         y = x
>         if isinstance( y, dict ):
>             y = std_map_std_string_to_std_string()
>             y.update( x )
>         return foo_impl( x )
> 
>     Basically, if you have many functions like that you can create a
> function decorator, which converts arguments from one type to another.
> 
> > Shouldn't indexing_suite do automatically this job?
> 
> Strong no :-)

Thanks for your response, I'll consider your suggestions.
Bye
 		 	   		  
_________________________________________________________________
Un mondo di personalizzazioni per Messenger, PC e cellulare
http://www.pimpit.it/

Re: [pygccxml-development] Indexing suite and Python containers

[Roman Y. <rom...@gm...>]

On Tue, Jan 19, 2010 at 10:37 AM, Berserker <ber...@ho...> wrote:
> I'm exposing some containers with indexing suite 2, in particular:
> std::map<std::string, std::string>, std::vector<std::string> and
> std::list<std::string>
> The manipulation of the containers works fine, I mean get the container from
> C++
> and work on it. The only "problem" I have found is when I need to pass a
> container to
> a C++ function, for example:
>
> void foo(const std::map<std::string, std::string> &m);
>
> In Python I expected that I could write:
>
> m = { "1":"2", "3":"4"}
> foo(m)
>
> The above code doesn't works because I need to write:
>
> m = std_map_std_string_to_std_string()
> m["1"] = "2"
> m["3"] = "4"
> foo(m)

In many cases containers are used as "in-out" arguments.

> My question is: do I need to write a specific converter for each C++
> container
> or is there a quicker solution to enable the automatic conversion from
> Python
> containers to C++ containers?

Did you consider the performance penalties? At least in my cases such
"marshaling" is very expensive and time consuming operation. If your
case is different you can solve the problem in a few ways:
* give a better name to the class "std_map_std_string_to_std_string"
* create "factory" :
    def cppdict( type_ ):
        if type_ == ( str, str ):
            return std_map_std_string_to_std_string()
        ...
    m = cppdict( (str,str) )

* expose the functions under different name and create a function
wrapper in Python:

   from <your module> import foo_impl

   def foo( x ):
        y = x
        if isinstance( y, dict ):
            y = std_map_std_string_to_std_string()
            y.update( x )
        return foo_impl( x )

    Basically, if you have many functions like that you can create a
function decorator, which converts arguments from one type to another.

> Shouldn't indexing_suite do automatically this job?

Strong no :-)

-- 
Roman Yakovenko
C++ Python language binding
http://www.language-binding.net/

[pygccxml-development] Indexing suite and Python containers

[Berserker <ber...@ho...>]

I'm exposing some containers with indexing suite 2, in particular:
std::map<std::string, std::string>, std::vector<std::string> and std::list<std::string>
The manipulation of the containers works fine, I mean get the container from C++
and work on it. The only "problem" I have found is when I need to pass a container to
a C++ function, for example:

void foo(const std::map<std::string, std::string> &m);

In Python I expected that I could write:

m = { "1":"2", "3":"4"}
foo(m)

The above code doesn't works because I need to write:

m = std_map_std_string_to_std_string()
m["1"] = "2"
m["3"] = "4"
foo(m)

My question is: do I need to write a specific converter for each C++ container
or is there a quicker solution to enable the automatic conversion from Python 
containers to C++ containers? Shouldn't indexing_suite do automatically this job?
 		 	   		  
_________________________________________________________________
Velocità, sicurezza e...tanto spazio! Scopri le novità di Hotmail
http://www.windowslive.it/hotmail/Home_novita.aspx

Re: [pygccxml-development] name_based_recognizer_t and pure functions

[Berserker <ber...@ho...>]

> There are few reasons:
> * In my opinion, "get" property is a function which returns
> "reference". It is impossible to "override" pure virtual function,
> which returns reference, on Python side and call it from C++. So I
> filter such functions.

I don't understand well your response, in particular "get" property is a 
function which returns "reference".Why Py++ does generate a property
for "virtual std::string getDescription() const;" in my example? getDescription
doesn't return a reference.

 		 	   		  
_________________________________________________________________
Velocità, sicurezza e...tanto spazio! Scopri le novità di Hotmail
http://www.windowslive.it/hotmail/Home_novita.aspx

Re: [pygccxml-development] name_based_recognizer_t and pure functions

[Roman Y. <rom...@gm...>]

On Wed, Jan 13, 2010 at 3:01 PM, Berserker <ber...@ho...> wrote:
> I'm using name_based_recognizer_t to bind properties to my exposed methods.
> I don't understand why pure virtual (public) functions are not supported.
> Given the code:
>
> class Foo {
> public:
>     virtual std::string getName() const = 0;
>     virtual std::string getDescription() const;
> }
>
> Py++ creates the "Description" property but not the "Name" one.
> I tweaked the code in "property_recognizer_i.is_accessor" in this way:
>
> def is_accessor( self, mem_fun ):
>         if mem_fun.ignore:
>             return False
>         if mem_fun.access_type != 'public':
>             return False
>         if mem_fun.has_static:
>             return False
>         #if mem_fun.virtuality ==
> declarations.VIRTUALITY_TYPES.PURE_VIRTUAL:
>         #    return False
>         return True
>
> and now it seems working, can I ask the meaning of that check?

There are few reasons:
* In my opinion, "get" property is a function which returns
"reference". It is impossible to "override" pure virtual function,
which returns reference, on Python side and call it from C++. So I
filter such functions.

* This behavior is "close" to "native" Python:

class Foo:

    def __init__( self ):

        pass

    def x( self ):

        return 1

    x = property( x )



class DFoo(Foo):

    def __init__( self ):

        Foo.__init__(self)

    def x( self ):

        return 2



df = DFoo()

print df.x


The output is: <bound method DFoo.x of <__main__.DFoo instance at 0xb781758c>>

HTH

-- 
Roman Yakovenko
C++ Python language binding
http://www.language-binding.net/

[pygccxml-development] name_based_recognizer_t and pure functions

[Berserker <ber...@ho...>]

I'm using name_based_recognizer_t to bind properties to my exposed methods.
I don't understand why pure virtual  (public) functions are not supported.
Given the code:

class Foo {
public:
    virtual std::string getName() const = 0;
    virtual std::string getDescription() const;
}

Py++ creates the "Description" property but not the "Name" one.
I tweaked the code in "property_recognizer_i.is_accessor" in this way:

def is_accessor( self, mem_fun ):
        if mem_fun.ignore:
            return False
        if mem_fun.access_type != 'public':
            return False
        if mem_fun.has_static:
            return False
        #if mem_fun.virtuality == declarations.VIRTUALITY_TYPES.PURE_VIRTUAL:
        #    return False        
        return True    

and now it seems working, can I ask the meaning of that check?
 		 	   		  
_________________________________________________________________
Non sei a casa? Prova il nuovo Web Messenger
http://www.messenger.it/web/default.aspx

Re: [pygccxml-development] Two patches proposal

[Berserker <ber...@ho...>]

> > Probably there is a better way to implement this, but now it seems working
> > :)
> > Let me know what's your opinion about this issue.
> 
> I just committed a fix to this issue. Take a look on it, as it use
> boost::python registry API to check whether the class is registered or
> not.
> 
> 
> Enjoy.
> 
> P.S. Can you start new discussion for a new issue? It is very
> difficult to follow you. Thanks.

Thanks for the fix, I think it's perfect now :)
Sry about "flooding" this topic.
 		 	   		  
_________________________________________________________________
25 Gygabite gratis online. Archivia e condividi i tuoi file!
http://www.windowslive.it/skyDrive.aspx