pyobjc-dev — CVS commit notices go here

Re: [Pyobjc-dev] testing NSCell

[David E. <epp...@ic...>]

Sorry, a couple of the tests failed due to me not reading the NSCell docs 
sufficiently carefully -- specifically the part about needing to become a 
text-type cell before setIntValue_ and setFloatValue_ will work.  Here's a 
corrected version.  Now all tests still fail, but in the same place: the 
objc accessors work, but the pythonic coercions don't.

import unittest
import objc

from AppKit import NSCell

class TestNSCell(unittest.TestCase):
    cell = NSCell.alloc().init()
    cell.setStringValue_('') # make into text-type cell

    def testString(self):
        s = 'string'
        self.cell.setStringValue_(s)
        assert(self.cell.stringValue() == s)
        assert(str(self.cell) == s)

    def testUnicode(self):
        u = u'\xc3\xbc\xc3\xb1\xc3\xae\xc3\xa7\xc3\xb8d\xc3\xa8'
        self.cell.setStringValue_(u)
        assert(self.cell.stringValue() == u)
        assert(unicode(self.cell) == u)

    def testInt(self):
        i = 17
        self.cell.setIntValue_(i)
        assert(self.cell.intValue() == i)
        assert(int(self.cell) == i)

    def testFloat(self):
        f = 3.0  # exactly representable as decimal string
        self.cell.setFloatValue_(f)
        assert(self.cell.floatValue() == f)
        assert(float(self.cell) == f)

def suite():
    suite = unittest.TestSuite()
    suite.addTest(unittest.makeSuite(TestNSCell))
    return suite

if __name__ == '__main__':
    unittest.main( )

--
David Eppstein       UC Irvine Dept. of Information & Computer Science
epp...@ic... http://www.ics.uci.edu/~eppstein/

[Pyobjc-dev] testing NSCell

[David E. <epp...@ic...>]

Which if any of the following tests should fail?  Currently, they all do.

import unittest
import objc

from AppKit import NSCell

class TestNSCell(unittest.TestCase):
    cell = NSCell.alloc().init()

    def testString(self):
        s = 'string'
        self.cell.setStringValue_(s)
        assert(self.cell.stringValue() == s)
        assert(str(self.cell) == s)

    def testUnicode(self):
        u = u'\xc3\xbc\xc3\xb1\xc3\xae\xc3\xa7\xc3\xb8d\xc3\xa8'
        self.cell.setStringValue_(u)
        assert(self.cell.stringValue() == u)
        assert(unicode(self.cell) == u)

    def testInt(self):
        i = 17
        self.cell.setIntValue_(i)
        assert(self.cell.intValue() == i)
        assert(int(self.cell) == i)

    def testFloat(self):
        f = 3.14159
        self.cell.setFloatValue_(f)
        assert(self.cell.floatValue() == f)
        assert(float(self.cell) == f)

def suite():
    suite = unittest.TestSuite()
    suite.addTest(unittest.makeSuite(TestNSCell))
    return suite

if __name__ == '__main__':
    unittest.main( )

--
David Eppstein       UC Irvine Dept. of Information & Computer Science
epp...@ic... http://www.ics.uci.edu/~eppstein/

[Pyobjc-dev] Unicode-like objects

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

In response to my query on c.l.py, Michael Hudson came up with this
example:

>>> re.match('(a)|b', array.array('u', u'a string')).groups()
(array('u', u'a'),)

So apparently there is some sort of unicode buffer interface. Yet I
believe this can only work if the internal layout of the bytes match
that of a real unicode object. Could that be made the case for NSString?

Additional potential problem: for string-like objects to work
interchangably with real strings, they must hash equally when they
compare equally. The Python unicode implementation apparently had to go
through quite a bit of trouble to make this true between (7-bit) 'str'
instances and 'unicode' instances.

Just

Re: [Pyobjc-dev] Auto bridging instances by conversion

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

bb...@ma... wrote:

> On Tuesday, Feb 4, 2003, at 04:01 US/Eastern, Just van Rossum wrote:
> > Sure, eg. in Python this happens with exceptions. However we're not
> > talking about arbitrary objects, but about real basic immutable
> > types (strings and numbers). I claim that any code in which the id
> > of an NSNumber or NSString is important is seriously broken.
> 
> That claim is faulty.

