@BarryZ Are you sure that you're running exactly the same code on your Mac and in Pythonista, especially the part that you type into the Python console? There is an important difference between q = Quadratic_Functions_4_1 and q = Quadratic_Functions_4_1() (note the parentheses at the end).

Also, it looks like you might not need to use a class here at all. Your current code would work just fine if you move the functions out of the class, then you can use QFY(1, 2, 3, 4) directly (without q before it).

What exactly isn't working when you run the code? Do you get an error? If so, please tell us what the error message is, otherwise it's very hard to find out what's going wrong. If possible, copy and paste the exact error message that you get.

@Abdul If you want to make a new forum topic, click on the "Pythonista" link at the top (next to "Home"), and then use the "New Topic" button.

If you want to reply to an existing topic, use the "Reply" button (like you just did :)

My pythonista_startup repo has a customize_sys_hooks.py that implements a better traceback display in the console. Among other things, it lets you customize the colors that are used. (It also has a few other features, for example the file paths in tracebacks can be tapped to open the source file in question.) The default colors are designed for light themes, but you can change the set_color calls to use colors that work better with a dark theme.

This only affects tracebacks though, any other stderr output will still be displayed in red. You could probably customize that too, by writing a sys.stderr replacement that sets the console color to something different. Alternatively, if you don't care about the difference between stdout and stderr, you can do sys.stderr = sys.stdout.

It's not possible to install scipy into Pythonista yourself, because it requires large amounts of compiled code. (Apple's code signing requirements make it impossible to run any compiled code in Pythonista that doesn't come from Apple or the app developer.) This means that any libraries that depend on scipy probably can't be used either. If matplotlib-venn is a pure Python library, it will install successfully, but without its dependencies it won't work properly.

It might be possible to get the library to work if scipy isn't used in many places in the library. You could try to edit the library source code (under site-packages) and comment out all scipy imports, and see if the library still works. If you're lucky, you might be able to get the library at least partially working in Pythonista.

(Note: when you modify a library under site-packages, and you have already imported that library, your changes won't take effect right away because the imported module is cached. To fix this, you need to restart Pythonista, so that the library is reloaded properly.)

I'll add my vote for using a JSON file to save settings :) JSON maps nicely to Python lists/dicts, so I find it very convenient to use for this sort of thing. I wouldn't put it in the keychain unless the data is actually sensitive, simply because it seems like the wrong tool for the job. I don't know enough about Pythonista's keychain module and the iOS keychain in general to say if it would actually be bad, but personally I wouldn't want to test it out.

@cvp By the way, you can use dict.pop(key, None) to remove a key if it's in the dict, and do nothing if it's already missing. That way you can simplify your code to this:

for key in settings_del:
    settings.pop(key, None)

Similarly, there's dict.setdefault(key, value): if key is already in the dict, it returns the existing value, otherwise it does dict[key] = value and returns value. That way you can write code like language = settings.setdefault("language", "en-US"), which gets the language from the settings and sets it to "en-US" if missing.

Right, normally I work in Pythonista, so I don't know that much about Editorial workflows and such. As far as I know, Editorial and Pythonista share the same code for their Python runtime (although Editorial's is Python 2 only and older than Pythonista's), so the ui module should be compatible between Editorial and Pythonista aside from minor bugs.

I forgot that Editorial doesn't let you import files directly... you can use this code for example to download the zip file (paste the code into the Python console, then run download_file("<zip url copied from GitHub>")).

OK, so it seems that the current version of filenav runs fine in Editorial, it seems I tried it previously, because I already had all the files in Editorial :)

The basic installation steps are like this:

1. Download the filenav source code as a zip from GitHub and import it into Editorial
2. Make a folder site-packages (in the "Local Files" folder in Editorial), and in that a folder filenav
3. Use the zipfile module to extract all files from the zip into that folder (with zipfile.ZipFile("filenav.zip") as zf: zf.extractall("site-packages/filenav"))

And to launch filenav, run the following code (in the console or in a workflow):

import os
import filenav.__main__

