@nicktimebreak@wnMark@mikashkin The Today widget was removed in the release version of Pythonista because it was too unstable - many scripts required more RAM than iOS allows for Today widgets. If you're really interested in my script, you can run it normally in Pythonista, it will appear as a normal sheet view. Trust me, you haven't missed much :)
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.
One nice thing about the sidebar was that it could be narrower than 200 pt, so a 30 or 40 pix wide sidebar worked well for creating custom auxilary shortcut bars in the editor without sacrificing too much width. But so much more can now be done in objc, I am not complaining.
Not from the console, that's still a normal Python prompt. Inside the pip package there is a __main__.py file, which is the main pip program. If you tap and hold the play button you can pass arguments to the program, so if you would normally run pip install requests you'd write install requests into the arguments field.
On a slightly related note, it looks like sys.path is reset every time a script is run (even an editor action) without reloading site again, which means that any previous sys.path changes from site (including .pth files) are lost until site is manually reloaded.
The original version no longer works in Pythonista 3. It seems that the dir function now converts the return value of __dir__ to an actual list, instead of allowing a subclass. This is the updated version:
# THESE LINES MUST COME LAST.
# Anything past this point is executed in the context of the old
# pythonista_startup module, which may already be partially
new_module = DirAllTheGlobals(__name__, __doc__)
sys.modules["pythonista_startup"] = new_module
This should also still work in Pythonista 2.
@omz please can you add the option to keep globals back?
Perhaps not technically a bug, but a common source of incompatibilities:
sys.stdin, std.stdout, and sys.stderr should have an isatty() method which returns false. This might not technically be a "bug", since python docs don't seem to require all file methods to be implemented, except maybe read and write, many other external libraries assume a file-like object.
I agree. I actually emailed @omz to request that the folders shown be made collapsible. It becomes a problem as soon as you install a single outside library. It seems like the most intuitive "move" interface would be the same sidebar used for navigation.
So that's why I didn't find anything on Wikipedia... I searched for "atomic", which led to a disambig page that didn't have the "Atomicity (programming)" article linked. Thanks for pointing me in the right way.
The problem I think is that your flush() is inside the ui loop, nude red events maybe are getting things out of whack, like the content size perhaps doesn't get updated until after you leave the loop? I found a delay works, as does in_background. Replace your original set to this.
self.out.content_offset = (0, self.out.content_size -self.out.height) # this is the bugged line
Alright, checked some more, and the explicit relative imports seem to indeed work correctly. __package__ is also very useful.
What I'm now wondering about is the first line in my example, since it doesn't explicitly import relatively, but just from the regular PATH locations. I'm almost 100% certain this was different in pysta 1.4, because this script's PATH-relative imports worked just fine, even if the script and its modules were in a subfolder. Now (at least I think it's caused by the 1.5 update) this no longer works, and the modules either need to be in a regular PATH location, or the folder name needs to also be given in the import statements.
Figured it out... apparently SOMEHOW my os.environ["PATH"] got messed up and no longer had "." in it. Added that back in, restarted the app, and everything worked perfectly. Sorry for the trouble.
Though I'd be very interested in what did change my PATH in the first place.
At the moment, no. It would definetely be possible to implement, though it would require a better UI to select multiple files. If you have more than one or two files to distribute it would probably also be better to set up a GitHub repo. That way updating will also be easier, as you only need to update the files that actually changed.