pyobjc-dev — CVS commit notices go here

[Pyobjc-dev] Address Book ABMultiValueCoreDataWrapper

[Markos K. <mk...@gm...>]

I’m trying to figure out how to modify address book entries, specifically phone numbers…. I’ve got the ABMultiValueCoreDataWrapper for phone numbers, but try as I might, I seem to come up with errors in using replaceValueAtIndex_inPropertyWithKey_withValue_(), specifically about the key…. I’ve tried getting the property at said index, and then re-entering it, since I’m modifying the value, not the key, but that’s not working, as I get NSUnknownKeyException. I’ve also tried using ABMultiValueReplaceValue, but I get a different problem for the key error, that is, that, despite the fact that I use ABMultiValueCopyIdentifierAtIndex, I still get an key error for the identifier. What’s the right way to modify address book data?

Thanks,
—Markos

Re: [Pyobjc-dev] PyObjCPointer

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

On 15 Aug 2014, at 01:14, Adam Duston <ad...@do...> wrote:

> Using pyobjc 2.5.1:
> 
>>>> import WebKit
>>>> webview = WebKit.WebView.alloc().init()
>>>> ctx = webview.mainFrame().globalContext()
> 2014-08-14 19:08:09.820 Python[16771:d07] PyObjCPointer created: at
> 0x105edf8d8 of type {OpaqueJSContext=}
>>>> ctx.pointerAsInteger
> Traceback (most recent call last):
>  File "<stdin>", line 1, in <module>
> AttributeError: 'PyObjCPointer' object has no attribute 'pointerAsInteger
> 
> I need to pass the pointer as a ctypes.c_void_p to a ctypes-wrapped
> function, so getting the integral value of the underlying object
> address would be great. I just can't seem to do that. Any way around
> this?

This attribute is not present in PyObjC 2.5. The only way I know of working around that is to use ctypes to directly access the storage area of the pointer object, actually doing that is left as an exercise for the reader ;-)

Ronald

[Pyobjc-dev] Auto Response

[Ian B. <ian...@ya...>]

Hi, This email address is no longer in use because it has been overrun with spam. Please email me at my other email account. Thank you and warm regards, I

[Pyobjc-dev] PyObjCPointer

[Adam D. <ad...@do...>]

Using pyobjc 2.5.1:

>>> import WebKit
>>> webview = WebKit.WebView.alloc().init()
>>> ctx = webview.mainFrame().globalContext()
2014-08-14 19:08:09.820 Python[16771:d07] PyObjCPointer created: at
0x105edf8d8 of type {OpaqueJSContext=}
>>> ctx.pointerAsInteger
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
AttributeError: 'PyObjCPointer' object has no attribute 'pointerAsInteger

I need to pass the pointer as a ctypes.c_void_p to a ctypes-wrapped
function, so getting the integral value of the underlying object
address would be great. I just can't seem to do that. Any way around
this?

Thanks,
Adam



-- 
Adam Duston

Re: [Pyobjc-dev] Calling Objective-C++ code

[Douglas R. <jo...@vt...>]

Hey everyone. I just wanted to do a quick follow-up.

As Ronald suggested in his reply, the best solution ended up being
SIP. It's the only solution I found that has built-in support for
Objective-C and Qt. Getting SIP & qmake set up was a bit painful but I
eventually nailed it. So, yes, always choose the best tool for the
job. In this case, it wasn't PyObjC. Maybe it will be for some of you.

Good luck!

Re: [Pyobjc-dev] PyObjC 3.0.1 on PyPI

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

On Jul 27, 2014, at 10:50 AM, Ronald Oussoren <ron...@ma...> wrote:
>> 
>> Remarks:
>> So far the release seems stable the only issue we had was that since the latest upgrade to pyobjc 3.0 of 2014-05-30. + Python 2.7.6
>> The startup time of our app was about 10 seconds longer. I haven't had the time yet to investigate what caused it but profiler indicated it was in gzip.
>> So I changed our packaging and distribute site-packages as unzipped and notice at 10 seconds startup speed up.
>> Hopefully in the coming months I have sometime to investigate what caused it.
> 
> The metadata system may be at fault here, although it is supposed to be faster than before. Do you use “from Foundation import *”?  It is highly advisable to avoid that because the framework wrapper modules lazily instantiate their contents and star-imports forces greedy initialisation. At least 3.0 should avoid the additional slowdown that was in 2.5 in the code that handles __all__.

no "from XYZ import *" in our project.