Uh, I didn't say such code didn't _exist_.

> There are many situations where the type of the object is totally
> irrelevant to the local implementation.  That is, as far as the
> implementation is concerned, everything is an (NSObject*) and the
> only important piece of information is the id-- the self pointer-- of
> that object.    As Ronald indicated, this situation arises outside of
> various random performance hacks-- NSMapTables and the underlying CF*
> types are often used to map instances to other instances, regardless
> of type, as a part of object graph maintenance.

Can't find decent doco for NSMapTable, yet what I have found says it's
not even a true object (it's not even an id); just an opaque struct with
a functional interface. Where are the semantics of NSMapTable _visible_
when using Cocoa classes, and in what case would code actually break if
we supply it with an NSNumber with a different id?

I want things to be as convenient as possible in the usual case, I don't
mind some odd surprises in extreme cases. NSMapTable seems sufficiently
low level that I don't see how it can be relevant to Python code using
Cocoa.

> By assuming otherwise, the bridge will cause very subtle, but very 
> ugly, problems in many situations where the developer is going to be 
> mighty surprised that it didn't "just work".  

I don't believe your "many" qualifier here. A real example would be
useful.

> We already have that 
> situation with the string conversions that are happening now.

Like where? (Apart from the NSMutableString conversion bug of course.)

Just

Re: [Pyobjc-dev] Auto bridging instances by conversion

[<bb...@ma...>]

On Tuesday, Feb 4, 2003, at 04:01 US/Eastern, Just van Rossum wrote:
> Sure, eg. in Python this happens with exceptions. However we're not
> talking about arbitrary objects, but about real basic immutable types
> (strings and numbers). I claim that any code in which the id of an
> NSNumber or NSString is important is seriously broken.

That claim is faulty.

There are many situations where the type of the object is totally 
irrelevant to the local implementation.  That is, as far as the 
implementation is concerned, everything is an (NSObject*) and the only 
important piece of information is the id-- the self pointer-- of that 
object.    As Ronald indicated, this situation arises outside of 
various random performance hacks-- NSMapTables and the underlying CF* 
types are often used to map instances to other instances, regardless of 
type, as a part of object graph maintenance.

By assuming otherwise, the bridge will cause very subtle, but very 
ugly, problems in many situations where the developer is going to be 
mighty surprised that it didn't "just work".   We already have that 
situation with the string conversions that are happening now.

b.bum

Re: [Pyobjc-dev] Auto bridging instances by conversion

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

Ronald Oussoren wrote:

> > I don't see why the id should matter either. From a Python
> > perspective, all that matters is that the two objects compare and
> > hash equally. Sure, comparison is _cheaper_ when the two objects
> > have the same id, but would stuff actually _break_ if the id's
> > weren't the same? That's just sick.
> 
> Not necessarily, I'm sure we can come up with sane scenarios where 
> object identity is used other than as a performance hack.

Sure, eg. in Python this happens with exceptions. However we're not
talking about arbitrary objects, but about real basic immutable types
(strings and numbers). I claim that any code in which the id of an
NSNumber or NSString is important is seriously broken.

> > Regarding numbers: from ObjC -> Python there will be hardly a
> > difference between conversion and wrapping: for both cases a new
> > object needs to be allocated (except when the number is between -1
> > and 99 in which case conversion is _cheaper_).
> And likewise for Python->ObjC: A new object will be created.

Not for a wrapped NSNumber, when you would just pass the original object
back.

Just

Re: [Pyobjc-dev] Auto bridging instances by conversion

[David E. <epp...@ic...>]

On 2/4/03 8:03 AM +0100 Ronald Oussoren <ous...@ci...> wrote:
> Be warned that some (many?) C functions assume that if an object is an
> instance of PyString_Type (either directly or an instance of a subclass
> of str) they can use PyString_AS_STRING on it. The same thing is true for
> most other buildin types. This means the NS* types can never be a full
> substitute for native python types (which is really too bad).

What about the new Python 2.3 basestring type?  Would inheriting from that 
convince callers that it's a string without letting them think they can use 
low-level string representation details?  Of course, it would be bad if 
pyobjc required 2.3...
--
David Eppstein       UC Irvine Dept. of Information & Computer Science
epp...@ic... http://www.ics.uci.edu/~eppstein/

Re: [Pyobjc-dev] Auto bridging instances by conversion

[Ronald O. <ous...@ci...>]

On Monday, Feb 3, 2003, at 21:10 Europe/Amsterdam, Bob Ippolito wrote:
[ interesting text removed]

> Unfortunately this _still_ won't work with re.match (at least in 
> Jaguar's 2.2.0, I'd consider this a bug in re.match), but it *does* 
> work with open()

