First time here? Check out the FAQ!
1

Debug console and gettext-enabled programs

When you use the Debug console while a program is paused, it sets the special variable _ with the value of the last executed expression. as is the normal Python interpreter behaviour.
This gets to be a problem though: I have a gettext-enabled project with lots of _("localized") strings, so whenever I execute a statement inside the debug console, the _ gets redefined and I can't resume the program correctly, since on the next _("string") occurrence it would throw an error while trying to call _. Is there a recommended way to preserve _ while using the debug console?

I'm using Wing Pro 7.0.2.0

Joril's avatar
104
Joril
asked 2019-05-22 03:21:43 -0500
Wingware Support's avatar
4k
Wingware Support
updated 2020-01-22 19:49:21 -0500
edit flag offensive 0 remove flag close merge delete

Comments

add a comment see more comments

3 Answers

0

Wing should only be setting _ if it's not already defined in the environment, so in the case where gettext is used it should be leaving it alone. I just checked this in a simple test here and it works. It does set _ if you interact in the Debug Console before _ has been defined, so calling something that expects _ to be gettext won't work in that context. But of course in that case it would fail anyway on _ being undefined. Is that the case you are seeing, or something else? If you have a test case that shows it not working right, that would be useful to have.

Wingware Support's avatar
4k
Wingware Support
answered 2019-05-22 08:00:42 -0500
edit flag offensive 0 remove flag delete link

Comments

add a comment see more comments
0

I see... I think the problem is that I define _ just once throughout my code, via __builtin__.__dict__['_'] = translate_function. Wing instead expects _ to be defined/imported inside every module, maybe?

Joril's avatar
104
Joril
answered 2019-05-22 08:14:45 -0500
edit flag offensive 0 remove flag delete link

Comments

Yes, that's it. It appears our test doesn't look in __builtin__. We'll fix this in the next release. Thanks for reporting this problem!

Wingware Support's avatar Wingware Support (2019-05-22 08:34:10 -0500) edit

Great, thanks! :)

Joril's avatar Joril (2019-05-22 08:36:00 -0500) edit

Actually turns out we're trying to identify that _ is a gettext translator and overriding the default shell behavior of resetting _ only in that case. Contrary to what I thought, we are looking in __builtin__ correctly, but I think the problem is your translate_function is not being recognized. Can you show what it is set to?

For example, the following works for me:

__builtin__.__dict__['_'] = gettext.translation('test', '/Users/test', ['de']).ugettext

I'm looking at a different approach that doesn't try to narrow messing with it to only the gettext case, but I'm not sure it'll work so it would be useful to see what you've set as _.

Thanks for reporting this problem!

Wingware Support's avatar Wingware Support (2019-05-22 10:05:02 -0500) edit

Well I'm using a custom function that wraps gettext with some logic... May I ask how you tell if _ is related to gettext? Maybe I can modify my code to trick Wing :)

Joril's avatar Joril (2019-05-22 10:51:06 -0500) edit
1

We're expecting isinstance(_, types.MethodType) and isinstance(_.__self__, gettext.NullTranslations) (or _.im_self in Python 2). So you may be able to fake out Wing <= 7.0.2.0 by descending a class from gettext.NullTranslations and using a method in that class as the translator.

That said, I'm pretty sure we're just going to change this to override the default of setting _ to last value if _ was set at all (to anything). I think the rationale for the current implementation was to narrow the case where we mess with default shell behavior as much as possible, but arguably if code has _ defined it shouldn't be altered even if it's not gettext.

Wingware Support's avatar Wingware Support (2019-05-22 11:05:18 -0500) edit
add a comment see more comments
1

For the record, this was fixed in Wing 7.0.3.1. Thanks!

Joril's avatar
104
Joril
answered 2019-06-07 02:21:55 -0500
edit flag offensive 0 remove flag delete link

Comments

add a comment see more comments

Your Answer

Please start posting anonymously - your entry will be published after you log in or create a new account. This space is reserved only for answers. If you would like to engage in a discussion, please instead post a comment under the question or an answer that you would like to discuss.

Add Answer