If unicode Functionality is Required under Windows then Developer Responsible to Load it

[flywire]

"... Note that it should be a responsibility of a Python user on Windows to install win_unicode_console and fix his Python environment regarding Unicode interaction with console, rather than of a third-party developer enabling win_unicode_console in his application, which adds a dependency. Our package should be seen as an external patch to Python on Windows rather than a feature package for other packages not directly related to fixing Unicode issues."

Sounds like another typical comment from a *nix user - far removed from reality! Windows users expect these issues to be sorted out as part of the installation package.

[Drekin]

Well, as a Windows user I expected these issues to be sorted out as part of the standard Python installation package, but they were not. It's a long standing issue. That's why I've put together this package.

It's the user who should require the Unicode functionality on his Windows Python installation. Why would a developer of a third party package want Unicode support explicitly for his package? Or rather I would think that every package developer implicitly expects that Unicode strings work – there is even not such a thing as a Unicode string in Python 3, it's just a string. It's not a matter of any particular third party package, it's a matter of whole Python installation.

Imagine I'm a developer of a simple Python package for creating and maintaining simple tree-like and tabular structures in plain text files. It may easily happen that a user has a foreign name in his table of names and when he tries to interactively display the table in his console on Windows, it raises an exception. Should every developer of every such a package be adding a dependency to win-unicode-console to his package? Should he be aware of any similar problem on any platform supported by Python and include a dependency to any other platform specific fix like that? Following this logic, even some packages from the standard Python library should be dependent on win-unicode-console since they may print a string originating from a user.

From the other side, imagine the following situation. A user installs a package that prints a string contaning non-ASCII characters and it results in an exception. The user asks the developers: your package raises this exception, is it a bug? The developers answer: it's not a bug in our package, it's a bug of Python itself – just try print("\u03b1") in your console and see. It's a long standing issue, win_unicode_console package tries to solve it – look there for more information. And that's it.

Actually after some time, people won't ask, they will just google the answer. This may increase the awareness of this problem among Python users and may show that there are many Windows Python users that want working Unicode in their consoles, so there will be greater pressure on Python core developers to fix the issue.

[flywire]

"Well, as a Windows user I expected these issues to be sorted out as part of the standard Python installation package ...". I totally agree that this IS where it should be sorted out.