Be warned that some (many?) C functions assume that if an object is an 
instance of PyString_Type (either directly or an instance of a subclass 
of str) they can use PyString_AS_STRING on it. The same thing is true 
for most other buildin types. This means the NS* types can never be a 
full substitute for native python types (which is really too bad).

Ronald

Re: [Pyobjc-dev] Auto bridging instances by conversion

[Ronald O. <ous...@ci...>]

On Monday, Feb 3, 2003, at 20:12 Europe/Amsterdam, Just van Rossum 
wrote:
>
> I recently learned about this but hadn't thought of it in this context.
> I don't assume the _declared_ return type is available at runtime? If
> so, we could use that, but I guess it isn't.

The declared return and argument types aren't available beyond "it's an 
object". Most of these type declarations are only used for compile-time 
checks.
>> --
>>
>> Furthermore, the (id) of an object-- the address contained in self--
>> is often used as a meaningful identifier.   If a developer places an
>> object into a container-- a dictionary or an array-- they expect to
>> retrieve the exact same instance-- the same self pointer-- upon
>> retrieving that object.
>
> Such an assumption is only safe if the code works directly with these
> collection objects. I don't think any code can be called sane it it
> stops working when it receives an object from elsewhere that has a
> different id than it expects.

The assumption could lead to bugs for some types (like integers): There 
is no guarantee whatsever on the value of 'id(x+1) == id(x+1)' if x is 
an integer. That means that you might think you add two different 
objects to a list while you add only one (or v.v.!)

>
>> In this context, that an object is an (int) and the first 100 ints are
>> singletons is completely irrelevant.   Consider the object in pure OO
>> terms-- it is just an object contained in a collection, its type does
>> not matter.
>
> I don't see why the id should matter either. From a Python perspective,
> all that matters is that the two objects compare and hash equally. 
> Sure,
> comparison is _cheaper_ when the two objects have the same id, but 
> would
> stuff actually _break_ if the id's weren't the same? That's just sick.

Not necessarily, I'm sure we can come up with sane scenarios where 
object identity is used other than as a performance hack. That said: 
type *does* matter (see above).
>
> Yet Python is _primarily_ about convenience. Efficiency is secondary.
> Using Python comes at a price, and every bridge causes some overhead.
> For example passing a C string to Python *always* causes the string to
> be copied. I don't see what's so inherently bad at treating NSStrings
> the same way.
>
> Regarding numbers: from ObjC -> Python there will be hardly a 
> difference
> between conversion and wrapping: for both cases a new object needs to 
> be
> allocated (except when the number is between -1 and 99 in which case
> conversion is _cheaper_).
And likewise for Python->ObjC: A new object will be created.

Ronald

Re: [Pyobjc-dev] Re: [ pyobjc-Bugs-679748 ] NSMutableString gets converted to Python string

[David E. <epp...@ic...>]

On 2/3/03 6:19 PM -0500 Bob Ippolito <bo...@re...> wrote:
>> Currently, because of the 7-bit possibility, if you want a unicode
>> string from a value s that came from the objc side, you need to call
>> unicode(s). I hope and assume that whatever happens with strings,
>> unicode(s) will still work.
>
> unicode(s) works for any str or unicode instance, or any instance that
> otherwise implements __str__ and/or __unicode__.  If it's a str or
> __str__ that has 8-bit characters, you have to specify an encoding.
> Optionally you may also specify a way to handle errors ('strict',
> 'ignore', or 'replace').

