On 18 Mar 2009 at 2:07, Haoyu Bai wrote:
> First thing come into my mind is the build system. For Python 3, we
> would have a separate build target, eg. having libboost_python.so
> built for Python 2.x and libboost_python3.so for Python 3. This would
> match the current situation that most Linux d
I tried the code below with Python 2.x. For a given str or unicode object, it
copies the
bytes in memory (char*) to a list of 1-character strings. I'm getting
"hello" = ['h', 'e', 'l', 'l', 'o']
u"hello" = ['h', '\x00', 'e', '\x00', 'l', '\x00', 'l', '\x00', 'o', '\x00']
U"hello" = ['h', '\x0
on Wed Mar 18 2009, "troy d. straszheim" wrote:
> The current rule for overload resolution are simply 'first match in reverse
> order of
> registration'. You could relatively easily make this 'first match in forward
> order of
> registration'. The library currently has no notion of one func
Haoyu Bai wrote:
Yes of course we should allow users to set policy. So the problem is
what the default behavior should be when there is no policy set by
user explicitly. The candidates are:
- raise an error
- convert char* and std::string to/from Python bytes
- convert char* and std::string to/
I also like the last one best. I can always explicitly construct a bytes in my
ambiguous situations.
-Original Message-
From: cplusplus-sig-bounces+matthew.scouten=tradingtechnologies@python.org
[mailto:cplusplus-sig-bounces+matthew.scouten=tradingtechnologies@python.org]
On Beh
On Thu, Mar 19, 2009 at 1:52 AM, Stefan Seefeld wrote:
> Ralf W. Grosse-Kunstleve wrote:
>>
>> C++ has wchar_t and std::wstring. Could these be leveraged to avoid
>> ambiguities?
>> E.g. char, std::string are mapped to py3 byte objects, wchar_t and
>> std::wstring
>> to py3 str objects.
>>
>
> I d
Ralf W. Grosse-Kunstleve wrote:
C++ has wchar_t and std::wstring. Could these be leveraged to avoid ambiguities?
E.g. char, std::string are mapped to py3 byte objects, wchar_t and std::wstring
to py3 str objects.
I don't quite agree with that suggestion. First, wchar_t doesn't imply
Unicode
C++ has wchar_t and std::wstring. Could these be leveraged to avoid ambiguities?
E.g. char, std::string are mapped to py3 byte objects, wchar_t and std::wstring
to py3 str objects.
(Hope this suggestion isn't totally dumb; I have very little experience using
unicode strings.)
- Original Me
Very nice analysis of the pros-and-cons!
> Maybe somebody else has more ideas on this. I think you could tighten
> up the automatic conversion rules (like the > patch below does for
> int and bool), so that one would have to clarify at the call site
> which function you're calling:
>
> >> f(f
So, this isn't just a bool-int issue, you can get the same thing with
int and double:
std::string takes_bool(bool b) { return "bool"; }
std::string takes_int(int b) { return "int"; }
std::string takes_double(double b) { return "double"; }
BOOST_PYTHON_MODULE(overload_resolution)
{
On Tuesday 17 March 2009 21:23:03 Matthew Scouten (TT) wrote:
> I can work with whatever you come up with, but it might convenient if a
> char* or char[] was treated as a bytes object and a std::string was
> treated as a string. Thoughts?
I would say one cannot see from the type (i.e. std::string,
On Wed, Mar 18, 2009 at 7:25 AM, Rene Rivera wrote:
> Matthew Scouten (TT) wrote:
>>
>> I can work with whatever you come up with, but it might convenient if a
>> char* or char[] was treated as a bytes object and a std::string was
>> treated as a string. Thoughts?
>
> A char* can never be fully tr
12 matches
Mail list logo
