pyobjc-dev — CVS commit notices go here

Re: [Pyobjc-dev] strings returned from ObjC are now unicode?

[Chris R. <cp...@em...>]

On Sunday, February 9, 2003, at 03:23  AM, Just van Rossum wrote:

> Chris Ryland wrote:
>
>> The latest CVS seems to return unicode strings from objc
>> string-producing calls.
>>
>> Is that the final decision about this hotly-debated topic?
>
> I'm not sure it's final, but is it a problem for you? NSStrings can
> always contain unicode so I think it's a good signal to the user (of
> PyObjC ;-) to always return unicode strings.

No, not necessarily--just wondering if that decision is in flux or if 
it'll change tomorrow. ;-)

Cheers!
--Chris Ryland / Em Software, Inc. / www.emsoftware.com

Re: [Pyobjc-dev] OC_PythonString implementation

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

Ronald Oussoren wrote:

> I've just checked in working version of unicode-object.m (the bug was
> a pretty lame bug in the initialization of ObjCUnicode_Type). The
> resulting version of the bridge mostly passes the unit tests, the
> additional failures seem to be caused by a minor change in the
> semantics of the bridge.

My brief tests seem to indicate that things work great. Thanks!

[ ... ]
> - Determine, and use, best interface for accessing the NSString 
> (currently method pyobjc_NSString). Using 'nsstring' as the name is 
> probably better. Should this be a method or a (read-only) property?

Since the wrapper get created on the fly, I think a method is most
apporpriate after all. I would call that method nsstring(), though. Hm,
maybe as_nsstring() is better. Yeah, I like that. Or as_NSString().

Just

Re: [Pyobjc-dev] strings returned from ObjC are now unicode?

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

On Sunday, Feb 9, 2003, at 09:23 Europe/Amsterdam, Just van Rossum 
wrote:

> Chris Ryland wrote:
>
>> The latest CVS seems to return unicode strings from objc
>> string-producing calls.
>>
>> Is that the final decision about this hotly-debated topic?
Converting NSStrings to unicode was only a sidetrack of the string 
related discussions ;-).
>
> I'm not sure it's final, but is it a problem for you? NSStrings can
> always contain unicode so I think it's a good signal to the user (of
> PyObjC ;-) to always return unicode strings.

This is partially because I was lazy and only subclassed 
__builtin__.unicode, but mostly because NSStrings are unicode strings. 
Unless returning unicode strings proves to be a real problem I'd like 
to keep it this way (if you want a string you can always do the 
conversion yourself).

Ronald

Re: [Pyobjc-dev] should I worry about nibclassbuilder?

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

On Sunday, Feb 9, 2003, at 07:31 Europe/Amsterdam, Chris Ryland wrote:

> I installed pyobjc from CVS and I had to change a few permissions to 
> get it built and installed--is that normal? (But mostly for things I'm 
> adding, so that doesn't worry me, such as /usr/local/include, etc.)
>
> I didn't want to do that for /usr/bin, so the installation of 
> Scripts/nibclassbuilder failed. Should I worry?
No, the script is not essential.

BTW. The correct way to install is 'sudo python setup.py install', that 
way you don't have to change the permissions on /usr/local (making it 
harder to accidently trash the /usr/local tree).

Ronald

Re: [Pyobjc-dev] strings returned from ObjC are now unicode?

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

Chris Ryland wrote:

> The latest CVS seems to return unicode strings from objc 
> string-producing calls.
> 
> Is that the final decision about this hotly-debated topic?

I'm not sure it's final, but is it a problem for you? NSStrings can
always contain unicode so I think it's a good signal to the user (of
PyObjC ;-) to always return unicode strings.

Just

Re: [Pyobjc-dev] should I worry about nibclassbuilder?

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

Chris Ryland wrote:

