pyobjc-dev — CVS commit notices go here

Re: [Pyobjc-dev] Problem with pyObjC and Swift

[Wim L. <wi...@om...>]

On Thu, 30 Mar 2017 at 10:27 Georg Seifert <geo...@gm...> wrote:
> I have an app written in ObjectiveC. It allows loading plugins from third parties. Most of those are written in python, some in ObjectiveC. Now someone tries to write on in Swift. That plugin works as expected but all the python plugin don't work any more and crash the app. At least when the plugin is build with Xcode 8 and Swift 3. Compiling it on Xcode 7 (macOS 10.10) works fine. Running the Xcode 8 version on 10.10 crashes, too.
> 
> The app links agains the system python framework.
> 
> Anyone has knows anything about this?
> 
>  Thanks
>  Georg Seifert
> 
>  p.s. I get backtraces like this:
> 
>  Calling a method on an python object inheriting from NSObject
> 
>  #0      0x0000000100a56ed7 in ___lldb_unnamed_function679$$Python ()
>  #1      0x0000000100a584f1 in PyDict_SetItemString ()
>  #2      0x00000001098319a5 in PyObjCClass_CheckMethodList (
>  #3      0x0000000109832543 in ___lldb_unnamed_function453$$_objc.so ()
>  #4      0x0000000100aa3238 in ___lldb_unnamed_function1431$$Python ()
>  #5      0x0000000100aa9d8c in PyEval_EvalFrameEx ()


I recently ran into this same problem (I have an app that uses PyObjC, and elsewhere in the app --- code that never interacts with python --- there are some Swift classes). As far as I can tell, this is a bug in the ancient version of PyObjC that Apple ships: it fails to check for an exception return from PyObjCSelector_NewNative(), and crashes because that function can't handle some selectors registered by Swift. In my case the first problem it hits is a Swift extension on NSDictionary from libswiftFoundation.dylib.

Although this bug exists in PyObjC 2.5.1 (the version shipped with MacOSX as of 10.13.1), it looks like it was fixed as far back as PyObjC 3.x. 

Re: [Pyobjc-dev] doctest and PyObjC

[Just v. R. <jus...@gm...>]

That’s fantastic news, thank you. I’ll keep an eye on the release.

Just


> On 04 Feb 2018, at 12:29, Ronald Oussoren <ron...@ma...> wrote:
> 
> I’ve just pushed a fix to the repository. I’m hoping to push out a new release next weekend.
> 
> There is no workaround for the issue other than patching PyObjC: In Lib/objc/_convenience.py remove the @register decorator from makeBundleForClass. I had hoped that there’d be a cleaner workaround, but that workaround caused a hard crash (also fixed in the repository).
> 
> Ronald
> 
> 
> 
>> On 28 Jan 2018, at 19:28, Ronald Oussoren <ron...@ma...> wrote:
>> 
>> 
>> 
>>> On 6 Jan 2018, at 20:39, Just van Rossum <jus...@gm...> wrote:
>>> 
>>> Hello,
>>> 
>>> I’m having trouble with integrating PyObjC and doctest. Whenever a module contains an NSObject subclass, the doctest test discovery code fails like so:
>>> 
>>> 
>>> Traceback (most recent call last):
>>> File "Lib/typemachine/ui/appDelegate.py", line 54, in <module>
>>>   doctest.testmod()
>>> File "/Library/Frameworks/Python.framework/Versions/3.6/lib/python3.6/doctest.py", line 1950, in testmod
>>>   for test in finder.find(m, name, globs=globs, extraglobs=extraglobs):
>>> File "/Library/Frameworks/Python.framework/Versions/3.6/lib/python3.6/doctest.py", line 933, in find
>>>   self._find(tests, obj, name, module, source_lines, globs, {})
>>> File "/Library/Frameworks/Python.framework/Versions/3.6/lib/python3.6/doctest.py", line 996, in _find
>>>   globs, seen)
>>> File "/Library/Frameworks/Python.framework/Versions/3.6/lib/python3.6/doctest.py", line 1027, in _find
>>>   self._from_module(module, val)):
>>> File "/Library/Frameworks/Python.framework/Versions/3.6/lib/python3.6/doctest.py", line 954, in _from_module
>>>   obj_mod = object.__objclass__.__module__
>>> AttributeError: 'NoneType' object has no attribute ‘__module__'
>>> 
>>> 
>>> Simplest way to reproduce:
>>> 
>>> =========
>>> from Foundation import NSObject
>>> 
>>> class Foo(NSObject):
>>>   pass
>>> 
>>> import doctest
>>> doctest.testmod()
>>> =========
>>> 
>>> I can’t judge whether this is a bug in doctest or in PyObjC.
>>> 
>>> Is there a workaround?
>>> 
>>> My problem is not so much that I can’t use doctest in NSObject subclasses, but rather that test discovery fails in general in the vicinity of PyObjC code. For example, I can’t use pytest’s test discovery at all: it simply fails any module that contains an NSObject subclass.
>>> 
>>> Thanks for any insights,
>> 
>> This appears to be a bug. I don’t have a workaround yet, but am investigating.
>> 
>> Ronald
>> 
>> 
>> ------------------------------------------------------------------------------
>> Check out the vibrant tech community on one of the world's most
>> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
>> _______________________________________________
>> Pyobjc-dev mailing list
>> Pyo...@li...
>> https://lists.sourceforge.net/lists/listinfo/pyobjc-dev
> 

Re: [Pyobjc-dev] doctest and PyObjC

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

I’ve just pushed a fix to the repository. I’m hoping to push out a new release next weekend.

There is no workaround for the issue other than patching PyObjC: In Lib/objc/_convenience.py remove the @register decorator from makeBundleForClass. I had hoped that there’d be a cleaner workaround, but that workaround caused a hard crash (also fixed in the repository).

Ronald



