pyobjc-dev

[Pyobjc-dev] NSCoding support for python list & dict

[Barry W. <bar...@gm...>]

PyObjC2 now raises an exception if one tries to encode a python list
or dict instance using an NSCoder. I agree that this behavior is
preferable to letting the action proceed silently. I'm wondering why
PyObjC doesn't encode a list as if it were an NSMutableArray and a
dict as if it were an NSMutableDictionary, however. One of our apps
does a lot encoding of dictionaries created in python plugins.
Converting these dicts to NSDictionaries via
NSDictionary.dictionaryFromDictionary_ is fine, but seems to be a
glaring special case of the otherwise seemless bridge. If I can treat
python dicts as NSMutableDictionaries on the Objective-C side, why
can't I encode them as such? Scanning the NEWS file, I see that this
is mentioned, but I haven't found the rationale.

Please understand I'm not trying to disparage the amazing work that
the PyObjC devs have done on PyObjC2. I'm just posing the question to
either understand the technical reason(s) behind the decision or raise
some discussion on other options.

Thanks,
Barry

Re: [Pyobjc-dev] NSCoding support for python list & dict

[Ronald O. <ron...@ma...>]

On 26 Nov, 2007, at 21:35, Barry Wark wrote:

> PyObjC2 now raises an exception if one tries to encode a python list
> or dict instance using an NSCoder. I agree that this behavior is
> preferable to letting the action proceed silently. I'm wondering why
> PyObjC doesn't encode a list as if it were an NSMutableArray and a
> dict as if it were an NSMutableDictionary, however. One of our apps
> does a lot encoding of dictionaries created in python plugins.
> Converting these dicts to NSDictionaries via
> NSDictionary.dictionaryFromDictionary_ is fine, but seems to be a
> glaring special case of the otherwise seemless bridge. If I can treat
> python dicts as NSMutableDictionaries on the Objective-C side, why
> can't I encode them as such? Scanning the NEWS file, I see that this
> is mentioned, but I haven't found the rationale.
>
> Please understand I'm not trying to disparage the amazing work that
> the PyObjC devs have done on PyObjC2. I'm just posing the question to
> either understand the technical reason(s) behind the decision or raise
> some discussion on other options.

Good point. I'd like to add full NSCoding support for all python  
objects (or at least all pickle-able objects) in the future, but  
supporting just lists/tuples/dicts should be easy enough to do.

NSCoding support for other objects should also be doable, but is more  
work and requires a lot of testing. Pickling Objective-C objects on  
the other hand has the outlooks of being a very hard problem.

Anyhow, the most likely reason for missing features like this is me  
not having time to work on them. Knowing which features are helpfull  
for real applications, rather than just looking nice on a list of  
features, helps prioritizing development. So, thanks for the feedback.

Ronald
>
>
> Thanks,
> Barry
>
> -------------------------------------------------------------------------
> This SF.net email is sponsored by: Microsoft
> Defy all challenges. Microsoft(R) Visual Studio 2005.
> http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
> _______________________________________________
> Pyobjc-dev mailing list
> Pyo...@li...
> https://lists.sourceforge.net/lists/listinfo/pyobjc-dev

Re: [Pyobjc-dev] NSCoding support for python list & dict

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

On Nov 26, 2007, at 9:59 PM, Ronald Oussoren wrote:
> NSCoding support for other objects should also be doable, but is  
> more work and requires a lot of testing. Pickling Objective-C  
> objects on the other hand has the outlooks of being a very hard  
> problem.

NSArchiver and NSKeyedArchiver support arbitrary archival of objects.   
That is, you can create an archiving session and then archive the sub- 
graphs of objects of objects in arbitrary order and with arbitrary  
references between the subgraphs.

Pickling of a graph containing a mix of Python and Objective-C objects  
could be done by creating a UUID for each object in the graph at the  
pickle/archiver boundary.  The UUID could be stored in the pickle,  
could be used to archive the sub-graph of Objective-C objects and  
store 'em away via -encodeObject:forKey:, and then the resulting BLOB  
of archived Objective-C data could be stored in the pickle as a  
<string>.

Completely trivial, right?

Only because of my ignorance.   There is a definite chicken-and-egg  
problem in that archival will produce the archived obj-c objects  
*last* whereas unarchival will need them to be decoded *first*.   And  
that is just scratching the surface.

b.bum

Re: [Pyobjc-dev] NSCoding support for python list & dict

[Ronald O. <ron...@ma...>]

 
On Tuesday, November 27, 2007, at 08:56AM, "Bill Bumgarner" <bb...@ma...> wrote:
>On Nov 26, 2007, at 9:59 PM, Ronald Oussoren wrote:
>> NSCoding support for other objects should also be doable, but is  
>> more work and requires a lot of testing. Pickling Objective-C  
>> objects on the other hand has the outlooks of being a very hard  
>> problem.
>
>NSArchiver and NSKeyedArchiver support arbitrary archival of objects.   
>That is, you can create an archiving session and then archive the sub- 
>graphs of objects of objects in arbitrary order and with arbitrary  
>references between the subgraphs.
>
>Pickling of a graph containing a mix of Python and Objective-C objects  
>could be done by creating a UUID for each object in the graph at the  
>pickle/archiver boundary.  The UUID could be stored in the pickle,  
>could be used to archive the sub-graph of Objective-C objects and  
>store 'em away via -encodeObject:forKey:, and then the resulting BLOB  
>of archived Objective-C data could be stored in the pickle as a  
><string>.
>
>Completely trivial, right?

