pyobjc-dev — CVS commit notices go here

[Pyobjc-dev] [ANN] py2app 0.16 and macholib 1.11

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

Hi,

I’ve released py2app 0.16 and macholib 1.11 with a couple of small changes.

The most important fix is in macholib and avoids the "New Mach-O header is too large to relocate in …” error when using Python wheels containing shared libraries (such as Pillow).



A full list of changes in py2app 0.16:

* #244: Copy the Tcl/Tk support libraries into the application bundle for
  Python builds using a classic unix install of Tcl/Tk instead of a framework
  build.

  This results in working app bundles when a Python.org installation that
  includes Tcl/Tk (such as Python 3.7).

* Don't copy numpy into application just because the application uses
  Pillow.

* Add recipe for Pyside

  Patch by Alberto Sottile

And macholib 1.11:

* Add very hacky limited support for @loader_path. This is just
  enough to deal with extensions and dylibs found in Python
  binary wheels.


Regards,

Ronald

[Pyobjc-dev] 10.14 branch merged into default

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

Hi,

I’ve merged the 10.14 branch into the default branch and will continue the work towards PyObjC 5.0 there.

My focus for near future w.r.t. PyObjC will be on testing the bindings with various python versions and macOS releases and adding some manual wrappers (C code) for a couple of APIs in the CoreMedia, CoreMediaIO and MediaToolbox frameworks.

Ronald

P.S. readthedocs.com <http://readthedocs.com/> is doing maintenance, hence https://pyobjc.readthedocs.io/ <https://pyobjc.readthedocs.io/> does not yet reflect my merge at this time. That should resolve itself automatically. 

[Pyobjc-dev] [ANN] First alpha release for PyObjC 5.0

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

