Re: [Pyobjc-dev] NSString & mutability

[Just v. R. <ju...@le...>]

bb...@ma... wrote:

> It is unreasonable to expect that the internal implementation will 
> remain consistent over time, yet that is exactly what a partial 
> conversion solution expects.

Ok, I'm about to give in.

Let's focus on making NSString instances work as much as Python strings
as possible.

For fun, I removed the conversion, and (quite obviously) as it stands
stuff breaks horribly. The first error thrown by starting a random
PythonCocoa app is in NibClassBuilder, where an NSString is fed to an
os.path function. I _think_ for many cases it's enough if we implement
all string methods. There aren't even that many:

    'capitalize', 'center', 'count', 'encode', 'endswith', 'expandtabs',
    'find', 'index', 'isalnum', 'isalpha', 'isdecimal', 'isdigit',
    'islower', 'isnumeric', 'isspace', 'istitle', 'isupper', 'join',
    'ljust', 'lower', 'lstrip', 'replace', 'rfind', 'rindex', 'rjust',
    'rstrip', 'split', 'splitlines', 'startswith', 'strip', 'swapcase',
    'title', 'translate', 'upper', 'zfill'

It would perhaps be best if the ones that return a string would return
Python str or unicode instances and not a new NSString instance. In many
cases the implementation could consist of:

    def a_random_string_method(self):
        s = convert_to_python_string(self)
        return s.a_random_string_method()

If there is an NSString counterpart, it's perhaps better to do:

    def a_random_string_method(self):
        s = self.NSString_equivalent_of_a_random_string_method()
        return convert_to_python_string(s)

Hm, but then again, maybe not. Thoughts?

The buffer interface should make raw NSStrings work in many cases (eg.
system calls), yet I don't think it's possible to make it work for
unicode strings in all cases: we would need to provide a raw character
buffer that's compatible with the unicode internals. We need to figure
that out.

[I just looked at the implementation of the "et" format for
PyArg_ParseTuple() (gets a buffer with a specified encoding), and while
traversing down the call graph I came across PyUnicode_FromObject().
This call wants a buffer, which sucks for our purposes. However, a
comment in that function says
    /* XXX Perhaps we should make this API an alias of
           PyObject_Unicode() instead ?! */
which might be exactly what we need, as _that_ one actually calls
ob.__unicode__(). So by careful lobbying me might be able to fix this
for Python 2.3. Must hurry, though, as 2.3a2 is supposed to be out soon.
Code to be compatible with 2.2 would then still have to call
unicode(anNSString).]

Oh, it's that time again: Must Sleep...

Just