> I installed pyobjc from CVS and I had to change a few permissions to 
> get it built and installed--is that normal? (But mostly for things I'm 
> adding, so that doesn't worry me, such as /usr/local/include, etc.)
> 
> I didn't want to do that for /usr/bin, so the installation of 
> Scripts/nibclassbuilder failed. Should I worry?

No, just run "python setup.py install" with sudo.

Just

[Pyobjc-dev] strings returned from ObjC are now unicode?

[Chris R. <cp...@em...>]

The latest CVS seems to return unicode strings from objc 
string-producing calls.

Is that the final decision about this hotly-debated topic?

Cheers!
--Chris Ryland / Em Software, Inc. / www.emsoftware.com

[Pyobjc-dev] bus error from Web Services Tool in latest CVS?

[Chris R. <cp...@em...>]

A lot of things in the pyobjc CVS image seem to work, but when I build 
and run the Web Services Tool, it starts up and gets a bus error after 
a few seconds before anything visible happens. Is that normal or should 
I start trying to figure out what's wrong with my installation?

Cheers!
--Chris Ryland / Em Software, Inc. / www.emsoftware.com

[Pyobjc-dev] should I worry about nibclassbuilder?

[Chris R. <cp...@em...>]

I installed pyobjc from CVS and I had to change a few permissions to 
get it built and installed--is that normal? (But mostly for things I'm 
adding, so that doesn't worry me, such as /usr/local/include, etc.)

I didn't want to do that for /usr/bin, so the installation of 
Scripts/nibclassbuilder failed. Should I worry?

Cheers!
--Chris Ryland / Em Software, Inc. / www.emsoftware.com

Re: [Pyobjc-dev] OC_PythonString implementation

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

I've just checked in working version of unicode-object.m (the bug was a 
pretty lame bug in the initialization of ObjCUnicode_Type). The 
resulting version of the bridge mostly passes the unit tests, the 
additional failures seem to be caused by a minor change in the 
semantics of the bridge.

Todo:
- ObjCUnicodeObject has a slot for weakrefs, make this known to the 
runtime (easy)
- objc-object.m contains a mapping from id's to weakrefs to Python 
proxies, use this to make sure that there is at most one 
ObjCUnicodeObject for an NSString
- More testing
- Determine, and use, best interface for accessing the NSString 
(currently method pyobjc_NSString). Using 'nsstring' as the name is 
probably better. Should this be a method or a (read-only) property?

Ronald

[Pyobjc-dev] Re: [Pythonmac-SIG] PyObjC Article at O'Reilly

[Pascal O. <p.o...@ur...>]

Ronald Oussoren at ous...@ci...:

> I'm afraid that support for 10.1.x will stay absent until someone
> volunteers to do the port. Luckily that shouldn't be too hard.
> 
> You also try to use the latest version from CVS, this uses libffi
> (downloadable from our files section of SF) instead of the contents of
> file that's failing for you.

Unfortunately libffi won't compile on 10.1.5 either. So no chance for me to
discover where the latest version from CVS would stop compiling.

Thank you anyway.

Pascal

Re: [Pyobjc-dev] Bridging NSMutableString, a compromise

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

Ronald Oussoren wrote:

> > Why are there _two_ relevant objects instead of just one being the
> > "master"? Without looking at the code I would have assumed it would
> > work like this:
> > a) a native ObjC object
> > b) a thin Python wrapper, only containing a ref to the ObjC objects
> 
> That might also work. I wanted NSObject to behave as much as possible 
> like a 'proper' new-style class (including __slots__), without copying 
> code from the python implementation.

Ah, I see what you mean: this approach would force you reimplement much
of the __slots__ logic for an NSObject.

If we would go this route, I would propose to drop support for __slots__
in NSObject subclasses. Its purpose is twofold:

  1) to define the set of names that can be used as attributes,
     causing typos in attr names to be caught earlier (or at all...)

  2) to save space in the object as it then doesn't need a separate
     __dict__ object; the attr refs live in the allocated object itself

I don't care much for #2, but #1 is useful. I could live without it,
though.

Hm, here's an idea (that probably only complicates things, so don't take
it too seriously ;-): could the __slots__ definition be mapped to ivars
in the native object? That would actually be pretty cool, except it
doesn't save space, since all attrs need to be wrapped in
OC_PythonObject instances... Ha, this would make the following two
classes equivalent:

  class Foo(NSObject):
      a = objc.ivar("a")
      b = objc.ivar("b")
  
  class Bar(NSObject):
      __slots__ = ("a", "b")

> It might be worthwhile to reexamine this issue after we get strings
> working properly.

Definitely not before 0.9!

Just

Re: [Pyobjc-dev] Bridging NSMutableString, a compromise

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

Just van Rossum wrote:

> Bill's stuff also looks pretty good! We actually manages to reuse the
> Python string storage!

Duh, substitute "He" for "We"...

Just

Re: [Pyobjc-dev] Bridging NSMutableString, a compromise

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

Jack Jansen wrote:

> Still, I think the whole idea of this double-headed-monster-string is
> far to complex for the problem we're trying to solve.

Yet the module that Ronald just posted is remarkably small. It's very
simple, it must be good! ;-)

Bill's stuff also looks pretty good! We actually manages to reuse the
Python string storage!