> BTW. According to one of the talks at EP14 translating your source code using Cython could help in startup time. They started looking into Cython to get obfuscated code (to make it harder to reverse engineer their application) and noticed some performance improvements as well. That’s with plain Python code and no Cython-specific annotations.  It would be cool to teach py2app to do this automatically and I have filed a feature request for that. I don’t know when I’ll get around to that though.
> 
> The talk: https://ep2014.europython.eu/en/schedule/sessions/31/  (video and slides are available).

Interesting will take a look at that.

marc

Re: [Pyobjc-dev] PyObjC 3.0.1 on PyPI

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

On 27 Jul 2014, at 15:49, Marc Van Olmen <ma...@ac...> wrote:

> hi Ronald,
> 
> Thanks for you work and keep this project alive!
> We shipped in July Checkout 4.0 with the pyobjc 3.0 of 2014-05-30. + Python 2.7.6
> 
> Q:
> Any speeds ups mentioned here happened after that?

Nope. Almost all that work happened early in 2013. 

> 
> Remarks:
> So far the release seems stable the only issue we had was that since the latest upgrade to pyobjc 3.0 of 2014-05-30. + Python 2.7.6
> The startup time of our app was about 10 seconds longer. I haven't had the time yet to investigate what caused it but profiler indicated it was in gzip.
> So I changed our packaging and distribute site-packages as unzipped and notice at 10 seconds startup speed up.
> Hopefully in the coming months I have sometime to investigate what caused it.

The metadata system may be at fault here, although it is supposed to be faster than before. Do you use “from Foundation import *”?  It is highly advisable to avoid that because the framework wrapper modules lazily instantiate their contents and star-imports forces greedy initialisation. At least 3.0 should avoid the additional slowdown that was in 2.5 in the code that handles __all__.

BTW. According to one of the talks at EP14 translating your source code using Cython could help in startup time. They started looking into Cython to get obfuscated code (to make it harder to reverse engineer their application) and noticed some performance improvements as well. That’s with plain Python code and no Cython-specific annotations.  It would be cool to teach py2app to do this automatically and I have filed a feature request for that. I don’t know when I’ll get around to that though.

The talk: https://ep2014.europython.eu/en/schedule/sessions/31/  (video and slides are available).

Ronald

> 
> best
> 
> marc
> 
> 
> 
> On Jul 27, 2014, at 5:00 AM, Ronald Oussoren <ron...@ma...> wrote:
> 
>> Hi,
>> 
>> I’ve just pushed PyObjC 3.0.1 to PyPI. This is a major update to the previously uploaded release and contains a rewrite of the core bridge itself.  All tests pass without problems, but there could still be problems. 
>> 
>> With this update the bridge is a lot lazier about when to add methods to the class proxy __dict__: methods are now only added when they are actually used. This should result in slightly better performance, and more importantly removes some very ugly code that tried very hard to keep the __dict__ up to date without there being support for detecting changes to a class in the Objective-C runtime. 
>> 
>> Because of this it is more important that ever to have “from objc import super” at the top of modules that use super calls in subclasses of Cocoa classes. In previous releases this was already necessary to avoid a race condition, but with this release you will definitely run into problems when using builtin.super.  I am working on a PEP that adds a new API to Python that would remove the need of a custom super class, but that will at best be present in Python 3.5 (and that’s assuming the PEP is accepted).
>> 
>> The metadata and framework wrappers have not yet been updated with support of OSX 10.9, let alone support of 10.10. That means that those wrappers work fine on OSX 10.9, but any special support for API’s introduced in OSX 10.9 is not present yet.  Adding such support is on my todo list, but is a significant amount of work and sadly enough requires updating some tooling I used previously (which means yet more work).
>> 
>> Getting out this release took way to much time, I started work on this during a Dropbox hack week in Januari 2013 (!).  It’s highly unlikely that this rewrite and cleanup would have happend without the uninterrupted week of hacking during that event, it what just not something I could have managed in the couple of (fragmented) hours a week I can spent on PyObjC at the moment. 
>> 
>> Ronald
>> 
>> P.S.  I’ve also done some more optimisation work with PyObjC 3.0 which has sped up method calls by removing malloc calls in a number of cases. That seems to have been more effective for speed enhancements than the core rewrite itself ;-)
>> ------------------------------------------------------------------------------
>> Want fast and easy access to all the code in your enterprise? Index and
>> search up to 200,000 lines of code with a free copy of Black Duck
>> Code Sight - the same software that powers the world's largest code
>> search on Ohloh, the Black Duck Open Hub! Try it now.
>> http://p.sf.net/sfu/bds
>> _______________________________________________
>> Pyobjc-dev mailing list
>> Pyo...@li...
>> https://lists.sourceforge.net/lists/listinfo/pyobjc-dev
> 

