• Maybe if you want to support Olé @omz, you can buy Pythonista 3 now for your friends or even for yourself ( one time or maybe ten times) and use the iTunes codes later.

  • Love Pythonista And Love Reddit.
    I think the biggest advantage in moving to Reddit would be getting a more intelligent search, searching in this forum is not good.
    I am no expert but i see no downside to shifting to Reddit.

  • I tested the new BETA build 330012

    it still crashes when I use the in 330007 new introduced key_command feature

    Pythonista.app completely exists when pressing the 'a' key on the external BT keyboard

    # coding: utf-8 import ui import console class UIView (ui.View): def get_key_commands(self): print('get_key_commands') return [{'input': 'a'}] #return [{'input': 'a', 'modifiers':'cmd'}] def key_command(self,sender): print('key_command='+str(sender)) def main(): main_view = UIView(frame=(0, 0, 400, 400)) main_view.name = 'Key Commands Demo' main_view.present('sheet') if __name__ == '__main__': main()

    @omz Do you still have some working example code of the new keycommand API ?

    EDIT: OMZ wrote me. Although title is optional as written in the documentation, it must be set in the BETA otherwise it crashes.

    so the statement

    return [{'input': 'a', 'title': 'a'}]

    repairs keycommands for the BETA. It will be fixed in the coming builds...

  • Still happening. Just now decided to poke them with a @testflightapp on twitter. Maybe they can give me an answer why.

  • @ Phuket2 , My script decodes exactly the way omz's script does the decoding. Omz's script directly does the load_view afterwards but my script just writes to a file (.pyui). Omz's script has the encoded string in data variable but my script reads the whole code as string (it does not run it and hence it does not have the encoded string) and extracts the encoded string. May be there are better ways to extract but I just use regular expression split to extract the encoded string. The data variable uses triple single quotes and hence that is used for splitting. Instead of extracting you can also modify the code file to write the decoded string to a pyui file. I hope it answers your question.

  • This works great except when my ipad is turned sideways the camera acts weird and is like the camera is in mirror mode or something.

  • Hi--is there an FAQ someplace on this subject? Confused about it all. Does the current version of the app support both 2.7 and 3? How? Thanks!

    ETA: Oops. Just answered my own question (saw there's a new app version for 3).

  • There is currently no Xcode template for Pythonista 3, but I'm working on something...

  • @omz thanks, just got scared because of

  • Oh, that's the most useful thing i've ever seen :O

  • https://gist.github.com/3fbe2e785541a43dcfcf887670feb0e6

    This is an updated version of @omz's original, but converted to using create_objc_class so it works in latest version.

    Also, I added a delegate method which returns an annotationView, and uses the annotation title to set the image

  • ui.input_alert() does not accept input as keyword argument, though it says so in the documentation. However following workaround works: ui.input_alert('Title','',<actual-prefilled-input>)

  • @JonB , ok great.
    Edit
    I just noticed that is supported with devices supporting 3D Touch. I didn't really notice before as not using my iphone much

  • Omz could support both but that would be almost twice as much work for him with little extra revenue to pay for it.

    Not within the same app, because of Apple's app guidelines and the whole single-binary-no-dynamic-linking thing.

  • @gyronaut said:

    I would like to compile and run the template under Xcode 7.1 and iOS 9 but get such an error:

    Undefined symbols for architecture arm64:
    "_ffi_prep_closure_loc", referenced from:
    __ctypes_alloc_callback in liblibpythonista.a(callbacks.o)
    "_ffi_prep_cif", referenced from:
    __ctypes_callproc in liblibpythonista.a(callproc.o)
    __ctypes_alloc_callback in liblibpythonista.a(callbacks.o)
    "_ffi_call", referenced from:
    __ctypes_callproc in liblibpythonista.a(callproc.o)
    ld: symbol(s) not found for architecture arm64
    clang: error: linker command failed with exit code 1 (use -v to see invocation)

    Are there any ideas, what will be wrong ?

    THX, Stefan

    Hi Stefan,

    Take a look here:
    [https://forum.omz-software.com/topic/1912/problem-with-xcode-template](link url)

    Summary: Change "Enable bitcode" to "No" in the project settings. I think.

    Good luck,
    TIzzy

  • The extension runs in its own sandbox.. As I recall there was an extensions site packages? You have to separately install packages to both locations.

  • @omz - could you discuss what the background is with cffi and how it relates to the ctypes - ffi combination? I keep seeing references to it as an active project that makes writing the python code simpler somehow but does basically the same thing as ctypes and ffi in combination. Is this old stuff - or new? If new - maybe it solves the 64-bit issues already. Just curious.

    UPDATE: I just noticed that cffi is included in Pythonista under pylib/site_packages along with a copy of pycparser. Interesting.

    ./pylib/site-packages/cffi/__init__.py ./pylib/site-packages/cffi/api.py ./pylib/site-packages/cffi/backend_ctypes.py ./pylib/site-packages/cffi/commontypes.py ./pylib/site-packages/cffi/cparser.py ./pylib/site-packages/cffi/ffiplatform.py ./pylib/site-packages/cffi/gc_weakref.py ./pylib/site-packages/cffi/lock.py ./pylib/site-packages/cffi/model.py ./pylib/site-packages/cffi/vengine_cpy.py ./pylib/site-packages/cffi/vengine_gen.py ./pylib/site-packages/cffi/verifier.py
  • As someone who's been programming for over 15 years, I've found that I agree with the Zen of Python here that usually explicit is better than implicit. Also, in my experience, when faced with an issue like this, the best overall results are gained by trying to help the programmer to understand exactly what the code is doing rather than hide those details away. I know it's common that beginner programmers want to avoid getting caught up in the gory details, but when they eventually do hit problems that knowledge really helps them find the cause and fix it.

    Is running in the background important for most actions, or just a few special (but common) scenarios, like triggering a dialog? I've coded in a few different GUI toolkits, and usually event handlers are run on the main thread. Modal dialogs blocking the app is, in other toolkits, expected behavior, as often in those cases you need a response from the user before the app can continue. If you don't want that behavior there is usually a separate option for showing dialogs non-blocking, where you send in a dialog finished callback function or a delegate.

Internal error.

Oops! Looks like something went wrong!