So I guess my point is that if NSStrings with 8-bit characters stopped 
being converted to unicodes automatically, an appropriate implementation of 
__unicode__ should be added.  It would be bad to go through __str__ and 
force an encoding to be specified explicitly, because an encoding is 
already determined for this kind of object.

On 2/4/03 12:24 AM +0100 Just van Rossum <ju...@le...> wrote:
>> Currently, because of the 7-bit possibility, if you want a unicode
>> string from a value s that came from the objc side, you need to call
>> unicode(s). I hope and assume that whatever happens with strings,
>> unicode(s) will still work.
>
> I'm curious: if the string is known to be 7-bit ascii, in what situation
> does an 8-bit string not work where a unicde string does?

I had some code of the form unicode(s).encode('utf8') because I thought it 
didn't make sense to encode something that wasn't already unicode.  But 
looking at it again, I guess encode works equally well on 7-bit strings...

> Btw. while peeking around I came across the thing Bill warned for:
> [NSString stringWithCString:] returns an instance of NSCFString, which
> is a subclass of -- tada -- NSMutableString. This doesn't mean it _is_
> mutable: I get an exception if I try. So _inheritance_ can't be used to
> determine mutability. Does anyone know off hand what can?

Any idea whether it reuses the storage of the C string, or copies it?
If it reuses it, it could be mutable by the C code...

--
David Eppstein       UC Irvine Dept. of Information & Computer Science
epp...@ic... http://www.ics.uci.edu/~eppstein/

Re: [Pyobjc-dev] Re: [ pyobjc-Bugs-679748 ] NSMutableString gets converted to Python string

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

David Eppstein wrote:

> Currently, because of the 7-bit possibility, if you want a unicode
> string from a value s that came from the objc side, you need to call
> unicode(s). I hope and assume that whatever happens with strings,
> unicode(s) will still work.

I'm curious: if the string is known to be 7-bit ascii, in what situation
does an 8-bit string not work where a unicde string does?

> There seems to be a thread going now on c.l.py about unicode
> filenames...

I only see one about source encodings...

Btw. while peeking around I came across the thing Bill warned for:
[NSString stringWithCString:] returns an instance of NSCFString, which
is a subclass of -- tada -- NSMutableString. This doesn't mean it _is_
mutable: I get an exception if I try. So _inheritance_ can't be used to
determine mutability. Does anyone know off hand what can?

Just

Re: [Pyobjc-dev] Re: [ pyobjc-Bugs-679748 ] NSMutableString gets converted to Python string

[Bob I. <bo...@re...>]

On Monday, Feb 3, 2003, at 18:08 America/New_York, David Eppstein wrote:

> On 2/3/03 10:48 PM +0100 Just van Rossum <ju...@le...> wrote:
>> What works nicely now is that the conversion of unicode strings to
>> NSStrings and vice versa is really transparant: pass Python unicode
>> strings to ObjC call expecting an NSString and it works. The other way
>> also: if the NSString is representable in 7-bit ascii you get a str, 
>> if
>> not you get a unicode string.
>
> My code certainly depends on this (at least, the part about sending 
> unicode strings to objc and getting unicode strings back).
>
>> I worry about that Python users will have
>> to convert to a unicode string after all when this conversion 
>> _doesn't_
>> take place.
>
> Currently, because of the 7-bit possibility, if you want a unicode 
> string from a value s that came from the objc side, you need to call 
> unicode(s). I hope and assume that whatever happens with strings, 
> unicode(s) will still work.

unicode(s) works for any str or unicode instance, or any instance that 
otherwise implements __str__ and/or __unicode__.  If it's a str or 
__str__ that has 8-bit characters, you have to specify an encoding.  
Optionally you may also specify a way to handle errors ('strict', 
'ignore', or 'replace').

-bob

Re: [Pyobjc-dev] Re: [ pyobjc-Bugs-679748 ] NSMutableString gets converted to Python string

[Bob I. <bo...@re...>]

On Monday, Feb 3, 2003, at 17:42 America/New_York, Bill Bumgarner wrote:

