Discerning "Run Environment"

Chris Angelico rosuav at gmail.com
Wed May 18 05:56:18 EDT 2022


On Wed, 18 May 2022 at 19:40, Stephen Tucker <stephen_tucker at sil.org> wrote:
>
> Hi,
>
> I am a Windows 10 user still using Python 2.x (for good reasons, I assure
> you.)
>
> I have a Python 2.x module that I would like to be able to use in a variety
> of Python 2.x programs. The module outputs characters to the user that are
> only available in the Unicode character set.
>
> I have found that the selection of characters in that set that are
> available to my software depends on whether, for example, the program is
> being run during an IDLE session or at a Command Prompt.

Real solution? Set the command prompt to codepage 65001. Then it
should be able to handle all characters. (Windows-65001 is its alias
for UTF-8.)

> I am therefore needing to include logic in this module that (a) enables it
> to output appropriate characters depending on whether it is being run
> during an IDLE session or at a command prompt, and (b) enables it to
> discern which of these two "run environments" it is running in.
>
> Goal (a) is achieved easily by using string.replace to replace unavailable
> characters with available ones where necessary.
>
> The best way I have found so far to achieve goal (b) is to use sys.modules
> and ascertain whether any modules contain the string "idlelib". If they do,
> that I assume that the software is being run in an IDLE session.
>
> I suspect that there is a more Pythonic (and reliable?) way of achieving
> goal (b).
>
> Can anyone please tell me if there is, and, if there is, what it is?

Ultimately, it's going to depend on where your text is going: is it
going to the console, or to a Tk widget? I don't have a Windows system
handy to check, but I would suspect that you can distinguish these by
seeing whether sys.stdout is a tty, since Idle pipes stdout into its
own handler. That won't be a perfect check, as it would consider
"piped into another command" to be UTF-8 compatible, but that's
probably more right than wrong anyway.

ChrisA


More information about the Python-list mailing list