> If we would just return the actual object, i.e. an NSString or
> NSMutableString, all our problems would disappear, except for one: it
> is cumbersome (not to mention butt-ugly) to have to do
> obj.NSStringAsCString(), or even str(obj), on 99% of all the
> NSStrings you get back from objc.

Which is IMO exactly what we must avoid.

Just

Re: [Pyobjc-dev] OC_PythonString implementation

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

bb...@ma... wrote:

> ! -initWithPythonObject:(PyObject*)v;
>    {
> !     value = v;
> 
> !     if (PyString_Check(value)) {
> !       char *buffer;
> !       int length;
> !       int result;
> !
> !       result = PyString_AsStringAndSize(value, &buffer, &length);
> !       if(result == -1) {
> !           ObjCErr_ToObjC();
> !           [self release];
> !           return nil; // not reached
> !       }
> !       stringValue = CFStringCreateWithCStringNoCopy(NULL,
> !                                                     buffer,
> !                                                     
> kCFStringEncodingUTF8,

This is wrong. You cannot assume a PyString contains utf-8. In theory
you should ocnvert it to unicode using the default encoding (usually
ASCII) but since this would break your scheme you should raise an
exception if the PyString is not 7-bit clean.

> !
kCFAllocatorNull);
> !       _internalRep = NULL;
> !     } else if (PyUnicode_Check(value)) {
> !       char *buffer;
> !       int length;
> !       int result;
> ! #warning Is there a way to determine what the encoding of value is 
> and instantiate a CFString directly?
> !       _internalRep = PyUnicode_AsUTF8String(value);
> !       result = PyString_AsStringAndSize(_internalRep, &buffer, 
> &length);

I'm not 100% sure what you're asking here. The encoding of the internal
representation of a PyUnicode object is a either a 16 bit encoding or a
32 bit encoding depending on a compile-time flag. This is the relevant
comment from unicodeobject.h:

/* Setting Py_UNICODE_WIDE enables UCS-4 storage.  Otherwise, Unicode
   strings are stored as UCS-2 (with limited support for UTF-16) */

Py_UNICODE_WIDE is not set by default, so in the normal case I think you
should specify UTF-16.

Just

Re: [Pyobjc-dev] Bridging NSMutableString, a compromise

[Jack J. <Jac...@or...>]

On vrijdag, feb 7, 2003, at 19:07 Europe/Amsterdam, Ronald Oussoren 
wrote:

>> The only mutable strings that we want to represent as Pythonic string
>> lookalikes are those returned in places where the promise was that we 
>> would get an
>> NSString.
> The only way to detect that the API promises to return an (immutable) 
> NSString is by parsing header files, as far as the Objective-C runtime 
> (and therefore PyObjC) is concerned all classes are the same when 
> mentioned in method signatures.

I keep forgetting that. That basically kills the whole idea.

Still, I think the whole idea of this double-headed-monster-string is 
far to complex for the problem we're trying to solve.

If we would just return the actual object, i.e. an NSString or 
NSMutableString, all our problems would disappear, except for one: it 
is cumbersome (not to mention butt-ugly) to have to do 
obj.NSStringAsCString(), or even str(obj), on 99% of all the NSStrings 
you get back from objc.

I have a half-baked idea on how this may be solvable, in a way that may 
also allow us to get rid of the underscores in method names for 99% of 
the usage, and possibly more. I'll get back when I've done a bit more 
thinking.
--
- Jack Jansen        <Jac...@or...>        
http://www.cwi.nl/~jack -
- If I can't dance I don't want to be part of your revolution -- Emma 
Goldman -

[Pyobjc-dev] python extension namespace clash in jaguar python?

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

Using the stock python from OS X 10.2, is there a way around the issue 
where two python extensions with the same name (but in different 
packages) will cause a clash?  I know this has been resolved in later 
builds of python, but it would be nice to be able to get around this 
without distributing a custom build.

In my particular example, I was seeing how possible it is to port 
pygame to the stock python using methods similar to what the pyobjc 
team has done...  pygame has a module called time, which clashes with 
python's time.  If I import pygame.time, and then import time, both of 
them are actually pygame.time, and vice versa if I do it in reverse 
order.  I know I could rename pygame.time (and change inittime) to 
something else, but that doesn't seem like a very good solution.  Are 
there any alternatives?

-bob

Re: [Pyobjc-dev] Bridging NSMutableString, a compromise

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

On Friday, Feb 7, 2003, at 22:59 Europe/Amsterdam, Just van Rossum 
wrote:

> Ronald Oussoren wrote:
>
>> On Friday, Feb 7, 2003, at 22:31 Europe/Amsterdam, Just van Rossum
>> wrote:
>>> Btw. I noticed PyObjC tries to sync the refcounts for both objects
>>> in class-builder.m's object_method_retain() and
>>> object_method_release() calls. Why is this needed?
>>
>> This is for Python subclasses of Objective-C classes (and only those).
>> Such instances have two parts, an Objective-C object and a Python
>> object, that behave as if there is 1 object. Using 1 refcount for both
>> parts is IMHO the only feaseable way to ensure that we don't end up
>> with only one of the parts and that these objects are not immortal.
>>
>> Getting this right was one of the hardest elements of my rewrite of
>> PyObjC, and something that really should be documented...
>
> For lack of documentation <wink>, I hope you don't mind me asking the
> following, because I must be missing something deep:
>
> Why are there _two_ relevant objects instead of just one being the
> "master"? Without looking at the code I would have assumed it would 
> work
> like this:
> a) a native ObjC object
> b) a thin Python wrapper, only containing a ref to the ObjC objects