> On Monday, Feb 3, 2003, at 17:36 US/Eastern, Just van Rossum wrote:
>> This seems the worst of both worlds, performance wise: allocate new
>> storage *and* keep the old object? Hm...
>
> If implemented correctly, the allocation only happens once the first 
> time the object crosses the bridge from ObjC->Python.   From then on, 
> the bridge should be able to use the already existing instance of 
> NSString when going from Python->ObjC.   The challenge will be when 
> going from ObjC->Python after the first invocation.  I'm hoping the 
> weak reference code that is already present in the bridge will provide 
> some kind of a solution.
>
> The truth will be revealed in the code, I suppose.

Is it really the worst of both worlds, performance wise?  If you have 
*both* available, you have a native object to work with on both sides 
of the bridge.  Since you're keeping the NSString around, when/if it 
needs to get passed back you don't need anything special on the ObjC 
end.  It also has the potential to save a lot of programmer hours (for 
everyone using pyobjc), I think, which is more important for Python 
users IMHO.

It might use twice the memory, but how often do you pass gigantic 
NSStrings around over a bridge?  If you really wanted to garbage 
collect the NSString (assuming it has no references on the ObjC side) 
you could do myUnicodeNSStringWrapper = 
unicode(myUnicodeNSStringWrapper) or myNSStringWrapper = 
str(myNSStringWrapper).

In any case, as far as I can tell, you still need to have both 
allocated at the same time at one point *if* you want something that 
can act like a PyString or PyUnicode without the pyobjc user knowing 
too much about it.  You might as well keep both around as long as you 
need them.

-bob

Re: [Pyobjc-dev] Re: [ pyobjc-Bugs-679748 ] NSMutableString gets converted to Python string

[David E. <epp...@ic...>]

On 2/3/03 10:48 PM +0100 Just van Rossum <ju...@le...> wrote:
> What works nicely now is that the conversion of unicode strings to
> NSStrings and vice versa is really transparant: pass Python unicode
> strings to ObjC call expecting an NSString and it works. The other way
> also: if the NSString is representable in 7-bit ascii you get a str, if
> not you get a unicode string.

My code certainly depends on this (at least, the part about sending unicode 
strings to objc and getting unicode strings back).

> I worry about that Python users will have
> to convert to a unicode string after all when this conversion _doesn't_
> take place.

Currently, because of the 7-bit possibility, if you want a unicode string 
from a value s that came from the objc side, you need to call unicode(s). 
I hope and assume that whatever happens with strings, unicode(s) will still 
work.

> Python has only limited support for unicode file names and I believe
> it's highly platform dependent. Right now it doesn't work with unicode
> strings on OSX, but it does work with 8-bit strings encoded as utf-8:
>
>>>> os.stat('a\xcc\x8a')
> (33188, 1685956L, 234881029L, 1, 501, 20, 0L, 1044307510, 1044307510,
> 1044307510)
>>>> os.stat(unicode('a\xcc\x8a', "utf-8"))
> Traceback (most recent call last):
>   File "<stdin>", line 1, in ?
> UnicodeEncodeError: 'ascii' codec can't encode character '\u30a' in
> position 1: ordinal not in range(128)
>>>>
>
> This seems pretty broken, but I don't know enough of the internals to
> see what it would take to fix this.

There seems to be a thread going now on c.l.py about unicode filenames...
--
David Eppstein       UC Irvine Dept. of Information & Computer Science
epp...@ic... http://www.ics.uci.edu/~eppstein/

Re: [Pyobjc-dev] Re: [ pyobjc-Bugs-679748 ] NSMutableString gets converted to Python string

[Bill B. <bb...@co...>]

On Monday, Feb 3, 2003, at 17:36 US/Eastern, Just van Rossum wrote:
> This seems the worst of both worlds, performance wise: allocate new
> storage *and* keep the old object? Hm...

If implemented correctly, the allocation only happens once the first 
time the object crosses the bridge from ObjC->Python.   From then on, 
the bridge should be able to use the already existing instance of 
NSString when going from Python->ObjC.   The challenge will be when 
going from ObjC->Python after the first invocation.  I'm hoping the 
weak reference code that is already present in the bridge will provide 
some kind of a solution.

The truth will be revealed in the code, I suppose.

