unspecified

+ class_& staticmethod(char const* name);
+ 
  template <unspecified>
  class_& def(ob_type->tp_name
+             );
+         throw_error_already_set();
+ 
+         return 0;
+       }
+ 
+   }
+   void class_base::make_method_static(const char * method_name)
+   {
+         dict d(handle<>(borrowed(downcast(this->ptr())->tp_dict)));
+ 
+         object method(d[method_name]);
+ 
+         this->attr(method_name) = object(
+             handle<>(
+                 PyStaticMethod_New(callable_check(method.ptr()) )
+                 ));
+   }
+ 
    BOOST_PYTHON_DECL type_handle registered_class_object(class_id id)
    {
        return query_class(id);
Index: libs/python/src/object/function.cpp
===================================================================
RCS file: /cvsroot/boost/boost/libs/python/src/object/function.cpp,v
retrieving revision 1.26
diff -c -r1.26 function.cpp
*** libs/python/src/object/function.cpp	21 Dec 2002 22:12:31 -0000	1.26
--- libs/python/src/object/function.cpp	17 Jan 2003 17:19:25 -0000
***************
*** 12,17 ****
--- 12,18 ----
  #include 
  #include 
  #include 
+ #include 

  #include 
  #include 
***************
*** 262,267 ****
--- 263,279 ----
          {
              if (existing->ob_type == &function_type)
                  new_func->add_overload(existing);
+             else if (existing->ob_type == &PyStaticMethod_Type){
+                 //this can probably be made a lot better
+                 std::string name_space_name = extract(name_space.attr("__name__"));
+                 ::PyErr_Format(
+                     PyExc_RuntimeError
+                     , "Boost.Python - All overloads of \"%s\" must be exported before calling \'class_(\"%s\").staticmethod\'"
+                     , name_
+                     , name_space_name.c_str()
+                     );
+                 throw_error_already_set();
+             }
          }
          else if (is_binary_operator(name_))
          {

From mike at bindkey.com  Fri Jan 17 22:39:53 2003
From: mike at bindkey.com (Mike Rovner)
Date: Fri, 17 Jan 2003 13:39:53 -0800
Subject: [C++-sig] map key
Message-ID: 

I'm trying to wrap a std::map  with

template
struct map_item

{

typedef typename T::key_type Key;

typedef typename T::mapped_type Value;

static Value const& get(T& x, const Key n)

{

if( x.find(n) != x.end() ) return x[n];

PyErr_SetString(PyExc_KeyError,"Map key not found");
throw_error_already_set();

}

static void set(T& x, const Key n, const Value& val) { x[n]=val; }

static void del(T& x, const Key n) { x.erase(n); }

static bool in(T const& x, const Key n) { return x.find(n) != x.end(); }

static list keys(T const& x)

{ list t;

for(T::const_iterator it=x.begin(); it!=x.end(); ++it)

t.append( object(it->first) );

return t;

}

static list values(T const& x)

{ list t;

for(T::const_iterator it=x.begin(); it!=x.end(); ++it)

t.append( object(it->second) );

return t;

}

static list items(T const& x)

{ list t;

for(T::const_iterator it=x.begin(); it!=x.end(); ++it)

t.append( make_tuple(object(it->first), object(it->second)) );

return t;

}

};

typedef std::map Map;
class_("Key", no_init) /*...*/;

class_("Value") /*...*/;

class_("Map")

.def("keys", &map_item::keys)

;

My problem is to return keys:

>>> m=Map(...)

>>> m.keys()

TypeError: No to_python (by-value) converter found for C++ type: class Key

Other functions returning const Key* are just fine with
return_internal_reference.

Can I specify return_internal_reference when constructing keys list? How?
Will it solve the problem?

Thanks in advance,

Mike

From dave at boost-consulting.com  Fri Jan 17 23:29:28 2003
From: dave at boost-consulting.com (David Abrahams)
Date: Fri, 17 Jan 2003 17:29:28 -0500
Subject: [C++-sig] map key
In-Reply-To:  ("Mike Rovner"'s message of "Fri,
 17 Jan 2003 13:39:53 -0800")
References: 
Message-ID: 

"Mike Rovner"  writes:

> I'm trying to wrap a std::map  with
>
> template
> struct map_item
>
> {
>
> typedef typename T::key_type Key;

Mike, lots of mailers don't respond well to indentation with tabs.

Cleaning up your code, I get:

template
struct map_item
{
    typedef typename T::key_type Key;
    typedef typename T::mapped_type Value;

    static Value const& get(T& x, const Key n)
    {
        if( x.find(n) != x.end() ) return x[n];
        PyErr_SetString(PyExc_KeyError,"Map key not found");
        throw_error_already_set();
    }

    static void set(T& x, const Key n, const Value& val) { x[n]=val; }

    static void del(T& x, const Key n) { x.erase(n); }

    static bool in(T const& x, const Key n) { return x.find(n) != x.end(); }

    static list keys(T const& x)
    {
        list t;
        for(T::const_iterator it=x.begin(); it!=x.end(); ++it)
            t.append( object(it->first) );
You don't need this---^^^^^^^---------^
        return t;
    }

    static list values(T const& x)
    {
        list t;
        for(T::const_iterator it=x.begin(); it!=x.end(); ++it)
            t.append( object(it->second) );
You don't need this---^^^^^^^----------^
        return t;
    }
    static list items(T const& x)
    {
        list t;
        for(T::const_iterator it=x.begin(); it!=x.end(); ++it)
            t.append( make_tuple(object(it->first), object(it->second)) );
You don't need this--------------^^^^^^^---------^--^^^^^^^----------^
        return t;
    }
};

typedef std::map Map;
class_("Key", no_init) /*...*/;
class_("Value") /*...*/;

class_("Map")
    .def("keys", &map_item::keys)
    ;
--

> My problem is to return keys:
>
>>>> m=Map(...)
>>>> m.keys()
>
> TypeError: No to_python (by-value) converter found for C++ type:
> class Key
>
> Other functions returning const Key* are just fine with
> return_internal_reference.

There is no function returning const Key* being invoked, but I see
what you mean.  The problem occurs where you try to convert a ``const
Key*'' to a Python object.

> Can I specify return_internal_reference when constructing keys list? 

Hum, that's an interesting question.  I guess you'd like each of the
items in the keys list to keep the map object alive so that they will
remain valid.  You could use t.append(ptr(it->second)), which would
build an object around the pointer and stick it in the list, but that
would not have the desired lifetime-management properties.

One approach would be to wrap a function which could convert
the pointer with the lifetime management you want:

    Key const* managed(object map, Key const* x) { return x; }
    object py_managed = make_function(managed, return_internal_reference<>());

Then you need to get ahold of the map's Python object in your keys
function:

    static list keys(python::back_reference xx)
    {
        T const& x = xx.get();
        list t;
        for(T::const_iterator it=x.begin(); it!=x.end(); ++it)
            t.append( py_managed(xx.source(), it->first) );
        return t;
    }

> How?  Will it solve the problem?

I think that would solve it.

Mike, I think this would make a really good tutorial case study for
the Boost.Python documentation.  Is there any way I could persuade you
to write it up so that others can benefit?

-- 
                       David Abrahams
   dave at boost-consulting.com * http://www.boost-consulting.com
Boost support, enhancements, training, and commercial distribution

From dave at boost-consulting.com  Sat Jan 18 00:28:07 2003
From: dave at boost-consulting.com (David Abrahams)
Date: Fri, 17 Jan 2003 18:28:07 -0500
Subject: [C++-sig] staticmethod diffs
In-Reply-To: <3E2854FA.E773C7DC@sitius.com> (Nikolay Mladenov's message of
 "Fri, 17 Jan 2003 14:09:46 -0500")
References: <3E2854FA.E773C7DC@sitius.com>
Message-ID: 

Nikolay Mladenov  writes:

> Attached is the static method diffs (diff -NR -c)
> I have not done much testing, but it works for me and compiles with MSVC6/STLPort4.5

This is great, Nikolay!  Can you post a small test module and script
for the libs/python/test directory?  That would put the icing on the
cake.

Thanks again for your contribution!

-- 
                       David Abrahams
   dave at boost-consulting.com * http://www.boost-consulting.com
Boost support, enhancements, training, and commercial distribution

From mike at bindkey.com  Sat Jan 18 00:37:53 2003
From: mike at bindkey.com (Mike Rovner)
Date: Fri, 17 Jan 2003 15:37:53 -0800
Subject: [C++-sig] Re: map key
References:  
Message-ID: 

"David Abrahams"  wrote in message
news:usmvrh0l3.fsf at boost-consulting.com...
> "Mike Rovner"  writes:
>
> 
>
> Mike, lots of mailers don't respond well to indentation with tabs.

I'm sorry for the formatting. There was no tabs but something strange
happened with pasting from VC7.

> There is no function returning const Key* being invoked, but I see
> what you mean.  The problem occurs where you try to convert a ``const
> Key*'' to a Python object.

That's correct.

> > Can I specify return_internal_reference when constructing keys list?
>
> Hum, that's an interesting question.  I guess you'd like each of the
> items in the keys list to keep the map object alive so that they will
> remain valid.  You could use t.append(ptr(it->second)), which would
> build an object around the pointer and stick it in the list, but that
> would not have the desired lifetime-management properties.

It is working, but I still don't understand it. ;)
I have a map, so map<>::iterator it->first shall
return const Key* or at least const Key* const&. So we already have a
pointer,
why we need a ptr() call around it?

I'd like to have a lifetime-management, but I'm still shallow on it.
I don't need to keep a map, because map keys are pointers to an object
elsewhere and
manupulating them can be a potential disaster but I'm limited by existing
library I'm wrapping. :(

But while it's great at hand-maid keys() and items() lists, there's still a
problem with
iterator >(). Obviosly it doesn't know about ptr().

> One approach would be to wrap a function which could convert
> the pointer with the lifetime management you want:

I have a host object Host which holds all Keys and cleaning them on
desruction.
Host can return const Key* and I'd like to keep that (wrapped) host instead.

> I think that would solve it.

Thanks a lot, Dave. BPL already saved us a week debugging and more is on the
way.

> Mike, I think this would make a really good tutorial case study for
> the Boost.Python documentation.  Is there any way I could persuade you
> to write it up so that others can benefit?

(side note) I'm constantly adding some stuff from that list to the wiki.
OK, if you think I can do it, I can do it. :)
You mean that http://www.boost.org/libs/python/doc/tutorial/index.html
tutorial?
I need a few lines guidelines like a few questions that my future text will
answer
and I'll go for it.

From dave at boost-consulting.com  Sat Jan 18 01:00:11 2003
From: dave at boost-consulting.com (David Abrahams)
Date: Fri, 17 Jan 2003 19:00:11 -0500
Subject: [C++-sig] Re: map key
In-Reply-To:  ("Mike Rovner"'s message of "Fri,
 17 Jan 2003 15:37:53 -0800")
References:  

Message-ID: 

"Mike Rovner"  writes:

> "David Abrahams"  wrote in message
> news:usmvrh0l3.fsf at boost-consulting.com...
>> "Mike Rovner"  writes:
>>
>> 
>>
>> Mike, lots of mailers don't respond well to indentation with tabs.
>
> I'm sorry for the formatting. There was no tabs but something strange
> happened with pasting from VC7.
>
>> There is no function returning const Key* being invoked, but I see
>> what you mean.  The problem occurs where you try to convert a ``const
>> Key*'' to a Python object.
>
> That's correct.
>
>> > Can I specify return_internal_reference when constructing keys list?
>>
>> Hum, that's an interesting question.  I guess you'd like each of the
>> items in the keys list to keep the map object alive so that they will
>> remain valid.  You could use t.append(ptr(it->second)), which would
>> build an object around the pointer and stick it in the list, but that
>> would not have the desired lifetime-management properties.
>
> It is working, but I still don't understand it. ;)
> I have a map, so map<>::iterator it->first shall
> return const Key* or at least const Key* const&. So we already have a
> pointer,
> why we need a ptr() call around it?

Because, in general, building a Python object around a pointer
(instead of a copy of the pointee) is unsafe, we don't do it by
default.  You have to ask for it explicitly.  Of course
return_internal_reference makes it safe, but it's not known that
you're using it at that point in the code.

> I'd like to have a lifetime-management, but I'm still shallow on it.
> I don't need to keep a map, because map keys are pointers to an object
> elsewhere 

Oh, good point. return_internal_reference is ineffectual here.

> and manupulating them can be a potential disaster but I'm limited by
> existing library I'm wrapping. :(

You can only do what you can do.

> But while it's great at hand-maid keys() and items() lists, there's
> still a problem with iterator >(). Obviosly
> it doesn't know about ptr().

I think it doesn't know about std::pair, which is
the iterator's value type ;-)

A Python map's iterator just iterates the keys, so you might need to
build the iterator by hand if you want it to do the same thing.

>> One approach would be to wrap a function which could convert
>> the pointer with the lifetime management you want:
>
> I have a host object Host which holds all Keys and cleaning them on
> desruction.  Host can return const Key* and I'd like to keep that
> (wrapped) host instead.

Fine; I think you can figure out how to make that work, yes?

>> I think that would solve it.
>
> Thanks a lot, Dave. BPL already saved us a week debugging and more
> is on the way.

That's great!  I'm curious, though: how can you tell it saved you a
week?

>> Mike, I think this would make a really good tutorial case study for
>> the Boost.Python documentation.  Is there any way I could persuade
>> you to write it up so that others can benefit?
>
> (side note) I'm constantly adding some stuff from that list to the wiki.
> OK, if you think I can do it, I can do it. :)

I have complete faith!

> You mean that http://www.boost.org/libs/python/doc/tutorial/index.html
> tutorial?

No, I think we'll probably build up a bunch of these case studies, and
they would just weigh down the tutorial.

> I need a few lines guidelines like a few questions that my future
> text will answer and I'll go for it.

Sorry, I don't understand what it is you need to know.  Just let me
know; I really appreciate your willingness to contribute!

-- 
                       David Abrahams
   dave at boost-consulting.com * http://www.boost-consulting.com
Boost support, enhancements, training, and commercial distribution

From dave at boost-consulting.com  Sat Jan 18 01:24:14 2003
From: dave at boost-consulting.com (David Abrahams)
Date: Fri, 17 Jan 2003 19:24:14 -0500
Subject: [C++-sig] Re: map key
In-Reply-To:  (David Abrahams's message
 of "Fri, 17 Jan 2003 19:00:11 -0500")
References:  

Message-ID: 

David Abrahams  writes:

> "Mike Rovner"  writes:
>
>> But while it's great at hand-maid keys() and items() lists, there's
>> still a problem with iterator >(). Obviosly
>> it doesn't know about ptr().
>
> I think it doesn't know about std::pair, which is
> the iterator's value type ;-)
>
> A Python map's iterator just iterates the keys, so you might need to
> build the iterator by hand if you want it to do the same thing.

You could use the Boost transform iterator adaptor with std::select1st
to build an iterator over keys and expose it with class_<...>.range().

-- 
                       David Abrahams
   dave at boost-consulting.com * http://www.boost-consulting.com
Boost support, enhancements, training, and commercial distribution

From nickm at sitius.com  Sun Jan 19 07:20:53 2003
From: nickm at sitius.com (Nikolay Mladenov)
Date: Sun, 19 Jan 2003 01:20:53 -0500
Subject: [C++-sig] Re: staticmethod diffs
References: <3E2854FA.E773C7DC@sitius.com> 
Message-ID: <3E2A43C5.D5926865@sitius.com>

An HTML attachment was scrubbed...
URL: 
-------------- next part --------------
'''
>>> from static_method import *

>>> class X1(X):
...     pass

>>> x = X(16)
>>> x1 = X1(17)

>>> x1.count()
2

>>> x.count()
2

>>> X1.count()
2

>>> X.count()
2

>>> x1.magic()
7654321

>>> x.magic()
7654321

>>> X1.magic()
7654321

>>> X.magic()
7654321

'''

def run(args = None):
    import sys
    import doctest

    if args is not None:
        sys.argv = args
    return doctest.testmod(sys.modules.get(__name__))

if __name__ == '__main__':
    print "running..."
    import sys
    sys.exit(run()[0])
-------------- next part --------------
A non-text attachment was scrubbed...
Name: static_methods.cpp
Type: application/x-unknown-content-type-cppfile
Size: 1430 bytes
Desc: not available
URL: 

From dave at boost-consulting.com  Sun Jan 19 20:13:38 2003
From: dave at boost-consulting.com (David Abrahams)
Date: Sun, 19 Jan 2003 14:13:38 -0500
Subject: [C++-sig] Re: staticmethod diffs
In-Reply-To: <3E2A43C5.D5926865@sitius.com> (Nikolay Mladenov's message of
 "Sun, 19 Jan 2003 01:20:53 -0500")
References: <3E2854FA.E773C7DC@sitius.com>
	 <3E2A43C5.D5926865@sitius.com>
Message-ID: 

Thanks very much, Nikolay!

I've integrated your changes to CVS and added your name to the
acknowledgements page.

Nikolay Mladenov  writes:

> I was not sure how exactly the doctest scripts work, and I followed
> the virtual function example.  Attached are the test files.

-- 
                       David Abrahams
   dave at boost-consulting.com * http://www.boost-consulting.com
Boost support, enhancements, training, and commercial distribution

From nickm at sitius.com  Mon Jan 20 17:05:35 2003
From: nickm at sitius.com (Nikolay Mladenov)
Date: Mon, 20 Jan 2003 11:05:35 -0500
Subject: [C++-sig] customizing return_from_python
Message-ID: <3E2C1E4F.DF786794@sitius.com>

An HTML attachment was scrubbed...
URL: 

From dave at boost-consulting.com  Mon Jan 20 17:13:23 2003
From: dave at boost-consulting.com (David Abrahams)
Date: Mon, 20 Jan 2003 11:13:23 -0500
Subject: [C++-sig] customizing return_from_python
In-Reply-To: <3E2C1E4F.DF786794@sitius.com> (Nikolay Mladenov's message of
 "Mon, 20 Jan 2003 11:05:35 -0500")
References: <3E2C1E4F.DF786794@sitius.com>
Message-ID: 

Nikolay Mladenov  writes:

> I want to customize call_method is such way, that if the python call returns "None",
> call_method to return some default value.
> I tried specializing return_from_python and returnable, but I had two problems with that:
> ?1. MSVC6 did not compile the return_from_python specialization
> ?2. returnable is in the "detail" namespace.
>
> Can someone suggest me how to do this?

Not sure what you are trying to accomplish exactly.  Might I suggest:

    object result = call_method