From ronaldoussoren at mac.com Sun Sep 2 15:27:06 2018 From: ronaldoussoren at mac.com (Ronald Oussoren) Date: Sun, 02 Sep 2018 21:27:06 +0200 Subject: [Pythonmac-SIG] [ANN] PyObjC 5.0b1 Message-ID: <14E3E334-F50B-45A2-9E8B-6EA9065304FD@mac.com> Hi, I just uploaded PyObjC 5.0b1 to PyPI. This is the first beta of the version of PyObjC that includes support for macOS 10.14 (Mojave). I expect to release 5.0 soon after the GM release of Xcode 10. The primary new ?feature? as compared with the 5.0a1 is that this release includes binary wheels for all supported versions of Python (2.7, 3.4, 3.5, 3.6 and 3.7, and for 2.7, 3.6 and 3.7 there are wheels for both the older ?intel? installer and the newer 64-bit installer on Python.org) Changes w.r.t. PyObjC 5.0a1: * Bindings updated for Xcode 10 beta 6. * Add a custom binding for a number of structure types in CoreAudio: - AudioBuffer - AudioBufferList - AudioChannelDescription - AudioChannelLayout - AudioValueTranslation With this patch using APIs with these types should actually work. * PR19: Fix deprecation warning in bridgesupport support module Patch by: Micka?l Schoentgen * Creating objc.ObjCPointer instances now results in a Python warning, instead of an unconditional message on stdout. .. note:: The creation of these objects is a sign that APIs are not wrapped correctly, these objects are created for pointers where the bridge doesn't know how to handle them properly. * System bridgesupport XML files (normally not used by PyObjC) can contain constant numbers with value "inf", PyObjC now knows how to handle those. * Added bindings for the "Metadata" subframework of the "CoreServices" framework. * Added bindings for the "CarbonCore" subframework of the "CoreServices" framework. Most APIs in this subframework are not available to Python, only those APIs that are not deprecated and seem interesting are exposed. * The separate framework wrappers DictionaryServices, LaunchServices and SearchKit are deprecated, use the CoreServices bindings instead. These framework wrappers still exists, but are effectively aliases for CoreServices with this release. Because of this these bindings can expose more symbols than previously. * Fix unexpected exception when trying to call getattr on a framework wrapped with a name that isn't a valid identifier. * #244: Bad metadata for CGPDFOperatorTableSetCallback * #247: Fix crash in regression test case One specific test in pyobjc-core crashed the interpreter when run separately. Because of this I've disabled an optimization that uses alloca instead of PyMem_Malloc to allocate memory for now. Regards, Ronald From ronaldoussoren at mac.com Tue Sep 18 16:22:36 2018 From: ronaldoussoren at mac.com (Ronald Oussoren) Date: Tue, 18 Sep 2018 22:22:36 +0200 Subject: [Pythonmac-SIG] [ANN] PyObjC 5.0 Message-ID: <5125878D-F7B7-40FD-AA9F-F5C0E06463A4@mac.com> PyObjC 5.0 is out The release of macOS 10.14 is near, it is therefore time to release a new major version of PyObjC. I?ve uploaded PyObjC to PyPI, it can be installed using ?python3 -m pip install -U pyobjc?. What is PyObjC The PyObjC project provides bindings to most of Apple?s higher-level APIs (frameworks). More information about these bindings and how to use PyObjC can be found on the PyObjC website. What is new The main feature of this release is the addition of support for APIs introduced in macOS 10.14 (Mojave). In particular: * Adds support for macOS 10.14 (Mojave) * This release updates the framework wrappers with support for new APIs in macOS 10.14 and adds bindings for the following new frameworks: ? AdSupport ? CoreAudio (new in macOS 10.0) ? CoreAudioKit (new in macOS 10.4) ? CoreMedia (new in macOS 10.7) ? CoreMediaIO (new in macOS 10.7) ? DiscRecording (new in macOS 10.2) ? DiscRecordingUI (new in macOS 10.2) ? DVDPlayback (new in macOS 10.3) ? MediaToolbox ? NaturalLanguage ? Network ? OSAKit (new in macOS 10.4) ? UserNotifications ? VideoSubscriberAccount ? VideoToolbox (new in macOS 10.8) * Added two features that can help with gating code on the version of macos: 1) The constants ?objc.MAC_OS_X_VERSION_CURRENT? can be compared with one of the ?objc.MAC_OS_X_VERSION_?? contants. 2) The function ?objc.macos_avaiable(major, minor[, patch])? returns true if the current macOS version is at least the specified version, comparable with ?@available? in Swift. * PR19: Fix deprecation warning in bridgesupport support module Patch by: Micka?l Schoentgen * Creating objc.ObjCPointer instances now results in a Python warning, instead of an unconditional message on stdout. * System bridgesupport XML files (normally not used by PyObjC) can contain constant numbers with value ?inf?, PyObjC now knows how to handle those. * Added bindings for the ?Metadata? subframework of the ?CoreServices? framework. * Added bindings for the ?CarbonCore? subframework of the ?CoreServices? framework. Most APIs in this subframework are not available to Python, only those APIs that are not deprecated and seem interesting are exposed. * The separate framework wrappers DictionaryServices, LaunchServices and SearchKit are deprecated, use the CoreServices bindings instead. These framework wrappers still exists, but are effectively aliases for CoreServices with this release. Because of this these bindings can expose more symbols than previously. * Fix unexpected exception when trying to call getattr on a framework wrapped with a name that isn?t a valid identifier. * Issue 244: Bad metadata for CGPDFOperatorTableSetCallback * Issue 247: Fix crash in regression test case * One specific test in pyobjc-core crashed the interpreter when run separately. Because of this I?ve disabled an optimization that uses alloca instead of PyMem_Malloc to allocate memory for now. Supporting development I do all development on PyObjC in my spare time. Please consider donating if you use PyObjC professionally. This will help me to improve PyObjC and related projects. See my website for more information. P.S. This is a cross-post from http://blog.ronaldoussoren.net/2018/09/18/pyobjc-is-out.html, and I?ve also tweeted about this from @RonaldOussoren. -------------- next part -------------- An HTML attachment was scrubbed... URL: From glyph at twistedmatrix.com Thu Sep 20 23:59:47 2018 From: glyph at twistedmatrix.com (Glyph) Date: Thu, 20 Sep 2018 20:59:47 -0700 Subject: [Pythonmac-SIG] [ANN] PyObjC 5.0 In-Reply-To: <5125878D-F7B7-40FD-AA9F-F5C0E06463A4@mac.com> References: <5125878D-F7B7-40FD-AA9F-F5C0E06463A4@mac.com> Message-ID: On Sep 18, 2018, at 1:22 PM, Ronald Oussoren via Pythonmac-SIG wrote: > > PyObjC 5.0 is out Thanks again for your tireless (or at least apparently tireless) maintenance, Ronald! > * Added bindings for the ?CarbonCore? subframework of the ?CoreServices? framework. > > Most APIs in this subframework are not available to Python, only those APIs that are not deprecated and seem interesting are exposed. One thing I wondered about when I saw "carbon" here is that I wonder if the APIs that could make https://pythonhosted.org/pyobjc/examples/Cocoa/AppKit/HotKeyPython/index.html are exposed again? The cautions that the relevant Carbon APIs require 32-bit mode are inaccurate; https://blog.shpakovski.com/2012/07/global-keyboard-shortcuts-in-cocoa.html explains that they're still supported in sandboxed Mac App Store apps, so they're just poorly documented, not deprecated. (It seems that there's never been a proper Cocoa replacement for this functionality, just a couple of popular wrappers floating around out there...) This is something I have wanted to do in Python many times, but never quite badly enough to figure out all the build gymnastics required to get the bindings for https://github.com/shpakovski/MASShortcut built and bundled with my application. -glyph P.S.: speaking of build gymnastics, does anyone on this list happen to have a way to use CocoaPods or something similar to pull in open source Cocoa frameworks to a PyObjC application? -------------- next part -------------- An HTML attachment was scrubbed... URL: From ronaldoussoren at mac.com Fri Sep 21 07:50:23 2018 From: ronaldoussoren at mac.com (Ronald Oussoren) Date: Fri, 21 Sep 2018 13:50:23 +0200 Subject: [Pythonmac-SIG] [ANN] PyObjC 5.0 In-Reply-To: References: <5125878D-F7B7-40FD-AA9F-F5C0E06463A4@mac.com> Message-ID: <9DF47F0A-FCDC-4601-9459-4F5D359939FF@mac.com> > On 21 Sep 2018, at 05:59, Glyph wrote: > > On Sep 18, 2018, at 1:22 PM, Ronald Oussoren via Pythonmac-SIG > wrote: >> >> PyObjC 5.0 is out > > Thanks again for your tireless (or at least apparently tireless) maintenance, Ronald! > >> * Added bindings for the ?CarbonCore? subframework of the ?CoreServices? framework. >> >> Most APIs in this subframework are not available to Python, only those APIs that are not deprecated and seem interesting are exposed. > > One thing I wondered about when I saw "carbon" here is that I wonder if the APIs that could make https://pythonhosted.org/pyobjc/examples/Cocoa/AppKit/HotKeyPython/index.html are exposed again? The API used in that example is not exposed through PyObjC at this time (AFAIK it is part of ?Carbon.framework?, not the CarbonCore sub framework of ?CoreServices.framework?. I?m open to adding bindings to interesting APIs, but note that ?RegisterEventHotKey? is not documented on Apple?s website and might not be the right solution for modern code. I don?t know yet what the right solution is though (a number of APIs that are exposed through PyObjC can be used to implement similar functionality). > The cautions that the relevant Carbon APIs require 32-bit mode are inaccurate; https://blog.shpakovski.com/2012/07/global-keyboard-shortcuts-in-cocoa.html explains that they're still supported in sandboxed Mac App Store apps, so they're just poorly documented, not deprecated. (It seems that there's never been a proper Cocoa replacement for this functionality, just a couple of popular wrappers floating around out there?) > > This is something I have wanted to do in Python many times, but never quite badly enough to figure out all the build gymnastics required to get the bindings for https://github.com/shpakovski/MASShortcut built and bundled with my application. I?ll look into exposing this API for PyObjC 5.1, even if that means adding a very limited set of bindings for Carbon.framework. > > -glyph > > P.S.: speaking of build gymnastics, does anyone on this list happen to have a way to use CocoaPods or something similar to pull in open source Cocoa frameworks to a PyObjC application? I haven?t looked into this yet. I guess the hardest part is creating the metadata for constants and pointer arguments. Could you file and issue for this? Ronald -------------- next part -------------- An HTML attachment was scrubbed... URL: From glyph at twistedmatrix.com Fri Sep 21 17:24:45 2018 From: glyph at twistedmatrix.com (Glyph) Date: Fri, 21 Sep 2018 14:24:45 -0700 Subject: [Pythonmac-SIG] [ANN] PyObjC 5.0 In-Reply-To: <9DF47F0A-FCDC-4601-9459-4F5D359939FF@mac.com> References: <5125878D-F7B7-40FD-AA9F-F5C0E06463A4@mac.com> <9DF47F0A-FCDC-4601-9459-4F5D359939FF@mac.com> Message-ID: <3ACD74AC-FF04-4D57-8CC7-EACE50330EE6@twistedmatrix.com> > On Sep 21, 2018, at 4:50 AM, Ronald Oussoren wrote: > > > >> On 21 Sep 2018, at 05:59, Glyph > wrote: >> >> On Sep 18, 2018, at 1:22 PM, Ronald Oussoren via Pythonmac-SIG > wrote: >>> >>> PyObjC 5.0 is out >> >> Thanks again for your tireless (or at least apparently tireless) maintenance, Ronald! >> >>> * Added bindings for the ?CarbonCore? subframework of the ?CoreServices? framework. >>> >>> Most APIs in this subframework are not available to Python, only those APIs that are not deprecated and seem interesting are exposed. >> >> One thing I wondered about when I saw "carbon" here is that I wonder if the APIs that could make https://pythonhosted.org/pyobjc/examples/Cocoa/AppKit/HotKeyPython/index.html are exposed again? > > The API used in that example is not exposed through PyObjC at this time (AFAIK it is part of ?Carbon.framework?, not the CarbonCore sub framework of ?CoreServices.framework?. > > I?m open to adding bindings to interesting APIs, but note that ?RegisterEventHotKey? is not documented on Apple?s website and might not be the right solution for modern code. I don?t know yet what the right solution is though (a number of APIs that are exposed through PyObjC can be used to implement similar functionality). If there were a more modern solution I'd gladly use it rather than asking you to expose gross and ancient Carbon APIs :). Which APIs that are already exposed can do this? >> The cautions that the relevant Carbon APIs require 32-bit mode are inaccurate; https://blog.shpakovski.com/2012/07/global-keyboard-shortcuts-in-cocoa.html explains that they're still supported in sandboxed Mac App Store apps, so they're just poorly documented, not deprecated. (It seems that there's never been a proper Cocoa replacement for this functionality, just a couple of popular wrappers floating around out there?) >> >> This is something I have wanted to do in Python many times, but never quite badly enough to figure out all the build gymnastics required to get the bindings for https://github.com/shpakovski/MASShortcut built and bundled with my application. > > I?ll look into exposing this API for PyObjC 5.1, even if that means adding a very limited set of bindings for Carbon.framework. Thanks! >> -glyph >> >> P.S.: speaking of build gymnastics, does anyone on this list happen to have a way to use CocoaPods or something similar to pull in open source Cocoa frameworks to a PyObjC application? > > I haven?t looked into this yet. I guess the hardest part is creating the metadata for constants and pointer arguments. Could you file and issue for this? Sure, sometime this weekend I'll try to write it up. -------------- next part -------------- An HTML attachment was scrubbed... URL: From ronaldoussoren at mac.com Sun Sep 23 06:00:53 2018 From: ronaldoussoren at mac.com (Ronald Oussoren) Date: Sun, 23 Sep 2018 12:00:53 +0200 Subject: [Pythonmac-SIG] [ANN] PyObjC 5.0 In-Reply-To: <3ACD74AC-FF04-4D57-8CC7-EACE50330EE6@twistedmatrix.com> References: <5125878D-F7B7-40FD-AA9F-F5C0E06463A4@mac.com> <9DF47F0A-FCDC-4601-9459-4F5D359939FF@mac.com> <3ACD74AC-FF04-4D57-8CC7-EACE50330EE6@twistedmatrix.com> Message-ID: <31D9948F-1EE6-4289-A6A1-55124B72DAEA@mac.com> > On 21 Sep 2018, at 23:24, Glyph wrote: > > > >> On Sep 21, 2018, at 4:50 AM, Ronald Oussoren > wrote: >> >> >> >>> On 21 Sep 2018, at 05:59, Glyph > wrote: >>> >>> On Sep 18, 2018, at 1:22 PM, Ronald Oussoren via Pythonmac-SIG > wrote: >>>> >>>> PyObjC 5.0 is out >>> >>> Thanks again for your tireless (or at least apparently tireless) maintenance, Ronald! >>> >>>> * Added bindings for the ?CarbonCore? subframework of the ?CoreServices? framework. >>>> >>>> Most APIs in this subframework are not available to Python, only those APIs that are not deprecated and seem interesting are exposed. >>> >>> One thing I wondered about when I saw "carbon" here is that I wonder if the APIs that could make https://pythonhosted.org/pyobjc/examples/Cocoa/AppKit/HotKeyPython/index.html are exposed again? >> >> The API used in that example is not exposed through PyObjC at this time (AFAIK it is part of ?Carbon.framework?, not the CarbonCore sub framework of ?CoreServices.framework?. >> >> I?m open to adding bindings to interesting APIs, but note that ?RegisterEventHotKey? is not documented on Apple?s website and might not be the right solution for modern code. I don?t know yet what the right solution is though (a number of APIs that are exposed through PyObjC can be used to implement similar functionality). > > If there were a more modern solution I'd gladly use it rather than asking you to expose gross and ancient Carbon APIs :). Which APIs that are already exposed can do this? Good question :-). I thought CGEventTapCreate and related APIs could be used for this, but now that I?ve reread the documentation I no longer think so. MASShortCut still uses the Carbon APIs in its implementation, which seems to confirm that there is no good modern alternative for the RegisterEventHotKey API. > >>> The cautions that the relevant Carbon APIs require 32-bit mode are inaccurate; https://blog.shpakovski.com/2012/07/global-keyboard-shortcuts-in-cocoa.html explains that they're still supported in sandboxed Mac App Store apps, so they're just poorly documented, not deprecated. (It seems that there's never been a proper Cocoa replacement for this functionality, just a couple of popular wrappers floating around out there?) >>> >>> This is something I have wanted to do in Python many times, but never quite badly enough to figure out all the build gymnastics required to get the bindings for https://github.com/shpakovski/MASShortcut built and bundled with my application. >> >> I?ll look into exposing this API for PyObjC 5.1, even if that means adding a very limited set of bindings for Carbon.framework. > > Thanks! > >>> -glyph >>> >>> P.S.: speaking of build gymnastics, does anyone on this list happen to have a way to use CocoaPods or something similar to pull in open source Cocoa frameworks to a PyObjC application? >> >> I haven?t looked into this yet. I guess the hardest part is creating the metadata for constants and pointer arguments. Could you file and issue for this? > > Sure, sometime this weekend I'll try to write it up. I have created an experimental binding to MASShortcut on my bitbucket account: https://bitbucket.org/ronaldoussoren/pyobjc-masshortcut . This library can be installed using ?pip install pyobjc-MASShortcut==1.0a0? (and has a wheel if you use a 64-bit installation of Python 3.7) This ?works? in the sense that I ran my unit tests with Python 3.6 (64-bit), but I have done no testing beyond that. Creating the bindings was fairly easy, but harder than it should be because the tooling I use to create bindings is primarily created for Apple?s system frameworks and has some issues with 3th-party frameworks. I do want to improve the tooling for this, but don?t know when I?ll get around to actually doing this. Ronald -------------- next part -------------- An HTML attachment was scrubbed... URL: From justvanrossum at gmail.com Thu Sep 27 10:05:20 2018 From: justvanrossum at gmail.com (Just van Rossum) Date: Thu, 27 Sep 2018 16:05:20 +0200 Subject: [Pythonmac-SIG] py2app -A and virtual environments Message-ID: Hi all, py2app seems to do the right thing from an activated virtual env when building a full app. However, for speedy development I use the py2app -A option a lot, and when running such an alias bundle it appears to use the global Python install instead of the virtual env. Is there a way around that? Just From justvanrossum at gmail.com Fri Sep 28 04:34:59 2018 From: justvanrossum at gmail.com (Just van Rossum) Date: Fri, 28 Sep 2018 10:34:59 +0200 Subject: [Pythonmac-SIG] py2app -A and virtual environments In-Reply-To: References: Message-ID: <10601342-3D10-4A17-965A-82C48C292A31@gmail.com> Following up to this: it seems line 1832 in py2app/build_app.py isn?t correct anymore, with Python 3 venv behavior: if os.path.exists(os.path.join(sys.prefix, ".Python")): Not sure how to fix it. If I force this code path to be taken, I get an AttributeError on sys.real_prefix, so I guess a bit more needs to be done. Just > On 27 Sep 2018, at 16:05, Just van Rossum wrote: > > Hi all, > > py2app seems to do the right thing from an activated virtual env when building a full app. However, for speedy development I use the py2app -A option a lot, and when running such an alias bundle it appears to use the global Python install instead of the virtual env. Is there a way around that? > > Just > From j.orponen at 4teamwork.ch Fri Sep 28 05:31:03 2018 From: j.orponen at 4teamwork.ch (Joni Orponen) Date: Fri, 28 Sep 2018 11:31:03 +0200 Subject: [Pythonmac-SIG] py2app -A and virtual environments In-Reply-To: <10601342-3D10-4A17-965A-82C48C292A31@gmail.com> References: <10601342-3D10-4A17-965A-82C48C292A31@gmail.com> Message-ID: On Fri, Sep 28, 2018 at 10:36 AM Just van Rossum wrote: > Following up to this: it seems line 1832 in py2app/build_app.py isn?t > correct anymore, with Python 3 venv behavior: > > if os.path.exists(os.path.join(sys.prefix, ".Python")): > > Not sure how to fix it. If I force this code path to be taken, I get an > AttributeError on sys.real_prefix, so I guess a bit more needs to be done. > Use py2app via setup.py. -- Joni Orponen -------------- next part -------------- An HTML attachment was scrubbed... URL: From ronaldoussoren at mac.com Fri Sep 28 07:08:07 2018 From: ronaldoussoren at mac.com (Ronald Oussoren) Date: Fri, 28 Sep 2018 13:08:07 +0200 Subject: [Pythonmac-SIG] py2app -A and virtual environments In-Reply-To: <10601342-3D10-4A17-965A-82C48C292A31@gmail.com> References: <10601342-3D10-4A17-965A-82C48C292A31@gmail.com> Message-ID: > On 28 Sep 2018, at 10:34, Just van Rossum wrote: > > Following up to this: it seems line 1832 in py2app/build_app.py isn?t correct anymore, with Python 3 venv behavior: > > if os.path.exists(os.path.join(sys.prefix, ".Python")): > > Not sure how to fix it. If I force this code path to be taken, I get an AttributeError on sys.real_prefix, so I guess a bit more needs to be done. The line of code is for virtualenv support. I?ll have to check the code to see what?s needed to support venv here as well. Ronald > > Just > >> On 27 Sep 2018, at 16:05, Just van Rossum wrote: >> >> Hi all, >> >> py2app seems to do the right thing from an activated virtual env when building a full app. However, for speedy development I use the py2app -A option a lot, and when running such an alias bundle it appears to use the global Python install instead of the virtual env. Is there a way around that? >> >> Just >> >