b.bum

Re: [Pyobjc-dev] Re: [ pyobjc-Bugs-679748 ] NSMutableString gets converted to Python string

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

Bob Ippolito wrote:

> What about this:
> class UnicodeNSStringWrapper(unicode):
>   def __new__(clazz, myNSString):
>       s =  
>
unicode.__new__(somethingToConvertNSStringInstanceToPyUnicodeObject(myNS 
> String))
>       s._objc = myNSString
>       return s
>   def __getattr__(self, attr):
>       try:
>           return getattr(self._objc, attr)
>       except:
>           raise AttributeError, '%r object has no attribute %r' %  
> (self.__class__.__name__, self._objc)
> 
> It should do anything that unicode() will do, just like the str  
> subclass I posted a bit ago.. and you don't lose any of the NSString  
> functionality.

This seems the worst of both worlds, performance wise: allocate new
storage *and* keep the old object? Hm...

Just

Re: [Pyobjc-dev] Re: [ pyobjc-Bugs-679748 ] NSMutableString gets converted to Python string

[Bob I. <bo...@re...>]

On Monday, Feb 3, 2003, at 17:20 America/New_York, Bill Bumgarner wrote:

> On Monday, Feb 3, 2003, at 17:16 US/Eastern, Bob Ippolito wrote:
>> What about this:
>> class UnicodeNSStringWrapper(unicode):
>> 	def __new__(clazz, myNSString):
>> 		s =  
>> unicode.__new__(somethingToConvertNSStringInstanceToPyUnicodeObject(my 
>> NSString))
>> 		s._objc = myNSString
>> 		return s
>> 	def __getattr__(self, attr):
>> 		try:
>> 			return getattr(self._objc, attr)
>> 		except:
>> 			raise AttributeError, '%r object has no attribute %r' %  
>> (self.__class__.__name__, self._objc)
>>
>> It should do anything that unicode() will do, just like the str  
>> subclass I posted a bit ago.. and you don't lose any of the NSString  
>> functionality.
>
> Given that I have to write  
> somethingToConvertNSStringInstanceToPyUnicodeObject() anyway, I'll do  
> so first, plug it into this and see what happens.   (This old had ObjC  
> programmer sometimes has to be beaten around the head with the obvious  
> elegant path that only Python can offer.)

PyObject *somethingToConvertNSStringInstanceToPyUnicodeObject(NSString  
*myNSString) {
	const char *s;
	if (myNSString == nil)
		return NULL;
	s = [myNSString UTF8String];
	return PyUnicode_Decode(s, strlen(s), "utf-8", NULL);
}

not sure about the NULL for errors, but that just about does it!

-bob

Re: [Pyobjc-dev] unicode strings to system calls

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

Bill Bumgarner wrote:

> Broken, yes, but the behavior makes sense.
> 
> The entire [I think entire, that was the goal] BSD layer can accept
> and use UTF-8 encoded strings.   It "just works".
> 
> As such, Python probably isn't doing anything with the strings before 
> passing 'em into the underlying API.   The following lends support to 
> that theory:
> 
>  >>> x = 'a\xcc\x8a'
>  >>> type(x)
> <type 'str'>

Unicode strings can always be recognized by the leading u char in the
repr:

  >>> u'a'
  u'a'
  >>> type(u'a')
  <type 'unicode'>

If the repr doesn't start with a u, it's an 8-bit string. Unicode
strings are internally represented by 16-bit chars (but there's a build
option that makes this 32-bits).

> In effect, -x- in the above example is just a regular string-- not
> unicode-- and is passed into the stat() [which parses the first
> argument in the same fashion as file()/open();  via the 'et' format
> sequence] function as the filename in the same fashion as
> file()/open().
> 
> So, in theory, I should be able to create an object that implements
> the character buffer interface, contains the NSString reference, and
> provides immutable access to the NSString's contents through the
> character buffer interface.   The NSString's contents will be encoded
> as UTF8String into the buffer.

But to do anything _meaningful_ with unicode in Python (other than
working with the file system), you are going to need an actual unicode
object (or one that acts justs like it, which is what I'm not sure is
possible).

Just