That might also work. I wanted NSObject to behave as much as possible 
like a 'proper' new-style class (including __slots__), without copying 
code from the python implementation. It might be worthwhile to 
reexamine this issue after we get strings working properly.

Ronald

Re: [Pyobjc-dev] OC_PythonString implementation

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

And below is unicode-object.m, a subclass of PyUnicode_Type that stores 
a reference to an NSString
value. This isn't working entirely correctly yet, that's why I haven't 
checked it in yet.

If you call ObjCUnicode_New in the __pyobjc_PythonObject__ method for 
NSString objects NSString values are proxied using a unicode object, 
and calling the method 'pyobjc_NSString' will retrieve a 'plain' proxy 
for the NSString object (making it possible to call NSString methods).

This will crash your interpreter, probably due to a memory management 
bug.

Ronald


/*
  * Custom subclass of PyUnicode_Type, to allow for transparent bridging 
of
  * strings
  */

#include <Python.h>
#include "pyobjc.h"
#include "objc_support.h"

typedef struct {
	PyUnicodeObject	base;
	PyObject*	weakrefs;
	id		nsstr;
} ObjCUnicodeObject;

PyDoc_STRVAR(class_doc,
	"objc.pyobjc_unicode\n"
	"\n"
	"Subclass of unicode for representing NSString values. Use \n"
	"the method pyobjc_NSString to access the NSString. \n"
	"Note that instances are immutable and won't be updated when\n"
	"the value of the NSString changes."
);

static void
class_dealloc(PyObject* obj)
{
	PyObject* weakrefs = ((ObjCUnicodeObject*)obj)->weakrefs;
	id nsstr = ((ObjCUnicodeObject*)obj)->nsstr;

	if (weakrefs) {
		PyObject_ClearWeakRefs(obj);
	}

	[nsstr release];
	PyMem_Free(((PyUnicodeObject*)obj)->str);
	PyObject_Del(obj);
}

static PyObject* ObjCUnicode_pyobjc_NSString(PyObject* self)
{
	return ObjCObject_New(
	    *(id*)(((char*)self) +sizeof(PyUnicodeObject) + 
sizeof(PyObject*)));
}

static PyMethodDef class_methods[] = {
	{
	  "pyobjc_NSString",
	  (PyCFunction)ObjCUnicode_pyobjc_NSString,
	  METH_NOARGS,
	  "directly access NSString instance"
	},
         { 0, 0, 0, 0 } /* sentinel */
};



PyTypeObject ObjCUnicode_Type = {
	PyObject_HEAD_INIT(&PyType_Type)
	0,					/* ob_size */
	"objc.pyobjc_unicode",			/* tp_name */
	0,					/* tp_basicsize */
	sizeof(ObjCUnicodeObject), 		/* tp_itemsize */
	/* methods */
	class_dealloc,	 			/* tp_dealloc */
	0,					/* tp_print */
	0,					/* tp_getattr */
	0,					/* tp_setattr */
	0,					/* tp_compare */
	0,					/* tp_repr */
	0,					/* tp_as_number */
	0,					/* tp_as_sequence */
	0,		       			/* tp_as_mapping */
	0,					/* tp_hash */
	0,					/* tp_call */
	0,					/* tp_str */
	0,					/* tp_getattro */
	0,					/* tp_setattro */
	0,					/* tp_as_buffer */
	Py_TPFLAGS_DEFAULT,			/* tp_flags */
  	class_doc,				/* tp_doc */
  	0,					/* tp_traverse */
  	0,					/* tp_clear */
	0,					/* tp_richcompare */
	0,	/* tp_weaklistoffset */
	0,					/* tp_iter */
	0,					/* tp_iternext */
	class_methods,				/* tp_methods */
	0,					/* tp_members */
	0,					/* tp_getset */
	&PyUnicode_Type,			/* tp_base */
	0,					/* tp_dict */
	0,					/* tp_descr_get */
	0,					/* tp_descr_set */
	0,					/* tp_dictoffset */
	0,					/* tp_init */
	0,					/* tp_alloc */
	0,					/* tp_new */
	0,		        		/* tp_free */
};

