Changing the name of any folder will always move it into the root Script Library folder, even if it was previously located elsewhere. Fortunately this does not cause data loss, all files will still be in the folder after this happens, so you can move the folder back to the correct location no problem. If you can move folders, that is.
Thanks! I'm surprised no one (including me) has noticed this before, that bug must have been there for a while...
I noticed it a while back, but actually thought it was a feature :). The name you type gets interpreted as a path name relative to the Documents folder, so you can move a folder using the rename button, by typing in a relative/path/name. If you want to rename in place, you can do it, if you include the path name relative to Documents.
@omz, I have noticed it a while ago too, but I thought you already know about it and it will be fixed in the new version :)
Here is another bug.
Looking at a script, if you press and hold the Run button, a dialog box appears that allows you to specify command line parameters. Looking at the console, if you press and hold the Run button, no dialog box appears.
More bugs! When calling a console.input_alert(), password_alert() or login_alert(), the keyboard focus isn't actually in the text field, but remains in the console/editor.
Here's one... ui.measure_string seems to give an error when trying to pass a line break mode
>>> ui.measure_string('test',line_break_mode=ui.LB_WORD_WRAP )
Traceback (most recent call last):
File "<string>", line 1, in <module>
RuntimeError: more argument specifiers than keyword list entries (remaining format:'i')
ui.measure_string needs to be called in the main thread within a drawing context. Does this bug occur when ui.measure_string() is called in the main thread within a drawing context?
@ccc It looks like those are two separate bugs.
The console input alert variants only take title, message and hide_cancel_button as keyword arguments. The other arguments need to be passed positionally. For example, this is not possible:
console.input_alert("Enter something", ok_button_title="Uzbekistan")
Instead, this has to be done:
console.input_alert("Enter something", "", "", "Uzbekistan")
However, this is possible:
console.input_alert("Enter something", hide_cancel_button=True)
Oh, and hiding the cancel button causes the input dialog to always raise a KeyboardInterrupt("canceled"), even though it should return the input string.
Pythonista crashes when I try to save a PIL Image. No python errors, but a real crash. I think this happens at a memory leak, I've had pythonista crash before when using too big PIL Images.
@coolius A few more details would be helpful – what type of image file are you trying to save (png, jpeg...), where did the image come from, how big is it, what kind/generation of device are you using...?
ui.covert_point, et al, does not work right in fullScreen, converting to/from Screen coordinates.
Here's an example.
import ui
class testconvert(ui.View):
def __init__(self):
self.t1=ui.Label(frame=(0,60,400,20))
self.t2=ui.Label(frame=(0,90,400,20))
self.t3=ui.TextView( frame=(0,120,100,20),bg_color=(1,0,0))
self.t3.begin_editing()
self.t3.text='textview for kb'
self.t1.text='touch to begin'
[self.add_subview(s) for s in [self.t1,self.t2,self.t3]]
def touch_began(self,touch):
self.t1.text='touch in view:={0:1}'.format(touch.location)
self.t2.text='touch in screen:={0:1}'.format(ui.convert_point(touch.location,self,None))
def draw(self):
kb=ui.get_keyboard_frame()
ui.set_color((0,1,0,0.5))
ui.fill_rect(kb[0]-10,kb[1]-10, kb[2]+20,kb[3]+20)
def keyboard_frame_did_change(self,frame):
ui.delay(self.set_needs_display,0.5)
def touch_moved(self,touch):
self.touch_began(touch)
V=testconvert()
V.present('fullscreen',hide_title_bar=True)
In fullscreen, we'd expect both screen and view coordinates to match. But it seems like convert is using landscape, button left, as the coordinate system, both for origin and orientation.
This may be related to some of the keyboard funniness, seems like maybe keyboard frame related functions might be using a similar convention, except I think keyboard frame is fixed in portrait! The keyboard frame in this example is drawn in green, slighty bigger than real frame so you can see it... Setting the keyboard to split and moving it up/down shows how the kb thinks it is moving... Things seems to be fixed to portrait, except it seems to switch between right side up and upside down depending on how it is rotated in landscape...
A bug in the scene module?
If you set frame_interval to 0.1 in scene.run, it will give you an error.
If after that you change frame_interval to 0 and try to run script again, nothing happens.
If you try to run the script again, Pythonista crashes (often)
Smallest example:
import scene
scene.run(scene.Scene(), frame_interval=0.1)
When using the UI Editor...
1.) Place a segmented control in the center of your view.
2.) Place a label underneath segmented control, also in the center of your view.
3.) Present as a sheet, and you'll see the label gets auto positioned under right segment.
Tech, not a bug. label defauls to no flex, segmented control defaults to LR. Just go into attributes/resizing, snd select the left and right parts to force LR flex.
Actually, this does bring up something confusing: in the ui editor, where you select flex settings, the convention seems to be reversed for WH compared to TBL or R. In other words, when you have W or H selected, those arrows show up as dark/solid. When you have T, B, L, or R selected, they show up as light/dashed.
@JonB True, that can be a bit confusing. I'm following Interface Builder's conventions in the UI, see this StackOverflow answer for a couple of examples (screenshots with explanations).
@omz wow, bizarre! The IB convention makes no sense!
Can't remember if this was reported... In ui builder, if the resizing options dialog is open (the flex animation thingie), then you click in the button which toggles between editor and ui builder, pythonista crashes
I often find Pythonista crashes when I copy text from a web page directly into the editor. Is this a well known bug or should I provide examples?
sys.exit() does not put a \n after its output
import sys ; sys.exit()EXIT (0)EXIT (0)EXIT (0)EXIT (0)\nEXIT (0)\nEXIT (0)\nSometimes, in the editor, when I write two equal signs in an if condition and quickly touch space, the last equal sign will be replaced by a whitespace. I don't know if anyone else have stumbled upon this bug, but it really bugs me (pardon the pun).
@Sebastian, yes, I am expecting the same behaviour. I thought it was me pressing spacebar instead of another = sign accidentally
This bug has been reported before - Windows style carriage returns can cause Pythonista to crash. The report said that happened when using the delete key. I have found that too. But also I have found the crash simply upon opening a script.
The interesting bit is that it was only a small section of code that caused the crash. Deleting a couple of lines on a PC avoided the crash.
If you want a copy of the file I can supply it as a zip archive.
Hi, we found a bug for input from external bluetooth keyboard.
We have a japanese layout bluetooth keyboard.
When use the keyboard for coding in Pythonista, the keyboard is recognized as US layout, can't enter some marks as printed including double-quote, brackets brabrabra.
We've checked another applications then they accept the characters as printed.
I think this can be happened with a AZERTY layout keyboard. But I don't have it.
It is possible that your keyboard layout is set incorrectly. In the Settings app, go to General > Keyboard > Hardware Keyboard, and check the settings for the Japanese layout you're using. I don't know anything about Japanese, but I can set my hardware layout to "Kana", that may be what you're looking for.
If this didn't help, try pressing Cmd+Space until the right keyboard layout is selected.
@inoddy - Thank you! I was wondering what was causing me to crash when hitting backspace on a carraige return. I would have never guessed.
Two more things:
something .attrib .do_stuff(arg1 , arg2 ). I know it's just a minor style thing, but the code just looks wrong with the extra space. And it doesn't work the same as the completion in the editor does.@dgelessus I know this isn't ideal, but for now, if you're "locked out", you could open Pythonista by entering pythonista:// in Safari. This will skip the "reload last file" step.
Thanks, that works perfectly! Now to clean up the C lexer cache files that caused this...
Yet another thing: when typing any kind of opening parenthesis inside a string or comment without "closing" it in the same line, the next line will be indented like e. g. with multiline dicts. For example:
dict = { # expected indentation
"a": "b",
"c": "d",
"e": "f",
}
if char == "{": # curly brace inside string should be ignored
# gets indented up to here
# but should only be up to here
Pythonista crashes when I try to save any kind of image, no matter what size. I am using an iPad 4.
Coolius, can you provide an example?
@dgelessus Thank you to your keyboard setting advice. And sorry to late reply.
I miss understood, actually iOS doesn't accept inputting English with Japanese hardware keyboard layout.
This mean, in the hardware keyboard setting, no option to choose input ASCII character with Japanese keyboard layout.
Note: With "Kana", it means inputting Japanese character, not ASCII.
sys.exitfunc isn't called when Pythonista catches a SystemExit, and the atexit module doesn't work either. On the contrary, os._exit(status) is not caught and will actually exit the app.
@dgelessus mentioned it, but I'd like to confirm the whole hud_alert sending a constant KeyboardInterupt when you hide the cancel button. I don't know why it was never noted when I posted in July.
https://omz-forums.appspot.com/pythonista/post/5284607821873152#post-5284607821873152
I'm having weird behavior when using the ui module. I'll post an example of when it happens, though I think it can happen in other instances as well but I haven't narrowed it down.
I have 2 unrelated scripts that both use the ui module and use the same names for delegate handlers for ListDataSource e.g. the name of the method for tableview_accessory_button_tapped is foobar. I run one script (but don't call the delegate method) and then leave Pythonista. When I come back and run the second [unrelated] script and (e.g.) tap the detail_button in my TableViewCell it calls the method of the OTHER script with the data of the CURRENT script (and outputs that result and/or throws an error, for obvious reasons).
I think the key issue is Pythonista caching of code - when it sees a method name that it already knows (even if it wasn't called prior) it will call that method. Is this expected behavior and/or is there a workaround (other than renaming all my methods)?
Are you running these as scripts? Or do you import?
If importing, note that if you have already imported a module, it won't reimport unless you specifically reload the module.
When you say you leave pythonista and come back, do you actually kill the app?
If you just task switch away, then come back within 15 minutes or so, generally the interpreter hasn't been cleared. If you see the large >>> splash screen, I think that means the interpreter has restarted, otherwise your old interpreter session is active(unless you set the setting to clear globals). You can also hold the clear button in the console screen, which lets you restart pythonista.
Also, are you setting delegate handlers in the ui editor, or in the script?
If you have set a custom class in the ui editor, loading the pyui actually creates an instance of that custom class, so if you were sharing a pyui between two scripts...maybe you might get unexpected things happening.
Are you sure that your second script defines the method before using it? You should be able to redefine a method and it will overwrite the existing definition..
It might help if you can post an example of two minimal scripts that show this problem, and steps to recreate.
@JonB It does seem to only happen when there is a pyui file although if 1 script has a pyui and one doesn't (no shared pyui) it still happens. I'm trying to make a minimal example that reproduces this.
OK here's a minimal example that I extracted from my code. 1 script uses a pyui file and the other does not.
2 ways to reproduce:
1) when starting Pythonista from a cold start and launching test1.py (has a pyui file) and tapping the accessory button nothing happens. If I re-launch it then the proper action is executed.
2) launch test2.py and then launch test1.py and tap the accessory button, the console.alert will have the data from test2.py
The problem is, your action and accessory action must be define BEFORE your load your view, if the pyui references them.
In test1, when you load the pyui first, the actions are not defined, thus nothing happens, until you run the second time, at which point it is defined.
When you run test2 first, you are defining the accessory action, which gets used when you load the pyui.
The solution: in test1.py, define your actions, before you load the pyui. I posted a comment on your gist.
@JonB yes that's it! Thanks so much.
I guess I'll leave this conversation here - although it's not a bug, the default behavior should be to throw a NameError exception instead of using a "cached" method from a totally different script.
If you don't want old scripts to carry over, you can set Clear Global Variables before run in the interpreter options menu. That way it is more like the python commandline. Default behaves more like an interactive interpreter, which personally I prefer, but you do have to be wary of leftover globals that make otherwise invalid code run without exceptions. So, your case 2 doesn't bother me.
I was surprised that case 1 failed silently. For other actions, like button, if the function cannot be found it doesn't generate a NameError, but does at least print a warning to the console. If delegate actions just fail silently, that may be a bug, or at least an oversight.
Warning: Couldn't bind action 'some_undefined_action' of 'button1'
Yeah it fails silently in both cases if Clear Global Variables is on.
1)Since upgrading to iOS 8.x any alert that takes input doesn't open the keyboard. console.input_alert, console.login_alert, when prompted for keychain.master_password. Before iOS 8 the keyboard would automatically pop up.
2) switching to a 3rd party keyboard and using it, then switching to another keyboard (maybe only 1st party?) crashes Pythonista.
The current Paramiko module (version 1.13.0) in Pythonista is not compatible with newer OpenSSH versions
https://github.com/paramiko/paramiko/issues/423
(I already told Ole on twitter - but just want to put it in the forums also)
@omz I have been playing around with the ui.Image module and have found what I may think is a bug. When I use ui.Image.named('Test_Lenna') it works as expected, but when I do the following: ui.Image.named('_my_Image') it returns None. For now, I have a work-around, where I first open the image in PIL and then convert the Image to a bytes and then use ui.Image.from_data(bIO.getvalue()).
Let me know if there is something obvious I have overlooked or if this kind of picture importing is not possible. Thank you!!!
@blmacbeth If it's not a built in image, I believe you have to use the image's full path.
Perhaps not technically a bug, but a common source of incompatibilities:
sys.stdin, std.stdout, and sys.stderr should have an isatty() method which returns false. This might not technically be a "bug", since python docs don't seem to require all file methods to be implemented, except maybe read and write, many other external libraries assume a file-like object.