James Emerton <[EMAIL PROTECTED]> wrote:
> For my own purposes, I am going to attempt to reimplement QString as a
> %MappedType. I want my users to have as low a barrier to entry as
> possible, and that means strings are string. Having multiple string
> types is a uniquely C++ problem, not somet
I am very pleased with the amount of discussion this topic has garnered!
mutability:
Strings in python are immutable for good reason. One being that they
are considered a low-level data type that should behave like it's
passed by value. (To modify a python string in some function, you
have to re
On Friday 03 June 2005 10:50 pm, James Emerton wrote:
> On 6/3/05, Jim Bublitz <[EMAIL PROTECTED]> wrote:
> > On Friday 03 June 2005 11:40, Matej Cepl wrote:
> > > And why do you have to use QString at all? Cannot you just use Python's
> > > native strings/unicode strings? Read more about the relat
On Fri, 3 Jun 2005 14:50:40 -0700
James Emerton <[EMAIL PROTECTED]> wrote:
> On 6/3/05, Jim Bublitz <[EMAIL PROTECTED]> wrote:
> > On Friday 03 June 2005 11:40, Matej Cepl wrote:
> > > And why do you have to use QString at all? Cannot you just use Python's
> > > native strings/unicode strings? Rea
On 6/3/05, Jim Bublitz <[EMAIL PROTECTED]> wrote:
> On Friday 03 June 2005 11:40, Matej Cepl wrote:
> > And why do you have to use QString at all? Cannot you just use Python's
> > native strings/unicode strings? Read more about the relationship between
> > Python's and Qt-string machinery read
> >
On Friday 03 June 2005 11:40, Matej Cepl wrote:
> James Emerton wrote:
> > This all leads me to thinking about the strategies used whenan API
> > targeting one language is wrapped for some other language with
> > different idioms and culture. In many cases, utility types (such as
> > QString, QDat
James Emerton wrote:
> This all leads me to thinking about the strategies used whenan API
> targeting one language is wrapped for some other language with
> different idioms and culture. In many cases, utility types (such as
> QString, QDate[Time]) have fully capable couterparts native to the
> en