Re: [Pyobjc-dev] PyObjC 3.0.1 on PyPI

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

hi Ronald,

Thanks for you work and keep this project alive!
We shipped in July Checkout 4.0 with the pyobjc 3.0 of 2014-05-30. + Python 2.7.6

Q:
Any speeds ups mentioned here happened after that?

Remarks:
So far the release seems stable the only issue we had was that since the latest upgrade to pyobjc 3.0 of 2014-05-30. + Python 2.7.6
The startup time of our app was about 10 seconds longer. I haven't had the time yet to investigate what caused it but profiler indicated it was in gzip.
So I changed our packaging and distribute site-packages as unzipped and notice at 10 seconds startup speed up.
Hopefully in the coming months I have sometime to investigate what caused it.

best

marc



On Jul 27, 2014, at 5:00 AM, Ronald Oussoren <ron...@ma...> wrote:

> Hi,
> 
> I’ve just pushed PyObjC 3.0.1 to PyPI. This is a major update to the previously uploaded release and contains a rewrite of the core bridge itself.  All tests pass without problems, but there could still be problems. 
> 
> With this update the bridge is a lot lazier about when to add methods to the class proxy __dict__: methods are now only added when they are actually used. This should result in slightly better performance, and more importantly removes some very ugly code that tried very hard to keep the __dict__ up to date without there being support for detecting changes to a class in the Objective-C runtime. 
> 
> Because of this it is more important that ever to have “from objc import super” at the top of modules that use super calls in subclasses of Cocoa classes. In previous releases this was already necessary to avoid a race condition, but with this release you will definitely run into problems when using builtin.super.  I am working on a PEP that adds a new API to Python that would remove the need of a custom super class, but that will at best be present in Python 3.5 (and that’s assuming the PEP is accepted).
> 
> The metadata and framework wrappers have not yet been updated with support of OSX 10.9, let alone support of 10.10. That means that those wrappers work fine on OSX 10.9, but any special support for API’s introduced in OSX 10.9 is not present yet.  Adding such support is on my todo list, but is a significant amount of work and sadly enough requires updating some tooling I used previously (which means yet more work).
> 
> Getting out this release took way to much time, I started work on this during a Dropbox hack week in Januari 2013 (!).  It’s highly unlikely that this rewrite and cleanup would have happend without the uninterrupted week of hacking during that event, it what just not something I could have managed in the couple of (fragmented) hours a week I can spent on PyObjC at the moment. 
> 
> Ronald
> 
> P.S.  I’ve also done some more optimisation work with PyObjC 3.0 which has sped up method calls by removing malloc calls in a number of cases. That seems to have been more effective for speed enhancements than the core rewrite itself ;-)
> ------------------------------------------------------------------------------
> Want fast and easy access to all the code in your enterprise? Index and
> search up to 200,000 lines of code with a free copy of Black Duck
> Code Sight - the same software that powers the world's largest code
> search on Ohloh, the Black Duck Open Hub! Try it now.
> http://p.sf.net/sfu/bds
> _______________________________________________
> Pyobjc-dev mailing list
> Pyo...@li...
> https://lists.sourceforge.net/lists/listinfo/pyobjc-dev

[Pyobjc-dev] py2app 0.9 on PyPI

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

Hi,

Now that I’m writing announcements anyway…  I’ve also uploaded a new release of py2app.  This release uses a new version of modulegraph that records more information about the links in the graph. This makes it possible to provide more interesting information on modules that py2app couldn’t find while building the app bundle: py2app now shows if a missing module was imported conditionally or not, and if it was imported as “from Y import mod” or “import mod” (the latter is more likely to be a real problem).

This required some restructuring of the modulegraph code base, while the modulegraph unit tests are still not good enough. I think I’ve found and fixed all problems introduced by the refactoring, but I’m not 100% about that.   There will be further refactoring, and test updates, in upcoming releases of both modulegraph and py2app.

Ronald

[Pyobjc-dev] PyObjC 3.0.1 on PyPI

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

Hi,

I’ve just pushed PyObjC 3.0.1 to PyPI. This is a major update to the previously uploaded release and contains a rewrite of the core bridge itself.  All tests pass without problems, but there could still be problems. 