[This is a cross-post from http://blog.ronaldoussoren.net]

I pushed a first alpha release for PyObjC 5.0 to PyPI, it can be installed with “pip install –pre pyobc”.

The major change in the 5.0 release is the addition of API bindings for macOS 10.14. This release is mostly up-to-date w.r.t. developer beta 3 of that release.

Other than updating existing API bindings this release adds new framework bindings for the following 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

The bindings for CoreAudio, CoreMedia and MediaToolbox aren’t fully usable in this release, I have to write C code for a number of APIs and data structures that cannot be accessed using the generic FFI in pyobjc-core.

This alpha release only included wheels for the 64-bit installer of Python 3.7 (the default download on Python.org), the final release will include the full set of wheels.

Footnote

The release is a week later and less complete than I had hoped earlier. The reason for that is primarily that I was too optimistic on the amount of work I’d be able to do before and during EuroPython. In the end I barely touched my computer for PyObjC work at EuroPython, and not at all during the trip around Scotland beforehand (both of which were good for me, but less so for making progress)

Regard,

  Ronald

[Pyobjc-dev] ANN: py2app 0.15

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

Hi,

I just pushed py2app 0.15 to PyPI. This has basically one change from the previous release: This release supports Python 3.7.

There are also updates to altgraph, modulegraph and macholib that should get automatically installed as well. 

Ronald

[Pyobjc-dev] Pointers to in-depth pyobjc tutorials, blogs, and StackOverflow answers.

[Shyamal C. <shy...@gm...>]

Hi,

Does anyone have pointers to in-depth pyobjc tutorials, blogs, and
StackOverflow answers?  I feel there needs to be more work to make the
pyobjc documentation more linear.  Any feedback?

Thanks,

Shyamal Chandra
shy...@gm...

[Pyobjc-dev] Towards PyObjC 5.0

[John F. <joh...@ma...>]

Thank you, Ronald! This is good news. 

-- 
John Finch

On July 10, 2018 at 1:00:34 PM, pyo...@li... (pyo...@li...(mailto:pyo...@li...)) wrote:

> Send Pyobjc-dev mailing list submissions to
> pyo...@li...
> 
> To subscribe or unsubscribe via the World Wide Web, visit
> https://lists.sourceforge.net/lists/listinfo/pyobjc-dev
> or, via email, send a message with subject or body 'help' to
> pyo...@li...
> 
> You can reach the person managing the list at
> pyo...@li...
> 
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of Pyobjc-dev digest..."
> 
> 
> Today's Topics:
> 
> 1. Towards PyObjC 5.0 (Ronald Oussoren)
> 
> 
> ----------------------------------------------------------------------
> 
> Message: 1
> Date: Tue, 10 Jul 2018 09:46:54 +0200
> From: Ronald Oussoren <ron...@ma...>
> To: pyobjc-dev list <pyo...@li...>, Pythonmac-Sig
> <pyt...@py...>
> Subject: [Pyobjc-dev] Towards PyObjC 5.0
> Message-ID: <6D0...@ma...>
> Content-Type: text/plain; charset=utf-8
> 
> Hi,
> 
> Just a quick message about development on PyObjC 5.0. The process of updating PyObjC for macOS 10.14 is going faster than expected, although it has helped that I took time of from work during WWDC to work on this.
> 
> I expect to push out a first beta release of PyObjC 5 during the EuroPython 2018 sprints. This release should be feature complete (barring surprises in future SDK betas).
> 
> This is turning out to be a major milestone for PyObjC: with some luck PyObjC 5.0 will support almost all public frameworks in macOS, with the exception of deprecated frameworks that aren?t already wrapped and the Metal frameworks (Metal and MetalPerformanceShaders).
> 
> Major items on my TODO list until then:
> - Finish a number of bindings that require manual wrappers due to APIs that are too complex to expres correctly in metadata files
> - Work on support for APIs that have SIMD types as arguments or return values (such as vector_float3 in ObjC)
> - Work on providing DeprecationWarnings for APIs that are deprecated in macOS. The basic framework for this is present, I ?just? have add correct metadata for this.
> 
> Beyond 5: My current plan is that PyObjC 5 will be the last version of PyObjC that supports Python 2.7 and PowerPC.
> 
> I have not yet decided on 32-bit x86 support, that might be dropped as well (at least in the released binaries). Dropping support for 32-bit x86 would primarily make it easier to provide wheels, as the compiler tools in Xcode 10 no longer support that architecture.
> 
> Ronald
> 
> 
> ------------------------------
> 
> ------------------------------------------------------------------------------
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> 
> ------------------------------
> 
> Subject: Digest Footer
> 
> _______________________________________________
> Pyobjc-dev mailing list
> Pyo...@li...
> https://lists.sourceforge.net/lists/listinfo/pyobjc-dev
> 
> 
> ------------------------------
> 
> End of Pyobjc-dev Digest, Vol 106, Issue 1
> ******************************************

[Pyobjc-dev] Towards PyObjC 5.0

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

Hi,

Just a quick message about development on PyObjC 5.0.  The process of updating PyObjC for macOS 10.14 is going faster than expected, although it has helped that I took time of from work during WWDC to work on this.

I expect to push out a first beta release of PyObjC 5 during the EuroPython 2018 sprints. This release should be feature complete (barring surprises in future SDK betas). 

This is turning out to be a major milestone for PyObjC: with some luck PyObjC 5.0 will support almost all public frameworks in macOS, with the exception of deprecated frameworks that aren’t already wrapped and the Metal frameworks (Metal and MetalPerformanceShaders).

Major items on my TODO list until then:
- Finish a number of bindings that require manual wrappers due to APIs that are too complex to expres correctly in metadata files
- Work on support for APIs that have SIMD types as arguments or return values (such as vector_float3 in ObjC)
- Work on providing DeprecationWarnings for APIs that are deprecated in macOS. The basic framework for this is present, I “just” have add correct metadata for this.

Beyond 5: My current plan is that PyObjC 5 will be the last version of PyObjC that supports Python 2.7 and PowerPC. 

I have not yet decided on 32-bit x86 support, that might be dropped as well (at least in the released binaries). Dropping support for 32-bit x86 would primarily make it easier to provide wheels, as the compiler tools in Xcode 10 no longer support that architecture.

Ronald

[Pyobjc-dev] PyObjC and macOS 10.14

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

Hi,

The PyObjC repository has grown a new branch: macos-10.14-support

I’ll use this branch to work on updating PyObjC for full support for macOS 10.14 and expect to spend most time on updating the exiting framework wrappers and adding new ones.

A textual diff between the SDK headers for macOS 10.13 and 10.14 is about 200K lines long, processing all that information will take quite some time. 

Ronald

P.S. I have a VM running, and the system Python is still only Python 2.7.10 :-(

[Pyobjc-dev] PyObjC 4.2.2

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

Hi,

I’ve pushed PyObjC 4.2.2 to PyPI. This is a very minor bug fix release that I’ve pushed out to clear the queue before WWDC.

There is one new feature with this release: There are now two variants of the binary wheels for Python 3.6 and 3.7, both now have variants for the universal build for macOS 10.6 or later (i386 and x86_64) as well as the 64-bit build for macOS 10.9 or later. 

Next up is support for the macOS release beyond High Sierra. I expect that this will take quite some time, especially w.r.t. updating the framework wrappers. 

Ronald

[Pyobjc-dev] Two new repos

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

Hi,

I’ve started two new repositories:

1) nibless: https://bitbucket.org/ronaldoussoren/nibless/src/default/ <https://bitbucket.org/ronaldoussoren/nibless/src/default/>

This is currently a minimal application with only a menubar. This will grow into a full application that does not use Xcode. 

I have three goals with this repository: create a substantial application that is a good example of how to use PyObjC, create Cocoa GUIs without relying on Xcode and finally develop convenience APIs on top of Apple’s Cocoa APIs to make developing easier.

2) py2app-rewrite: https://bitbucket.org/ronaldoussoren/py2app-rewrite/src/default/ <https://bitbucket.org/ronaldoussoren/py2app-rewrite/src/default/>