/* TODO: Use proper access macros to access UnicodeObject fields */
PyObject* ObjCUnicode_New(NSString* value)
{
	const char* utf8 = [value UTF8String];
	PyUnicodeObject* tmp = (PyUnicodeObject*)PyUnicode_DecodeUTF8(utf8, 
strlen(utf8), "strict");
	ObjCUnicodeObject* result;

	if (tmp == NULL) return NULL;

	result = PyObject_New(ObjCUnicodeObject, &ObjCUnicode_Type);
	result->base.str = PyMem_NEW(Py_UNICODE, tmp->length);
	if (result->base.str == NULL) {
		Py_DECREF((PyObject*)result);
		PyErr_NoMemory();
		return NULL;
	}
	result->base.length = tmp->length;
	memcpy(result->base.str, tmp->str, sizeof(tmp->str[0]) * tmp->length);
	Py_DECREF(tmp);

	result->weakrefs = 0;
	result->nsstr = [value retain];

	return result;
}

NSString* ObjCUnicode_Extract(PyObject* value)
{
	if (!ObjCUnicode_Check(value)) {
		PyErr_BadInternalCall();
		return NULL;
	}

	return ((ObjCUnicodeObject*)value)->nsstr;
}

[Pyobjc-dev] OC_PythonString implementation

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

Posting a patch for comment -- all unit tests continue to work as 
expected (and the ones that break still break).

It eliminates some duplication of the string's data.  If I could figure 
out how to determine the encoding of a Unicode object, I could 
eliminate the rest of the duplication.   It currently may be slower 
overall simply because the various string extension methods haven't 
been implemented yet.   The implementation should also eliminate the 
creation of a new PythonString or Unicode object on the way from ObjC 
back to Python (as the implementation of -__pyobjc_PythonObject__ in 
OC_PythonString class will override the category of NSString that 
implements the same).

This would seem to have similar reference counting issues as does 
OC_PythonDictionary and friends.

This implementation would also seem to be consistent with 
OC_PythonDictionary and friends.

Index: Modules/objc/OC_PythonString.h
===================================================================
RCS file: /cvsroot/pyobjc/pyobjc/Modules/objc/OC_PythonString.h,v
retrieving revision 1.3
diff -c -r1.3 OC_PythonString.h
*** Modules/objc/OC_PythonString.h      18 Oct 2002 10:03:14 -0000      
1.3
--- Modules/objc/OC_PythonString.h      7 Feb 2003 21:51:13 -0000
***************
*** 1,44 ****
! /* Copyright (c) 1996,97 by Lele Gaifax.  All Rights Reserved
!  *
!  * This software may be used and distributed freely for any purpose
!  * provided that this notice is included unchanged on any and all
!  * copies. The author does not warrant or guarantee this software in
!  * any way.
!  *
!  * This file is part of the PyObjC package.
!  *
!  * RCSfile: OC_PythonString.h,v
!  * Revision: 1.8
!  * Date: 1998/01/04 17:59:21
!  *
!  * Created Thu Sep  5 19:46:45 1996.
!  */

! #ifndef _OC_PythonString_H
! #define _OC_PythonString_H

! #include "OC_PythonObject.h"

! /*#C This class wraps a PyString object, making it easier to handle 
this
!   kind of objects from Objective-C.  */
! @interface OC_PythonString : OC_PythonObject
   {
   }

! /*#M Returns a new autoreleased PyString object with @var{str} of
!   length @var{size} as contents. */
! + (id <PythonObject>) fromString:(char *) str andSize:(int) size;
!
! //#M Returns a new autoreleased PyString object with @var{str} as 
contents.
! + (id <PythonObject>) fromString:(char *) str;
!
! //#M Returns the size of the string.
! - (int) size;
!
! //#M Returns the ``C'' equivalent.
! - (char *) asString;
!
! @end /* OC_PythonString class interface */
!
!
! #endif /* _OC_PythonString_H */
--- 1,29 ----
! #ifndef OC_PythonString_h
! #define OC_PythonString_h