> On 28 Jan 2018, at 19:28, Ronald Oussoren <ron...@ma...> wrote:
> 
> 
> 
>> On 6 Jan 2018, at 20:39, Just van Rossum <jus...@gm...> wrote:
>> 
>> Hello,
>> 
>> I’m having trouble with integrating PyObjC and doctest. Whenever a module contains an NSObject subclass, the doctest test discovery code fails like so:
>> 
>> 
>> Traceback (most recent call last):
>> File "Lib/typemachine/ui/appDelegate.py", line 54, in <module>
>>   doctest.testmod()
>> File "/Library/Frameworks/Python.framework/Versions/3.6/lib/python3.6/doctest.py", line 1950, in testmod
>>   for test in finder.find(m, name, globs=globs, extraglobs=extraglobs):
>> File "/Library/Frameworks/Python.framework/Versions/3.6/lib/python3.6/doctest.py", line 933, in find
>>   self._find(tests, obj, name, module, source_lines, globs, {})
>> File "/Library/Frameworks/Python.framework/Versions/3.6/lib/python3.6/doctest.py", line 996, in _find
>>   globs, seen)
>> File "/Library/Frameworks/Python.framework/Versions/3.6/lib/python3.6/doctest.py", line 1027, in _find
>>   self._from_module(module, val)):
>> File "/Library/Frameworks/Python.framework/Versions/3.6/lib/python3.6/doctest.py", line 954, in _from_module
>>   obj_mod = object.__objclass__.__module__
>> AttributeError: 'NoneType' object has no attribute ‘__module__'
>> 
>> 
>> Simplest way to reproduce:
>> 
>> =========
>> from Foundation import NSObject
>> 
>> class Foo(NSObject):
>>   pass
>> 
>> import doctest
>> doctest.testmod()
>> =========
>> 
>> I can’t judge whether this is a bug in doctest or in PyObjC.
>> 
>> Is there a workaround?
>> 
>> My problem is not so much that I can’t use doctest in NSObject subclasses, but rather that test discovery fails in general in the vicinity of PyObjC code. For example, I can’t use pytest’s test discovery at all: it simply fails any module that contains an NSObject subclass.
>> 
>> Thanks for any insights,
> 
> This appears to be a bug. I don’t have a workaround yet, but am investigating.
> 
> Ronald
> 
> 
> ------------------------------------------------------------------------------
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> _______________________________________________
> Pyobjc-dev mailing list
> Pyo...@li...
> https://lists.sourceforge.net/lists/listinfo/pyobjc-dev

Re: [Pyobjc-dev] doctest and PyObjC

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

> On 6 Jan 2018, at 20:39, Just van Rossum <jus...@gm...> wrote:
> 
> Hello,
> 
> I’m having trouble with integrating PyObjC and doctest. Whenever a module contains an NSObject subclass, the doctest test discovery code fails like so:
> 
> 
> Traceback (most recent call last):
>  File "Lib/typemachine/ui/appDelegate.py", line 54, in <module>
>    doctest.testmod()
>  File "/Library/Frameworks/Python.framework/Versions/3.6/lib/python3.6/doctest.py", line 1950, in testmod
>    for test in finder.find(m, name, globs=globs, extraglobs=extraglobs):
>  File "/Library/Frameworks/Python.framework/Versions/3.6/lib/python3.6/doctest.py", line 933, in find
>    self._find(tests, obj, name, module, source_lines, globs, {})
>  File "/Library/Frameworks/Python.framework/Versions/3.6/lib/python3.6/doctest.py", line 996, in _find
>    globs, seen)
>  File "/Library/Frameworks/Python.framework/Versions/3.6/lib/python3.6/doctest.py", line 1027, in _find
>    self._from_module(module, val)):
>  File "/Library/Frameworks/Python.framework/Versions/3.6/lib/python3.6/doctest.py", line 954, in _from_module
>    obj_mod = object.__objclass__.__module__
> AttributeError: 'NoneType' object has no attribute ‘__module__'
> 
> 
> Simplest way to reproduce:
> 
> =========
> from Foundation import NSObject
> 
> class Foo(NSObject):
>    pass
> 
> import doctest
> doctest.testmod()
> =========
> 
> I can’t judge whether this is a bug in doctest or in PyObjC.
> 
> Is there a workaround?
> 
> My problem is not so much that I can’t use doctest in NSObject subclasses, but rather that test discovery fails in general in the vicinity of PyObjC code. For example, I can’t use pytest’s test discovery at all: it simply fails any module that contains an NSObject subclass.
> 
> Thanks for any insights,

This appears to be a bug. I don’t have a workaround yet, but am investigating.

Ronald

[Pyobjc-dev] doctest and PyObjC

[Just v. R. <jus...@gm...>]

Hello,

I’m having trouble with integrating PyObjC and doctest. Whenever a module contains an NSObject subclass, the doctest test discovery code fails like so:


Traceback (most recent call last):
  File "Lib/typemachine/ui/appDelegate.py", line 54, in <module>
    doctest.testmod()
  File "/Library/Frameworks/Python.framework/Versions/3.6/lib/python3.6/doctest.py", line 1950, in testmod
    for test in finder.find(m, name, globs=globs, extraglobs=extraglobs):
  File "/Library/Frameworks/Python.framework/Versions/3.6/lib/python3.6/doctest.py", line 933, in find
    self._find(tests, obj, name, module, source_lines, globs, {})
  File "/Library/Frameworks/Python.framework/Versions/3.6/lib/python3.6/doctest.py", line 996, in _find
    globs, seen)
  File "/Library/Frameworks/Python.framework/Versions/3.6/lib/python3.6/doctest.py", line 1027, in _find
    self._from_module(module, val)):
  File "/Library/Frameworks/Python.framework/Versions/3.6/lib/python3.6/doctest.py", line 954, in _from_module
    obj_mod = object.__objclass__.__module__
AttributeError: 'NoneType' object has no attribute ‘__module__'


Simplest way to reproduce:

=========
from Foundation import NSObject

class Foo(NSObject):
    pass

import doctest
doctest.testmod()
=========

I can’t judge whether this is a bug in doctest or in PyObjC.

Is there a workaround?

My problem is not so much that I can’t use doctest in NSObject subclasses, but rather that test discovery fails in general in the vicinity of PyObjC code. For example, I can’t use pytest’s test discovery at all: it simply fails any module that contains an NSObject subclass.

Thanks for any insights,

Just

Re: [Pyobjc-dev] DeprecationWarning: Using struct wrapper as sequence

[Just v. R. <jus...@gm...>]

That’s great news. Thank you!

Just