This is currently mostly empty apart from some documentation. My goal for this repository is to redesign and rewrite py2app to end up with a modern and maintainable tool for building application bundles.  

My current plan is to build a tool that is not setuptools command but a standalone tool with structured configuration file (the repo says that this file will use TOML, but I’ll probably switch to YAML as a nicer to edit format).  There currently is no code in the repository.  

The reason I’m starting from scratch is that py2app’s current code base is a mess that’s hard to change due to a lack of tests and a code structure that makes adding tests unnecessarily hard. 


Both projects are Python 3 only (currently targeting 3.6, that might change in the future). I have no intention of supporting Python 2 for these projects.

Ronald

P.S. I expect progress on both projects to be slow because I’m working on these in my free time and there’s not a lot of that due to other hobbies.  I also expect to have a lot of work to do after WWDC to prepare PyObjC’s framework wrappers for the next release of macOS.

Re: [Pyobjc-dev] Synchronous venue?

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

> On 17 Apr 2018, at 15:26, Zachery Bir <zb...@za...> wrote:
> 
> Also, it seems the #macpython channel is a bit underused. Is there a better place where folks congregate synchronously? A Slack or the like?

I don’t know.  I’m pretty much e-mail only at the moment, although I am trying to at least follow conversations in the new Zulip instance for Python. 

Ronald

Re: [Pyobjc-dev] Reviving an old PyObjC app

[Marc V. O. <ma...@ac...>]

Diez,

I just downloaded your sample project. And that raises a question: I see

    view = IBOutlet("view")

but how do I make Xcode 9.x recognize a new outlet or a new action I want
to add.
In the past I was able to do that in old Interface Builder because you
manually type the outlets and actions in the Library tool but I haven't
found a way to do that in in Xcode. For that reason I have not converted my
older .nib files to the new format.

thanks

Marc.


On Tue, Apr 17, 2018 at 11:00 AM, Diez B. Roggisch <de...@we...> wrote:

> Maybe this helps you:
>
>  https://github.com/deets/minimal-pyobjc/tree/outlets-and-actions
>
> It’s a small example project I created for a talk. It worked until quite
> recently for me after Xcode transitioned to the built-in IB, and XIBs.
> Haven’t checked it in a while, but maybe it gives you a headstart.
>
> Cheers,
>
> Diez
>
> On 17. Apr 2018, at 15:10, Zachery Bir <zb...@za...> wrote:
>
> Hey, all
>
> I’m resurrecting an app I wrote years ago. In addition to updating it to
> Python 3, I’m also trying to get it happy with modern Xcode. I’ve removed
> the NibClassBuilder references, but I’m not entirely sure the best way to
> make it IB-able. The docs seems to be pinned to much older versions of
> Xcode, and the File -> Read Class Files has long gone. Anyone have any
> updated pointers for using modern Xcode (9+) with PyObjC? I’m happy to
> contribute updated docs once I’ve made the transition myself.
>
> Thanks,
>
> Zac
>
>
> ------------------------------------------------------------
> ------------------
> 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
>
>
>
> ------------------------------------------------------------
> ------------------
> 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] Reviving an old PyObjC app

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

Hi Marc,

disclaimer: I last checket with xcode 8.x, so this might have broken.

What happens for me is that these outlets (and actions) just appear in IB after I add them to the classes. There seems to be some at least basic parsing of the class declarations happening.

Cheers,

Diez

> On 17. Apr 2018, at 17:49, Marc Van Olmen <ma...@ac...> wrote:
> 
> Diez,
> 
> I just downloaded your sample project. And that raises a question: I see
> 
>     view = IBOutlet("view")
> 
> but how do I make Xcode 9.x recognize a new outlet or a new action I want to add.
> In the past I was able to do that in old Interface Builder because you manually type the outlets and actions in the Library tool but I haven't found a way to do that in in Xcode. For that reason I have not converted my older .nib files to the new format.
> 
> thanks
> 
> Marc.
> 
> 
> On Tue, Apr 17, 2018 at 11:00 AM, Diez B. Roggisch <de...@we... <mailto:de...@we...>> wrote:
> Maybe this helps you:
> 
>  https://github.com/deets/minimal-pyobjc/tree/outlets-and-actions <https://github.com/deets/minimal-pyobjc/tree/outlets-and-actions>
> 
> It’s a small example project I created for a talk. It worked until quite recently for me after Xcode transitioned to the built-in IB, and XIBs. Haven’t checked it in a while, but maybe it gives you a headstart.
> 
> Cheers,
> 
> Diez
> 
>> On 17. Apr 2018, at 15:10, Zachery Bir <zb...@za... <mailto:zb...@za...>> wrote:
>> 
>> Hey, all
>> 
>> I’m resurrecting an app I wrote years ago. In addition to updating it to Python 3, I’m also trying to get it happy with modern Xcode. I’ve removed the NibClassBuilder references, but I’m not entirely sure the best way to make it IB-able. The docs seems to be pinned to much older versions of Xcode, and the File -> Read Class Files has long gone. Anyone have any updated pointers for using modern Xcode (9+) with PyObjC? I’m happy to contribute updated docs once I’ve made the transition myself.
>> 
>> Thanks,
>> 
>> Zac
>> 
>> 
>> ------------------------------------------------------------------------------
>> Check out the vibrant tech community on one of the world's most
>> engaging tech sites, Slashdot.org <http://slashdot.org/>! http://sdm.link/slashdot <http://sdm.link/slashdot>
>> _______________________________________________
>> Pyobjc-dev mailing list
>> Pyo...@li... <mailto:Pyo...@li...>
>> https://lists.sourceforge.net/lists/listinfo/pyobjc-dev <https://lists.sourceforge.net/lists/listinfo/pyobjc-dev>
> 
> 
> ------------------------------------------------------------------------------
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot <http://sdm.link/slashdot>
> _______________________________________________
> Pyobjc-dev mailing list
> Pyo...@li... <mailto:Pyo...@li...>
> https://lists.sourceforge.net/lists/listinfo/pyobjc-dev <https://lists.sourceforge.net/lists/listinfo/pyobjc-dev>
> 
> 

