🌐 Mailman 3 June 2014 - Pythonmac-SIG - python.org

Building compatible dependencies
by Chris Barker July 21, 2014

July 21, 2014

Hi folks, I know it'a at least theoretically possible to build libs under 10.9 that will work on 10.6 -- specifically compatible with the python.org python binaries. But I"m having trouble finding documentation of what flags you need. MACOSX_DEPLOYMENT_TARGET=10.6 should be required -- but anything else? personally, I've solved this by building on the oldest machine I want to support, but that's not always possible anymore. Anyone have an example? -thanks, --Chris -- Christopher Barker, Ph.D. Oceanographer Emergency Response Division NOAA/NOS/OR&R (206) 526-6959 voice 7600 Sand Point Way NE (206) 526-6329 fax Seattle, WA 98115 (206) 526-6317 main reception Chris.Barker(a)noaa.gov

5 4

py2app & pillow
by Karsten Wolf July 21, 2014

July 21, 2014

Hi, in an py2app app I replaced the thumbnail mechanism from sips (via os.system) to Pillow. The resulting app size went from 11MB to 50 MB for the inclusion of the complete TCL/TK stuff. Is there an easy way to reduce that? Both, Python 2.7.6 and Pillow are compiled for intel 32bit on OSX10.6 -karsten

2 1

Re: [Pythonmac-SIG] Code signing py2app generated apps
by Brendan Simon (eTRIX) June 8, 2014

June 8, 2014

> On 6/7/14, 9:31 AM, Brendan Simon (eTRIX) wrote: >> Is there anything special one needs to do to sign py2app generated >> apps ? >> >> I've tried: codesign -s <certificate-identifier> <path-to-my-app> >> >> but I when verifying it with "codesign -v" I get: >> >> src/dist/SureAnalysis.app: Unknown format in import. >> In architecture: i386 >> >> The certificate is a .p12 file that was imported with KeyChain.app to >> the System destination keychain. > > This works for me: > > codesign --deep --signature-size 9400 -f -s "Developer ID > Application: Kevin Walzer" cbk/QuickWho.app > > I use cx_freeze in this app, not py2app, but this also worked for me > with py2app. > > --Kevin Tried the above codesign suggestion but I still get the same error => Unknown format in import. The certificate issuer is: DigiCert SHA2 Assured ID Code Signing CA The app uses python2.7 (32-bit) and wxPython 2.8.12.1 (Carbon). Universal bundles with i386 and ppc architectures. I wonder if building the app to use only 64-bit and/or i386/x86_64 architectures and/or wxPython (Cocoa) would make a difference ? Thanks for any thoughts :) Brendan.

1 0

py2app 0.8.1 with python3.4 + pyqt5 crashes the app
by apaeffgen June 8, 2014

June 8, 2014

Hi All, Starting the app inside the bundle on the command line works fine with some menu glitches, but clicking on the Application Icon the app crashes. The crash report is listet below: Process: Opml_Converter [53618] Path: /Users/USER/*/Opml_Converter.app/Contents/MacOS/Opml_Converter Identifier: org.pythonmac.unspecified.Opml_Converter Responsible: Opml_Converter [53618] 27 org.pythonmac.unspecified.Opml_Converter 0x000000010000275b 0x100000000 + 10075 28 org.pythonmac.unspecified.Opml_Converter 0x000000010000117a main + 650 29 org.pythonmac.unspecified.Opml_Converter 0x0000000100000be4 start + 52 0x100000000 - 0x100009fff +org.pythonmac.unspecified.Opml_Converter (0.0.0 - 0.0.0) <FFD751CA-37B6-3FAC-9CF0-413E01DAA81D> /Users/USER/*/Opml_Converter.app/Contents/MacOS/Opml_Converter 0x1004c6000 - 0x1004c9fff +zlib.so (0) <F62754E4-EBE2-3A2C-B78A-3942155A0A04> /Users/USER/*/Opml_Converter.app/Contents/Resources/zlib.so 0x1004ed000 - 0x1004effff +time.so (0) <3551C948-7FEC-39A0-83F2-600A47781F59> /Users/USER/*/Opml_Converter.app/Contents/Resources/lib/python3.4/lib-dynload/time.so 0x1004f5000 - 0x1004f8fff +_struct.so (0) <B09C2F51-D3FB-3BB3-A019-1319E62AE7DF> /Users/USER/*/Opml_Converter.app/Contents/Resources/lib/python3.4/lib-dynload/_struct.so 0x102800000 - 0x10294aff7 +org.python.python (3.4.1, [c] 2004-2014 Python Software Foundation. - 3.4.1) <2E8065CE-5540-3FBF-9D5F-04044DFF0731> /Users/USER/*/Opml_Converter.app/Contents/Frameworks/Python.framework/Versions/3.4/Python 0x1029cb000 - 0x1029daff7 +_ctypes.so (0) <0826D76F-5793-3CF7-B66F-A7A84C380B10> /Users/USER/*/Opml_Converter.app/Contents/Resources/lib/python3.4/lib-dynload/_ctypes.so 0x104202000 - 0x104203fff +_heapq.so (0) <B0E9F274-E89A-313A-8E14-FF3CBB70D03F> /Users/USER/*/Opml_Converter.app/Contents/Resources/lib/python3.4/lib-dynload/_heapq.so 0x104287000 - 0x10439cff7 +etree.so (0) <467DEE63-5EBF-3EE6-9383-D187ABA4C94F> /Users/USER/*/Opml_Converter.app/Contents/Resources/lib/python3.4/lib-dynload/lxml/etree.so 0x1044e2000 - 0x1044e2fff +_opcode.so (0) <B23A0D31-4902-3220-9C59-277303D59A09> /Users/USER/*/Opml_Converter.app/Contents/Resources/lib/python3.4/lib-dynload/_opcode.so 0x1044f0000 - 0x104501ff7 +sip.so (0) <C173D82C-37BC-3FE6-8450-04A184D6DDB2> /Users/USER/*/Opml_Converter.app/Contents/Resources/lib/python3.4/lib-dynload/sip.so 0x105ac8000 - 0x105c45ff7 +QtGui.so (0) <CAE6F6E7-261D-3993-8917-DC850C465AC1> /Users/USER/*/Opml_Converter.app/Contents/Resources/lib/python3.4/lib-dynload/PyQt5/QtGui.so 0x105d43000 - 0x10617aff7 +QtGui (5.3) <834FC6CC-D0A2-3B2C-B2F5-13ECA920483B> /Users/USER/*/Opml_Converter.app/Contents/Frameworks/QtGui.framework/Versions/5/QtGui 0x10624a000 - 0x106754fff +QtCore (5.3) <6C09A68B-0A13-3237-A5AE-585303D42DDB> /Users/USER/*/Opml_Converter.app/Contents/Frameworks/QtCore.framework/Versions/5/QtCore 0x1067d9000 - 0x106938ff7 +QtCore.so (0) <6CA7DB65-5ABF-334A-9D3E-FF1893F3BE58> /Users/USER/*/Opml_Converter.app/Contents/Resources/lib/python3.4/lib-dynload/PyQt5/QtCore.so 0x106a19000 - 0x106ca0fff +QtWidgets.so (0) <84C0E80B-7542-3CCF-876E-BD56816F90B9> /Users/USER/*/Opml_Converter.app/Contents/Resources/lib/python3.4/lib-dynload/PyQt5/QtWidgets.so 0x106eb9000 - 0x10737fff7 +QtWidgets (5.3) <49CD46B1-BD99-37B0-87A6-D30C3F1BDBE2> /Users/USER/*/Opml_Converter.app/Contents/Frameworks/QtWidgets.framework/Versions/5/QtWidgets Any hints?

1 0

Code signing py2app generated apps
by Brendan Simon (eTRIX) June 7, 2014

June 7, 2014

Is there anything special one needs to do to sign py2app generated apps ? I've tried: codesign -s <certificate-identifier> <path-to-my-app> but I when verifying it with "codesign -v" I get: src/dist/SureAnalysis.app: Unknown format in import. In architecture: i386 The certificate is a .p12 file that was imported with KeyChain.app to the System destination keychain. I've read that all binaries and frameworks need to be signed. Is there an easy way of doing that ? Is there a tool to determine which files need to be signed ? Thanks, Brendan.

2 1

Re: [Pythonmac-SIG] [Pyobjc-dev] Towards PyObjC 3.0
by has June 5, 2014

June 5, 2014

Ronald Oussoren 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; Yep, it's not runtime translation, its syntactic swizzling being done in the parser. MacRuby did [1] the same thing IIRC, allowing Ruby users to write methods using familiar Ruby method name + keyword args syntax, but obviously what looked like the method's name was only part of it and the 'keyword' args were 100% positional and order-sensitive: the parser just stripped out the 'keywords' and reassembled the real ObjC signature. It also meant, of course, that you could safely have several methods with identical-looking 'names' in the same class, even though Ruby doesn't support method overloading, because they weren't really identical names at all and therefore didn't actually mask each other. That alone should rule out a translation table approach, since Python would only give you the last splitBy(...) method in your class; every other splitBy(...) would be masked by it, regardless of what their selector names are. Whether you could dive into Python's lexer/tokenizer/parser/AST and do the same sort of swizzling as MR there, I don't know. And I really wouldn't like to say if it'd be a wise choice or not: the current syntax is ugly, but you can throw rocks at it and it's still guaranteed to work, whereas once you start mucking with something as complex and knotty as Python syntax, who knows what you might step on? HTH has

1 0

Re: [Pythonmac-SIG] [Pyobjc-dev] Towards PyObjC 3.0
by Ronald Oussoren June 3, 2014

June 3, 2014

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 <amorris(a)mistermorris.com> 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 <nicholas.cole(a)gmail.com > 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 > <ronaldoussoren(a)mac.com > wrote: > > > > > On 4 Jul, 2013, at 17:08, Ronald Oussoren <ronaldoussoren(a)mac.com > 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 - Pythonmac-SIG(a)python.org > > http://mail.python.org/mailman/listinfo/pythonmac-sig > > unsubscribe: http://mail.python.org/mailman/options/Pythonmac-SIG > _______________________________________________ > Pythonmac-SIG maillist - Pythonmac-SIG(a)python.org > https://mail.python.org/mailman/listinfo/pythonmac-sig > unsubscribe: https://mail.python.org/mailman/options/Pythonmac-SIG

2 2

Towards PyObjC 3.0
by Ronald Oussoren June 3, 2014

June 3, 2014

Hi, I recently realised that I've been much to silent on the development of PyObjC. I'm making steady progress on a new major release of PyObjC and am getting closer to a beta release of PyObjC 3.0, although progress is too slow to my taste :-) In januari (6 months ago already...) I was at a hackweek @Dropbox where I seriously started work on this new release. During that week I basicly rewrote the way that PyObjC looks for methods, the old way was inherently ugly and slow, the new one is cleaner and faster (although it appears to be not so much faster that its actually noticable...). That rewrite probably wouldn't have happened without hackweek, it required several days of concentrated hacking and that is something I can't do in my regular environment (there's those pesky customers that also want to get work done). Since then I've done further cleanup work and some optimization (first tests indicate that the bridge uses less memory and is faster). I'm finally closing in on a situation where the core bridge is cleaned up and can be reasonably sure that I won't have to make backward incompatible changes in the future. Now up to the really hard work: clean up the documentation and example code. That will probably eat away a lot of nights (with a lot of simple changes in the examples and hard thinking on how to improve the documentation; writing usable documentation is hard). 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. Currently side-tracked on trying to get a change to super() into Python 3.4, Ronald P.S. A small public service announcement: try to avoid "from Cocoa import *", and use explicit imports (either "import Cocoa; o = Cocoa.NSObject.new()" or "from Cocoa import NSObject"). The current release of PyObjC contains optimizations that make explicit imports faster by doing much less work, and I expect to improve this further in future release. A nice side effect of avoiding '*' imports is that code analysis tools like pyflakes will do a much better jobs on your code.

3 3