! #import <CoreFoundation/CoreFoundation.h>
! #import <Foundation/NSString.h>
! #include "Python.h"

! /*
!  * OC_PythonString - Objective-C proxy class for Python strings
!  *
!  * Instances of this class are used as proxies for Python strings
!  * when these are passed to Objective-C code. Because this class is
!  * a subclass of NSString Python sequences can be used everywhere
!  * where NSString is used.  Python strings are immutable.
!  */

! @interface OC_PythonString:NSString
   {
+     PyObject* value;
+     PyObject* _internalRep;
+     CFStringRef stringValue;
   }

! +newWithPythonObject:(PyObject*)value;
! -initWithPythonObject:(PyObject*)value;
! -(void)dealloc;
! -(PyObject*)__pyobjc_PythonObject__;
! @end
! #endif
Index: Modules/objc/OC_PythonString.m
===================================================================
RCS file: /cvsroot/pyobjc/pyobjc/Modules/objc/OC_PythonString.m,v
retrieving revision 1.4
diff -c -r1.4 OC_PythonString.m
*** Modules/objc/OC_PythonString.m      5 Feb 2003 21:08:51 -0000       
1.4
--- Modules/objc/OC_PythonString.m      7 Feb 2003 21:51:13 -0000
***************
*** 1,49 ****
- /* Copyright (c) 1996,97 by Lele Gaifax.  All Rights Reserved
-  *
-  * This software may be used and distributed freely for any purpose
-  * provided that this notice is included unchanged on any and all
-  * copies. The author does not warrant or guarantee this software in
-  * any way.
-  *
-  * This file is part of the PyObjC package.
-  *
-  * RCSfile: OC_PythonString.m,v
-  * Revision: 1.9
-  * Date: 1998/01/04 17:59:22
-  *
-  * Created Thu Sep  5 19:49:36 1996.
-  */
-
   #include "OC_PythonString.h"

   @implementation OC_PythonString

! + (id <PythonObject>) fromString:(char *) str andSize:(int) size
   {
!       PyObject *pystr = PyString_FromStringAndSize (str, size);
!       id <PythonObject> result = [self newWithObject:pystr];

!       Py_DECREF(pystr);
!       return result;
   }

! + (id <PythonObject>) fromString:(char *) str
   {
!       PyObject *pystr = PyString_FromString(str);
!       id <PythonObject> result = [self newWithObject:pystr];
!
!       Py_DECREF(pystr);
!       return result;
   }

! - (int) size
   {
!       return PyString_Size([self  pyObject]);
   }

! - (char *) asString
   {
!       return PyString_AsString([self  pyObject]);
   }

! @end /* OC_PythonString class implementation */
--- 1,84 ----
   #include "OC_PythonString.h"
+ #include "pyobjc.h"
+ #include "objc_support.h"

   @implementation OC_PythonString
+ +newWithPythonObject:(PyObject*)v;
+ {
+     OC_PythonString* res = [[OC_PythonString alloc] 
initWithPythonObject:v];
+     [res autorelease];
+     return res;
+ }

! -initWithPythonObject:(PyObject*)v;
   {
!     value = v;

!     if (PyString_Check(value)) {
!       char *buffer;
!       int length;
!       int result;
!
!       result = PyString_AsStringAndSize(value, &buffer, &length);
!       if(result == -1) {
!           ObjCErr_ToObjC();
!           [self release];
!           return nil; // not reached
!       }
!       stringValue = CFStringCreateWithCStringNoCopy(NULL,
!                                                     buffer,
!                                                     
kCFStringEncodingUTF8,
!                                                     kCFAllocatorNull);
!       _internalRep = NULL;
!     } else if (PyUnicode_Check(value)) {
!       char *buffer;
!       int length;
!       int result;
! #warning Is there a way to determine what the encoding of value is 
and instantiate a CFString directly?
!       _internalRep = PyUnicode_AsUTF8String(value);
!       result = PyString_AsStringAndSize(_internalRep, &buffer, 
&length);
!       if(result == -1) {
!           ObjCErr_ToObjC();
!           [self release];
!           return nil;
!       }
!
!       stringValue = CFStringCreateWithCStringNoCopy(NULL,
!                                                     buffer,
!                                                     
kCFStringEncodingUTF8,
!                                                     kCFAllocatorNull);
!     }
!
!     Py_INCREF(value);
!
!     return self;
   }

