On Wed, Jan 31, 2018 at 9:48 AM, Serhiy Storchaka <storchaka@gmail.com> wrote:
Hm. As a user, unless I run into problems with a specific encoding, I
never care about how many encodings we have, so I don't see how adding extra encodings bothers those users who have no need for them.
The codecs module documentation contains several tables of encodings: standard encodings, Python-specific text encodings, binary transforms and text transforms (a single one). This will add yet one large table. The user that learn Python will need to learn the difference of these encodings from others encodings and how to use them correctly. The new user doesn't know what is important for he, and what he can ignore until he will need it (and how to know that he needs it).
no new user to Python is going ot study the entire set of built-in encoding in Python to decide what is useful to them -- no one! New (and experienced) users take the opposite approach -- they need an encoding for one reason or another (they are provided data to a service that requires a particular encoding, or they are reading data in another particular encoding). They then look at the built-in encoding to see if the one they want is there. A slightly larger set to look through is a very small burden, particularly if it's properly documented and has all the common synonyms. I still have no ide4a why there is such resistance to this -- yes, it's a fairly small benefit over a package no PyPi, but there is also virtually no downside. (I'm assuming the OP (or someone) will do all the actual work of coding and updating docs....) Practicality Beats Purity -- and this is a practical solution. sigh. -CHB -- Christopher Barker, Ph.D. Oceanographer Emergency Response Division NOAA/NOS/OR&R (206) 526-6959 voice 7600 Sand Point Way NE (206) 526-6329 fax Seattle, WA 98115 (206) 526-6317 main reception Chris.Barker@noaa.gov