General bug report thread

techteej

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.

JonB

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.

omz

@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).

JonB

@omz wow, bizarre! The IB convention makes no sense!

JonB

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

Kenbo01

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?

ccc

sys.exit() does not put a \n after its output

Put the following into an Empty Script: import sys ; sys.exit()
When run three time, it genereates the output: EXIT (0)EXIT (0)EXIT (0)
Instead of the output: EXIT (0)\nEXIT (0)\nEXIT (0)\n

Sebastian

Sometimes, 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).

JadedTuna

@Sebastian, yes, I am expecting the same behaviour. I thought it was me pressing spacebar instead of another = sign accidentally

inoddy

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.

yusuke

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.

dgelessus

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.

smath

@inoddy - Thank you! I was wondering what was causing me to crash when hitting backspace on a carraige return. I would have never guessed.

dgelessus

Two more things:

When in the interactive console, tapping an autocomplete suggestion (that is not a callable) will always add an extra space after the name. This makes sense for assignments and most operators, but for attributes and function calls it will produce strange results, such as 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.
Large files can (and will) lock you out of the app. Accidentally opening one causes Pythonista to practically hang on the "loading file" screen, and although the app isn't considered as "crashed" or "hung up" by the system, no input is accepted anymore until the file is loaded. Quitting and restarting the app won't help either, as it will try to open the large file before displaying any UI. Would it be possible to add a warning before opening a file larger than X megabtyes, or a switch in the external Settings sheet for the app that disables opening the last file temporarily? The latter is common for apps with file management and viewing capabilities to prevent these kinds of lockouts.

omz

@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.

dgelessus

Thanks, that works perfectly! Now to clean up the C lexer cache files that caused this...

dgelessus

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

coolius

Pythonista crashes when I try to save any kind of image, no matter what size. I am using an iPad 4.

JonB

Coolius, can you provide an example?

yusuke

@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.