os.chdir(os.path.expanduser("~/Documents/site-packages/filenav")
filenav.__main__.main([])

The main difference between filenav v1 and v2 is that v2 has a cleaner code structure, makes better use of the large screen on iPad (you get multiple folder columns, like in the Finder on macOS), and has the "favorites" feature. Also it's newer and has fewer bugs than v1 :) filenav_v1.py in the filenav repo is just the old version of filenav, I don't think there's anything special about it.

I don't know if filenav will help much in your situation, like the standard file browser it cuts off filenames longer than a certain length. Maybe there's a way to change it to "cut out the middle" mode ("abc...xyz" rather than "abcdefg...") but I don't know if that's easily possible with the ui module. Also it seems that in Editorial you cannot present views in "panel" mode (i. e. as a tab next to the console and documentation), at least on iPhone, so you can't quickly switch back and forth between filenav and the editor.

I can't say much about how secure and/or private iCloud Drive is - Apple claims that all iCloud user data on their servers is encrypted and that they can't read it, but of course there's no way to know for certain. I also don't know how it compares to Dropbox. In the end, the only way to be really sure that your data is safe is to use an extra layer of encryption on top of the cloud/sync service, but that's not really possible on iOS.

By default, if you enable iCloud Drive on your device, it will sync files for all apps that support it. You can selectively disable iCloud Drive for certain apps, but you cannot selectively enable it (unless you turn it off manually for each new app). What exactly gets synced depends on the app - for example Apple's "office" apps (Pages, Numbers, Keynote) store into iCloud with no other option. (At least that's how it works on iOS 10 and before, things might have changed since iOS 11.) Other apps (such as Pythonista) let you choose yourself which files to put into iCloud and which to keep local.

I don't use Dropbox with Pythonista myself, so what I'm saying here might be wrong, you should try it out yourself to be sure. But as I understand it, when you open code from external apps (such as Dropbox) in Pythonista, the code has to be in a single file and cannot read any other files from Dropbox. This is because of how iOS handles file permissions - when you open a script from Dropbox in Pythonista, iOS allows Pythonista to access exactly that one script, and nothing else. You don't have this problem when using Pythonista's iCloud Drive integration, because there Pythonista has its own folder separated from all other apps, so iOS gives Pythonista full access to that folder. (However, iCloud Drive files outside of Pythonista's folder have the same access restrictions as Dropbox files for example.)

I can tell you for sure that Stash (or anything like it) was never included in Pythonista or Editorial. :) The old filenav version that you linked to apparently supports integration with Shellista (the predecessor of Stash), I totally forgot that I implemented that :) However the integration wouldn't work without having Shellista already installed before, it's definitely not an automatic downloader.

In any case, that version of filenav is really old, and Shellista is obsolete now. Stash is quite easy to install though, there are installation instructions on the repo page, you only need to copy and paste a single line into the Python console.

Editorial has no iCloud Drive support, but does have built-in Dropbox sync, so you should have no issues there. I don't know how well filenav works in Editorial, I never tested it there. Also the current filenav version is split into multiple files, which is always a bit difficult to use in Editorial, because then you can't simply paste it into a workflow. However the current filenav version lets you add custom "root folders"/favorites, so if you can get it to run in Editorial and find out where Editorial stores the Dropbox files, you can add that location into filenav.

For transferring your own code, I would strongly recommend using iCloud, which Pythonista supports since version 3.2. The "iCloud" folder that you see in Pythonista appears as "Pythonista 3" in iCloud Drive on your Mac (assuming both devices use the same iCloud account of course). Since iCloud Drive is Apple's native way of syncing files, it works relatively quickly and with almost no issues - if you create/modify/remove a file in "iCloud" under Pythonista, the change will appear in iCloud Drive on your Mac, and vice versa. I use iCloud with Pythonista to sync some code between my iPhone, iPad and Mac, and haven't had any issues so far.

If you want to use Git, I would recommend installing Stash, which has a git command implemented in Python that supports the most important Git features. There's also an app called Working Copy, which can work with Git repositories, and can be used together with Pythonista. I have never tried this myself though, so I don't know how (or how well) this works.