Pythonista 1.6 Beta #160020
Build #160020 is now available via TestFlight. Please use this thread for feedback.
I've just added a couple of new people to the TestFlight list – if you didn't get an invite, but would like to participate, please fill out this form: → Beta Signup.
Here's an example of using
objc_utilto query your Apple Music database. This script just prints the 25 artists you have the most songs of, but you could obviously extend this to get all sorts of statistics about your music... (yes, this does work with the new iCloud Music Library).
from objc_util import * from collections import Counter MPMediaQuery = ObjCClass('MPMediaQuery') query = MPMediaQuery.songsQuery() items = query.items() print '%i songs found, collecting artist info...' % len(items) song_counter = Counter() for item in items: artist = str(item.valueForProperty_(ns('artist'))) song_counter[artist] += 1 print '\n'.join('%i. %s: %i songs' % (i+1, x, x) for i, x in enumerate(song_counter.most_common(25)))
Not sure yet, I might bring it back
Please do. Before the new beta I had an
_init.pyscript that I would run every time I started Pythonista, which loaded various things into the global namespace that I would use a lot interactively. Those were mostly modules like
math, but I also had a nifty
forloop that made every built-in Python class available as a global. Admittedly that isn't too useful, but it's nice to be able to write
_init.pywas also a nice test subject for spontaneous file clearing, which by the way has not happened anymore in the recent betas, even with lots of open tabs.)
Do you have an example of this? I just tried the following code, and it seemed to work fine:
that example crashes my ipad 3, running 8.3! do you want me to send the crash report?
Bug: had the ui editor opened and I put Pythonista in the background. Now when I try to open it it just crashes - doesn't open.
Seem the ui.load_view does not like my fairly complicated pyui file. Worked fine but now:
Traceback (most recent call last): File "/var/mobile/Containers/Data/Application/9EC48B68-E4CB-454A-B52E-3E92C934916F/Documents/chordcalc/chordCalc/chordcalc.py", line 3314, in <module> mainView = ui.load_view('chordcalc') File "/private/var/mobile/Containers/Bundle/Application/743EA4AB-23E2-4CB0-BE78-8FAE0E9A2A89/Pythonista.app/pylib/site-packages/ui.py", line 373, in load_view return load_view_str(json_str, bindings, stackframe) File "/private/var/mobile/Containers/Bundle/Application/743EA4AB-23E2-4CB0-BE78-8FAE0E9A2A89/Pythonista.app/pylib/site-packages/ui.py", line 359, in load_view_str return _view_from_dict(root_view_dict, g, l) File "/private/var/mobile/Containers/Bundle/Application/743EA4AB-23E2-4CB0-BE78-8FAE0E9A2A89/Pythonista.app/pylib/site-packages/ui.py", line 342, in _view_from_dict subview = _view_from_dict(d, f_globals, f_locals) File "/private/var/mobile/Containers/Bundle/Application/743EA4AB-23E2-4CB0-BE78-8FAE0E9A2A89/Pythonista.app/pylib/site-packages/ui.py", line 342, in _view_from_dict subview = _view_from_dict(d, f_globals, f_locals) File "/private/var/mobile/Containers/Bundle/Application/743EA4AB-23E2-4CB0-BE78-8FAE0E9A2A89/Pythonista.app/pylib/site-packages/ui.py", line 258, in _view_from_dict v.text = attrs.get('text') TypeError: Expected a string
Interesting, I guess I haven't really tested this on a 32 bit device. Looks like I have to use
objc_msgSend_stretthere (which doesn't even exist in the 64-bit runtime for some reason).
Could you send me the pyui file somehow? It looks like an easy fix, but in the meantime you can use:
import _ui _ui._load_view(...)
to get the old implementation. This will go away, but I left it in there for now, in case there are problems with the new one.
Could you send me the pyui file you had open (that probably caused the crash)? You can transfer it to your Mac/PC via iTunes file sharing. Let me know if you need more details.
@omz email sent
@omz email sent. Works fine with legacy
This isn't specific to the new beta build, but zip archives with multiple files at root level extract into their parent directory, not a new subfolder like most other unzipping programs do. With only a single file at root level that's not a problem, but I had a zip file with a lot of files at root level, which are now all in the main Script Library folder.
Interesting, I guess I haven't really tested this on a 32 bit device. Looks like I have to use objc_msgSend_stret there (which doesn't even exist in the 64-bit runtime for some reason).
that worked. i updated
__call__to check for Structure restype, and called objc_msgSend_stret. i suspect one may actually need to check the size of the struct, but this seems to work for most structs ive encountered.
No idea if this would be of any use, but have you tried to use
CTypesBackend? Might or might not be a more convenient interface than raw
back on clearing globals, thought id share the workaround for stash:
launch_stash.pywhich imports, rather than runs, stash, then create a new instance.
since the module never gets cleared, it survives global clearing.
import stash _stash = stash.StaSh() _stash.run() stash._stash=_stash
also, some may find this useful as an action menu script. instead pressing Play to run a script, run this from the action menu, which executes the current script without clearing globals. thats at least a workaround if the option to not clear globals doesnt come back.
# execute script in editor, in current interpreter session without clearing globals import editor execfile(editor.get_path())
New to the beta. Firstly, everything seems to run very smoothly on my iPad. However at some point the app stopped working completely: I couldn't open it anymore, I tried restarting my iPad but that didn't work. I had to reinstall it to use it again. It might've been caused by something in iOS 9 (beta 3) though. Also, I noticed that the MIDIPlayer doesn't seem to work properly in a UI action (even with ui.in_background, it's immediately stopped when the action function ends), although it can be fixed with an empty while loop looping until the end of the MIDI file is reached. Lastly, while it's not really a bug, it seems I have to open a new tab, tap Documentation and close the tab to open the documentation, which is a little bit unintuitive.
Anyway, nice work on the update, the tabbed editor and appex module are really useful!
When Pythonista won't launch, you can always try and launching the pythonista:// URL in Safari.
Lol, ccc. I was just about to write the same thing after my screw up yesterday ;)
@omz sorry Ollie but newest load_ view does to handle custom view. My fretboard view does not execute did_load(). Fine with legacy version.
Got it and tested it, it's very promising - I really like the enhanced screen resolution and the new features so far.
Well now I have 2 problems:
- I didn't manage to run my current Scene() totally fullscreen, there is still a close button & white bar displayed. BTW auto-rotation with device seems disabled (my app is running in landscape mode)
- The SceneView() addition, in my UI-based app, crashes Pythonista upon running.
Hackingroelz, you probably need the MIDIPlayer to be a global, or at least an instance variable -- otherwise i think it goes out of scope and stops when the function ends. you just need to hang onto a reference. i dont remember if SoundPlayer had that problem.
Few more comments on latest beta.
NSDictionary get/set using python dictionary language doesnt seem to work. at least for dicts found in the wild, the isKindClass seems to not be returning true. i wonder if it would be better to look for whether the object responds to
valueForKey_etc, rather than checking class? similarly for iterables.
with the tabbed editor, the
editorclass needs updates to access tabs, or should have a
reloadcommand which reloads all tabs. when changing a file on disk, it was a good idea to check if it was thr current file in the editor, and reload, but this cant happen in current version, since reopening a file programatically causes a new tab to open, and the
get_pathonly returns current tab.
the editor should probably disallow opening two copies of the same file, unless one is set to read only. this can cause confusion, where one copy is edited, then switching to the other copy effectively undoes the changes! maybe just bring existing file tab to the front if opening an already open file? alternatively, editor should detect if file on disk changed, and reload (or prompt for reload) as is done in many text editors. ... there are use cases for having two tabs open on the same file, say for editing very large files, but keeping edits in sync is necessary.