pyobjc-dev — CVS commit notices go here

[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

Re: [Pyobjc-dev] @python_method rationale?

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

The change is intentional and makes it possible to to write nicer code without running into vague issues. I fixed a number of bugs in my code when I made PyObjC more strict and started requiring the use of @python_method when writing (basically) PEP8-style method names. 

In hindsight it would have been better to have required explicit marking of methods that need to be called from Objective-C, but that’s not something I can change at this point. 

Ronald

> On 11 Mar 2018, at 08:42, Just van Rossum <jus...@gm...> wrote:
> 
> Hi,
> 
> I’m curious about the rationale of the @python_method decorator from the objc module.
> 
> In current PyObjC versions any method in an NSObject subclass that does not conform to the ObjC conventions need to be decorated with @python_method. I understand this means such methods can’t be called from ObjC.
> 
> The thing is, when I’m writing Python code, I am well aware of what will be a valid ObjC method and what won’t be. I write lots of methods that I know will never be accessed from the ObjC side, and I’m fine with that. I want to write Pythonic code, so I have no interest in using ObjC selector naming conventions for such methods. Yet my code is now necessarily littered with @python_method decorators, which feels clumsy and ugly, and goes against the point of wanting to write clean Python code that does _not_ use the ObjC naming conventions. I’m currently looking at a page of code containing seven methods, _all_ of which have the decorator, which makes me sad :)
> 
> I long for the “old” days when these things “just worked”, and there was simple and clean code on the Python side.
> 
> If I omit the decorator, an exception is raised: objc.BadPrototypeError. So PyObjC already knows that that method is not conforming.
> 
> I feel this is a case of “explicit is better than implicit” going too far.
> 
> Maybe I’m missing something, but how is the @python_method decorator actually solving problems? So far it’s only gettin in my way.
> 
> Thanks for any insights,
> 
> 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] @python_method rationale?

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

Just,

My thoughts on this:

I have been doing PyOBJC for about 8 years because the previous team started the project like this and they created like 600 files/classes…
So this exception was introduced about a year ago, so it took me 1 day to upgrade the source code, but with this I found like a dozen of mistakes of misnamed methods.

1. So personally I prefer this approach, because it finds errors early, just as the editor with integrated PEP 8 linter finds typos early… I would regret if this functionality would go away.
2. Usually when I have a lot of python methods, this usually goes in a separate python class, with python naming conventions, and the PyObJC class is more like an interface that hides this python class. Just as Model-View-Controller… where the View in this case is the PyObjc class.

Maybe for you there should be a kind of "class decorator/flag" that you don’t care about it for this class.

best

Marc




> On Mar 11, 2018, at 3:42 AM, Just van Rossum <jus...@gm...> wrote:
> 
> Hi,
> 
> I’m curious about the rationale of the @python_method decorator from the objc module.
> 
> In current PyObjC versions any method in an NSObject subclass that does not conform to the ObjC conventions need to be decorated with @python_method. I understand this means such methods can’t be called from ObjC.
> 
> The thing is, when I’m writing Python code, I am well aware of what will be a valid ObjC method and what won’t be. I write lots of methods that I know will never be accessed from the ObjC side, and I’m fine with that. I want to write Pythonic code, so I have no interest in using ObjC selector naming conventions for such methods. Yet my code is now necessarily littered with @python_method decorators, which feels clumsy and ugly, and goes against the point of wanting to write clean Python code that does _not_ use the ObjC naming conventions. I’m currently looking at a page of code containing seven methods, _all_ of which have the decorator, which makes me sad :)
> 
> I long for the “old” days when these things “just worked”, and there was simple and clean code on the Python side.
> 
> If I omit the decorator, an exception is raised: objc.BadPrototypeError. So PyObjC already knows that that method is not conforming.
> 
> I feel this is a case of “explicit is better than implicit” going too far.
> 
> Maybe I’m missing something, but how is the @python_method decorator actually solving problems? So far it’s only gettin in my way.
> 
> Thanks for any insights,
> 
> 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

[Pyobjc-dev] @python_method rationale?

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

Hi,

I’m curious about the rationale of the @python_method decorator from the objc module.

In current PyObjC versions any method in an NSObject subclass that does not conform to the ObjC conventions need to be decorated with @python_method. I understand this means such methods can’t be called from ObjC.

The thing is, when I’m writing Python code, I am well aware of what will be a valid ObjC method and what won’t be. I write lots of methods that I know will never be accessed from the ObjC side, and I’m fine with that. I want to write Pythonic code, so I have no interest in using ObjC selector naming conventions for such methods. Yet my code is now necessarily littered with @python_method decorators, which feels clumsy and ugly, and goes against the point of wanting to write clean Python code that does _not_ use the ObjC naming conventions. I’m currently looking at a page of code containing seven methods, _all_ of which have the decorator, which makes me sad :)

I long for the “old” days when these things “just worked”, and there was simple and clean code on the Python side.

If I omit the decorator, an exception is raised: objc.BadPrototypeError. So PyObjC already knows that that method is not conforming.

I feel this is a case of “explicit is better than implicit” going too far.

Maybe I’m missing something, but how is the @python_method decorator actually solving problems? So far it’s only gettin in my way.

Thanks for any insights,

Just