Welcome!
This is the community forum for my apps Pythonista and Editorial.
For individual support questions, you can also send an email. If you have a very short question or just want to say hello — I'm @olemoritz on Twitter.
List of possible enhancements to Pythonista
-
Okay, so I've been using Pythonista quite literally every single day since I first purchased Pythonista 2 a long long time ago. It's fantastic to have Python at your fingertips anywhere you go, anytime, without Internet access, with autocompletion and all the good stuff. I'm always using it to hack some stuff together, test new ideas, start new projects (and then move to PyCharm if they get big), quickly modify code in my GitHub projects with Working Copy etc.
After all that time, I started noticing some things that Pythonista 3 could've done better, and now I decided to list them here, in no particular order.
- Python 3.6 is kinda old - it would be nice to get an update and a wider choice of Python interpreters. For example, 2.7 (which is about to die - please update your projects to use Python 3!), 3.7 and 3.8 beta
- It would be nice to have an update of all the 3rd-party libraries available in Pythonista
- Code completion by Jedi is very useful, but it really sucks sometimes. For example, after you define a new class with
class Thing: ...
and then start typingT...h...i...n...
to refer to this class, the class' name doesn't show up in he autocompletion view, which is super annoying. There's also a much newer version of Jedi: 0.15.1, while Pythonista's using version 0.9.0 - The completion system of the editor relies on caches too much. For example, paste
parser = object()
in the editor and then start typingparser.
on the next line to refer to some attribute. Pythonista will start suggesting attributes of the built-inparser
module, likecompilest
,expr
,isexpr
, which are clearly not applicable here. The completion in the console will suggest the relevant attributes though. I suppose that's because the console has more information about the objects because it has access to the runtime? - Completion of
import
statements in the console is much better than that in the editor. For example, after you install a new module, it will show up in the console's completion, but won't show up when writing the same import statement in the editor. It would be nice if completion ofimport
statements in the editor was as good sys.stdin
andsys.stdout
are actually custom objects that don't properly implement thefile
protocol. For example, they don't have thefileno
method, and in general,sys.__stdout__
andsys.stdout
are completely different beasts, while they should provide the same basic functionality- In the console view, input, for example,
5
and press Return. Then attempt to select the5
in the output. It gets selected, but then the keyboard goes down, and the options to Copy/Select all/Define disappear, making it necessary to touch the selection again. That's also very annoying, especially when you need to Copy&paste random chinks of output into the script - Input this as a script:
ugh = '#' * 2000; print(ugh.join(' hello ; happy ; world ; !'.split(';')))
. Close the keyboard, run the script, scroll up, copy the first word, go back to the script and paste the copied word there. Attempt to copy the second word in the same way. Notice that the console has scrolled all the way down, and now you have to scroll back up. This process quickly becomes very frustrating when copying random chunks of output into the script. It also happens when you don't copy anything: run the code, scroll really high up to find some output, go back to your code to check if this output is correct, then go back - only to find that the view has scrolled back down and you have no idea where exactly that one bit of output you were looking at is.
It would be nice to have the following features too:
- Ability to "run" arbitrary file types (not only Python). For example, running an HTML file would open it in the browser. It may be useful to be able to associate Python scripts with file types, so that when you tap "Run" for some "non-runnable" file, Pythonista would check for the associated script and run it almost like with the
appex
module workflow. It could pass the file's path to the script, which would then process the file's content however it wants to. (Personally, I'd love to run Rust code like that by passing it to some online API)
I may add more points to the list later. I was thinking about posting this for a long time yet never wrote down any of these observations, so this list is most likely incomplete.
Device information: iPhone 6+ iOS 12.4
-
A few more... https://github.com/omz/Pythonista-Issues/issues