At first glance that doesn't quite fit into the pickle interface, but could be made to work using a class/function on top of pickle that does the work.

Dealing with cycles and object-identity will be interesting though (e.g. pickle.dumps([O, NSArray.arrayWithArray_([O])]), where O is a pure Python object (or even (O=[]; A=NSArray.arrayWithArray_([O]); O.append(A); pickle.dumps([O,A]).

The other way around (adding NSCoding support to Python objects) is easy: just call __getstate__/__reduce__ to get object state, then use encodeObject:forKey: to write that, more basic, object to the stream.

>
>Only because of my ignorance.   There is a definite chicken-and-egg  
>problem in that archival will produce the archived obj-c objects  
>*last* whereas unarchival will need them to be decoded *first*.   And  
>that is just scratching the surface.

What might work: implement __reduce__ for objc.objc_object using a custom NSCoder subclass that builds a python datastructure containing the object state, then let the pickle machinery serialize that. That is, encodeObject:forKey: would add the object to a dictionary. At some point the object state must be some basic object, such as C integers, which pickle can encode without further recursion.

I know this is a bit vague, I made this up while typing this e-mail. It does look like something that can be made to work though.

Volunteers?

Ronald
>
>b.bum
>
>-------------------------------------------------------------------------
>This SF.net email is sponsored by: Microsoft
>Defy all challenges. Microsoft(R) Visual Studio 2005.
>http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
>_______________________________________________
>Pyobjc-dev mailing list
>Pyo...@li...
>https://lists.sourceforge.net/lists/listinfo/pyobjc-dev
>
>

Re: [Pyobjc-dev] NSCoding support for python list & dict

[Barry W. <bar...@gm...>]

I don't think I have the chops to pull off the pickling of Objective-C
objects. It seems that we might be able to encode list and dict types
however by just calling [super encode...] from their OC_PythonXX
wrappers. Unless one of the gurus thinks that's a stupid idea, I will
give it a try.

Barry

On 11/27/07, Ronald Oussoren <ron...@ma...> wrote:
>
> On Tuesday, November 27, 2007, at 08:56AM, "Bill Bumgarner" <bb...@ma...> wrote:
> >On Nov 26, 2007, at 9:59 PM, Ronald Oussoren wrote:
> >> NSCoding support for other objects should also be doable, but is
> >> more work and requires a lot of testing. Pickling Objective-C
> >> objects on the other hand has the outlooks of being a very hard
> >> problem.
> >
> >NSArchiver and NSKeyedArchiver support arbitrary archival of objects.
> >That is, you can create an archiving session and then archive the sub-
> >graphs of objects of objects in arbitrary order and with arbitrary
> >references between the subgraphs.
> >
> >Pickling of a graph containing a mix of Python and Objective-C objects
> >could be done by creating a UUID for each object in the graph at the
> >pickle/archiver boundary.  The UUID could be stored in the pickle,
> >could be used to archive the sub-graph of Objective-C objects and
> >store 'em away via -encodeObject:forKey:, and then the resulting BLOB
> >of archived Objective-C data could be stored in the pickle as a
> ><string>.
> >
> >Completely trivial, right?
>
> At first glance that doesn't quite fit into the pickle interface, but could be made to work using a class/function on top of pickle that does the work.
>
> Dealing with cycles and object-identity will be interesting though (e.g. pickle.dumps([O, NSArray.arrayWithArray_([O])]), where O is a pure Python object (or even (O=[]; A=NSArray.arrayWithArray_([O]); O.append(A); pickle.dumps([O,A]).
>
> The other way around (adding NSCoding support to Python objects) is easy: just call __getstate__/__reduce__ to get object state, then use encodeObject:forKey: to write that, more basic, object to the stream.
>
> >
> >Only because of my ignorance.   There is a definite chicken-and-egg
> >problem in that archival will produce the archived obj-c objects
> >*last* whereas unarchival will need them to be decoded *first*.   And
> >that is just scratching the surface.
>
> What might work: implement __reduce__ for objc.objc_object using a custom NSCoder subclass that builds a python datastructure containing the object state, then let the pickle machinery serialize that. That is, encodeObject:forKey: would add the object to a dictionary. At some point the object state must be some basic object, such as C integers, which pickle can encode without further recursion.
>
> I know this is a bit vague, I made this up while typing this e-mail. It does look like something that can be made to work though.
>
> Volunteers?
>
> Ronald
> >
> >b.bum
> >
> >-------------------------------------------------------------------------
> >This SF.net email is sponsored by: Microsoft
> >Defy all challenges. Microsoft(R) Visual Studio 2005.
> >http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
> >_______________________________________________
> >Pyobjc-dev mailing list
> >Pyo...@li...
> >https://lists.sourceforge.net/lists/listinfo/pyobjc-dev
> >
> >
>
> -------------------------------------------------------------------------
> This SF.net email is sponsored by: Microsoft
> Defy all challenges. Microsoft(R) Visual Studio 2005.
> http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
> _______________________________________________
> Pyobjc-dev mailing list
> Pyo...@li...
> https://lists.sourceforge.net/lists/listinfo/pyobjc-dev
>