Re: [Pyobjc-dev] Reviving an old PyObjC app

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

Don’t forget to check out the various branches - I did this to switch seamlessly during the talk.

Cheers,

Diez

> On 17. Apr 2018, at 17:01, Zachery Bir <zb...@za...> wrote:
> 
> Fantastic, thanks!
> 
> Zac
> 
>> On Apr 17, 2018, at 11:00 AM, Diez B. Roggisch <de...@we... <mailto:de...@we...>> wrote:
>> 
>> Maybe this helps you:
>> 
>>  https://github.com/deets/minimal-pyobjc/tree/outlets-and-actions <https://github.com/deets/minimal-pyobjc/tree/outlets-and-actions>
>> 
>> It’s a small example project I created for a talk. It worked until quite recently for me after Xcode transitioned to the built-in IB, and XIBs. Haven’t checked it in a while, but maybe it gives you a headstart.
>> 
>> Cheers,
>> 
>> Diez
>> 
>>> On 17. Apr 2018, at 15:10, Zachery Bir <zb...@za... <mailto:zb...@za...>> wrote:
>>> 
>>> Hey, all
>>> 
>>> I’m resurrecting an app I wrote years ago. In addition to updating it to Python 3, I’m also trying to get it happy with modern Xcode. I’ve removed the NibClassBuilder references, but I’m not entirely sure the best way to make it IB-able. The docs seems to be pinned to much older versions of Xcode, and the File -> Read Class Files has long gone. Anyone have any updated pointers for using modern Xcode (9+) with PyObjC? I’m happy to contribute updated docs once I’ve made the transition myself.
>>> 
>>> Thanks,
>>> 
>>> Zac
>>> 
>>> 
>>> ------------------------------------------------------------------------------
>>> Check out the vibrant tech community on one of the world's most
>>> engaging tech sites, Slashdot.org <http://slashdot.org/>! http://sdm.link/slashdot <http://sdm.link/slashdot>
>>> _______________________________________________
>>> Pyobjc-dev mailing list
>>> Pyo...@li... <mailto:Pyo...@li...>
>>> https://lists.sourceforge.net/lists/listinfo/pyobjc-dev <https://lists.sourceforge.net/lists/listinfo/pyobjc-dev>
>> 
> 

Re: [Pyobjc-dev] Reviving an old PyObjC app

[Zachery B. <zb...@za...>]

Fantastic, thanks!

Zac

> On Apr 17, 2018, at 11:00 AM, Diez B. Roggisch <de...@we...> wrote:
> 
> Maybe this helps you:
> 
>  https://github.com/deets/minimal-pyobjc/tree/outlets-and-actions <https://github.com/deets/minimal-pyobjc/tree/outlets-and-actions>
> 
> It’s a small example project I created for a talk. It worked until quite recently for me after Xcode transitioned to the built-in IB, and XIBs. Haven’t checked it in a while, but maybe it gives you a headstart.
> 
> Cheers,
> 
> Diez
> 
>> On 17. Apr 2018, at 15:10, Zachery Bir <zb...@za... <mailto:zb...@za...>> wrote:
>> 
>> Hey, all
>> 
>> I’m resurrecting an app I wrote years ago. In addition to updating it to Python 3, I’m also trying to get it happy with modern Xcode. I’ve removed the NibClassBuilder references, but I’m not entirely sure the best way to make it IB-able. The docs seems to be pinned to much older versions of Xcode, and the File -> Read Class Files has long gone. Anyone have any updated pointers for using modern Xcode (9+) with PyObjC? I’m happy to contribute updated docs once I’ve made the transition myself.
>> 
>> Thanks,
>> 
>> Zac
>> 
>> 
>> ------------------------------------------------------------------------------
>> Check out the vibrant tech community on one of the world's most
>> engaging tech sites, Slashdot.org <http://slashdot.org/>! http://sdm.link/slashdot <http://sdm.link/slashdot>
>> _______________________________________________
>> Pyobjc-dev mailing list
>> Pyo...@li... <mailto:Pyo...@li...>
>> https://lists.sourceforge.net/lists/listinfo/pyobjc-dev
> 

