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
In the JSON output, the JSON encoder will escape any non-ascii characters to be in the form \u<hex> instead of encoding the unicode char in the encoding of stdout.
However, for text/table output, py3/py27 will print unicode:
$ aws dynamodb scan --table-name testtable2 --output text
FOO ✓
but py2.6 (and only py2.6) will raise an encoding error for table/text output:
$ aws dynamodb scan --table-name testtable2 --output text
'ascii' codec can't encode character u'\u2713' in position 4: ordinal not in range(128)
I believe this is due to a bug in py2.6 (http://bugs.python.org/issue4947) in which the .encoding attribute of sys.stdout is not being honored. To fix this, we can use the compat.get_stdout_text_writer to ensure we have something that will always encode to our preferred encoding.
So the end result of this should be that we always display unicode chars instead of the escape sequences, and this should occur across all of the supported output formats.
The text was updated successfully, but these errors were encountered:
Also, we need to use the get_stdout_text_writer because of a
bug in py2.6 in which the `.encoding` attribute is not honored
for `sys.stdout` (http://bugs.python.org/issue4947).
Fixesaws#1048.
In the JSON output, the JSON encoder will escape any non-ascii characters to be in the form
\u<hex>
instead of encoding the unicode char in the encoding of stdout.However, for text/table output, py3/py27 will print unicode:
but py2.6 (and only py2.6) will raise an encoding error for table/text output:
I believe this is due to a bug in py2.6 (http://bugs.python.org/issue4947) in which the
.encoding
attribute ofsys.stdout
is not being honored. To fix this, we can use thecompat.get_stdout_text_writer
to ensure we have something that will always encode to our preferred encoding.So the end result of this should be that we always display unicode chars instead of the escape sequences, and this should occur across all of the supported output formats.
The text was updated successfully, but these errors were encountered: