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

PyObjC 3.0.1 on PyPI
by Ronald Oussoren Jan. 2, 2015

Jan. 2, 2015

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 ;-)

2 1

Re: [Pythonmac-SIG] What does it take to run a GUI app?
by Chris Barker Aug. 27, 2014

Aug. 27, 2014

On Mon, Aug 25, 2014 at 8:32 AM, Aaron Meurer <aaron.meurer(a)continuum.io> wrote: > > you can. but you sure don't want to from the start of your development > > process. And there are hybrid command-line GuI apps like iPython or > anything > > that wants to pop up, say, a matplotlib graph. So we do need a command > line > > python that can run a GUI. > > Yes, matplotlib is big here. The default backend on OS X uses a Cocoa > GUI, which is almost completely broken if not run with a framework > build (see https://github.com/matplotlib/matplotlib/issues/665). > > However, I just tested both Anaconda pythonw and the python.org python > (both 3.4), and neither work directly with matplotlib. Both require > you to start IPython and type %matplotlib or the plot will not show. That's standard iPython -- it has to do with event loops capturing (or not) the REPL. Nothing to so with the issue at hand. YOu can also start up iPython with this turned on (ipython --pylab, I think) > well Anaconda would need to be able to re-locate, that's kind of the point > > -- so probably why they didn't just grab that build to begin with. Not > that > > they couldn't make a re-locatable Framework. But problem at hand is about > > the app bundle and start up executable, not the Framework anyway. > > Yes, relocatability is essential. Conda can make path replacements in > plain text files at install time, but in general it's best if > everything uses relative paths. hence the avoidance of a Framework -- though _maybe_ one could build a re-locatable framework. > The app bundle seems to work just as well as the framework. If > something explicitly looks for WITH_NEXT_FRAMEWORK it fill fail > (although we could probably forcibly set that to 1 if it helps). yup -- these are orthogonal -- for the GUI issue you need the app bundle. So the trick at hand is how to re-direct an executable in a "normal" location to the one in the app bundle. While Ned may be right that there could be a better way to do it, the short bit of code (pythonw.c) in the python source has been working well for years -- seem worth giving it a shot with Anaconda. As for a Framework build, one advantage it would give is keeping the python lib dir cleanly separated from the rest of the Anaconda lib dir (this has caused problems for me, anyway). There are other ways to do that anyway, if you choose to do so. -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

1 0

What does it take to run a GUI app?
by Chris Barker Aug. 23, 2014

Aug. 23, 2014

Folks, Over on the list for the Anaconda distribution, we've run into a limitation in our understanding of the whole app bundle, etc business. The problem is thus: Anaconda is currently built with the old python / pythonw dichotomy. python is a standard unix-style executable -- great for command line apps, web servers, what have you. But you get the dreaded: """ This program needs access to the screen. Please run with a Framework build of python, and only when you are logged in on the main display of your Mac. """ when you try to run a GUI app (this error message from wxPython) pythonw, on the other hand, is a shell script that re-directs to a python that is inside a hand-built application bundle: #!/bin/bash export PYTHONEXECUTABLE=/Users/chris.barker/PythonStuff/Anaconda/anaconda/bin/python /Users/chris.barker/PythonStuff/Anaconda/anaconda/python.app/Contents/MacOS/python $@ This all sort-of works. But it's a pain, because you may not know when you start up an app, whether it needs to access the Window manger (like iPython, for instance). And now I need to put "pythonw" in my #! lines, which may fail on other *nix systems, and... One thought is to simply have "python" be the same shell script as "pythonw" but there is concern that having it be a re-directing shell script may cause problems for some use cases. I know that this has been solved for years in the python.org installer. So how is that done? Anaconda doesn't seem to want to make their python a proper framework build -- don't know why not -- would there be any downside? But is it possible to build the python executable so it can access the GUI system without structuring their whole python install? 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

2 2

Re: [Pythonmac-SIG] What does it take to run a GUI app?
by Chris Barker Aug. 23, 2014

Aug. 23, 2014

On Fri, Aug 22, 2014 at 2:04 PM, Aaron Meurer <aaron.meurer(a)continuum.io> wrote: > It does cause problems. I'm not entirely clear what happens with > nested shebang lines, but you can't put > > #!/Users/aaronmeurer/anaconda/bin/pythonw > > as your shebang. If you do, it will try to run the script in bash. It has > to be > > #!/bin/bash /Users/aaronmeurer/anaconda/bin/pythonw > > OK, then this is broken anyway for scripts that need a GUI and want to use a #! line to start.....so another solution really would be good. > A (possibly weak) argument for not wanting to do a full framework > build is that it would break backwards compatibility with file > locations (possibly weak because the right symlinks might make > everything work). I believe the real reason is that it's (as far as > we can tell) unnecessary complexity, especially given that the fake > app bundle seems to work just as well. > for this, perhaps. But it's not all all complex, and might actually solve antoher problem (OK, my other problem) of keeping the python libs separated from all the other Anaconda libs... -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

1 0

MacPython and automating wheel builds
by Matthew Brett Aug. 7, 2014

Aug. 7, 2014

Hi, I would like some feedback on an idea I had for providing a wheel-building service via the MacPython organization. Following up an idea and code by Matt Terry [1], I've made a general repo called 'terryfy', with tools for building Python projects on the travis-ci OSX virtual machines [2]. Meanwhile, Olivier Grisel from scikit-learn kindly gave me access to the scikit-learn rackspace account for uploading built wheels. This made it rather easy to make a series of repos to build OSX wheels automatically. An example is the 'h5py-wheels' repo [3], to build OSX wheels for the h5py project. The idea of projects like these is that the (e.g) h5py release manager can click on the travis-ci webpage 'Restart build' button [4] or make a commit to the 'h5py-wheels' repo into order to trigger a build / test / upload of OSX wheels from travis-ci VMs to the rackspace hosted directory at http://wheels.scikit-image.org/ . From there they can upload to pypi for the release. There are currently terryfy-based wheel-building projects for h5py [3], numpy / scipy [5], matplotlib [6], cython [7], scikit-image [8], scikit-learn [9], pandas [10], Pillow [11], tornado [12], numexpr [13] and Markupsafe [14]. These all build wheels against the Python.org Python. I think this could be a big improvement for releasing OSX packages, but, at the moment, the process relies on me being available to maintain and trigger builds, as the owner of most of the building repos. So, I was wondering if y'all agreed that it was sensible to start transferring these repos to the MacPython organization. The idea would be that someone with a project on PyPi that wanted to build OSX wheels, could start off by making their own repo to build the wheels and test, based on the templates above. I have a script that partly automates this at [15]. Once the build and test phase is working, the owner transfers the repo to the MacPython organization, and I or someone else with the rackspace credentials adds the ability to upload the built wheels to the rackspace directory. The previous owner is a collaborator on the repository so they can push commits and trigger builds. In this way, we could have a collection of say 25 MacPython organization repos that would provide an OSX wheel-building service to projects that need it. It could be a central point for advice and help on building OSX wheels. Thanks for any feedback, Matthew [1] https://github.com/matplotlib/mpl_mac_testing [2] https://github.com/matthew-brett/terryfy [3] https://github.com/matthew-brett/h5py-wheels [4] https://travis-ci.org/matthew-brett/h5py-wheels [5] https://github.com/matthew-brett/numpy-atlas-binaries [6] https://github.com/matthew-brett/matplotlib-wheels [7] https://github.com/matthew-brett/cython-wheels [8] https://github.com/scikit-image/scikit-image-wheels [9] https://github.com/matthew-grett/scikit-learn-wheels [10] https://github.com/matthew-grett/pandas-wheels [11] https://github.com/python-Pillow/pillow-wheels [12] https://github.com/matthew-brett/tornado-wheels [13] https://github.com/matthew-brett/numexpr-wheels [14] https://github.com/matthew-brett/markupsafe-wheels [15] https://github.com/matthew-brett/terryfy/blob/master/make-wheel-builder -- Sent from Vmail

2 2

New page on wiki about system Python
by Matthew Brett Aug. 4, 2014

Aug. 4, 2014

Hi, I just put up a new wiki page on why system Python can be incovenient to use: https://github.com/MacPython/wiki/wiki/Which-Python I'd be very happy for feedback as to whether this is still the standard advice, Cheers, Matthew -- Sent from Vmail

4 3