pyobjc-dev

Re: [Pyobjc-dev] [Pythonmac-SIG] Towards PyObjC 3.0

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

Hi,

I'm continuing to work on PyObjC and hope to push a release to PyPI next weekend.  Development is going very slowly at the moment due to lack of time on my end, I'm doing all development in my spare time and that's filled with other stuff at the moment (and has been for a while).

I have no reason to assume that PyObjC won't work on 10.10, with some luck I'll "only" have to update the metadata to support new APIs. That's annoying work, but not very hard.

From what I've seen so far, and that's only a 5 minute glance at the public documentation, Swift will be a competing product as an easy scripting-like way to build applications. That's no reason to stop work on PyObjC though, I'm using PyObjC to write GUIs for applications where most of the code is written in Python and is using cross-platform Python code. Swift changes nothing for that use case w.r.t. Objective-C.

Swift might provide both opportunities and challenges in the future: Swift method names seem to be more like classic C- (and Python-) style names and not segmented names as used by Objective-C. As Swift can use existing ObjC libraries there might be some kind of translation table for method names, and if that exists this could be used by PyObjC as well to provide nicer names in Python code (instead of the ugly names we have to use now).

A possible challenge is the runtime model of Swift: I have no idea if Swift has, or will have, runtime introspection possibilities that could be used in the future to expose Swift libraries to Python code.  

Ronald

On Jun 03, 2014, at 12:40 PM, Adam Morris <am...@mi...> wrote:

I'm also very eager to hear an update, but PyObjC is going to be competing with Swift now!

        > On Jun 3, 2014, at 4:59 PM, Nicholas Cole <nic...@gm...    > wrote:
        > 
        > Hi Roland,
        > 
        > Could we all have an update on development plans? Do you think PyObjC
        > is going to work nicely with OS X 10.10?
        > 
        > N.
        > 
        > On Mon, Aug 26, 2013 at 12:42 PM, Ronald Oussoren
        > <ron...@ma...  > wrote:
        >        > 
        >        >        > On 4 Jul, 2013, at 17:08, Ronald Oussoren <ron...@ma...      > wrote:
        >        >        > 
        >        >        > My self-imposed dead-line for a 3.0 release is "before OSX 10.9 is released", that's the easiest way to avoid getting carried away with wrapping all new APIs in OSX 10.9 and delaying the release even further.
        >        > 
        >        > That seems to be overly optimistic on my part, I've done almost no work on PyObjC since my previous mail due to lack of time.
        >        > 
        >        > Ronald
        >        > _______________________________________________
        >        > Pythonmac-SIG maillist - Pyt...@py...
        >        > http://mail.python.org/mailman/listinfo/pythonmac-sig
        >        > unsubscribe: http://mail.python.org/mailman/options/Pythonmac-SIG
        > _______________________________________________
        > Pythonmac-SIG maillist - Pyt...@py...
        > https://mail.python.org/mailman/listinfo/pythonmac-sig
        > unsubscribe: https://mail.python.org/mailman/options/Pythonmac-SIG

Re: [Pyobjc-dev] [Pythonmac-SIG] Towards PyObjC 3.0

[Nicholas C. <nic...@gm...>]

On Tue, Jun 3, 2014 at 12:06 PM, Ronald Oussoren <ron...@ma...> wrote:

> From what I've seen so far, and that's only a 5 minute glance at the public
> documentation, Swift will be a competing product as an easy scripting-like
> way to build applications. That's no reason to stop work on PyObjC though,
> I'm using PyObjC to write GUIs for applications where most of the code is
> written in Python and is using cross-platform Python code. Swift changes
> nothing for that use case w.r.t. Objective-C.

I'm very glad to hear you say this.  I have downloaded the
documentation for Swift, and read it.  It looks like a huge
improvement on Objective-C, but I would have been very sad indeed if
it had led you to abandon PyObjC.  In fact, if you are right that
there is now some kind of translation table that could make PyObjC
method names even better, that would be really brilliant.

N.

Re: [Pyobjc-dev] [Pythonmac-SIG] Towards PyObjC 3.0

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

On 03 Jun 2014, at 15:00, Nicholas Cole <nic...@gm...> wrote:

>   In fact, if you are right that
> there is now some kind of translation table that could make PyObjC
> method names even better, that would be really brilliant.

I was too optimistic about that, looking at the section about methods in the Swift book (page 339 and onwards) Swift by default treats the second and later arguments of a method as function parameters with “external names” (see page 221 for a definition of that), which similar to required keyword parameters in Python 3, that is:

       func splitBy(separator: String, maxCount: Int) -> Array { …}

as a method on a String-like class is more or less similar to the following Python definition:

       def splitBy(separator, *, maxCount): …

And that cleanly translates into:

     -(NSArray) splitBySeparator:(NSString*)separator maxCount:(NSInteger)maxCount;

More importantly, it should generally be trivial to derive the Swift definition from the Objective-C one. 

I’ve in the past looked at using keyword arguments (basically a **kwds argument) to do something similar for PyObjC, but that doesn’t work in general because the order of keyword arguments in a call isn’t preserved in “kwds”, and that makes it expensive to derive Objective-C selector from the keyword dictionary (and in theory there might be two methods with the same segments in a different order). 