> On 19 Dec 2017, at 09:23, Ronald Oussoren <ron...@ma...> wrote:
> 
> You’ve got a good point there.  I’ll undeprecate in the next release. 
> 
> I personally don’t like the sequence nature of named tuples and structseq (where this api is modeled on), but your code does look nice. 
> 
> Ronald
> 
> --
> On the road, hence brief. 
> 
> Op 18 dec. 2017 om 17:18 heeft Just van Rossum <jus...@gm...> het volgende geschreven:
> 
>> In retrospect, I worded my question too mildly... I should have added:
>> 
>> This is going to break a LOT of code. (Not just mine.)
>> 
>> Just
>> 
>> 
>>> On 17 Dec 2017, at 09:50, Just van Rossum <jus...@gm...> wrote:
>>> 
>>> Hello,
>>> 
>>> I’m using to using NSSize, NSRange, NSRect etc. as sequences quite a lot, as that’s a nice Pythonic way to look at those types.
>>> 
>>> For example:
>>> 
>>>>>> url = AppKit.NSURL.URLWithString_("http://f.cl.ly/items/1T3x1y372J371p0v1F2Z/drawBot.jpg")
>>>>>> im = AppKit.NSImage.alloc().initByReferencingURL_(url)
>>>>>> w, h = im.size()
>>> 
>>> 
>>> But now I noticed that there are warnings being ussued for that usage:
>>> 
>>> __main__:1: DeprecationWarning: Using struct wrapper as sequence
>>> 
>>> My questions are:
>>> - this is so useful, and makes for nice looking code; must it really be deprecated?
>>> - if yes, when will that actually happen?
>>> - I use the reverse a lot, too; will that also be deprecated? For example:
>>>   obj.somethingExpectingARect_(((x, y), (w, h)))
>>> 
>>> Thanks,
>>> 
>>> Just
>>> 
>> 
>> 
>> ------------------------------------------------------------------------------
>> Check out the vibrant tech community on one of the world's most
>> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
>> _______________________________________________
>> Pyobjc-dev mailing list
>> Pyo...@li...
>> https://lists.sourceforge.net/lists/listinfo/pyobjc-dev

Re: [Pyobjc-dev] DeprecationWarning: Using struct wrapper as sequence

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

You’ve got a good point there.  I’ll undeprecate in the next release. 

I personally don’t like the sequence nature of named tuples and structseq (where this api is modeled on), but your code does look nice. 

Ronald

--
On the road, hence brief. 

Op 18 dec. 2017 om 17:18 heeft Just van Rossum <jus...@gm...> het volgende geschreven:

> In retrospect, I worded my question too mildly... I should have added:
> 
> This is going to break a LOT of code. (Not just mine.)
> 
> Just
> 
> 
>> On 17 Dec 2017, at 09:50, Just van Rossum <jus...@gm...> wrote:
>> 
>> Hello,
>> 
>> I’m using to using NSSize, NSRange, NSRect etc. as sequences quite a lot, as that’s a nice Pythonic way to look at those types.
>> 
>> For example:
>> 
>>>>> url = AppKit.NSURL.URLWithString_("http://f.cl.ly/items/1T3x1y372J371p0v1F2Z/drawBot.jpg")
>>>>> im = AppKit.NSImage.alloc().initByReferencingURL_(url)
>>>>> w, h = im.size()
>> 
>> 
>> But now I noticed that there are warnings being ussued for that usage:
>> 
>> __main__:1: DeprecationWarning: Using struct wrapper as sequence
>> 
>> My questions are:
>> - this is so useful, and makes for nice looking code; must it really be deprecated?
>> - if yes, when will that actually happen?
>> - I use the reverse a lot, too; will that also be deprecated? For example:
>>    obj.somethingExpectingARect_(((x, y), (w, h)))
>> 
>> Thanks,
>> 
>> Just
>> 
> 
> 
> ------------------------------------------------------------------------------
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> _______________________________________________
> Pyobjc-dev mailing list
> Pyo...@li...
> https://lists.sourceforge.net/lists/listinfo/pyobjc-dev

Re: [Pyobjc-dev] DeprecationWarning: Using struct wrapper as sequence

[Just v. R. <jus...@gm...>]

In retrospect, I worded my question too mildly... I should have added:

This is going to break a LOT of code. (Not just mine.)

Just


> On 17 Dec 2017, at 09:50, Just van Rossum <jus...@gm...> wrote:
> 
> Hello,
> 
> I’m using to using NSSize, NSRange, NSRect etc. as sequences quite a lot, as that’s a nice Pythonic way to look at those types.
> 
> For example:
> 
>>>> url = AppKit.NSURL.URLWithString_("http://f.cl.ly/items/1T3x1y372J371p0v1F2Z/drawBot.jpg")
>>>> im = AppKit.NSImage.alloc().initByReferencingURL_(url)
>>>> w, h = im.size()
> 
> 
> But now I noticed that there are warnings being ussued for that usage:
> 
> __main__:1: DeprecationWarning: Using struct wrapper as sequence
> 
> My questions are:
> - this is so useful, and makes for nice looking code; must it really be deprecated?
> - if yes, when will that actually happen?
> - I use the reverse a lot, too; will that also be deprecated? For example:
>     obj.somethingExpectingARect_(((x, y), (w, h)))
> 
> Thanks,
> 
> Just
> 

[Pyobjc-dev] DeprecationWarning: Using struct wrapper as sequence

[Just v. R. <jus...@gm...>]

Hello,

I’m using to using NSSize, NSRange, NSRect etc. as sequences quite a lot, as that’s a nice Pythonic way to look at those types.

For example:

>>> url = AppKit.NSURL.URLWithString_("http://f.cl.ly/items/1T3x1y372J371p0v1F2Z/drawBot.jpg")
>>> im = AppKit.NSImage.alloc().initByReferencingURL_(url)
>>> w, h = im.size()


But now I noticed that there are warnings being ussued for that usage:

__main__:1: DeprecationWarning: Using struct wrapper as sequence

My questions are:
- this is so useful, and makes for nice looking code; must it really be deprecated?
- if yes, when will that actually happen?
- I use the reverse a lot, too; will that also be deprecated? For example:
     obj.somethingExpectingARect_(((x, y), (w, h)))

Thanks,

Just

Re: [Pyobjc-dev] Return value "handler" / NSEvent.addLocalMonitorForEventsMatchingMask_handler_

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

> On 1 Dec 2017, at 18:30, Just van Rossum <jus...@gm...> wrote:
> 
> From a running PyObjC/Cocoa app, I try to do the following:
> 
> 
> from AppKit import NSKeyDownMask, NSEvent
> 
> def myHandler(event):
>   print(event)
>   return event
> 
> mask = NSKeyDownMask
> monitor = NSEvent.addLocalMonitorForEventsMatchingMask_handler_(mask, myHandler)
> 
> 
> (one could call this in an applicationDidFinishLaunching_() app delegate method)
> 
> 
> The handler indeed gets called when I press a key, but the caller complains it’s returning None:
> 
> ValueError: <function myHandler at 0x1146b4c80>: returned None, expecting a value

