Bits and pieces for pythonista_startup

dgelessus

https://github.com/dgelessus/pythonista_startup

I'm a big fan of the pythonista_startup feature (thanks @omz!) and use it a lot. Mine grew to a package with six submodules (is this normal?) so I decided to put it up on GitHub.

Installation is simple - back up your existing pythonista_startup file/folder, then run these commands in stash:

mkdir site-packages/pythonista_startup
cd site-packages/pythonista_startup
git clone https://github.com/dgelessus/pythonista_startup.git

And to update:

cd site-packages/pythonista_startup
git pull

Features:

Almost all of them are turned off by default as not everyone will find them useful or because they're unstable. To turn them on, edit __init__.py and uncomment the entries that you want to have enabled.

Anti-globals-clearing mechanism as originally posted here. (Optional)
Custom sys.displayhook and sys.excepthook for fancy colors in the interactive prompt, an IPython-like Out history, and cleaner exception display (only for code run interactively). (Optional, colors unsuitable for dark themes)
Makes "hidden" built-in types (like function, instancemethod and code) accessible as globals. (Optional, possibly not very useful)
Enables the standard faulthandler module to record a Python traceback when Pythonista hard-crashes. (Optional, Python 3 only, slightly untested)
Patches for the sys streams to make some "normal terminal" scripts work. (Optional, enabled by default)
Proper exception handling for any code run in pythonista_startup and the submodules - by default Pythonista just ignores all exceptions that happen there.
Experimental "preflight hook" support to run code every time a script is run from the Pythonista editor. (Optional, very unstable, probably breaks with every Pythonista update)

It is possible to add custom features in their own subfiles. Each submodule contains a run function, which is run by the main __init__.py. Submodules are not detected automatically, you need to add new ones to the __init__.py by hand.

JonB

Cool! Does the faulthandler actually catch objc crashes?

dgelessus

As far as I can tell it does work properly, which I found VERY surprising, considering this is iOS. I know nothing about Objective-C, but if you run this interactively, it is logged properly:

import ctypes
ctypes.string_at(0) # Null pointer access

This is just the example from the stdlib docs.

dgelessus

Update: Fixed chained exceptions under Python 3. Previously they were not shown at all. (See the original post for update instructions.)

dgelessus

Update: Made the error message less annoyting when you have enable_faulthandler enabled under Python 2, so you can put this into Pythonista 3's new shared site-packages without getting a red error message every time.

dgelessus

Update: enable_faulthandler now also sets an Objective-C uncaught exception handler, which logs the Objective-C exception details and C call stack. The Objective-C exception handler works in Pythonista 2 and 3, but you get a Python traceback (in addition to the C call stack) only in Pythonista 3.