From ronaldoussoren at mac.com Tue Jan 22 20:30:20 2013 From: ronaldoussoren at mac.com (Ronald Oussoren) Date: Tue, 22 Jan 2013 20:30:20 +0100 Subject: [Pythonmac-SIG] ANN: PyObjC 2.5.1 Message-ID: <898C31B4-6DB6-4D31-A8DA-172FFCAE0352@mac.com> Hi, I've just pushed PyObjC 2.5.1 to PyPI. This is primarily a bugfix release, the list of changes since 2.4 (the last version on PyPI) is included below. There will probably be a py2app bugfix later this week as well, I'm currently working on a bugfix that's holding up that release. Ronald Version 2.5.1 ------------- - PyObjC could crash when calling a method that is dynamicly generated (that is, the selector is not present in the class according to the Objective-C runtime but the instance responds to it anyway). The cases that used to crash now raise :exc:`objc.error` instead. .. note:: It is highly unlikely that real code would run into this, found while working on PyObjC 3.x. - When writing a python unicode object to an NSArchiver or NSKeyedArchiver the object is now stored exactly the same as a normal NSString, and will be read back as such. This increases interoperability with code that expects to read back a non-keyed archive in a different proces. An example of this is the use of Growl (see issue #31) Instances of subclasses of unicode are not affected by this change, and can only be read back by other PyObjC programs. - Issue #43: It was no longer possible to create instances of LaunchServices.LSLaunchURLSpec due to incomplete metadata. - Issue #41: the 'install.py' script in the root of pyobjc repository failed to perform an install when running in a clean checkout of the tree. - Issue #44: the various Cocoa frameworks only export @protocol defintions when they happen to be used by code in the framework. Added extensions to the various framework wrappers to ensure that all protocols are available to python code. - Opaque pointer types now can be constructed with a "c_void_p" keyword argument that contains a :type:`ctypes.c_void_p` value for the pointer. This is the reverse of the *__c_void_p__()* method that was added earlier. - Issue #46: It was not possible to use the Quartz.CoreGraphics module on OSX 10.5 when the binary was build on 10.8 (and using a 10.5 deployment target). Simular issues may be present in some of the other framework wrappers, there will be a more generic fix for this issue in a future release. Version 2.5 ----------- - Add conversion to/from ctypes.c_void_p to proxies for Cocoa objects. To use:: anObject = NSArray.array() void_p = anObject.__c_void_p__() # use void_p with ctypes otherObject = NSObject(c_void_p=voip_p) assert anObject is otherObject Note that it is save to contruct the python proxy from NSObject, the class will return an instance of the correct proxy type (in this example an instance of NSArray) - Fixed problem where the result of ``anObject.__cobject__()`` could not be converted back to a PyObjC object again. - A number of framework wrappers have a "protocols" submodule containing protocol objects (for example the module 'Foundation.protocol'). Use of these modules is deprecated, they will be removed in PyObjC 3.0. Use :func:`objc.protocolNamed` to access protocols instead. - Instances of :class:`objc.ivar` now have slots for introspection: - *__typestr__*: The type encoding - *__name__*: The Objective-C name - *__isOutlet__*: :data:`True` if the instance variable is an IBOutlet - *__isSlot__*: :data:`True` if the instance variable is a Python slot - Added implementation of '==' and '!=' for selectors defined in Python that is slightly smarter than the default (identity based) implementation in Python. This is mostly done for the PyObjC unittests and shouldn't affect user code. - Issue #30: Explicitly check if the compiler works, and try to fall back to clang if it doesn't. This uses a simular algoritm as the fix for in Python's tracker. - Issue #22: Reimplement support for bridgesupport files This reintroduces ``objc.parseBridgeSupport`` and ``objc.initFrameworkWrapper``, both are reimplemented in Python (previous version used C code) .. note:: The implementation is currently barely tested and therefore likely contains bugs. - Struct types created by the framework wrappers once again create class methods on :class:`objc.ivar` to generate instance variables of that type:: myLocation = objc.ivar.NSPoint() This has the same result as:: myLocation = objc.ivar(typer=NSPoint.__typestr__) - :func:`objc.IBAction` now raises TypeError when the argument is :data:`None`. - :func:`objc.instancemethod` is now actually exported by the :mod:`objc` package. - :func:`objc.accessor` and :func:`objc.typedAccessor` were not 64-bit safe. - :func:`objc.accessor` and :func:`objc.typedAccessor` didn't support the entire set of KVC accessors. - Add methods "_asdict" and "_replace" and field "_fields" to the struct wrapper types. These new attributes mirror the :class:`collections.namedtuple` interface. .. note:: In the long run I'd like to make struct wrappers immutable to allow using them as dictionary keys. This is a first step in that direction and makes it possible to verify that immutable struct wrappers are useable. - Added :func:`objc.createStructAlias`, and deprecated :func:`objc.registerStructAlias`. The new function has a "name" argument and can register types with the :class:`objc.ivar` type (see previous item) - Add explicit deprecation warnings to ``objc.CFToObject`` and ``objc.ObjectToCF``. Both functions barely function at all and will be removed with PyObjC 3.0. - ``objc.CFToObject`` and ``objc.ObjectToCF`` are no longer available when using Python 3.x, the APIs are used for MacPython support and that part of the standard library is not available with Python 3.x. - ``objc.splitStruct`` is renamed to ``objc.splitStructSignature`` and now actually works. The old name is temporarily available as an alias. - Fix refcounting leak in ``objc.splitSignature``. - ``objc._loadFunctionList`` is renamed to ``objc.loadFunctionList`` and is fully documented. The old name is temporarily available as an alias. - Move (deprected) decorator "signature" from objc._functions to objc._descriptors, and remove the former module. .. note:: The names op submodules of objc are implementation details, don't import them directly. - The optional argument for the decorator :func:`objc.selectorFor` was broken - The :class:`PyObjCTools.KeyValueCoding.kvc` wrapper `__setattr__` wrapper incorrectly set attributes on itself as well as on the wrapped object (the latter using Key-Value Coding) - Renamed (private) function injectSuffixes to inject_suffixes to match the other code in objc._dyld. - Slight restructuring of objc._pythonify to reduce code duplication between the python 2.x and python 3.x cases. - Removed deprecated methods from PyObjCTools.TestSupport - :class:`collections.Sequence` objects are now automaticly proxied as NSArray instances - :class:`collections.Mapping` objects are now automaticly proxies as NSDictionary instances - Removed some objects and functions from objc._bridges that weren't public and weren't used by PyObjC itself: - *BRIDGED_STRUCTURES*: mapping of python type to proxy class - *BRIDGED_STRUCTURES2*: mapping of python type to proxy class (not used at all) - *BRIDGED_TYPES*: mapping of python type to proxy class - *_bridgePythonTypes*: uses BRIDGED_STRUCTURES and BRIDGED_TYPES to update bridge data *_bridgePythonTypes* was called unconditionally, but never did anything because the data structures were empty and no code adds anything to them. - Improved documentation - For Objective-C blocks: try to extract the block signature from the (Objective-)C runtime when there is no metadata for the block. The block signature is available only when the code that creates the block is compiled using a recent enough compiler (although "recent enough" is fairly old by now) - Fixes some issues with :class:`objc.object_property` which were found by improved unittests. In particular: - The selector names for boolean properties were wrong - Properties with a "depends_on" list didn't inherit properly - Properties that were used in subclasses didn't generate the correct KVO events when they were observed. - KVO issues with computed (read-only) properties - Fixed some issues with :class:`objc.array_property` and :class:`objc.set_property` that were found by much improved unittests. - Fixed issues with :mod:`PyObjCTools.KeyValueCoding` that were found by improved unittests: - ``getKey`` didn't work propertly on dictionaries (dictionaries were treated as sequences) - ``getKeyPath(list, "@avg.field")`` didn't work when field wasn't a valid key for all items in the list, and likewise for the '@sum', '@min', '@max' special keys. - ``getKeyPath`` didn't raise the correct exception for empty key paths - ``@unionOfObjects`` and ``@distinctUnionOfObjects`` operators for Python sequences didn't raise an exception when the selected keypath didn't exist on an item of the sequence. - ``@unionOfArrays`` and ``@distinctUnionOfArrays`` operators for Python sequences didn't raise an exception when the selected keypath didn't exist on an item of the sequence. - ``@distinctUnionOfArrays`` and ``@distinctUnionOfObjects`` didn't work properly when the keypath pointed to objects that weren't hashable. - ``@distinctUnionOfSets`` operator was not present at all. - 'PyObjCTools.KeyValueCoding.setKey' now sets keys in dictionaries, that is:: >>> a = {} >>> setKey(a, 'foo', 42) >>> a {'foo': 42 } - 'PyObjCTools.KeyValueCoding.setKey(object, 'key', value)' now sets attribute 'key' when the object already has that attribute, before looking at '_key'. This avoids that ``setKey`` changes the underlying storage for a common Python property pattern:: class Record (object): @property def prop(self): return self._prop @prop.setter def prop(self, value): self._prop = calculate_using(value) Until PyObjC 2.5 the property setter for 'prop' would not be called when using KeyValueCoding. - Removed Mac OS X 10.2 (!) compatibility from :mod:`PyObjCTools.KeyValueCoding`. - PyObjCTools.KeyValueCoding has undocumented attributes 'ArrayOperators' and 'arrayOperators', both will be removed in a future release. - Using NSArchiver or NSKeyedArchiver to encode and then decode a python list or tuple could result in an unexpected value. In particular, if any element of the sequence was :data:`None` before archiving it would by ``NSNull.null()`` when read back. - Using NSArchiver or NSKeyedArchiver to encode and decode (pure) python objects didn't always work correctly. Found by improved unittests. - Using NSArchiver or NSKeyedArchiver to encode and decode bytes objects in Python 3 would result in an instance of NSData instead of bytes. - The implementation of cmp() for NSSet instances now matches the behavior of regular python sets, that is calling ``cmp(anNSSet, aValue)`` will raise a TypeError exception unless both arguments are the same object (``anNSSet is aValue``). - Issue #36: explictly document that PyObjC does not support the Objective-C Garbage Collection system (introduced in OSX 10.5, deprecated in OSX 10.8), and also mention this in the documentation for the screen saver framework because the screen saver engine uses GC on OSX 10.6 and 10.7. - Issue #37: Fix runtime link error with EPD (Enthought Python Distribution), which doesn't include the pymactoolbox functionality. - Various improvements to the documentation Version 2.4.1 ------------- .. note:: 2.41 was never released, all bugfixes are in the 2.4 branch as well as the 2.5 release. - Cocoa wrappers: fix metadata for ``copy``, ``mutableCopy``, ``copyWithZone:`` and ``mutableCopyWithZone:`` - Fix for issue 3585235 on SourceForge: the threading helper category on NSObject didn't work due to a typo (defined in the Cocoa bindings) Fix is based on a patch by "Kentzo" with further updates and tests by Ronald. - Rename ReadMe.txt to README.txt to work around misfeature in the sdist command in distutils. - Issue #28: Avoid crash when using CGEventTabProxy values. - Issue #33: "easy_install pyobjc" no longer tries to install the InterfaceBuilderKit bindings on OSX 10.7 or later. From aahz at pythoncraft.com Thu Jan 24 20:19:02 2013 From: aahz at pythoncraft.com (Aahz) Date: Thu, 24 Jan 2013 11:19:02 -0800 Subject: [Pythonmac-SIG] [Pyobjc-dev] ANN: PyObjC 2.5.1 In-Reply-To: <898C31B4-6DB6-4D31-A8DA-172FFCAE0352@mac.com> References: <898C31B4-6DB6-4D31-A8DA-172FFCAE0352@mac.com> Message-ID: <20130124191902.GA19470@panix.com> On Tue, Jan 22, 2013, Ronald Oussoren wrote: > > I've just pushed PyObjC 2.5.1 to PyPI. This is primarily a bugfix > release, the list of changes since 2.4 (the last version on PyPI) is > included below. Huzzah! Wow, that's a lot of stuff! -- Aahz (aahz at pythoncraft.com) <*> http://www.pythoncraft.com/ Weinberg's Second Law: If builders built buildings the way programmers wrote programs, then the first woodpecker that came along would destroy civilization. From kw at codebykevin.com Mon Jan 28 14:26:09 2013 From: kw at codebykevin.com (Kevin Walzer) Date: Mon, 28 Jan 2013 08:26:09 -0500 Subject: [Pythonmac-SIG] Re-linking app with system Tk frameworks Message-ID: <51067C71.10104@codebykevin.com> Hi, To deploy my Tkinter app to the Mac App Store, it has to be linked against the system Tcl/Tk frameworks because Tk uses internal/private API calls. (You can't submit an app that makes such calls directly, but apparently system-installed libraries are exempt.) My last build of Python linked against /System/Library/Tcl.framework and friends, but a more recent build I'm using links against /Library/Frameworks/Tcl.framework et al. Is there an install_name_tool trick I can run with py2app to make sure my deployed Tkinter app links against the system framework rather than my own installation in /Library/Frameworks? I don't want to have to rebuild Python to achieve this effect, but my previous experience with py2app suggests that it's the only way to make sure py2app doesn't vaccum up the /Library/Framework bits. --Kevin -- Kevin Walzer Code by Kevin http://www.codebykevin.com From ronaldoussoren at mac.com Mon Jan 28 15:31:43 2013 From: ronaldoussoren at mac.com (Ronald Oussoren) Date: Mon, 28 Jan 2013 15:31:43 +0100 Subject: [Pythonmac-SIG] Re-linking app with system Tk frameworks In-Reply-To: <51067C71.10104@codebykevin.com> References: <51067C71.10104@codebykevin.com> Message-ID: On 28 Jan, 2013, at 14:26, Kevin Walzer wrote: > Hi, > > To deploy my Tkinter app to the Mac App Store, it has to be linked against the system Tcl/Tk frameworks because Tk uses internal/private API calls. (You can't submit an app that makes such calls directly, but apparently system-installed libraries are exempt.) My last build of Python linked against /System/Library/Tcl.framework and friends, but a more recent build I'm using links against /Library/Frameworks/Tcl.framework et al. > > Is there an install_name_tool trick I can run with py2app to make sure my deployed Tkinter app links against the system framework rather than my own installation in /Library/Frameworks? I don't want to have to rebuild Python to achieve this effect, but my previous experience with py2app suggests that it's the only way to make sure py2app doesn't vaccum up the /Library/Framework bits. This should work: $ install_name_tool -change /Library/Frameworks/Tcl.framework/Versions/8.5/Tcl /System/Library/Frameworks/Tcl.framework/Versions/8.5/Tcl \ -change /Library/Frameworks/Tk.framework/Versions/8.5/Tk /System/Library/Frameworks/Tk.framework/Versions/8.5/Tk _tkinter.so Check that the binary is actually changed with 'otool -vL _tkinter.so' I haven't checked that the output actually works. It should be possible to exclude the Tk and Tcl frameworks from the py2app bundle using the '--dylib-excludes' option. That option is not yet tested by the py2app testsuite, and I'm therefore not 100% sure that it actually works. If it does work you can call install_name_tool on the _tkinter.so binary copied into the app bundle. Ronald > > --Kevin > > -- > Kevin Walzer > Code by Kevin > http://www.codebykevin.com > _______________________________________________ > Pythonmac-SIG maillist - Pythonmac-SIG at python.org > http://mail.python.org/mailman/listinfo/pythonmac-sig > unsubscribe: http://mail.python.org/mailman/options/Pythonmac-SIG