Re: [Pyobjc-dev] Reviving an old PyObjC app

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

Maybe this helps you:

 https://github.com/deets/minimal-pyobjc/tree/outlets-and-actions <https://github.com/deets/minimal-pyobjc/tree/outlets-and-actions>

It’s a small example project I created for a talk. It worked until quite recently for me after Xcode transitioned to the built-in IB, and XIBs. Haven’t checked it in a while, but maybe it gives you a headstart.

Cheers,

Diez

> On 17. Apr 2018, at 15:10, Zachery Bir <zb...@za...> wrote:
> 
> Hey, all
> 
> I’m resurrecting an app I wrote years ago. In addition to updating it to Python 3, I’m also trying to get it happy with modern Xcode. I’ve removed the NibClassBuilder references, but I’m not entirely sure the best way to make it IB-able. The docs seems to be pinned to much older versions of Xcode, and the File -> Read Class Files has long gone. Anyone have any updated pointers for using modern Xcode (9+) with PyObjC? I’m happy to contribute updated docs once I’ve made the transition myself.
> 
> Thanks,
> 
> Zac
> 
> 
> ------------------------------------------------------------------------------
> 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] Synchronous venue?

[Zachery B. <zb...@za...>]

Also, it seems the #macpython channel is a bit underused. Is there a better place where folks congregate synchronously? A Slack or the like?

Zac

[Pyobjc-dev] Reviving an old PyObjC app

[Zachery B. <zb...@za...>]

Hey, all

I’m resurrecting an app I wrote years ago. In addition to updating it to Python 3, I’m also trying to get it happy with modern Xcode. I’ve removed the NibClassBuilder references, but I’m not entirely sure the best way to make it IB-able. The docs seems to be pinned to much older versions of Xcode, and the File -> Read Class Files has long gone. Anyone have any updated pointers for using modern Xcode (9+) with PyObjC? I’m happy to contribute updated docs once I’ve made the transition myself.

Thanks,

Zac

Re: [Pyobjc-dev] Namespaces, intended behavior?

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

That is correct. There is another reason for that: the lazy loader I mentioned.  Apple’s frameworks expose a lot of names and * imports force PyObjC to create Python versions of all of them which uses memory and more importantly takes significant time. 

Ronald

--
On the road, hence brief. 

Op 5 apr. 2018 om 18:43 heeft Just van Rossum <jus...@gm...> het volgende geschreven:

> 
>> On 05 Apr 2018, at 18:12, Ronald Oussoren <ron...@ma...> wrote:
>> 
>> 
>> 
>>> On 5 Apr 2018, at 17:39, Just van Rossum <jus...@gm...> wrote:
>>> 
>>> Hi,
>>> 
>>> I am wondering, is the following intended behavior?
>>> 
>>> -------------
>>> import Foundation
>>> 
>>> class TestMyCustomObject(Foundation.NSObject):
>>>  pass
>>> 
>>> import AppKit
>>> # it's suddenly available via AppKit:
>>> print(AppKit.TestMyCustomObject)
>>> # even via import *:
>>> from AppKit import *
>>> print(TestMyCustomObject)
>>> -------------
>>> 
>>> Thanks,
>> 
>> That is expected behavior and is a side effect of lazy loading of frameworks.
>> 
>> In the past I have attempted to expose only the classes that belong in a framework (by exposing only those classes located in the correct framework bundle), but that code turned out to be too slow (because the Cocoa method I used for that is slow), so that got dropped a long time ago. When I started on the lazy loader I didn’t even try to make it guess whether or not a class should be loadable through the current framework wrapper.  This is not ideal, but good enough.
> 
> Thanks for the clarification. That does mean that one should pretty much never ever do
> 
>  from SomeFramework import *
> 
> Despite the fact that most frameworks have decent prefixes for their sybols.
> 
> Just
> 

