• Well, I was a little hasty about my comment about the data does not matter. tuples can not be updated, well at least in place anyway. So my statement was wrong. It does matter. Depends on what you need to do with your data. Tail between my legs again:)

  • This same error happens to me every time I cancel a script while importing requests. I get a keyboardinterrupt error and then it breaks until restart.

  • @dgelessus Thanks!

  • Yes, edit it like any other file.

  • @omz No problem. Relieved I wasn't going crazy lol

  • Thanks, I'll look into it. Couldn't reproduce it with my own files.

  • t.get('user').get('screen_name') did the trick. Thanks.

  • @omz Will do. Thanks for getting back to me so quickly!

  • The dialogs module is so so convenient when wanting to display and interact with simple data.

    And since it's pure python (thanks @JonB for the tip) it's so easy to tinker with.

    (The ui module is way too flexible for most of my projects - so I really like the dialogs module - thanks @omz !!)

  • Cool, I'll try it out.

  • @omz That was it, thanks. You could tell it's been a while!

  • Awesome!

  • If we used something wiki-like that would probably work best. Not sure if the infrastructure @ccc has set up is good for that purpose, or if a Wikimedia-based site would be better.

    As for me, I'm happy to put my shoulder to the wheel. I suspect to start with I'd just be proofreading and editing. But that's a valuable role, too. (I've spent a lot of happy weeks in Poughkeepsie, NY writing technical books (what we call Redbooks) and more time editing others'.)

    I think I'd learn quite a bit in the process.

    In other news I see Rocket have ported Python 2.7.x to z/OS so I might be absorbed with trying that on my home system. :-)

  • Very impressive. Thanks much.

  • If you need a newb's perspective, I'd be happy to help. I'm definitely less far along on the learning curve...

  • Faker isn't part of the Python standard library, it's a third-party module that is included by default in Pythonista. Just saying, in case you want to use it outside Pythonista.

  • @techteej Could be fun :) I don't know when I'll get the time though.

  • Apologies for not updating this earlier.

    I spent a bit of time tonight on Xcode 6.1, looking at where files are going. First, a few notes on setting up:

    Used the latest template linked to in the forum.

    when I open that template in Xcode 6.1, it pops up with a couple of comments on having to optimize a couple of parameters. I can't remember what those were now, but I just agreed. Didn't seem to matter that much.

    I use the tree structure setup by @omz, i.e. the main script is directly under the project root.

    In Finder, I make a 'script' folder in the main project directory. All of my .py and .pyui files go there.

    In Finder, I make an 'image' folder, where I put all of my supporting images.

    In Xcode, I make a 'Script' group (looks like a yellow folder), and add all of the files in the 'script' Finder folder to that group. Note that those groups - those seen in a yellow folder - are just a convenient way to group and organize resources.

    In Xcode, I make a 'my_images' group - also yellow folder - and add all of the files in the 'image' Finder folder to that group. Again, just a convenient way for Xcode to organize files. This is in contrast to the BLUE 'Textures' folder, which directly links to the 'Textures' subfolder in Finder. Any file you see in Finder in that subfolder, will automatically appear in your Xcode project in the 'Textures' BLUE folder.

    With all this being done, I open the 'AppDelegate.m' file in Xcode and add, before the '@end' line, the few lines of code posted by @omz, which address the fopen, fwrite and putenv objects. You can find those at https://omz-forums.appspot.com/pythonista/post/5862618212335616.

    somewhere in your main script, or in supporting scripts, you'll need the find_bundled_files function described in another post.

    If you organize your project as I describe here, all of your .pyui files will end up in the main App folder, just one branch above the os.py file as seen above, in the PythonistaProject.App folder, if you haven't changed anything further in your project. Note that all resources, .py, .pyui, custom images, text files that I've added ended up in here. The ONLY file that was in the Documents folder (os.path.join(os.path.expanduser('~'), Documents) is the main script (Script.py).

    I'm sure there are other ways to organize your folders. I've started reading through some of the 'Build' scripts that the Xcode template has. This is where you see the destination of files in your App. You can try playing around with stuff there. But if you don't, I would recommend start with the find_bundled_files script to find your specific resources, and once you know where to locate them, you can hard-code the relative path, so that your App starts up faster. I'm hoping to do that as an update to the drawing App I developed with my kids ("Drawing with Sonia") and posted recently on the App Store; it does have a bit of a slower launch.

    In addition to all this, a couple more comments - sorry for the very long post:

    If you click on the Project root in Xcode and look at the General properties, I recommend switching to using Xcode assets (.xcassets) files for the app icon and launch images. They've added that functionality since Xcode 5. You just drag and drop the images in there, and it manages everything else for you.

    In the main info.plist file, I've always had to switch the 'Application requires iPhone environment' to YES, otherwise, things don't work for me. Even though the only App I've posted is an iPad App, that flag seemed to be necessary.

    As @omz suggested, if you don't need matplotlib, numpy, images, sounds or other resources already included, I definitely recommend removing them carefully. The base size of an App, if you just use it as is, will run over 50MB just from having to compile for the different processors as well.

    And speaking of different processors supported: again clicking on the main Project root, and going in to the 'Build Settings', you need to remove 'arm64' from the 'Valid Architectures'. Currently, the project isn't compatible with 64-bit, but @omz recently confirmed in another post that he has that support ready for a future version, even though it does take up more space as a project.

    Finally, I would recommend trying to figure out a good place in your App, or in the online description, to give proper credit where it's due. Whether it's recognizing all the hard work @omz has put into Pythonista, or any resources he's included in the template, or any resources you're adding yourself.

    I believe these are most of the tips I can give to you. When it comes to setting up a Developer account and figuring out the iOS App development and posting pipeline, it took me a good several weeks to pass that hurdle, but it is certainly doable. I wish you good luck with that part, and look forward to seeing what can be accomplished with the Pythonista framework.

Internal error.

Oops! Looks like something went wrong!