Thread: [Pyobjc-dev] Structs, tuples and instances
Brought to you by:
ronaldoussoren
Menu
▾
▴
pyobjc-dev
|
From: Dinu G. <gh...@da...> - 2003-10-30 09:35:57
|
Hi,
I'm trying to fake some kind of a solution which is more struct-like
than plain Python tuples for things like NSPoint, NSSize, etc. Here's
a simple one:
class NSPoint:
"""An experimental NSPoint class/struct hybrid.
This is supposed to be usable with attribute names
as well as indices.
"""
def __init__(self, x, y):
self.x, self.y = x, y
def __getitem__(self, index):
assert index in (0, 1)
return (self.x, self.y)[index]
def __setitem__(self, index, value):
assert index in (0, 1)
setattr(self, "xy"[index], value)
Doing anything like the following:
view = NSView.alloc().init()
#origin = (10, 20)
origin = NSPoint(10, 20)
origin.x = 11
origin[1] = 22
print origin[0], origin[1]
print origin.x, origin.y
view.setFrameOrigin_(origin)
then gives me a "ValueError: depythonifying 'struct', got 'instance'"
on the last line, so I assume the background checks test for the type
of the argument and reject an instance.
What about testing only for __getitem__ and __len__? Then, I could
probably really use the type of hack above, which would make a cer-
tain kind of code much more readable?
Dinu
--
Dinu C. Gherman - http://python.net/~gherman
......................................................................
"I never apologize for the United States of America, I don't care what
the facts are." (George Bush, Sr.)
|
|
From: Ronald O. <ous...@ci...> - 2003-10-30 10:12:46
|
This should work better with current CVS version, that uses PySequence_Fast instead of requireing a tuple. Ronald |
|
From: Dinu G. <gh...@da...> - 2003-10-30 10:34:48
|
Ronald Oussoren: > This should work better with current CVS version, that uses > PySequence_Fast instead of requireing a tuple. Is it supposed to compile right now? I'm getting the following below. Or maybe I need a fresh libffi? Dinu ... gcc -bundle -bundle_loader /usr/bin/python build/temp.darwin-6.8-Power_Macintosh-2.2/_AppKit.o -o build/lib.darwin-6.8-Power_Macintosh-2.2/AppKit/_AppKit.so -framework CoreFoundation -framework AppKit ld: Undefined symbols: _PyInt_AsUnsignedLongMask error: command 'gcc' failed with exit status 1 |
|
From: Ronald O. <ous...@ci...> - 2003-10-30 10:59:05
|
On 30 okt 2003, at 11:35, Dinu Gherman wrote: > Ronald Oussoren: > >> This should work better with current CVS version, that uses >> PySequence_Fast instead of requireing a tuple. > > Is it supposed to compile right now? I'm getting the following > below. Or maybe I need a fresh libffi? > > Dinu > > ... > gcc -bundle -bundle_loader /usr/bin/python > build/temp.darwin-6.8-Power_Macintosh-2.2/_AppKit.o -o > build/lib.darwin-6.8-Power_Macintosh-2.2/AppKit/_AppKit.so -framework > CoreFoundation -framework AppKit > ld: Undefined symbols: > _PyInt_AsUnsignedLongMask > error: command 'gcc' failed with exit status 1 I noticed that too :-( Bob introduced a Python2.3-ism when he added support for OpenGL. It works with Python 2.3 and after my next checkin it will also work with 2.2 again. Ronald |
|
From: Dinu G. <gh...@da...> - 2003-10-30 11:02:40
|
Ronald Oussoren: > I noticed that too :-( Bob introduced a Python2.3-ism when he added > support for OpenGL. It works with Python 2.3 and after my next checkin > it will also work with 2.2 again. Thanks, please let us know when it should work again! Dinu -- Dinu C. Gherman - http://python.net/~gherman ...................................................................... "They that can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety." (Benjamin Franklin) |
|
From: Ronald O. <ous...@ci...> - 2003-10-30 15:34:24
|
On 30 okt 2003, at 12:02, Dinu Gherman wrote: > Ronald Oussoren: > >> I noticed that too :-( Bob introduced a Python2.3-ism when he added >> support for OpenGL. It works with Python 2.3 and after my next checkin >> it will also work with 2.2 again. > > Thanks, please let us know when it should work again! I've just checked in some fixes, including the one mentioned above. Ronald |
|
From: Bob I. <bo...@re...> - 2003-10-30 16:08:54
|
On Oct 30, 2003, at 10:34, Ronald Oussoren wrote:
> On 30 okt 2003, at 12:02, Dinu Gherman wrote:
>
>> Ronald Oussoren:
>>
>>> I noticed that too :-( Bob introduced a Python2.3-ism when he added
>>> support for OpenGL. It works with Python 2.3 and after my next
>>> checkin
>>> it will also work with 2.2 again.
>>
>> Thanks, please let us know when it should work again!
>
> I've just checked in some fixes, including the one mentioned above.
Yeah, sorry about that. I intended to fix it myself, but I didn't
think that many people were still using 2.2 so I figured it'd be ok for
a day or two. Why haven't you upgraded to 2.3, Dinu?
Also, back to the NSPoint thing.. how come you don't just use a list
subclass? Just put x and y descriptors on it:
class NSPoint(list):
def __init__(self, v=(0., 0.)):
list.__init__(self, v)
assert len(self) == 2
x = property(lambda s:s[0], lambda s,v: s.__setitem__(0,v))
y = property(lambda s:s[1], lambda s,v: s.__setitem__(1,v))
-bob
|
|
From: Dinu G. <gh...@da...> - 2003-10-30 16:14:32
|
Ronald Oussoren: > I've just checked in some fixes, including the one mentioned above. Well, I still get the following error below using Python 2.2.3 and libffi-src-20030921.tar.gz. On SF.net I see another snapshot of libffi: gcc-libffisnapshot20030705-patched.tar.gz but haven't tried it in the absence of any information about it. Dinu ... In file included from Modules/AppKit/_AppKit.m:627: Modules/AppKit/_AppKitMapping_NSOpenGLPixelFormat.m: In function `call_NSOpenGLPixelFormat_initWithAttributes_': Modules/AppKit/_AppKitMapping_NSOpenGLPixelFormat.m:43: warning: implicit declaration of function `PyInt_AsUnsignedLongMask' gcc -bundle -bundle_loader /usr/bin/python build/temp.darwin-6.8-Power_Macintosh-2.2/_AppKit.o -o build/lib.darwin-6.8-Power_Macintosh-2.2/AppKit/_AppKit.so -framework CoreFoundation -framework AppKit ld: Undefined symbols: _PyInt_AsUnsignedLongMask error: command 'gcc' failed with exit status 1 |
|
From: Jack J. <Jac...@cw...> - 2003-10-31 10:54:40
|
On 30 Oct 2003, at 10:36, Dinu Gherman wrote: > Hi, > > I'm trying to fake some kind of a solution which is more struct-like > than plain Python tuples for things like NSPoint, NSSize, etc. Here's > a simple one: > > class NSPoint: I don't have a real reason for it, but my gut feeling is that the Pythonic way to do this is the other way around: use a list as the baseclass, and subclass that. Actually, what you really want (I think) is something based on structmember, but I don't know whether that allows read/write access, and whether it's available from Python code. Hmm, even if it isn't available from Python the objc core could make it available. Using structmember for the various toolbox structures is something that's also on my to-do list, but I haven't done anything about it yet so I don't know how feasible this approach is. -- Jack Jansen <Jac...@cw...> http://www.cwi.nl/~jack If I can't dance I don't want to be part of your revolution -- Emma Goldman |
|
From: Michael H. <mw...@py...> - 2003-10-31 11:28:15
|
Jack Jansen <Jac...@cw...> writes:
> On 30 Oct 2003, at 10:36, Dinu Gherman wrote:
>
>> Hi,
>>
>> I'm trying to fake some kind of a solution which is more struct-like
>> than plain Python tuples for things like NSPoint, NSSize, etc.
This I can certainly sympathise with; I have some code like
v1.setFrameOrigin_((0, v2.frame()[0][1] + v3.frame()[1][1]))
which isn't especially clear.
>> Here's a simple one:
>>
>> class NSPoint:
>
> I don't have a real reason for it, but my gut feeling is that the
> Pythonic way to do this is the other way around: use a list as the
> baseclass, and subclass that.
Sounds reasonable.
> Actually, what you really want (I think)
> is something based on structmember, but I don't know whether that
> allows read/write access,
Yes.
> and whether it's available from Python code.
No.
> Hmm, even if it isn't available from Python the objc core could make
> it available. Using structmember for the various toolbox structures is
> something that's also on my to-do list, but I haven't done anything
> about it yet so I don't know how feasible this approach is.
Well, I think the modern way is to define tp_members (think it's that
one) which uses structmember under the hood rather than using
structmember directly.
I'm not sure what "available from Python" would really mean in this
context.
Cheers,
mwh
--
The only problem with Microsoft is they just have no taste.
-- Steve Jobs, (From _Triumph of the Nerds_ PBS special)
and quoted by Aahz on comp.lang.python
|
|
From: Ronald O. <ous...@ci...> - 2003-10-31 12:43:25
|
On 31 okt 2003, at 11:54, Jack Jansen wrote:
>
> On 30 Oct 2003, at 10:36, Dinu Gherman wrote:
>
>> Hi,
>>
>> I'm trying to fake some kind of a solution which is more struct-like
>> than plain Python tuples for things like NSPoint, NSSize, etc. Here's
>> a simple one:
>>
>> class NSPoint:
>
> I don't have a real reason for it, but my gut feeling is that the
> Pythonic way to do this is the other way around: use a list as the
> baseclass, and subclass that. Actually, what you really want (I think)
> is something based on structmember, but I don't know whether that
> allows read/write access, and whether it's available from Python code.
>
> Hmm, even if it isn't available from Python the objc core could make
> it available. Using structmember for the various toolbox structures is
> something that's also on my to-do list, but I haven't done anything
> about it yet so I don't know how feasible this approach is.
Do you mean the new PyStructSequence_Type as used by os.stat and
time.localtime? Those "structures" are (sadly) read-only. I'm thinking
of adding a generic method for creating struct-like types, which could
then be used to define NSPoint, NSRect, ... as a type.
Something like this:
def struct_type(name, signature, *fieldnames):
"""
implemented in C, return a new type
the signature is used to type-check assignments, could be left out.
"""
pass
NSPoint = objc.struct_type("NSPoint", "{_NSPoint=ff}", "x", "y")
val = NSPoint(1.0, 2.0)
x = val.x
x = val[0]
y = val.y
y = val[1]
val.x = 2.0
val[1] = 3
There would also be a C-level API for creating types and instances of
it, this would be used to make sure that ObjC API's returning an
NSPoint would actually create an instance of the NSPoint type defined
earlier, instead of a tuple.
Ronald
> --
> Jack Jansen <Jac...@cw...> http://www.cwi.nl/~jack
> If I can't dance I don't want to be part of your revolution -- Emma
> Goldman
>
>
>
> -------------------------------------------------------
> This SF.net email is sponsored by: SF.net Giveback Program.
> Does SourceForge.net help you be more productive? Does it
> help you create better code? SHARE THE LOVE, and help us help
> YOU! Click Here: http://sourceforge.net/donate/
> _______________________________________________
> Pyobjc-dev mailing list
> Pyo...@li...
> https://lists.sourceforge.net/lists/listinfo/pyobjc-dev
>
|
|
From: Michael H. <mw...@py...> - 2003-10-31 14:14:12
|
Ronald Oussoren <ous...@ci...> writes: > On 31 okt 2003, at 11:54, Jack Jansen wrote: > >> Hmm, even if it isn't available from Python the objc core could make >> it available. Using structmember for the various toolbox structures >> is something that's also on my to-do list, but I haven't done >> anything about it yet so I don't know how feasible this approach is. > > Do you mean the new PyStructSequence_Type as used by os.stat and > time.localtime? Ah, that would be more likely than what he actually said :-) > Those "structures" are (sadly) read-only. I'm thinking of ... If you do do something about this, it might be worth offering a patch to Python itself; tcgetattr at least could use such functionality. Cheers, mwh -- I'm not particularly fond of singing GSTQ because she stands for some things I don't, but it's not really worth letting politics getting in the way of a good bawling. -- Dan Sheppard, ucam.chat |
|
From: Jack J. <Jac...@cw...> - 2003-10-31 16:19:31
|
On 31 Oct 2003, at 15:14, Michael Hudson wrote: > Ronald Oussoren <ous...@ci...> writes: > >> On 31 okt 2003, at 11:54, Jack Jansen wrote: >> >>> Hmm, even if it isn't available from Python the objc core could make >>> it available. Using structmember for the various toolbox structures >>> is something that's also on my to-do list, but I haven't done >>> anything about it yet so I don't know how feasible this approach is. >> >> Do you mean the new PyStructSequence_Type as used by os.stat and >> time.localtime? > > Ah, that would be more likely than what he actually said :-) Right:-) >> Those "structures" are (sadly) read-only. I'm thinking of ... > > If you do do something about this, it might be worth offering a patch > to Python itself; tcgetattr at least could use such functionality. I'd love that... As I said I could put it to good use for the various Mac toolbox objects. -- Jack Jansen <Jac...@cw...> http://www.cwi.nl/~jack If I can't dance I don't want to be part of your revolution -- Emma Goldman |
|
From: Bob I. <bo...@re...> - 2003-10-31 16:31:03
|
On Oct 31, 2003, at 11:19 AM, Jack Jansen wrote: > > On 31 Oct 2003, at 15:14, Michael Hudson wrote: > >> Ronald Oussoren <ous...@ci...> writes: >> >>> On 31 okt 2003, at 11:54, Jack Jansen wrote: >>> >>>> Hmm, even if it isn't available from Python the objc core could make >>>> it available. Using structmember for the various toolbox structures >>>> is something that's also on my to-do list, but I haven't done >>>> anything about it yet so I don't know how feasible this approach is. >>> >>> Do you mean the new PyStructSequence_Type as used by os.stat and >>> time.localtime? >> >> Ah, that would be more likely than what he actually said :-) > > Right:-) > >>> Those "structures" are (sadly) read-only. I'm thinking of ... >> >> If you do do something about this, it might be worth offering a patch >> to Python itself; tcgetattr at least could use such functionality. > > I'd love that... As I said I could put it to good use for the various > Mac toolbox objects. While you're thinking about Mac toolbox objects, how about making FSSpec / FSRef / FSAlias easier to use? Personally, I think it would be killer if I could str(fsSpec) and get the utf8 path out of it (or unicode(fsSpec) and get the unicode path out of it). Thinking aloud here, I'm really liking the signatures. It allows me to fix PyObjC methods without recompiling (if I want to), and they're pretty easy to understand (after looking at a lot of them). I wish bgen wrapped modules had this kind of capability (but then we'd almost have ctypes). -bob |
|
From: Ronald O. <ous...@ci...> - 2003-10-31 17:07:15
|
On 31 okt 2003, at 17:30, Bob Ippolito wrote: > > On Oct 31, 2003, at 11:19 AM, Jack Jansen wrote: > >> >> On 31 Oct 2003, at 15:14, Michael Hudson wrote: >> >>> Ronald Oussoren <ous...@ci...> writes: >>> >>>> On 31 okt 2003, at 11:54, Jack Jansen wrote: >>>> >>>>> Hmm, even if it isn't available from Python the objc core could >>>>> make >>>>> it available. Using structmember for the various toolbox structures >>>>> is something that's also on my to-do list, but I haven't done >>>>> anything about it yet so I don't know how feasible this approach >>>>> is. >>>> >>>> Do you mean the new PyStructSequence_Type as used by os.stat and >>>> time.localtime? >>> >>> Ah, that would be more likely than what he actually said :-) >> >> Right:-) >> >>>> Those "structures" are (sadly) read-only. I'm thinking of ... >>> >>> If you do do something about this, it might be worth offering a patch >>> to Python itself; tcgetattr at least could use such functionality. >> >> I'd love that... As I said I could put it to good use for the various >> Mac toolbox objects. But such a patch would not be useable by PyObjC until Python 2.4 gets out :-(. That said, I'll work on such a patch. I will also work on a custom version for PyObjC ;-). > > While you're thinking about Mac toolbox objects, how about making > FSSpec / FSRef / FSAlias easier to use? Personally, I think it would > be killer if I could str(fsSpec) and get the utf8 path out of it (or > unicode(fsSpec) and get the unicode path out of it). > > Thinking aloud here, I'm really liking the signatures. It allows me > to fix PyObjC methods without recompiling (if I want to), and they're > pretty easy to understand (after looking at a lot of them). I wish > bgen wrapped modules had this kind of capability (but then we'd almost > have ctypes). But the signatures are used only because they are easily available at runtime and the implementation for all methods is basically the same. If you want to do the same for other frameworks/libararies you'd not *almost* have ctypes, but basically all of it. Ronald |
|
From: Ronald O. <ous...@ci...> - 2003-11-03 15:46:40
|
On 31 okt 2003, at 18:07, Ronald Oussoren wrote:
>>> I'd love that... As I said I could put it to good use for the
>>> various Mac toolbox objects.
>
> But such a patch would not be useable by PyObjC until Python 2.4 gets
> out :-(. That said, I'll work on such a patch. I will also work on a
> custom version for PyObjC ;-).
>
The patch for Python is easy enough, but there is one major downside of
this patch: writeable structseqs are not hashable, which makes it
impossible to use these objects as keys in dictionaries. Making them
hashable would be easy, it would even decrease the size of the patch,
but would make it possible to create invalid dicts:
d = {}
p = NSPoint(x=1, y=2)
d[p] = 1
p.x = 3
d[d.keys()[0]] will fail, as will d[NSPoint(x=3, y=2)] unless
NSPoint(1,2) happens to have the same hash as NSPoint(3,2).
A completely untested patch is included below, I haven't even tried to
compile this.
Ronald
Index: Include/structseq.h
===================================================================
RCS file: /cvsroot/python/python/dist/src/Include/structseq.h,v
retrieving revision 1.4
diff -c -r1.4 structseq.h
*** Include/structseq.h 17 Oct 2002 19:48:27 -0000 1.4
--- Include/structseq.h 3 Nov 2003 15:39:46 -0000
***************
*** 23,28 ****
--- 23,30 ----
PyAPI_FUNC(void) PyStructSequence_InitType(PyTypeObject *type,
PyStructSequence_Desc *desc);
+ PyAPI_FUNC(void) PyStructSequence_InitTypeRW(PyTypeObject *type,
+ PyStructSequence_Desc *desc);
PyAPI_FUNC(PyObject *) PyStructSequence_New(PyTypeObject* type);
Index: Objects/structseq.c
===================================================================
RCS file: /cvsroot/python/python/dist/src/Objects/structseq.c,v
retrieving revision 1.12
diff -c -r1.12 structseq.c
*** Objects/structseq.c 1 Feb 2003 02:16:37 -0000 1.12
--- Objects/structseq.c 3 Nov 2003 15:39:47 -0000
***************
*** 342,349 ****
structseq_new, /* tp_new */
};
! void
! PyStructSequence_InitType(PyTypeObject *type, PyStructSequence_Desc
*desc)
{
PyObject *dict;
PyMemberDef* members;
--- 342,349 ----
structseq_new, /* tp_new */
};
! static void
! _inittype(PyTypeObject* type, PyStructSequence_Desc* desc, int
readWrite)
{
PyObject *dict;
PyMemberDef* members;
***************
*** 373,384 ****
members[k].type = T_OBJECT;
members[k].offset = offsetof(PyStructSequence, ob_item)
+ i * sizeof(PyObject*);
! members[k].flags = READONLY;
members[k].doc = desc->fields[i].doc;
k++;
}
members[k].name = NULL;
type->tp_members = members;
if (PyType_Ready(type) < 0)
--- 373,393 ----
members[k].type = T_OBJECT;
members[k].offset = offsetof(PyStructSequence, ob_item)
+ i * sizeof(PyObject*);
!
! if (readWrite) {
! members[k].flags = 0;
! } else {
! members[k].flags = READONLY;
! }
members[k].doc = desc->fields[i].doc;
k++;
}
members[k].name = NULL;
+ if (readWrite) {
+ type->tp_hash = NULL;
+ }
+
type->tp_members = members;
if (PyType_Ready(type) < 0)
***************
*** 392,395 ****
--- 401,416 ----
PyInt_FromLong((long) n_members));
PyDict_SetItemString(dict, unnamed_fields_key,
PyInt_FromLong((long) n_unnamed_members));
+ }
+
+ void
+ PyStructSequence_InitType(PyTypeObject *type, PyStructSequence_Desc
*desc)
+ {
+ _inittype(type, desc, 0);
+ }
+
+ void
+ PyStructSequence_InitTypeRW(PyTypeObject *type, PyStructSequence_Desc
*desc)
+ {
+ _inittype(type, desc, 1);
}
|
|
From: Dinu G. <gh...@da...> - 2003-11-04 10:09:07
|
Ronald Oussoren: > The patch for Python is easy enough, but there is one major downside > of this patch: writeable structseqs are not hashable, which makes it > impossible to use these objects as keys in dictionaries. Making them > hashable would be easy, it would even decrease the size of the patch, > but would make it possible to create invalid dicts: I'm not sure why anybody would expect things like NSPoints, NSRects and NSSizes to be immutable? Being tuples in PyObjC adds a feature which has no equivalent in ObjC, isn't it? In fact, it prevents you from doing even point[0] = 1 not to mention point.x = 1... Perhaps immutability makes sense for other structs? I don't know of such examples, but maybe others do? Dinu -- Dinu C. Gherman - http://python.net/~gherman ...................................................................... "There are causes worth dying for, but none worth killing for." (Albert Camus) |
|
From: Ronald O. <ous...@ci...> - 2003-11-04 10:31:03
|
On 4 nov 2003, at 11:09, Dinu Gherman wrote: > Ronald Oussoren: > >> The patch for Python is easy enough, but there is one major downside >> of this patch: writeable structseqs are not hashable, which makes it >> impossible to use these objects as keys in dictionaries. Making them >> hashable would be easy, it would even decrease the size of the patch, >> but would make it possible to create invalid dicts: > > I'm not sure why anybody would expect things like NSPoints, NSRects > and NSSizes to be immutable? Being tuples in PyObjC adds a feature > which has no equivalent in ObjC, isn't it? In fact, it prevents you > from doing even point[0] = 1 not to mention point.x = 1... Tuples are commonly used to represent C-structs in Python. That is the only reason for using tuples to represent NSPoint as a tuple. As several people noticed, myrect[0][1] is a lot less readable than myrect.location.x, which is why structseq's would be usefull. Structseqs are backward compatible with tuples, and therefore immutable. I agree that immutability isn't very usefull, but it buys you one important feature: structseqs are useable as keys in dictionaries. Mutable structseqs would not be useable as dictionary keys, because such objects would not have a constant hash (and therefore should be unhashable) Does anyone use points, rects or sizes as the key in a dictionary? If not, we could change the representation of NSPoint, etc., to mutable structseq's (with a prominent notice in the release-notes for the next release, as this is a backward incompatible change). We could also add a hash function to mutable structseqs, with a note in the documentation that you shouldn't modify a mutable structseq object that is used as the key in a dictionary. None of the mutable types in the Python distribution seems to do this. Ronald |
|
From: Dinu G. <gh...@da...> - 2003-11-04 10:45:11
|
Ronald Oussoren: > I agree that immutability isn't very usefull, but it buys you one > important feature: structseqs are useable as keys in dictionaries. How much is that worth when dealing with elements which actually *are* and *should be* mutable? > Does anyone use points, rects or sizes as the key in a dictionary? My point of view is that doing this is a *bad idea* and the fact that you can do it now introduces a source of confusion because it advocates usage patterns in PyObjC which are not just some kind of a more Pythonic way of doing something, but introduce artificial and unnecessary differences between PyObjC and ObjC on a conceptual level, which must be something to minimize if technically possible. Dinu -- Dinu C. Gherman - http://python.net/~gherman ...................................................................... "The whole point of brainwashing, is that those being brainwashed don't know it." (Graham Haley) |
|
From: Bob I. <bo...@re...> - 2003-11-04 20:27:00
|
On Nov 4, 2003, at 5:45 AM, Dinu Gherman wrote: > Ronald Oussoren: > >> I agree that immutability isn't very usefull, but it buys you one >> important feature: structseqs are useable as keys in dictionaries. > > How much is that worth when dealing with elements which actually > *are* and *should be* mutable? > >> Does anyone use points, rects or sizes as the key in a dictionary? > > My point of view is that doing this is a *bad idea* and the fact > that you can do it now introduces a source of confusion because > it advocates usage patterns in PyObjC which are not just some > kind of a more Pythonic way of doing something, but introduce > artificial and unnecessary differences between PyObjC and ObjC > on a conceptual level, which must be something to minimize if > technically possible. I'm with Dinu on this. Although most of the structs passed around in ObjC seem to be passed by value and not by reference.. I'd still say that they're all mutable. If they want something immutable they can do tuple(structSeqObj) or some other kind of copy. I've never seen NSPoint, NSRect, etc. used as a dictionary key from PyObjC... in Objective C you can't even (directly) put them in any kind of collection b/c they are plain 'ol C structs so I don't see where anyone would get the idea to do it in Python. Personally, I'd like to see how these structseq's work out (anxiously waiting for a commit from Ronald!). Sounds like it might even be possible to use a more generic implementation as a general (and higher perforamance?) replacement for the struct module, at least when you're working in machine endian. For example, it would be a lot more elegant to use structseq to read mach-o headers, and try and rig the PyObjC generator scripts to autogenerate structseq definitions for me.. right now the mach-o structures are coded by hand by looking at structures in C header files as a reference and I am using a module I wrote called ptypes which does something similar (interface wise) to ctypes structures and base types, but ends up having to use the Python struct module to do the actual en/decoding (which is kinda wasteful and awkward). -bob |
|
From: Ronald O. <ous...@ci...> - 2003-11-04 22:12:39
|
On 4 nov 2003, at 21:26, Bob Ippolito wrote: > > Personally, I'd like to see how these structseq's work out (anxiously > waiting for a commit from Ronald!). That might take a while, the patch for python's structseq implementation is as far as I got. > Sounds like it might even be possible to use a more generic > implementation as a general (and higher perforamance?) replacement for > the struct module, at least when you're working in machine endian. > For example, it would be a lot more elegant to use structseq to read > mach-o headers, and try and rig the PyObjC generator scripts to > autogenerate structseq definitions for me.. right now the mach-o > structures are coded by hand by looking at structures in C header > files as a reference and I am using a module I wrote called ptypes > which does something similar (interface wise) to ctypes structures and > base types, but ends up having to use the Python struct module to do > the actual en/decoding (which is kinda wasteful and awkward). Structseqs as currently used by Python are just a tuple with named attributes that alias (some of) the items in the tuple, they cannot be used as a replacement for the struct module. My current idea for mutable structseqs in PyObjC is to use the same strategy, possibly enhanced with typechecking. The type-generator function will be exposed to Python. I could easily expose the functions for encoding/decoding Objective-C types to Python, which would help in creating a replacement for ptypes. Ronald |
|
From: Just v. R. <ju...@le...> - 2003-11-04 10:29:09
|
Ronald Oussoren wrote: > The patch for Python is easy enough, but there is one major downside > of this patch: writeable structseqs are not hashable, which makes it > impossible to use these objects as keys in dictionaries. Making them > hashable would be easy, it would even decrease the size of the patch, > but would make it possible to create invalid dicts: Under *no* circumstance this should be possible. If an object is hashable, it should be immutable. If this is not true, you're breaking a major dict invariant and you can't blame the user if things go wrong. For the same reason I think that pyobjc_unicode.syncFromNSString() is an extremely bad idea and should be removed. It's not even needed: if you work with an NSMutableString that actually mutates, you can get the up-to-date Python value with unicode(aMutableString.nsstring()). Just |
|
From: Ronald O. <ous...@ci...> - 2003-11-04 10:35:39
|
On 4 nov 2003, at 11:29, Just van Rossum wrote: > Ronald Oussoren wrote: > >> The patch for Python is easy enough, but there is one major downside >> of this patch: writeable structseqs are not hashable, which makes it >> impossible to use these objects as keys in dictionaries. Making them >> hashable would be easy, it would even decrease the size of the patch, >> but would make it possible to create invalid dicts: > > Under *no* circumstance this should be possible. If an object is > hashable, it should be immutable. If this is not true, you're breaking > a > major dict invariant and you can't blame the user if things go wrong. +1 > > For the same reason I think that pyobjc_unicode.syncFromNSString() is > an > extremely bad idea and should be removed. It's not even needed: if you > work with an NSMutableString that actually mutates, you can get the > up-to-date Python value with unicode(aMutableString.nsstring()). You've got a point. I'll add a deprication warning to syncFromNSString, and remove the method after the next release of PyObjC. I'd be surprised if anyone uses this method, maybe we can get away with removing it before the next release. Ronald |
×
Want the latest updates on software, tech news, and AI?
Get latest updates about software, tech news, and AI from SourceForge directly in your inbox once a month.
Thanks for helping keep SourceForge clean.
X