Re: [Pyobjc-dev] Namespaces, intended behavior?

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

> On 05 Apr 2018, at 18:12, Ronald Oussoren <ron...@ma...> wrote:
> 
> 
> 
>> On 5 Apr 2018, at 17:39, Just van Rossum <jus...@gm...> wrote:
>> 
>> Hi,
>> 
>> I am wondering, is the following intended behavior?
>> 
>> -------------
>> import Foundation
>> 
>> class TestMyCustomObject(Foundation.NSObject):
>>   pass
>> 
>> import AppKit
>> # it's suddenly available via AppKit:
>> print(AppKit.TestMyCustomObject)
>> # even via import *:
>> from AppKit import *
>> print(TestMyCustomObject)
>> -------------
>> 
>> Thanks,
> 
> That is expected behavior and is a side effect of lazy loading of frameworks.
> 
> In the past I have attempted to expose only the classes that belong in a framework (by exposing only those classes located in the correct framework bundle), but that code turned out to be too slow (because the Cocoa method I used for that is slow), so that got dropped a long time ago. When I started on the lazy loader I didn’t even try to make it guess whether or not a class should be loadable through the current framework wrapper.  This is not ideal, but good enough.

Thanks for the clarification. That does mean that one should pretty much never ever do

  from SomeFramework import *

Despite the fact that most frameworks have decent prefixes for their sybols.

Just

Re: [Pyobjc-dev] Namespaces, intended behavior?

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

> On 5 Apr 2018, at 17:39, Just van Rossum <jus...@gm...> wrote:
> 
> Hi,
> 
> I am wondering, is the following intended behavior?
> 
> -------------
> import Foundation
> 
> class TestMyCustomObject(Foundation.NSObject):
>    pass
> 
> import AppKit
> # it's suddenly available via AppKit:
> print(AppKit.TestMyCustomObject)
> # even via import *:
> from AppKit import *
> print(TestMyCustomObject)
> -------------
> 
> Thanks,

That is expected behavior and is a side effect of lazy loading of frameworks.

In the past I have attempted to expose only the classes that belong in a framework (by exposing only those classes located in the correct framework bundle), but that code turned out to be too slow (because the Cocoa method I used for that is slow), so that got dropped a long time ago. When I started on the lazy loader I didn’t even try to make it guess whether or not a class should be loadable through the current framework wrapper.  This is not ideal, but good enough.

Ronald

[Pyobjc-dev] Namespaces, intended behavior?

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

Hi,

I am wondering, is the following intended behavior?

-------------
import Foundation

class TestMyCustomObject(Foundation.NSObject):
    pass
    
import AppKit
# it's suddenly available via AppKit:
print(AppKit.TestMyCustomObject)
# even via import *:
from AppKit import *
print(TestMyCustomObject)
-------------

Thanks,

Just

[Pyobjc-dev] ANN: PyObjC 4.2.1

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

Hi,

I just pushed PyObjC 4.2.1 to PyPI. This is a very minor bug fix release and most people don’t have to upgrade. 

There’s only a single fix for some people from source: the automatic detection of the use of “—with-system-ffi” works again (it was disabled in 4.2 because that feature didn’t work with /usr/bin/python).

The fix doesn’t affect users of binary wheels.

Ronald

[Pyobjc-dev] Publishing PyObjC 4.2

[John F. <joh...@ma...>]

Thank you Ronald et. al., very much appreciated!