There’s been some talk about using an OrderedDict for the dictionary that’s used for **kwds on python-list, but I don’t recall the result of that discussion and even that did work out that would at best turn up in Python 3.5.

BTW. It might be possible to use a similar algorithm to derive Pythonic names for Objective-C selectors, but that would either require eagerly scanning the methods in an class, or doing the work up front and storing the result in metadata. Neither option is particularly appealing.  But you never know, maybe Swift inspires me to come up with a smart solution to the naming problem ;-)

Ronald

P.S. This is still without having read the Swift documentation.

Re: [Pyobjc-dev] [Pythonmac-SIG] Towards PyObjC 3.0

[Greg E. <gre...@ca...>]

Nicholas Cole wrote:
> In fact, if you are right that
> there is now some kind of translation table that could make PyObjC
> method names even better, that would be really brilliant.

I've just been looking at "A Swift Tour" here:

https://developer.apple.com/library/prerelease/ios/documentation/Swift/Conceptual/Swift_Programming_Language/GuidedTour.html#//apple_ref/doc/uid/TP40014097-CH2-XID_1

and it seems that the reality is rather less brilliant than that.
The following paragraph sets some alarm bells ringing:

"Methods on classes have one important difference from functions. Parameter
names in functions are used only within the function, but parameters names in
methods are also used when you call the method (except for the first
parameter)."

Then it gives an example:

   class Counter {
     ...
     func incrementBy(amount: Int, numberOfTimes times: Int) {
        ...

and how to call it:

   counter.incrementBy(2, numberOfTimes: 7)

It doesn't explicitly say at that point, but I strongly suspect that
you *have* to call it *exactly* like that, and not any of these ways:

   counter.incrementBy(2, 7)
   counter.incrementBy(amount: 2, numberOfTimes: 7)
   counter.incrementBy(numberOfTimes: 7, amount: 2)

In other words, it's just syntactic sugar for an Objective-C method
call, and not a true keyword-argument system. Which is rather disappointing,
and doesn't help at all with interfacing to Python.

-- 
Greg

Re: [Pyobjc-dev] [Pythonmac-SIG] Towards PyObjC 3.0

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

On Jun 3, 2014, at 4:46 PM, Greg Ewing <gre...@ca...> wrote:

> In other words, it's just syntactic sugar for an Objective-C method
> call, and not a true keyword-argument system. Which is rather disappointing,
> and doesn't help at all with interfacing to Python.

Or it is rather exactly precise, unlike keyword argument based systems.

(see the archives, this has been flogged to death about a zillion times in the 20 year -- yes 20! -- of PyObjC)

b.bum

Re: [Pyobjc-dev] [Pythonmac-SIG] Towards PyObjC 3.0

[Greg E. <gre...@ca...>]

Bill Bumgarner wrote:

> Or it is rather exactly precise, unlike keyword argument based systems.

What I mean is that it's not a keyword argument system
like Python has. It's disappointing because what's the
point of keyword args if you can't be flexible about
their ordering, give them default values, etc...?

It looks like Swift improves on ObjC in other areas,
such as closures, type inference and parameterised types,
but in this particular area it's no better.

-- 
Greg

[Pyobjc-dev] Fwd: [Pythonmac-SIG] Towards PyObjC 3.0

[Nicholas C. <nic...@gm...>]

On Wed, Jun 4, 2014 at 12:46 AM, Greg Ewing <gre...@ca...> wrote:
>    counter.incrementBy(2, numberOfTimes: 7)
>
> It doesn't explicitly say at that point, but I strongly suspect that
> you *have* to call it *exactly* like that, and not any of these ways:
>
>    counter.incrementBy(2, 7)
>    counter.incrementBy(amount: 2, numberOfTimes: 7)
>    counter.incrementBy(numberOfTimes: 7, amount: 2)
>
> In other words, it's just syntactic sugar for an Objective-C method
> call, and not a true keyword-argument system. Which is rather disappointing,
> and doesn't help at all with interfacing to Python.

The manual says that this is optional, and that you can define the
first argument as a keyword one.  You can also define default values,
so perhaps it is not quite as restrictive as you fear.

The first-arguemt-is-by-default-not-a-keyword is the kind of thing
that makes sense now, as developers move from Obj-C, but surely is
going to feel very odd if swift ever catches on.

Re: [Pyobjc-dev] [Pythonmac-SIG] Towards PyObjC 3.0

[Hans M. <han...@gm...>]

Hi,

Am 03.06.2014 um 13:06 schrieb Ronald Oussoren <ron...@ma...>:

> Swift might provide both opportunities and challenges in the future: Swift method names seem to be more like classic C- (and Python-) style names and not segmented names as used by Objective-C. As Swift can use existing ObjC libraries there might be some kind of translation table for method names, and if that exists this could be used by PyObjC as well to provide nicer names in Python code (instead of the ugly names we have to use now).
> 
> A possible challenge is the runtime model of Swift: I have no idea if Swift has, or will have, runtime introspection possibilities that could be used in the future to expose Swift libraries to Python code.

I am not sure whether you have seen Evan Swick’s Swift article: http://www.eswick.com/2014/06/inside-swift/

Maybe I understood that wrong, but to me it sounds rather disappointing from a PyObjC-perspective.  Do you draw different conclusions?

Best regards,
  Hans