You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Note: these values reflect the state of the issue at the time it was migrated and might not reflect the current state.
Show more details
GitHub fields:
assignee=Noneclosed_at=Nonecreated_at=<Date2005-08-01.18:23:30.000>labels= ['type-feature', 'docs']
title='Encodings and aliases do not match runtime'updated_at=<Date2020-09-19.19:04:08.068>user='https://bugs.python.org/liturgist'
2.4.1 documentation has a list of standard encodings in
4.9.2. However, this list does not seem to match what
is returned by the runtime. Below is code to dump out
the encodings and aliases. Please tell me if anything
is incorrect.
In some cases, there are many more valid aliases than
listed in the documentation. See 'cp037' as an example.
I see that the identifiers are intended to be case
insensitive. I would prefer to see the documentation
provide the identifiers as they will appear in
encodings.aliases.aliases. The only alias containing
any upper case letters appears to be 'hp_roman8'.
Doc patches are welcome - perhaps you could enhance your
script to have the doc table generated from the available
codecs and aliases ?!
Thanks.
liturgist commented on Aug 5, 2005
liturgistmannequin
MannequinAuthor
More actions
Logged In: YES
user_id=197677
I would very much like to produce the doc table from code.
However, I have a few questions.
It seems that encodings.aliases.aliases is a list of all
encodings and not necessarily those supported on all
machines. Ie. mbcs on UNIX or embedded systems that might
exclude some large character sets to save space. Is this
correct? If so, will it remain that way?
To find out if an encoding is supported on the current
machine, the code should handle the exception generated when
codecs.lookup() fails. Right?
To generate the table, I need to produce the "Languages"
field. This information does not seem to be available from
the Python runtime. I would much rather see this
information, including a localized version of the string,
come from the Python runtime, rather than hardcode it into
the script. Is that a possibility? Would it be a better
approach?
The non-language oriented encodings such as base_64 and
rot_13 do not seem to have anything that distinguishes them
from human languages. How can these be separated out
without hardcoding?
Likewise, the non-language encodings have an "Operand type"
field which would need to be generated. My feeling is,
again, that this should come from the Python runtime and not
be hardcoded into the doc generation script. Any suggestions?
loewis commented on Aug 6, 2005
loewismannequin
Mannequin
More actions
Logged In: YES
user_id=21627
I would not like to see the documentation contain a complete
list of all aliases. The documentation points out that this
are "a few common aliases", ie. I selected aliases that
people are likely to encounter, and are encouraged to use.
I don't think it is useful to produce the table from the
code. If you want to know everything in aliases, just look
at aliases directly.
Martin, I don't see any problem with putting the complete
list of aliases into the documentation.
liturgist, don't worry about hard-coding things into the
script. The extra information Martin gave in the table is
not likely going to become part of the standard lib, because
there's no a lot you can do with it programmatically.
liturgist commented on Aug 10, 2005
liturgistmannequin
MannequinAuthor
More actions
Logged In: YES
user_id=197677
The script attached generates two HTML tables in files
specified on the command line.
A static list of codecs in this script is used because the
language description is not available in the python runtime.
Codecs found in the encodings.aliases.aliases list are
added to the list, but will be described as "unknown" encodings.
The "bijectiveType" was, like the language descriptions,
taken from the current (2.4.1) documentation.
It would be much better for the descriptions and "bijective"
type settings to come from the runtime. The problem is one
of maintenance. Without these available for introspection
in the runtime, a new encoding with no alias will never be
identified. When it does appear with an alias, it can only
be described as "unknown."
loewis commented on Aug 10, 2005
loewismannequin
Mannequin
More actions
Logged In: YES
user_id=21627
I do see a problem with generating these tables
automatically. It suggests the reader that the aliases are
all equally relevant. However, I bet few people have ever
heard of or used, say, 'cspc850multilingual'.
As for the actual patch: Please don't generate HTML.
Instead, TeX should be generated, as this is the primary
source. Also please add a patch to the current TeX file,
updating it appropriately.
liturgist commented on Aug 11, 2005
liturgistmannequin
MannequinAuthor
More actions
Logged In: YES
user_id=197677
For example: there appears to be a codec for iso8859-1, but
it has no alias in the encodings.aliases.aliases list and it
is not in the current documentation.
What is the relationship of iso8859_1 to latin_1? Should
iso8859_1 be considered a base codec? When should iso8859_1
be used rather than latin_1?
loewis commented on Aug 11, 2005
loewismannequin
Mannequin
More actions
Logged In: YES
user_id=21627
I think the presence of iso8859_1.py is a bug, resulting
from automatic generation of these files. The file should be
deleted; iso8859-1 should be encoded through the alias to
latin-1. Thanks for pointing that out.
liturgist commented on Aug 11, 2005
liturgistmannequin
MannequinAuthor
More actions
Logged In: YES
user_id=197677
If it does not present a problem, making latin_1 and alias
for iso8859_1 as the base codec would present the ISO
standards as a complete, orthogonal set. The alias would
mean that no existing code is broken. Right?
Would this approach present any problem? Should this
become a separate bug entry?
loewis commented on Aug 11, 2005
loewismannequin
Mannequin
More actions
Logged In: YES
user_id=21627
It does present a problem: the latin-1 codec is faster than
the iso8859-1 codec, as it is a special case in C (employin
the fact that Latin-1 and Unicode share the first 256 code
points). So I think the iso8859-1 should be dropped. But, as
you guess, this is an issue independent of the documentation
issue at hand, and should be reported (and resolved) separately.
When this was discussed ~20 years ago, the list was much shorter. Now, it has grown to several hundred entries, I propose we leave it as is, as it would make the table very long. We can instead add a note pointing to the file?
.. note:: See aliases.py for a complete list of available aliases.
Activity
liturgist commentedon Aug 1, 2005
2.4.1 documentation has a list of standard encodings in
4.9.2. However, this list does not seem to match what
is returned by the runtime. Below is code to dump out
the encodings and aliases. Please tell me if anything
is incorrect.
In some cases, there are many more valid aliases than
listed in the documentation. See 'cp037' as an example.
I see that the identifiers are intended to be case
insensitive. I would prefer to see the documentation
provide the identifiers as they will appear in
encodings.aliases.aliases. The only alias containing
any upper case letters appears to be 'hp_roman8'.
$ cat encodingaliases.py #!/usr/bin/env python import sys import encodingsmalemburg commentedon Aug 4, 2005
Logged In: YES
user_id=38388
Doc patches are welcome - perhaps you could enhance your
script to have the doc table generated from the available
codecs and aliases ?!
Thanks.
liturgist commentedon Aug 5, 2005
Logged In: YES
user_id=197677
I would very much like to produce the doc table from code.
However, I have a few questions.
It seems that encodings.aliases.aliases is a list of all
encodings and not necessarily those supported on all
machines. Ie. mbcs on UNIX or embedded systems that might
exclude some large character sets to save space. Is this
correct? If so, will it remain that way?
To find out if an encoding is supported on the current
machine, the code should handle the exception generated when
codecs.lookup() fails. Right?
To generate the table, I need to produce the "Languages"
field. This information does not seem to be available from
the Python runtime. I would much rather see this
information, including a localized version of the string,
come from the Python runtime, rather than hardcode it into
the script. Is that a possibility? Would it be a better
approach?
The non-language oriented encodings such as base_64 and
rot_13 do not seem to have anything that distinguishes them
from human languages. How can these be separated out
without hardcoding?
Likewise, the non-language encodings have an "Operand type"
field which would need to be generated. My feeling is,
again, that this should come from the Python runtime and not
be hardcoded into the doc generation script. Any suggestions?
loewis commentedon Aug 6, 2005
Logged In: YES
user_id=21627
I would not like to see the documentation contain a complete
list of all aliases. The documentation points out that this
are "a few common aliases", ie. I selected aliases that
people are likely to encounter, and are encouraged to use.
I don't think it is useful to produce the table from the
code. If you want to know everything in aliases, just look
at aliases directly.
malemburg commentedon Aug 6, 2005
Logged In: YES
user_id=38388
Martin, I don't see any problem with putting the complete
list of aliases into the documentation.
liturgist, don't worry about hard-coding things into the
script. The extra information Martin gave in the table is
not likely going to become part of the standard lib, because
there's no a lot you can do with it programmatically.
liturgist commentedon Aug 10, 2005
Logged In: YES
user_id=197677
The script attached generates two HTML tables in files
specified on the command line.
<language-oriented-codecs-html-file>
<non-language-oriented-codecs-html-file>
A static list of codecs in this script is used because the
language description is not available in the python runtime.
Codecs found in the encodings.aliases.aliases list are
added to the list, but will be described as "unknown" encodings.
The "bijectiveType" was, like the language descriptions,
taken from the current (2.4.1) documentation.
It would be much better for the descriptions and "bijective"
type settings to come from the runtime. The problem is one
of maintenance. Without these available for introspection
in the runtime, a new encoding with no alias will never be
identified. When it does appear with an alias, it can only
be described as "unknown."
loewis commentedon Aug 10, 2005
Logged In: YES
user_id=21627
I do see a problem with generating these tables
automatically. It suggests the reader that the aliases are
all equally relevant. However, I bet few people have ever
heard of or used, say, 'cspc850multilingual'.
As for the actual patch: Please don't generate HTML.
Instead, TeX should be generated, as this is the primary
source. Also please add a patch to the current TeX file,
updating it appropriately.
liturgist commentedon Aug 11, 2005
Logged In: YES
user_id=197677
For example: there appears to be a codec for iso8859-1, but
it has no alias in the encodings.aliases.aliases list and it
is not in the current documentation.
What is the relationship of iso8859_1 to latin_1? Should
iso8859_1 be considered a base codec? When should iso8859_1
be used rather than latin_1?
loewis commentedon Aug 11, 2005
Logged In: YES
user_id=21627
I think the presence of iso8859_1.py is a bug, resulting
from automatic generation of these files. The file should be
deleted; iso8859-1 should be encoded through the alias to
latin-1. Thanks for pointing that out.
liturgist commentedon Aug 11, 2005
Logged In: YES
user_id=197677
If it does not present a problem, making latin_1 and alias
for iso8859_1 as the base codec would present the ISO
standards as a complete, orthogonal set. The alias would
mean that no existing code is broken. Right?
Would this approach present any problem? Should this
become a separate bug entry?
loewis commentedon Aug 11, 2005
Logged In: YES
user_id=21627
It does present a problem: the latin-1 codec is faster than
the iso8859-1 codec, as it is a special case in C (employin
the fact that Latin-1 and Unicode share the first 256 code
points). So I think the iso8859-1 should be dropped. But, as
you guess, this is an issue independent of the documentation
issue at hand, and should be reported (and resolved) separately.
6 remaining items
StanFromIreland commentedon Jul 12, 2025
When this was discussed ~20 years ago, the list was much shorter. Now, it has grown to several hundred entries, I propose we leave it as is, as it would make the table very long. We can instead add a note pointing to the file?
malemburg commentedon Jul 13, 2025
Yes, good idea. Having a basic version of the most used aliases in the docs is enough. For full detail, we can refer to the code.
pythongh-42237: Link to complete list of codec aliases (pythonGH-136625)
pythongh-42237: Link to complete list of codec aliases (pythonGH-136625)
[3.14] gh-42237: Link to complete list of codec aliases (GH-136625) (#…
[3.13] gh-42237: Link to complete list of codec aliases (GH-136625) (#…
pythongh-42237: Link to complete list of codec aliases (python#136625)
pythongh-42237: Link to complete list of codec aliases (python#136625)
pythongh-42237: Link to complete list of codec aliases (python#136625)
[3.14] pythongh-42237: Link to complete list of codec aliases (python…