! -(PyObject*)__pyobjc_PythonObject__
   {
!       Py_INCREF(value);
!       return value;
   }

! -(void)dealloc
   {
!     CFRelease(stringValue);
!     Py_XDECREF(value);
!     Py_XDECREF(_internalRep);
!     [super dealloc];
   }

! - (unsigned int)length;
   {
!     int result;
!     result = CFStringGetLength(stringValue);
!     return result;
   }

! - (unichar)characterAtIndex:(unsigned)index;
! {
!     UniChar result;
!     result = CFStringGetCharacterAtIndex(stringValue, index);
!     return result;
! }
! @end
Index: Modules/objc/objc_support.m
===================================================================
RCS file: /cvsroot/pyobjc/pyobjc/Modules/objc/objc_support.m,v
retrieving revision 1.22
diff -c -r1.22 objc_support.m
*** Modules/objc/objc_support.m 6 Feb 2003 21:01:05 -0000       1.22
--- Modules/objc/objc_support.m 7 Feb 2003 21:51:13 -0000
***************
*** 843,881 ****
           *(id *) datum = (id)ObjCClass_GetClass(argument);
         else if (ObjCObject_Check (argument)) {
           *(id *) datum = ObjCObject_GetObject(argument);
!       } else if (PyString_Check (argument))
!         {
!       /* We should probably translate to unicode using the default 
python
!        * encoding (which is ASCII and may be different from the 
NSString
!        * default encoding)
!        */
!       unsigned char* strval = (unsigned 
char*)PyString_AS_STRING(argument);
!       int   len = PyString_GET_SIZE(argument);
!       int   i;
!
!       for (i = 0; i < len; i++) {
!               if (strval[i] >= 128) {
!                       error = "string with ordinals in range(128)";
!                       return error;
!               }
!       }
!
!       *(id *) datum = [NSString
!                       stringWithCString:PyString_AS_STRING(argument)
!                                 length:PyString_GET_SIZE(argument)];
!       }
!       else if (PyUnicode_Check(argument))
!       {
!               PyObject* utf8 = PyUnicode_AsUTF8String(argument);
!
!               if (utf8) {
!                       *(id *) datum = [NSString
!                               
stringWithUTF8String:PyString_AS_STRING(utf8)];
!                       Py_DECREF(utf8);
!               } else {
!                       error = "Cannot convert Unicode string";
!               }
!       }
         else if (PyInt_Check (argument))
         *(id *) datum = [NSNumber numberWithLong:PyInt_AS_LONG 
(argument)];
         else if (PyFloat_Check (argument))
--- 843,850 ----
           *(id *) datum = (id)ObjCClass_GetClass(argument);
         else if (ObjCObject_Check (argument)) {
           *(id *) datum = ObjCObject_GetObject(argument);
!       } else if ( (PyString_Check (argument)) || 
(PyUnicode_Check(argument)) )
!       *(id *) datum = [OC_PythonString newWithPythonObject:argument];
         else if (PyInt_Check (argument))
         *(id *) datum = [NSNumber numberWithLong:PyInt_AS_LONG 
(argument)];
         else if (PyFloat_Check (argument))
Index: Modules/objc/pyobjc.h
===================================================================
RCS file: /cvsroot/pyobjc/pyobjc/Modules/objc/pyobjc.h,v
retrieving revision 1.19
diff -c -r1.19 pyobjc.h
*** Modules/objc/pyobjc.h       5 Feb 2003 21:08:53 -0000       1.19
--- Modules/objc/pyobjc.h       7 Feb 2003 21:51:13 -0000
***************
*** 12,17 ****
--- 12,18 ----
   #include "OC_PythonObject.h"
   #include "OC_PythonArray.h"
   #include "OC_PythonDictionary.h"