Looking a the metadata the error message is wrong, the handler should not return a value (retval for the last argument is ‘v’):

:>>> pprint.pprint(Cocoa.NSEvent.addLocalMonitorForEventsMatchingMask_handler_.__metadata__())
{'arguments': ({'_template': True, 'type': b'@'},
               {'_template': True, 'type': b':'},
               {'_template': True, 'type': b'Q'},
               {'callable': {'arguments': ({'null_accepted': True,
                                            'type': b'^v'},
                                           {'type': b'@'}),
                             'retval': {'type': b'v'}},
                'callable_retained': True,
                'type': b'@?'}),
 'classmethod': True,
 'hidden': False,
 'retval': {'_template': True, 'type': b'@'}}


However…. that is a second bug, the return value should be an NSEvent value. That is, your code is correct, but PyObjC contains two bugs: 1) the metadata incorrectly says that the handler should not return a value, and 2) the error message when returning a value from a block where no return value is expected is wrong.

I’ve committed a fix for the second problem, and will shortly commit a fix for the incorrect metadata as well.

A quick workaround: Look for “addLocalMonitorForEventsMatchingMask:handler:” in Lib/AppKit/_metadata.py and replace ‘retval’: ‘v’ by ‘retval’: ‘@‘.

Ronald

[Pyobjc-dev] Return value "handler" / NSEvent.addLocalMonitorForEventsMatchingMask_handler_

[Just v. R. <jus...@gm...>]

From a running PyObjC/Cocoa app, I try to do the following:


from AppKit import NSKeyDownMask, NSEvent

def myHandler(event):
   print(event)
   return event

mask = NSKeyDownMask
monitor = NSEvent.addLocalMonitorForEventsMatchingMask_handler_(mask, myHandler)


(one could call this in an applicationDidFinishLaunching_() app delegate method)


The handler indeed gets called when I press a key, but the caller complains it’s returning None:

ValueError: <function myHandler at 0x1146b4c80>: returned None, expecting a value

As you can see in my code above, the handler _does_ return a value, and I know from the print() output that it’s indeed not None.

Can a handler return something with PyObjC, or should I do something special with the cal/function/lmethod signature?

Thanks for any clues,

Just

[Pyobjc-dev] ANN: PyObjC 4.0.1

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

Hi,

I just uploaded PyObjC 4.0.1 to PyPI. This is a minor update to PyObjC 4.0, the changelog for this release is included below

Version 4.0.1
-------------

* Issue #213: Fix signature for ```-[NSObject forwardInvocation:]```

  Reported by user "pyrocat"

* Updated metadata for Xcode 9.1

* Changes to PyObjCTools.TestSupport to be able to include/exclude tests
  based on the minor release of macOS.

* Some tweaks to fix test failures when running on OSX 10.5, 10.6, 10.9.


Ronald

[Pyobjc-dev] ANN: PyObjC 4.0

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

Hi,

I’m happy to announce PyObjC 4.0.  The major difference in this release is support for new APIs and frameworks introduced in macOS 10.13 (High Sierra).  A minor change is that the documentation is now on readthedocs: <http://pyobjc.readthedocs.io/en/latest/ <http://pyobjc.readthedocs.io/en/latest/>>

The release notes <http://pyobjc.readthedocs.io/en/latest/changelog.html <http://pyobjc.readthedocs.io/en/latest/changelog.html>> contain more detailed information on what has changed.

And finally a technical note: this release was cut from the macos10.13-support branch of the repository, I haven’t merged the branch back into default yet.

Ronald

[Pyobjc-dev] PyObjC status w.r.t. macOS 10.13

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

Hi,

A little update on PyObjC on macOS 10.13: I’m working on updating the metadata for macOS 10.13.  This has taken a significant amount of time for checking API diffs and updating PyObjC’s code, and I’m not done yet. 

As of now I’ve updated most metadata and have even added wrappers for some of the new frameworks. I currently have 5 already wrapped frameworks and 3 new frameworks on my work queue. After updating the metadata I’ll move to testing on a VM running beta 1, when that’s done I’ll move to the then latest beta (updating metadata + testing). Hopefully the amount of work will get less and less as we get closer to the GM of macOS 10.13, but I’ve seen annoyingly large textual diffs in later beta’s in the past.

If the amount of work to keep up with the beta cycle does get smaller in later beta’s it should be possible to add new wrappers for older frameworks as well (the security frameworks are high on my list in that regard). 

With some luck I’ll be able to cut a release with full macOS 10.13 support around the time Apple says its OK to use the 10.13 SDK for uploads to the App Store (by that time the API should be stable).

Ronald

P.S. All work is done on the "macos10.13-support” of the bitbucket repository.
P.P.S. Because of work on macOS 10.13 support I’m spending close to no time on py2app and related projects

Re: [Pyobjc-dev] Using pyobjc with Sympy and Swift

[Ian M. <ip...@po...>]

While this is a bit of an over-simplification, PyObjC is typically used to
write Cocoa applications using Python. Consuming Python libraries from an
ObjC (or Swift) application is far less common. PyObjC can (probably) help
you achieve this in eliminating some boilerplate, but the place to start is
really with the "embedding" section of the standard Extending and Embedding
the Python Interpreter <https://docs.python.org/2/extending/>
 documentation.

As I read your message I couldn't help but wince a little because this is a
lot of hoops to jump through in order to consume a Python library. Also,
starting from Swift makes this considerably harder because there's not yet
ABI stability for Swift, so if there are any callbacks, or other patterns
that depend on the Swift ABI, you're setting yourself up for future
disappointment. If you're dead set on using Swift, could you perhaps find
an equivalent symbolic math library written in C or C++ (Boost perhaps)
that would get the job done? This would eliminate one stop along the way,
not to mention likely having better run-time performance.

Overall, what you're trying to do is... complicated. PyObjC may be able to
help you avoid some boilerplate work, but it's not going to be a silver
bullet, and you should understand that this use case is pretty obscure, so
the number of folks that are going to be able to provide concrete,
actionable advice to get you unstuck is going to be relatively small.

The concrete, actionable advice I can give you right now is that the first
step will be getting a python interpreter running inside your application,
so the above linked docs on embedding are definitely the place to start.
Once you've embedded the interpreter, you can start to figure out how to
get it "wired" together with the rest of your application. Start small. Get
your embedded interpreter running Hello World or something first. Then
graduate to a simple library call, and then, when you've got that all
figured out, start to think about the best ways to integrate the larger
library.

Regards and Hope this Helped,
Ian







On Sun, Apr 2, 2017 at 11:22 PM, Robert Hai <rh...@gm...> wrote:

> Hi,
>
> I need to use a Python Library (Sympy -> http://www.sympy.org/en/
> index.html) in my Swift App. So my idea was to bridge between Objective-C
> and Swift and bridge between Objective-C and Swift to achieve my goal. So
> how do I use PyObjC with Sympy and where can I find excat documentation of
> how to use my Python in Objective-C via PyObjC ?
>
> Thanks a lot for your help ! I have ben trying to achieve this for the
> past four weeks. I finally want to solve this =(
>
> All my best,
> Robert
>
> ------------------------------------------------------------
> ------------------
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> _______________________________________________
> Pyobjc-dev mailing list
> Pyo...@li...
> https://lists.sourceforge.net/lists/listinfo/pyobjc-dev
>
>

[Pyobjc-dev] Using pyobjc with Sympy and Swift

[Robert H. <rh...@gm...>]

<html><head></head><body><div style="font-family: Verdana;font-size: 12.0px;"><div>Hi,</div>

<div>&nbsp;</div>

<div>I need to use a Python Library (Sympy -&gt;&nbsp;http://www.sympy.org/en/index.html) in my Swift App. So my idea was to bridge between Objective-C and Swift and bridge between Objective-C and Swift to achieve my goal. So how do I use PyObjC with Sympy and where can I find excat documentation of how to use my Python in Objective-C via PyObjC ?&nbsp;</div>

<div>&nbsp;</div>

<div>Thanks a lot for your help ! I have ben trying to achieve this for the past four weeks. I finally want to solve this =(</div>

<div>&nbsp;</div>

<div>All my best,</div>

<div>Robert</div></div></body></html>

Re: [Pyobjc-dev] Problem with pyObjC and Swift

[John B. <nho...@gm...>]

Plugins written in Swift don't strike me as a good idea until we have ABI
stability. What if two plugins are loaded with different swift runtimes?
You can work-around that if your architecture loads plugins in a separate
process and communicates via XPC (or similar).

I work on a plugin for FCPX. We considered Swift, but it's a no-go until we
have ABI stability for the above reason.

Cheers,

John
--
John Buckley LBIPP M.Eng. Ph.D.
+44 7740 099518
johnbuckleyphotography.uk


On Thu, 30 Mar 2017 at 10:27 Georg Seifert <geo...@gm...> wrote:

> Hi
>
> I have an app written in ObjectiveC. It allows loading plugins from third
> parties. Most of those are written in python, some in ObjectiveC. Now
> someone tries to write on in Swift. That plugin works as expected but all
> the python plugin don't work any more and crash the app. At least when the
> plugin is build with Xcode 8 and Swift 3. Compiling it on Xcode 7 (macOS
> 10.10) works fine. Running the Xcode 8 version on 10.10 crashes, too.
>
> The app links agains the system python framework.
>
> Anyone has knows anything about this?
>
> Thanks
> Georg Seifert
>
> p.s. I get backtraces like this:
>
> Calling a method on an python object inheriting from NSObject
>
> #0      0x0000000100a56ed7 in ___lldb_unnamed_function679$$Python ()
> #1      0x0000000100a584f1 in PyDict_SetItemString ()
> #2      0x00000001098319a5 in PyObjCClass_CheckMethodList ()
> #3      0x0000000109832543 in ___lldb_unnamed_function453$$_objc.so ()
> #4      0x0000000100aa3238 in ___lldb_unnamed_function1431$$Python ()
> #5      0x0000000100aa9d8c in PyEval_EvalFrameEx ()
> #6      0x0000000100aa6352 in PyEval_EvalCodeEx ()
> #7      0x0000000100a4a5de in ___lldb_unnamed_function510$$Python ()
> #8      0x0000000100a2c50a in PyObject_Call ()
> #9      0x0000000109831c04 in PyObjCClass_CheckMethodList ()
> #10     0x00000001098361ed in PyObjCObject_New ()
> #11     0x00000001098368fa in ___lldb_unnamed_function487$$_objc.so ()
> #12     0x000000010983955d in pythonify_c_value ()
> #13     0x000000010982654a in ___lldb_unnamed_function373$$_objc.so ()
> #14     0x00007fff87356a07 in ffi_closure_unix64_inner ()
> #15     0x00007fff873560c6 in ffi_closure_unix64 ()
>
> or:
>
> calling [NSBundle principalClass] on the plugin containing the python class
>
> #0      0x0000000100a99bd3 in ___lldb_unnamed_symbol679$$Python ()
> #1      0x0000000100a9b1cd in PyDict_SetItemString ()
> #2      0x000000010e6a21cb in PyObjCClass_CheckMethodList ()
> #3      0x000000010e6a51a4 in PyObjCClass_FindSelector ()
> #4      0x000000010e6b0aef in PyObjCSelector_FromFunction ()
> #5      0x000000010e6a3005 in ___lldb_unnamed_symbol454$$_objc.so ()
> #6      0x0000000100a9fb14 in PyObject_SetAttr ()
> #7      0x0000000100ae97a6 in PyEval_EvalFrameEx ()
> #8      0x0000000100ae79be in PyEval_EvalCodeEx ()
> #9      0x0000000100ae7367 in PyEval_EvalCode ()
> #10     0x0000000100afc6bd in PyImport_ExecCodeModuleEx ()
> #11     0x0000000100aff3c7 in ___lldb_unnamed_symbol1546$$Python ()
> #12     0x0000000100afee2c in ___lldb_unnamed_symbol1545$$Python ()
> #13     0x0000000100afea00 in ___lldb_unnamed_symbol1543$$Python ()
> #14     0x0000000100afdc10 in PyImport_ImportModuleLevel ()
> #15     0x0000000100ae3006 in ___lldb_unnamed_symbol1412$$Python ()
> #16     0x0000000100a6f6fb in PyObject_Call ()
> #17     0x0000000100aeddbb in PyEval_CallObjectWithKeywords ()
> #18     0x0000000100ae9c0f in PyEval_EvalFrameEx ()
> #19     0x0000000100ae79be in PyEval_EvalCodeEx ()
> #20     0x0000000100ae7367 in PyEval_EvalCode ()
> #21     0x0000000100afc6bd in PyImport_ExecCodeModuleEx ()
> #22     0x0000000100aff3c7 in ___lldb_unnamed_symbol1546$$Python ()
> #23     0x0000000100aff64f in ___lldb_unnamed_symbol1548$$Python ()
> #24     0x0000000100afee2c in ___lldb_unnamed_symbol1545$$Python ()
> #25     0x0000000100afea41 in ___lldb_unnamed_symbol1543$$Python ()
> #26     0x0000000100afdbd8 in PyImport_ImportModuleLevel ()
> #27     0x0000000100ae3006 in ___lldb_unnamed_symbol1412$$Python ()
> #28     0x0000000100a6f6fb in PyObject_Call ()
> #29     0x0000000100aeddbb in PyEval_CallObjectWithKeywords ()
> #30     0x0000000100ae9c0f in PyEval_EvalFrameEx ()
> #31     0x0000000100ae79be in PyEval_EvalCodeEx ()
> #32     0x0000000100ae7367 in PyEval_EvalCode ()
> #33     0x0000000100afc6bd in PyImport_ExecCodeModuleEx ()
> #34     0x0000000100aff4e1 in ___lldb_unnamed_symbol1547$$Python ()
> #35     0x0000000100aff64f in ___lldb_unnamed_symbol1548$$Python ()
> #36     0x0000000100afee2c in ___lldb_unnamed_symbol1545$$Python ()
> #37     0x0000000100afea00 in ___lldb_unnamed_symbol1543$$Python ()
> #38     0x0000000100afdbd8 in PyImport_ImportModuleLevel ()
> #39     0x0000000100ae3006 in ___lldb_unnamed_symbol1412$$Python ()
> #40     0x0000000100a6f6fb in PyObject_Call ()
> #41     0x0000000100aeddbb in PyEval_CallObjectWithKeywords ()
> #42     0x0000000100ae9c0f in PyEval_EvalFrameEx ()
> #43     0x0000000100ae79be in PyEval_EvalCodeEx ()
> #44     0x0000000100ae7367 in PyEval_EvalCode ()
> #45     0x0000000100b075dd in ___lldb_unnamed_symbol1599$$Python ()
> #46     0x0000000100b07680 in PyRun_FileExFlags ()
> #47     0x0000000100ae3cbd in ___lldb_unnamed_symbol1427$$Python ()
> #48     0x0000000100aeb4d4 in PyEval_EvalFrameEx ()
> #49     0x0000000100ae79be in PyEval_EvalCodeEx ()
> #50     0x0000000100aee3e2 in ___lldb_unnamed_symbol1476$$Python ()
> #51     0x0000000100aeae4e in PyEval_EvalFrameEx ()
> #52     0x0000000100ae79be in PyEval_EvalCodeEx ()
> #53     0x0000000100ae7367 in PyEval_EvalCode ()
> #54     0x0000000100b075dd in ___lldb_unnamed_symbol1599$$Python ()
> #55     0x0000000100b07680 in PyRun_FileExFlags ()
> #56     0x0000000100b0890a in PyRun_File ()
> #57     0x000000010e5bea86 in ___lldb_unnamed_symbol1$$plugin ()
> #58     0x00000001002cfa1b in
> ImageLoaderMachO::doModInitFunctions(ImageLoader::LinkContext const&) ()
> #59     0x00000001002cfc1e in
> ImageLoaderMachO::doInitialization(ImageLoader::LinkContext const&) ()
> #60     0x00000001002cb4aa in
> ImageLoader::recursiveInitialization(ImageLoader::LinkContext const&,
> unsigned int, char const*, ImageLoader::InitializerTimingList&,
> ImageLoader::UninitedUpwards&) ()
> #61     0x00000001002ca524 in
> ImageLoader::processInitializers(ImageLoader::LinkContext const&, unsigned
> int, ImageLoader::InitializerTimingList&, ImageLoader::UninitedUpwards&) ()
> #62     0x00000001002ca5b9 in
> ImageLoader::runInitializers(ImageLoader::LinkContext const&,
> ImageLoader::InitializerTimingList&) ()
> #63     0x00000001002bf7cd in dyld::runInitializers(ImageLoader*) ()
> #64     0x00000001002c73ec in dlopen ()
> #65     0x00007fffaa2ac832 in dlopen ()
> #66     0x00007fff94b7a249 in _CFBundleDlfcnLoadBundle ()
> #67     0x00007fff94b7a0ca in _CFBundleLoadExecutableAndReturnError ()
> #68     0x00007fff9656283f in _NSBundleLoadCode ()
> #69     0x00007fff96562425 in -[NSBundle loadAndReturnError:] ()
> #70     0x00007fff965aca16 in -[NSBundle principalClass] ()
>
>
>
> ------------------------------------------------------------------------------
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> _______________________________________________
> Pyobjc-dev mailing list
> Pyo...@li...
> https://lists.sourceforge.net/lists/listinfo/pyobjc-dev
>

[Pyobjc-dev] Problem with pyObjC and Swift

[Georg S. <geo...@gm...>]

Hi

I have an app written in ObjectiveC. It allows loading plugins from third parties. Most of those are written in python, some in ObjectiveC. Now someone tries to write on in Swift. That plugin works as expected but all the python plugin don't work any more and crash the app. At least when the plugin is build with Xcode 8 and Swift 3. Compiling it on Xcode 7 (macOS 10.10) works fine. Running the Xcode 8 version on 10.10 crashes, too.

The app links agains the system python framework.

Anyone has knows anything about this?

Thanks
Georg Seifert

p.s. I get backtraces like this:

Calling a method on an python object inheriting from NSObject 

#0	0x0000000100a56ed7 in ___lldb_unnamed_function679$$Python ()
#1	0x0000000100a584f1 in PyDict_SetItemString ()
#2	0x00000001098319a5 in PyObjCClass_CheckMethodList ()
#3	0x0000000109832543 in ___lldb_unnamed_function453$$_objc.so ()
#4	0x0000000100aa3238 in ___lldb_unnamed_function1431$$Python ()
#5	0x0000000100aa9d8c in PyEval_EvalFrameEx ()
#6	0x0000000100aa6352 in PyEval_EvalCodeEx ()
#7	0x0000000100a4a5de in ___lldb_unnamed_function510$$Python ()
#8	0x0000000100a2c50a in PyObject_Call ()
#9	0x0000000109831c04 in PyObjCClass_CheckMethodList ()
#10	0x00000001098361ed in PyObjCObject_New ()
#11	0x00000001098368fa in ___lldb_unnamed_function487$$_objc.so ()
#12	0x000000010983955d in pythonify_c_value ()
#13	0x000000010982654a in ___lldb_unnamed_function373$$_objc.so ()
#14	0x00007fff87356a07 in ffi_closure_unix64_inner ()
#15	0x00007fff873560c6 in ffi_closure_unix64 ()

or:

calling [NSBundle principalClass] on the plugin containing the python class

#0	0x0000000100a99bd3 in ___lldb_unnamed_symbol679$$Python ()
#1	0x0000000100a9b1cd in PyDict_SetItemString ()
#2	0x000000010e6a21cb in PyObjCClass_CheckMethodList ()
#3	0x000000010e6a51a4 in PyObjCClass_FindSelector ()
#4	0x000000010e6b0aef in PyObjCSelector_FromFunction ()
#5	0x000000010e6a3005 in ___lldb_unnamed_symbol454$$_objc.so ()
#6	0x0000000100a9fb14 in PyObject_SetAttr ()
#7	0x0000000100ae97a6 in PyEval_EvalFrameEx ()
#8	0x0000000100ae79be in PyEval_EvalCodeEx ()
#9	0x0000000100ae7367 in PyEval_EvalCode ()
#10	0x0000000100afc6bd in PyImport_ExecCodeModuleEx ()
#11	0x0000000100aff3c7 in ___lldb_unnamed_symbol1546$$Python ()
#12	0x0000000100afee2c in ___lldb_unnamed_symbol1545$$Python ()
#13	0x0000000100afea00 in ___lldb_unnamed_symbol1543$$Python ()
#14	0x0000000100afdc10 in PyImport_ImportModuleLevel ()
#15	0x0000000100ae3006 in ___lldb_unnamed_symbol1412$$Python ()
#16	0x0000000100a6f6fb in PyObject_Call ()
#17	0x0000000100aeddbb in PyEval_CallObjectWithKeywords ()
#18	0x0000000100ae9c0f in PyEval_EvalFrameEx ()
#19	0x0000000100ae79be in PyEval_EvalCodeEx ()
#20	0x0000000100ae7367 in PyEval_EvalCode ()
#21	0x0000000100afc6bd in PyImport_ExecCodeModuleEx ()
#22	0x0000000100aff3c7 in ___lldb_unnamed_symbol1546$$Python ()
#23	0x0000000100aff64f in ___lldb_unnamed_symbol1548$$Python ()
#24	0x0000000100afee2c in ___lldb_unnamed_symbol1545$$Python ()
#25	0x0000000100afea41 in ___lldb_unnamed_symbol1543$$Python ()
#26	0x0000000100afdbd8 in PyImport_ImportModuleLevel ()
#27	0x0000000100ae3006 in ___lldb_unnamed_symbol1412$$Python ()
#28	0x0000000100a6f6fb in PyObject_Call ()
#29	0x0000000100aeddbb in PyEval_CallObjectWithKeywords ()
#30	0x0000000100ae9c0f in PyEval_EvalFrameEx ()
#31	0x0000000100ae79be in PyEval_EvalCodeEx ()
#32	0x0000000100ae7367 in PyEval_EvalCode ()
#33	0x0000000100afc6bd in PyImport_ExecCodeModuleEx ()
#34	0x0000000100aff4e1 in ___lldb_unnamed_symbol1547$$Python ()
#35	0x0000000100aff64f in ___lldb_unnamed_symbol1548$$Python ()
#36	0x0000000100afee2c in ___lldb_unnamed_symbol1545$$Python ()
#37	0x0000000100afea00 in ___lldb_unnamed_symbol1543$$Python ()
#38	0x0000000100afdbd8 in PyImport_ImportModuleLevel ()
#39	0x0000000100ae3006 in ___lldb_unnamed_symbol1412$$Python ()
#40	0x0000000100a6f6fb in PyObject_Call ()
#41	0x0000000100aeddbb in PyEval_CallObjectWithKeywords ()
#42	0x0000000100ae9c0f in PyEval_EvalFrameEx ()
#43	0x0000000100ae79be in PyEval_EvalCodeEx ()
#44	0x0000000100ae7367 in PyEval_EvalCode ()
#45	0x0000000100b075dd in ___lldb_unnamed_symbol1599$$Python ()
#46	0x0000000100b07680 in PyRun_FileExFlags ()
#47	0x0000000100ae3cbd in ___lldb_unnamed_symbol1427$$Python ()
#48	0x0000000100aeb4d4 in PyEval_EvalFrameEx ()
#49	0x0000000100ae79be in PyEval_EvalCodeEx ()
#50	0x0000000100aee3e2 in ___lldb_unnamed_symbol1476$$Python ()
#51	0x0000000100aeae4e in PyEval_EvalFrameEx ()
#52	0x0000000100ae79be in PyEval_EvalCodeEx ()
#53	0x0000000100ae7367 in PyEval_EvalCode ()
#54	0x0000000100b075dd in ___lldb_unnamed_symbol1599$$Python ()
#55	0x0000000100b07680 in PyRun_FileExFlags ()
#56	0x0000000100b0890a in PyRun_File ()
#57	0x000000010e5bea86 in ___lldb_unnamed_symbol1$$plugin ()
#58	0x00000001002cfa1b in ImageLoaderMachO::doModInitFunctions(ImageLoader::LinkContext const&) ()
#59	0x00000001002cfc1e in ImageLoaderMachO::doInitialization(ImageLoader::LinkContext const&) ()
#60	0x00000001002cb4aa in ImageLoader::recursiveInitialization(ImageLoader::LinkContext const&, unsigned int, char const*, ImageLoader::InitializerTimingList&, ImageLoader::UninitedUpwards&) ()
#61	0x00000001002ca524 in ImageLoader::processInitializers(ImageLoader::LinkContext const&, unsigned int, ImageLoader::InitializerTimingList&, ImageLoader::UninitedUpwards&) ()
#62	0x00000001002ca5b9 in ImageLoader::runInitializers(ImageLoader::LinkContext const&, ImageLoader::InitializerTimingList&) ()
#63	0x00000001002bf7cd in dyld::runInitializers(ImageLoader*) ()
#64	0x00000001002c73ec in dlopen ()
#65	0x00007fffaa2ac832 in dlopen ()
#66	0x00007fff94b7a249 in _CFBundleDlfcnLoadBundle ()
#67	0x00007fff94b7a0ca in _CFBundleLoadExecutableAndReturnError ()
#68	0x00007fff9656283f in _NSBundleLoadCode ()
#69	0x00007fff96562425 in -[NSBundle loadAndReturnError:] ()
#70	0x00007fff965aca16 in -[NSBundle principalClass] ()

Re: [Pyobjc-dev] Security framework and objective.metadata

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

> On 5 Mar 2017, at 12:22, Mosen <mo...@fa...> wrote:
> 
> Hi there.
> I have been using PyObjC for some time and up until recently i was using
> ctypes for the Security framework.
> 
> I managed to generate a wrapper for Security by modifying
> objective.metadata slightly so that it wouldn't attempt to parse a
> linked list recursively in the Security headers. My solution is really
> hacky though (basically if this struct contains a member that is this
> struct we dont recurse into it).

That’s great news.  The Security framework has been on my TODO list for
a long time, having bindings for that framework would be very useful for
some users.

> 
> I'd be happy to work with someone to come up with a cleaner solution as
> I'm not very familiar with objective.metadata, clang, etc etc.

I don’t think anyone is really familiar with that tooling, the codebase isn’t
as clear as I’d like and too be honest is mostly written for one user. I’ve tried
to keep to tooling usable for others, but didn’t really expect that anyone else
would actually use it :-)

> 
> Also will send a PR request for objective.metadata command line usage
> documentation. It look a few minutes to study the existing structure so
> I thought it was worth writing up.
> 
> Thanks Ronald and devs.
> Mosen.

Ronald

> 
> ------------------------------------------------------------------------------
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, SlashDot.org! http://sdm.link/slashdot
> _______________________________________________
> Pyobjc-dev mailing list
> Pyo...@li...
> https://lists.sourceforge.net/lists/listinfo/pyobjc-dev

[Pyobjc-dev] Security framework and objective.metadata

[Mosen <mo...@fa...>]

Hi there.
I have been using PyObjC for some time and up until recently i was using
ctypes for the Security framework.

I managed to generate a wrapper for Security by modifying
objective.metadata slightly so that it wouldn't attempt to parse a
linked list recursively in the Security headers. My solution is really
hacky though (basically if this struct contains a member that is this
struct we dont recurse into it).

I'd be happy to work with someone to come up with a cleaner solution as
I'm not very familiar with objective.metadata, clang, etc etc.

Also will send a PR request for objective.metadata command line usage
documentation. It look a few minutes to study the existing structure so
I thought it was worth writing up.

Thanks Ronald and devs.
Mosen.

Re: [Pyobjc-dev] py2app 0.12 and modulegraph 0.14 released

[Diez B. R. <de...@we...>]

Ha, thanks - this serves as a reminder right when I need this for some refactoring effort I’m about to undertake :)

Cheers,

Diez

> On 22 Feb 2017, at 11:39, Ronald Oussoren <ron...@ma...> wrote:
> 
> Hi,
> 
> I’ve just pushed py2app 0.12 and modulegraph 0.14 to PyPI. Both primarily contain bugfixes.
> 
> I had hoped to fix more issues in these releases, but that hasn’t worked out and the fixed bugs are serious enough to not delay the release any more. On to the next release…
> 
> Ronald
> ------------------------------------------------------------------------------
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, SlashDot.org! http://sdm.link/slashdot
> _______________________________________________
> Pyobjc-dev mailing list
> Pyo...@li...
> https://lists.sourceforge.net/lists/listinfo/pyobjc-dev

[Pyobjc-dev] py2app 0.12 and modulegraph 0.14 released

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

Hi,

I’ve just pushed py2app 0.12 and modulegraph 0.14 to PyPI. Both primarily contain bugfixes.

I had hoped to fix more issues in these releases, but that hasn’t worked out and the fixed bugs are serious enough to not delay the release any more. On to the next release…

Ronald

Re: [Pyobjc-dev] pyobjc documentation problems

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

> On 20 Jan 2017, at 03:25, Research and Dev <the...@un...> wrote:
> 
> Hi, 
> 
> I'm having trouble following your documentation. I understand the basics of Objective-C and know python pretty well. However, I've been trying it utilize your library, but keep coming across errors or simply just can't get the library to work. Is there better documentation with ObjC with pyobjc side-by-side examples? 

Not really. The translation from Objective-C names to Python names is explained in <https://pythonhosted.org/pyobjc/core/intro.html <https://pythonhosted.org/pyobjc/core/intro.html>>, that’s closer to a reference guide than a tutorial though.

What kind of errors do you run into? 

Ronald

[Pyobjc-dev] pyobjc documentation problems

[Research a. D. <the...@un...>]

Hi, 

I'm having trouble following your documentation. I understand the basics of Objective-C and know python pretty well. However, I've been trying it utilize your library, but keep coming across errors or simply just can't get the library to work. Is there better documentation with ObjC with pyobjc side-by-side examples? 

Thank you. 
Kevin

Re: [Pyobjc-dev] Unexplained warnings when accessing Contacts

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

> On 9 Jan 2017, at 16:54, Gordon Watson <gor...@gm...> wrote:
> 
> Hi,
> 
> Can anyone suggest why... When accessing entries in Contacts I'm getting the following warning messages: 
> 
> CoreData: warning: dynamic accessors failed to find @property implementation for 'uniqueId' for entity ABCDRelatedName while resolving selector 'uniqueId' on class 'ABCDOwnedObject'.  Did you remember to declare it @dynamic or @synthesized in the @implementation ?
> 
> Or, similarly:
> 
> CoreData: warning: dynamic accessors failed to find @property implementation for 'name' for entity ABCDRelatedName while resolving selector 'name' on class 'ABCDOwnedObject'.  Did you remember to declare it @dynamic or @synthesized in the @implementation ?
> 
> My code seems to work, though.
> 
> macOS 10.12.2
> py27-pyobjc 3.0.4
> pyobjc-framework-AddressBook 3.2.1

That’s odd. Do you have sample code that demonstrates the problem?

Ronald