Re: [Pyobjc-dev] Re: [ pyobjc-Bugs-679748 ] NSMutableString gets converted to Python string

[Bill B. <bb...@co...>]

On Monday, Feb 3, 2003, at 17:16 US/Eastern, Bob Ippolito wrote:
> What about this:
> class UnicodeNSStringWrapper(unicode):
> 	def __new__(clazz, myNSString):
> 		s =  
> unicode.__new__(somethingToConvertNSStringInstanceToPyUnicodeObject(myN 
> SString))
> 		s._objc = myNSString
> 		return s
> 	def __getattr__(self, attr):
> 		try:
> 			return getattr(self._objc, attr)
> 		except:
> 			raise AttributeError, '%r object has no attribute %r' %  
> (self.__class__.__name__, self._objc)
>
> It should do anything that unicode() will do, just like the str  
> subclass I posted a bit ago.. and you don't lose any of the NSString  
> functionality.

Given that I have to write  
somethingToConvertNSStringInstanceToPyUnicodeObject() anyway, I'll do  
so first, plug it into this and see what happens.   (This old had ObjC  
programmer sometimes has to be beaten around the head with the obvious  
elegant path that only Python can offer.)

thanks!
b.bum

Re: [Pyobjc-dev] Re: [ pyobjc-Bugs-679748 ] NSMutableString gets converted to Python string

[Bob I. <bo...@re...>]

On Monday, Feb 3, 2003, at 16:48 America/New_York, Just van Rossum  
wrote:

> Bill Bumgarner wrote:
>
>> On Monday, Feb 3, 2003, at 15:45 US/Eastern, Just van Rossum wrote:
>>> Bill Bumgarner wrote:
>>>> - a python object that provides a character buffer style interface
>>>> to the contents of an NSString.
>>>
>>> How would this work for NSStrings containing unicode?
>>
>> I have no clue yet.
>
> What works nicely now is that the conversion of unicode strings to
> NSStrings and vice versa is really transparant: pass Python unicode
> strings to ObjC call expecting an NSString and it works. The other way
> also: if the NSString is representable in 7-bit ascii you get a str, if
> not you get a unicode string. I worry about that Python users will have
> to convert to a unicode string after all when this conversion _doesn't_
> take place. I have no idea how to make an object can behave _like_ a
> unicode string and have it work everywhere. Maybe time for a post to
> c.l.py...

What about this:
class UnicodeNSStringWrapper(unicode):
	def __new__(clazz, myNSString):
		s =  
unicode.__new__(somethingToConvertNSStringInstanceToPyUnicodeObject(myNS 
String))
		s._objc = myNSString
		return s
	def __getattr__(self, attr):
		try:
			return getattr(self._objc, attr)
		except:
			raise AttributeError, '%r object has no attribute %r' %  
(self.__class__.__name__, self._objc)

It should do anything that unicode() will do, just like the str  
subclass I posted a bit ago.. and you don't lose any of the NSString  
functionality.

-bob

[Pyobjc-dev] unicode strings to system calls

[Bill B. <bb...@co...>]

On Monday, Feb 3, 2003, at 16:48 US/Eastern, Just van Rossum wrote:
> Python has only limited support for unicode file names and I believe
> it's highly platform dependent. Right now it doesn't work with unicode
> strings on OSX, but it does work with 8-bit strings encoded as utf-8:
>
>>>> os.stat('a\xcc\x8a')
> (33188, 1685956L, 234881029L, 1, 501, 20, 0L, 1044307510, 1044307510,
> 1044307510)
>>>> os.stat(unicode('a\xcc\x8a', "utf-8"))
> Traceback (most recent call last):
>   File "<stdin>", line 1, in ?
> UnicodeEncodeError: 'ascii' codec can't encode character '\u30a' in
> position 1: ordinal not in range(128)
>>>>
>
> This seems pretty broken, but I don't know enough of the internals to
> see what it would take to fix this.

Broken, yes, but the behavior makes sense.

The entire [I think entire, that was the goal] BSD layer can accept and 
use UTF-8 encoded strings.   It "just works".

As such, Python probably isn't doing anything with the strings before 
passing 'em into the underlying API.   The following lends support to 
that theory:

 >>> x = 'a\xcc\x8a'
 >>> type(x)