+ #include "OC_PythonString.h"
   #include "super-call.h"

   /*

Re: [Pyobjc-dev] Bridging NSMutableString, a compromise

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

Ronald Oussoren wrote:

> On Friday, Feb 7, 2003, at 22:31 Europe/Amsterdam, Just van Rossum 
> wrote:
> > Btw. I noticed PyObjC tries to sync the refcounts for both objects
> > in class-builder.m's object_method_retain() and
> > object_method_release() calls. Why is this needed?
> 
> This is for Python subclasses of Objective-C classes (and only those). 
> Such instances have two parts, an Objective-C object and a Python 
> object, that behave as if there is 1 object. Using 1 refcount for both 
> parts is IMHO the only feaseable way to ensure that we don't end up 
> with only one of the parts and that these objects are not immortal.
> 
> Getting this right was one of the hardest elements of my rewrite of 
> PyObjC, and something that really should be documented...

For lack of documentation <wink>, I hope you don't mind me asking the
following, because I must be missing something deep:

Why are there _two_ relevant objects instead of just one being the
"master"? Without looking at the code I would have assumed it would work
like this:
a) a native ObjC object
b) a thin Python wrapper, only containing a ref to the ObjC objects

The ObjC object could have a __dict__ ivar that can store arbitrary
attributes. The wrapper can be reconstructed from the native object at
any time, and the native object may live longer than the wrapper if the
ObjC runtime retains it. Apart from this not guaranteeing object
identity on the Python side, as well as having to recreate the wrapper
when the object enters Python again, I don't see any immediate flaw. An
optimization would be to store a weakref to the wrapper in the native
object to avoid reconstruction of the wrapper. But it's just that: an
optimization.

Just

Re: [Pyobjc-dev] Bridging NSMutableString, a compromise

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

On Friday, Feb 7, 2003, at 22:31 Europe/Amsterdam, Just van Rossum 
wrote:
> Btw. I noticed PyObjC tries to sync the refcounts for both objects in
> class-builder.m's object_method_retain() and object_method_release()
> calls. Why is this needed?

This is for Python subclasses of Objective-C classes (and only those). 
Such instances have two parts, an Objective-C object and a Python 
object, that behave as if there is 1 object. Using 1 refcount for both 
parts is IMHO the only feaseable way to ensure that we don't end up 
with only one of the parts and that these objects are not immortal.

Getting this right was one of the hardest elements of my rewrite of 
PyObjC, and something that really should be documented...

Ronald

Re: [Pyobjc-dev] Bridging NSMutableString, a compromise

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

bb...@ma... wrote:

> Huh?

Sorry, I've assumed a different context. Although?

> The weakref idea was to take advantage of the callback that happens
> when the object is finalized such that the object could be
> 'unbridged'.

What is 'unbridged'?

Here's how I see how it should work:

                    |
       runtime A    |    runtime B
                    |
    nativeObject ------> wrappedObject (contains a strong ref to
                    |                   nativeObject)
                    |

I see no need for nativeObject to have a ref to the wrapped object, so
there are no cycles and no need for weak refs.

The only place where this goes wrong is when runtime B stores a
reference without retaining it, hence my assumption.

> If we can receive notification from Python of when the
> Python side of the bridge is done with the PyString, the bridging of
> the NSString<->PyString can be broken, the NSString side of things
> can leave on in its unbridged state, and nothing gets lost.

This seems awfully convoluted and error prone. Can you clarify why this
is needed?

Btw. I noticed PyObjC tries to sync the refcounts for both objects in
class-builder.m's object_method_retain() and object_method_release()
calls. Why is this needed?

Just

Re: [Pyobjc-dev] Bridging NSMutableString, a compromise

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

On Friday, Feb 7, 2003, at 21:53 Europe/Amsterdam, bb...@ma... wrote:

> On Friday, Feb 7, 2003, at 15:29 US/Eastern, Just van Rossum wrote:
>> We're making this way to hard for ourselves. This weakref idea is an
>> attempt to try to hide a flaw in Cocoa (that some objects don't incref
>> an object while still storing a reference; it's a poor man's weak ref
>> scheme and it sucks). It will be hard to do right. It is easy to work
>> around in Python code. Let's make it a FAQ and move on.
>
> Huh?
>
> The weakref idea was to take advantage of the callback that happens 
> when the object is finalized such that the object could be 
> 'unbridged'.   If we can receive notification from Python of when the 
> Python side of the bridge is done with the PyString, the bridging of 
> the NSString<->PyString can be broken, the NSString side of things can 
> leave on in its unbridged state, and nothing gets lost.

I'm not entirely sure what you mean here. Do you want to create a 
NSString subclass for proxying Python strings that somehow goes in 
'native' mode if Python code no longer references the string? I think 
that this adds unnecessary complicated code to the bridge.

Is someone working on the subclass of unicode as propased by Just? 
Having an initial version of this would get us going forward again, the 
current discussion seems to center around misunderstandings :-).

Ronald

Re: [Pyobjc-dev] Bridging NSMutableString, a compromise

[Guido v. R. <gu...@py...>]

Folks, I have no bandwidth left this week.  Sorry.  Maybe when you
need an *action* from me, Just can send a short note?  (I notice Bill
is a bit more verbose than Just.  I read short notes quicker. :-)

--Guido van Rossum (home page: http://www.python.org/~guido/)