Mailing List Archive: Discerning "Run Environment"

Discerning "Run Environment"

May 18, 2022, 2:39 AM

Post #1 of 3 (124 views)

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.

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?

Thanks.

Stephen Tucker.
--
https://mail.python.org/mailman/listinfo/python-list

Re: Discerning "Run Environment" [ In reply to ]

rosuav at gmail

May 18, 2022, 2:56 AM

Post #2 of 3 (124 views)

Permalink

On Wed, 18 May 2022 at 19:40, Stephen Tucker <stephen_tucker@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
--
https://mail.python.org/mailman/listinfo/python-list

Re: Discerning "Run Environment" [ In reply to ]

eryksun at gmail

May 18, 2022, 9:18 PM

Post #3 of 3 (123 views)

Permalink

On 5/18/22, Chris Angelico <rosuav@gmail.com> wrote:
>
> 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 suggest using win_unicode_console for Python versions prior to 3.6:

https://pypi.org/project/win_unicode_console

This package uses the console's native 16-bit character support with
UTF-16 text, as does Python 3.6+. Compared to the console's incomplete
and broken support for UTF-8, the console's support for UTF-16 (or
just UCS-2 prior to Windows 10) is far more functional and reliable
across commonly used versions of Windows 7, 8, and 10.

Reading console input as UTF-8 is still limited to ASCII up to and
including Windows 11, which for me is a showstopper. Non-ASCII
characters are read as null bytes, which is useless. Support for
writing UTF-8 to the console screen buffer is implemented correctly in
recent builds of Windows 10 and 11, and mostly correct in Windows 8.
Prior to Windows 8, writing UTF-8 to the console is badly broken. It
returns the number of UTF-16 codes written instead of the number of
bytes written, which confuses buffered writers into writing a lot of
junk to the screen.
--
https://mail.python.org/mailman/listinfo/python-list