<type 'str'>

In effect, -x- in the above example is just a regular string-- not 
unicode-- and is passed into the stat() [which parses the first 
argument in the same fashion as file()/open();  via the 'et' format 
sequence] function as the filename in the same fashion as file()/open().

So, in theory, I should be able to create an object that implements the 
character buffer interface, contains the NSString reference, and 
provides immutable access to the NSString's contents through the 
character buffer interface.   The NSString's contents will be encoded 
as UTF8String into the buffer.

We'll see how far I get....

b.bum

Re: [Pyobjc-dev] Re: [ pyobjc-Bugs-679748 ] NSMutableString gets converted to Python string

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

Just van Rossum wrote:

> I have no idea how to make an object can behave _like_ a
> unicode string and have it work everywhere. Maybe time for a post to
> c.l.py...

Question posted. Something with "Unicode" in the subject...

Just

[Pyobjc-dev] Re: [ pyobjc-Bugs-679748 ] NSMutableString gets converted to Python string

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

Bill Bumgarner wrote:

> On Monday, Feb 3, 2003, at 15:45 US/Eastern, Just van Rossum wrote:
> > Bill Bumgarner wrote:
> >> - a python object that provides a character buffer style interface
> >> to the contents of an NSString.
> >
> > How would this work for NSStrings containing unicode?
> 
> I have no clue yet.

What works nicely now is that the conversion of unicode strings to
NSStrings and vice versa is really transparant: pass Python unicode
strings to ObjC call expecting an NSString and it works. The other way
also: if the NSString is representable in 7-bit ascii you get a str, if
not you get a unicode string. I worry about that Python users will have
to convert to a unicode string after all when this conversion _doesn't_
take place. I have no idea how to make an object can behave _like_ a
unicode string and have it work everywhere. Maybe time for a post to
c.l.py...

> NSString provides a rich set of API for converting from whatever the
> internal representation is to whatever Unicode representation you
> might want.   As such, it will be easy to produce a character buffer
> full of, say, UTF8 characters.
> 
> What can be done with this in the context of the Python API --
> whether it can be wrapped into a python object that is actually
> useful -- remains to be seen.   Given that file()/open() only looks
> for a character buffer and, I believe, can handle a UTF8 path gives
> me hope.

Python has only limited support for unicode file names and I believe
it's highly platform dependent. Right now it doesn't work with unicode
strings on OSX, but it does work with 8-bit strings encoded as utf-8:

>>> os.stat('a\xcc\x8a')
(33188, 1685956L, 234881029L, 1, 501, 20, 0L, 1044307510, 1044307510,
1044307510)
>>> os.stat(unicode('a\xcc\x8a', "utf-8"))
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
UnicodeEncodeError: 'ascii' codec can't encode character '\u30a' in
position 1: ordinal not in range(128)
>>> 

This seems pretty broken, but I don't know enough of the internals to
see what it would take to fix this.

Just

[Pyobjc-dev] Re: [ pyobjc-Bugs-679748 ] NSMutableString gets converted to Python string

[Bill B. <bb...@co...>]

On Monday, Feb 3, 2003, at 15:45 US/Eastern, Just van Rossum wrote:
> Bill Bumgarner wrote:
>> - a python object that provides a character buffer style interface to
>> the contents of an NSString.
>
> How would this work for NSStrings containing unicode?

I have no clue yet.

NSString provides a rich set of API for converting from whatever the 
internal representation is to whatever Unicode representation you might 
want.   As such, it will be easy to produce a character buffer full of, 
say, UTF8 characters.

What can be done with this in the context of the Python API -- whether 
it can be wrapped into a python object that is actually useful -- 
remains to be seen.   Given that file()/open() only looks for a 
character buffer and, I believe, can handle a UTF8 path gives me hope.

b.bum

[Pyobjc-dev] Re: [ pyobjc-Bugs-679748 ] NSMutableString gets converted to Python string

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

Bill Bumgarner wrote:

> - a python object that provides a character buffer style interface to 
> the contents of an NSString.

How would this work for NSStrings containing unicode?

Just