• dgelessus

    @scatter The ui module is specific to Pythonista, you cannot use it on other systems. It's also heavily based on the iOS UIKit framework, so it wouldn't be very easy to port (especially to non-Apple platforms).

    posted in Pythonista read more
  • dgelessus

    @BlockSweeps By default, the views loaded from your UI file aren't available as Python variables. If you want to access your views from Python, you need to store the root view (returned from ui.load_view) in a variable and use that to access the other views:

    import ui
    
    def hit_button(sender):
        # root['textfield1'] means "root's subview with the name textfield1"
        root['textfield1'].text = 'Hello'
    
    root = ui.load_view('My UI')
    root.present('sheet')
    

    posted in Pythonista read more
  • dgelessus

    No, Pythonista 3 is a separate app, so you need to purchase it again. For a while after Pythonista 3 was released, there was a bundle with Pythonista 2 and 3 in it, which allowed you to get Pythonista 3 at a lower price if you already owned Pythonista 2. This is no longer possible though. (Pythonista 2 is also no longer available for purchase - Pythonista 3 supports both Python 2 and 3, so there's no advantage to buying version 2 instead of 3. If you already own the app, you can still redownload it of course.)

    If you do buy Pythonista 3, there is one upgrade-related feature that you can still use. If you go into Pythonista 3's settings, you can enable the "Pythonista 2 Files" option. This shows your Pythonista 2 Script Library as a special folder inside the Pythonista 3 file list, which you can use to easily transfer your files from Pythonista 2 to 3, using the normal "move" button in the file list. You can disable the option later to hide the Pythonista 2 files again (nothing will be deleted of course).

    posted in Pythonista read more
  • dgelessus

    @technoway Python actually has a built-in limit on how deep the Python call stack can go. You can get the current limit with sys.getrecursionlimit() and change it with sys.setrecursionlimit(limit). The default limit is 1000, which is normally enough that you don't overflow the native stack even if you hit the Python recursion limit. In Pythonista that seems to be too much though, if I run an infinitely recursing function with the default limit, Pythonista crashes. With a lower limit (such as 500) I get a Python RecursionError as expected. I have no idea what the size of the native stack is on iOS, but it's probably lower than on Mac.

    posted in Pythonista read more
  • dgelessus

    This is a "feature" in Python and is indeed the expected behavior (though it's not exactly helpful). Stopping a script in Pythonista does the same thing as pressing Ctrl+C when you run Python in a terminal: it raises a KeyboardInterrupt exception. Normally that causes the script to cleanly stop, while still running all exception handlers. Of course that doesn't help if you catch the KeyboardInterrupt exception, which you are doing indirectly here with the unrestricted except block. As you found out, you can still stop your script by terminating the app though.

    If you have a real script where you want to catch exceptions but not prevent stopping the script, you should add the exception type you want to catch to the except block, for example except ValueError. If you want to catch all "normal" exceptions, use except Exception rather than except - the latter catches literally everything, whereas the former lets some "special" exceptions through (like KeyboardInterrupt).

    By the way, the code that you posted can actually be stopped, you just need to press the stop button roughly 1000 times. At some point you'll hit Python's default recursion limit, because every time you catch the exception, you call dont_stop_me_now recursively.

    posted in Pythonista read more
  • dgelessus

    Pythonista's main "Script Library" folder (where you have your scripts etc.) has a very long name, which is randomly generated by iOS and is different on every device. This makes it impossible to type out the full paths like you would on a normal computer.

    There is a way around this problem though: using the os.path.expanduser function, you can get the full path of a file in this randomly named folder. First, put import os at the top of your script so you can use the os module. Now you can use os.path.expanduser("~/Documents") to get the path to Pythonista's "Script Library" folder. This means that if you have a file "Assignment1.pdf" in the Script Library, you can get its path using os.path.expanduser("~/Documents/Assignment1.pdf").

    For example, if your paths list currently looks like this:

    paths = [
        "/Users/Jean/Dropbox/Assignment1.pdf",
        "/Users/Jean/Dropbox/Assignment2.pdf",
    ]
    

    you would change it to

    paths = [
        os.path.expanduser("~/Documents/Assignment1.pdf"),
        os.path.expanduser("~/Documents/Assignment2.pdf"),
    ]
    

    posted in Pythonista read more
  • dgelessus

    The system-wide font size setting (which you can change in the iOS Settings app) also affects the size of some text in Pythonista, including the file list. Many parts of Pythonista aren't affected though (such as the settings screen and some other table views) and the behavior might be different in the App Store version and the beta.

    posted in Pythonista read more
  • dgelessus

    This is not currently possible. The "Run Pythonista Script" action doesn't mean "run this file with Pythonista", it means "run a Python script that works with this file". At the moment the only way to run a Python script from iCloud is to copy and paste the text into Pythonista.

    The current beta version of Pythonista has much better integration with iCloud and the Files app, and it allows opening files in Pythonista directly, without copying them. I don't know when the next release of Pythonista will come out though.

    posted in General Discussion read more
  • dgelessus

    @wenchoheelio MyClass is a subclass of ui.View. ui.View already has its own __init__ method, and now we also define an __init__ method in our subclass. By default, our subclass __init__ would completely replace the __init__ from ui.View. This would not be good, because then the code in ui.View.__init__ would never run for our MyClass views, and they would not be set up properly. To avoid this, we call super().__init__(*args, **kwargs), which is (in this case) a shortcut for ui.View.__init__(self, *args, **kwargs). That is, we let ui.View initialize our custom view before we do our own initialization.

    The *args and **kwargs syntax is used here to pass all arguments from our own __init__ to the superclass __init__. In a function/method definition, *args stands for "accept any number of positional (unnamed) arguments and put them into args as a tuple", and **kwargs stands for "accept any number of keyword (named) arguments and put them into kwargs as a dictionary". In a function/method call, they do basically the opposite, and pass the contents of the given tuple/dictionary as arguments.

    posted in Pythonista read more
  • dgelessus

    @PeterG You're welcome :) (Are you the same person as @PKHG?)

    posted in Pythonista read more

Internal error.

Oops! Looks like something went wrong!