With this update the bridge is a lot lazier about when to add methods to the class proxy __dict__: methods are now only added when they are actually used. This should result in slightly better performance, and more importantly removes some very ugly code that tried very hard to keep the __dict__ up to date without there being support for detecting changes to a class in the Objective-C runtime. 

Because of this it is more important that ever to have “from objc import super” at the top of modules that use super calls in subclasses of Cocoa classes. In previous releases this was already necessary to avoid a race condition, but with this release you will definitely run into problems when using builtin.super.  I am working on a PEP that adds a new API to Python that would remove the need of a custom super class, but that will at best be present in Python 3.5 (and that’s assuming the PEP is accepted).

The metadata and framework wrappers have not yet been updated with support of OSX 10.9, let alone support of 10.10. That means that those wrappers work fine on OSX 10.9, but any special support for API’s introduced in OSX 10.9 is not present yet.  Adding such support is on my todo list, but is a significant amount of work and sadly enough requires updating some tooling I used previously (which means yet more work).

Getting out this release took way to much time, I started work on this during a Dropbox hack week in Januari 2013 (!).  It’s highly unlikely that this rewrite and cleanup would have happend without the uninterrupted week of hacking during that event, it what just not something I could have managed in the couple of (fragmented) hours a week I can spent on PyObjC at the moment. 

Ronald

P.S.  I’ve also done some more optimisation work with PyObjC 3.0 which has sped up method calls by removing malloc calls in a number of cases. That seems to have been more effective for speed enhancements than the core rewrite itself ;-)

Re: [Pyobjc-dev] Calling Objective-C++ code

[Douglas R. <jo...@vt...>]

Hello all. Sorry about the formatting of my last email. I used the
wrong address the first time, got lazy, and just hit "Forward." :)
Anyway....

On Tue, Jul 22, 2014 at 2:56 AM, Ronald Oussoren <ron...@ma...> wrote:
> The PyObjC core reads information about classes and methods using the Objective-C runtime
> API, generally that information is enough to access Objective-C code from Python. That should
> also work for Objective-C++ code, as long as you only try to use Objective-C classes (the @interface stuff)
> and don’t use C++ classes in method signatures (so no methods that return a vector<int>).

I'd like to use the C++ classes, so it looks like I'll need to take a
crack at SIP or SWIG. If I manage to work all that out, I'll report
back here with some code so that others can learn from my mistakes.
(If not, well, it looks like I'll be taking a crash course in porting
C++ to Objective-C.)

Thanks for the help!

D

Re: [Pyobjc-dev] Calling Objective-C++ code

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

On 22 Jul 2014, at 07:14, Douglas Roark <jo...@vt...> wrote:

> Hello. I'd like to request a little help. I'm trying to taking some
> Objective-C++ code and call it from Python. I seem to be stuck and
> could use a little help getting out of the proverbial mud.
> 
> I'm new to ObjC and am trying to figure out how to get a feature
> working. There's some ObjC++ code that's already written and can
> probably be used after making a few mods. The ObjC++ code basically
> uses C++-style headers, although one includes a "signals:" section
> (i.e., it's not pure C++). The underlying .mm code is your standard
> C++/ObjC mix. My initial thought was that I could use PyObjC to call
> the ObjC++ code from Python. The more I look into it, though, the more
> I think PyObjC may not be able to create a bridge as-is; pure ObjC
> code seems to be necessary. I don't think SWIG or SIP are able to
> handle ObjC++ either. This leads me to believe that I'll have to
> rewrite the ObjC++ code in pure ObjC and then call it from PyObjC (or
> maybe, if it's possible, just rewrite the header files). I have a
> couple of questions before I go much further.
> 
> -Is my understanding correct? In other words, is PyObjC unable to
> handle to handle such headers? (See
> https://github.com/bitcoin/bitcoin/blob/0.9.2/src/qt/macdockiconhandler.h
> for one such header I'm trying to use.)

PyObjC doesn’t use the header files at all, except for a side project that reads
header files an generates some optional definitions from them. That tool is very
picky, too picky even, in what it accepts and likely wouldn’t work even if the header
wasn’t Objective-C++.

The PyObjC core reads information about classes and methods using the Objective-C runtime
API, generally that information is enough to access Objective-C code from Python. That should
also work for Objective-C++ code, as long as you only try to use Objective-C classes (the @interface stuff)
and don’t use C++ classes in method signatures (so no methods that return a vector<int>).

Looking at the header you mention: that won’t work with PyObjC, that’s basically pure C++ code with small bits of Objective-C sprinkled in.

With some luck SIP might be able to wrap this class, its API appears to be completely in C++. You may have to tweak the headers a bit to ensure that the “Objective-“ definitions aren’t visible to SIP’s scanner, but other than that it should work. That said: I’ve never used SIP myself.

> -Is it possible to mix-and-match ObjC header files with C++-style
> definitions in the implementation (i.e., can I rewrite only the header
> files)? My gut says this isn't possible.

That’s not a problem, again: as long as you don’t use C++ classes in method signatures.

Ronald

> -If I'm incorrect, and PyObjC can call this code, are there any
> examples or douments online? I think I have a good idea of how to call
> the ObjC code, just not any potential ObjC++ code.
> 
> Thanks in advance for any help you can give!
> 
> Doug
> 
> ------------------------------------------------------------------------------
> Want fast and easy access to all the code in your enterprise? Index and
> search up to 200,000 lines of code with a free copy of Black Duck
> Code Sight - the same software that powers the world's largest code
> search on Ohloh, the Black Duck Open Hub! Try it now.
> http://p.sf.net/sfu/bds
> _______________________________________________
> Pyobjc-dev mailing list
> Pyo...@li...
> https://lists.sourceforge.net/lists/listinfo/pyobjc-dev

[Pyobjc-dev] Fwd: Calling Objective-C++ code

[Douglas R. <jo...@vt...>]

Hello. I'd like to request a little help. I'm trying to taking some
Objective-C++ code and call it from Python. I seem to be stuck and
could use a little help getting out of the proverbial mud.

I'm new to ObjC and am trying to figure out how to get a feature
working. There's some ObjC++ code that's already written and can
probably be used after making a few mods. The ObjC++ code basically
uses C++-style headers, although one includes a "signals:" section
(i.e., it's not pure C++). The underlying .mm code is your standard
C++/ObjC mix. My initial thought was that I could use PyObjC to call
the ObjC++ code from Python. The more I look into it, though, the more
I think PyObjC may not be able to create a bridge as-is; pure ObjC
code seems to be necessary. I don't think SWIG or SIP are able to
handle ObjC++ either. This leads me to believe that I'll have to
rewrite the ObjC++ code in pure ObjC and then call it from PyObjC (or
maybe, if it's possible, just rewrite the header files). I have a
couple of questions before I go much further.

-Is my understanding correct? In other words, is PyObjC unable to
handle to handle such headers? (See
https://github.com/bitcoin/bitcoin/blob/0.9.2/src/qt/macdockiconhandler.h
for one such header I'm trying to use.)
-Is it possible to mix-and-match ObjC header files with C++-style
definitions in the implementation (i.e., can I rewrite only the header
files)? My gut says this isn't possible.
-If I'm incorrect, and PyObjC can call this code, are there any
examples or douments online? I think I have a good idea of how to call
the ObjC code, just not any potential ObjC++ code.

Thanks in advance for any help you can give!

Doug

[Pyobjc-dev] modulegraph update

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

Hi,

I just pushed out an pretty invasive change to the tip of the modulegraph tree: the edges in that tree now have a DependencyInfo object associated with them that contains information about the location(s) of the import statements that caused the edge to exist. This new information will be used by py2app to give more useful reports about modules that cannot be found.

The change required some restructuring of the modulegraph source code, and as modulegraph didn’t have perfect test coverage (and still doesn’t) I may have missed some edge cases.  There may therefore be new and exciting bugs as well :-(

Ronald

[Pyobjc-dev] Can you help me with runConsoleEventLoop() command?

[vale b. <ada...@ya...>]

Hello Ronald,

first of all I congratulate with you for your package PyObjC, it is very useful for those who want to program in python on osx.
The only little lack is the documentation of some parts of code, but i understand all the work that is behind the the conversion from objective-c to python library.
Therefore i'm writing to you to get a little help regarding the operation of the *runConsoleEventLoop()* method.

I have posted on stakoverflow the full question.
http://stackoverflow.com/questions/24188799/how-to-implement-pyobjc-runconsoleeventloop
Your answer may be useful to many others people in the future.
(So avoid you from other pesky private messages like this in the future :-)  )

thanks in advance for your help.

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

[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

[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

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...>]

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

[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

[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...>]

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

[Adam M. <am...@mi...>]

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...>]

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