> On Apr 2, 2018, at 8:00 AM, pyo...@li... wrote:
> 
> Send Pyobjc-dev mailing list submissions to
> 	pyo...@li...
> 
> To subscribe or unsubscribe via the World Wide Web, visit
> 	https://lists.sourceforge.net/lists/listinfo/pyobjc-dev
> or, via email, send a message with subject or body 'help' to
> 	pyo...@li...
> 
> You can reach the person managing the list at
> 	pyo...@li...
> 
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of Pyobjc-dev digest..."
> 
> 
> Today's Topics:
> 
>   1. ANN: PyObjC 4.2 (Ronald Oussoren)
> 
> 
> ----------------------------------------------------------------------
> 
> Message: 1
> Date: Sun, 01 Apr 2018 13:52:11 +0200
> From: Ronald Oussoren <ron...@ma...>
> To: pyobjc-dev list <pyo...@li...>, Pythonmac-Sig
> 	<pyt...@py...>
> Subject: [Pyobjc-dev] ANN: PyObjC 4.2
> Message-ID: <B7A...@ma...>
> Content-Type: text/plain; charset="utf-8"
> 
> I?ve just published PyObjC 4.2 on PyPI. This is primarily a bug fix release, but also introduces bindings to the BusinessChat framework introduced in macOS 10.13.4.  Those bindings are probably totally uninteresting for most users as the framework can only be used by a small subset of macOS developers. 
> 
> The full list of changes for this release:
> 
> * Add bindings to the BusinessChat framework introduced in macOS 10.13.4
> 
> * Update metadata for Xcode 9.3
> 
> * Issue #233 Fix crash in Security.AuthorizationCopyRights() wrapper
> 
> * Issue #234 Fix crash in AuthorizationExecuteWithPrivileges() wrapper
> 
>  Reported by Vangelis Koukis
> 
> * Ensure doctest can work with modules containing subclasses of NSObject
> 
>  Reported by Just van Rossum
> 
> * Issue #236 : Importing can sometimes fail in multi-threaded scenarios
> 
>  Fix by Max B?langer
> 
> * Undeprecate treating struct wrappers as sequences. Removing this feature would
>  break too much existing code, hence deprecating is not really an option. Furthermore,
>  this would also break some nice idioms.
> 
> 
> * Pull request #17: Fix python 3 issues in PyObjCTools.AppHelper and PyObjCTools.Conversion
> 
>  Fix by Max B?langer
> 
> 
> Regards,
> 
>  Ronald
> -------------- next part --------------
> An HTML attachment was scrubbed...
> 
> ------------------------------
> 
> ------------------------------------------------------------------------------
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> 
> ------------------------------
> 
> Subject: Digest Footer
> 
> _______________________________________________
> Pyobjc-dev mailing list
> Pyo...@li...
> https://lists.sourceforge.net/lists/listinfo/pyobjc-dev
> 
> 
> ------------------------------
> 
> End of Pyobjc-dev Digest, Vol 103, Issue 1
> ******************************************

[Pyobjc-dev] ANN: PyObjC 4.2

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

I’ve just published PyObjC 4.2 on PyPI. This is primarily a bug fix release, but also introduces bindings to the BusinessChat framework introduced in macOS 10.13.4.  Those bindings are probably totally uninteresting for most users as the framework can only be used by a small subset of macOS developers. 

The full list of changes for this release:

* Add bindings to the BusinessChat framework introduced in macOS 10.13.4

* Update metadata for Xcode 9.3

* Issue #233 Fix crash in Security.AuthorizationCopyRights() wrapper

* Issue #234 Fix crash in AuthorizationExecuteWithPrivileges() wrapper

  Reported by Vangelis Koukis

* Ensure doctest can work with modules containing subclasses of NSObject

  Reported by Just van Rossum

* Issue #236 : Importing can sometimes fail in multi-threaded scenarios

  Fix by Max Bélanger

* Undeprecate treating struct wrappers as sequences. Removing this feature would
  break too much existing code, hence deprecating is not really an option. Furthermore,
  this would also break some nice idioms.


* Pull request #17: Fix python 3 issues in PyObjCTools.AppHelper and PyObjCTools.Conversion

  Fix by Max Bélanger


Regards,

  Ronald