Path: csiph.com!v102.xanadu-bbs.net!xanadu-bbs.net!news.mixmin.net!feeder.erje.net!eu.feeder.erje.net!newsfeed.xs4all.nl!newsfeed5.news.xs4all.nl!xs4all!newsgate.cistron.nl!newsgate.news.xs4all.nl!post.news.xs4all.nl!not-for-mail
Newsgroups: comp.lang.python
Date: Sun, 11 Nov 2012 05:42:35 -0800 (PST)
In-Reply-To: <mailman.3521.1352499071.27098.python-list@python.org>
Complaints-To: groups-abuse@google.com
Injection-Info: glegroupsg2000goo.googlegroups.com; posting-host=108.78.40.138; posting-account=S-UcDQoAAACh3mXdFBHQR00lNytDt6nm
References: <3d4644f8-ab88-41c5-9a52-2a5678dd64c0@googlegroups.com> <mailman.3508.1352483285.27098.python-list@python.org> <99d5bd83-35ab-4801-b953-391c497c35bf@googlegroups.com> <mailman.3517.1352496859.27098.python-list@python.org> <ba72452f-fac6-4b18-9b22-d1854eecbffb@googlegroups.com> <mailman.3521.1352499071.27098.python-list@python.org>
User-Agent: G2/1.0
MIME-Version: 1.0
Subject: Re: Printing characters outside of the ASCII range
From: danielk <danielkleinad@gmail.com>
To: comp.lang.python@googlegroups.com
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Cc: Python <python-list@python.org>
Precedence: list
Message-ID: <mailman.3558.1352642076.27098.python-list@python.org>
Lines: 122
NNTP-Posting-Host: 2001:888:2000:d::a6
Xref: csiph.com comp.lang.python:33127

On Friday, November 9, 2012 5:11:12 PM UTC-5, Ian wrote:
> On Fri, Nov 9, 2012 at 2:46 PM, danielk <danielkleinad@gmail.com> wrote:
>=20
> > D:\home\python>pytest.py
>=20
> > Traceback (most recent call last):
>=20
> >   File "D:\home\python\pytest.py", line 1, in <module>
>=20
> >     print(chr(253).decode('latin1'))
>=20
> > AttributeError: 'str' object has no attribute 'decode'
>=20
> >
>=20
> > Do I need to import something?
>=20
>=20
>=20
> Ramit should have written "encode", not "decode".  But the above still
>=20
> would not work, because chr(253) gives you the character at *Unicode*
>=20
> code point 253, not the character with CP437 ordinal 253 that your
>=20
> terminal can actually print.  The Unicode equivalents of those
>=20
> characters are:
>=20
>=20
>=20
> >>> list(map(ord, bytes([252, 253, 254]).decode('cp437')))
>=20
> [8319, 178, 9632]
>=20
>=20
>=20
> So these are what you would need to encode to CP437 for printing.
>=20
>=20
>=20
> >>> print(chr(8319))
>=20
> =E2=81=BF
>=20
> >>> print(chr(178))
>=20
> =C2=B2
>=20
> >>> print(chr(9632))
>=20
> =E2=96=A0
>=20
>=20
>=20
> That's probably not the way you want to go about printing them,
>=20
> though, unless you mean to be inserting them manually.  Is the data
>=20
> you get from your database a string, or a bytes object?  If the
>=20
> former, just do:
>=20
>=20
>=20
> print(data.encode('cp437'))
>=20
>=20
>=20
> If the latter, then it should be printable as is, unless it is in some
>=20
> other encoding than CP437.

Ian's solution gives me what I need (thanks Ian!). But I notice a differenc=
e between '__str__' and '__repr__'.

class Pytest(str):
    def __init__(self, data =3D None):
        if data =3D=3D None: data =3D ""
        self.data =3D data

    def __repr__(self):
        return (self.data).encode('cp437')

>>> import pytest
>>> p =3D pytest.Pytest("abc" + chr(178) + "def")
>>> print(p)
abc=C2=B2def
>>> print(p.data)
abc=C2=B2def
>>> print(type(p.data))
<class 'str'>

If I change '__repr__' to '__str__' then I get:

>>> import pytest
>>> p =3D pytest.Pytest("abc" + chr(178) + "def")
>>> print(p)
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
TypeError: __str__ returned non-string (type bytes)

Why is '__str__' behaving differently than '__repr__' ? I'd like to be able=
 to use '__str__' because the result is not executable code, it's just a st=
ring of the record contents.

The documentation for the 'encode' method says: "Return an encoded version =
of the string as a bytes object." Yet when I displayed the type, it said it=
 was <class 'str'>, which I'm taking to be 'type string', or can a 'string'=
 also be 'a string of bytes' ?

I'm trying to get my head around all this codecs/unicode stuff. I haven't h=
ad to deal with it until now but I'm determined to not let it get the best =
of me :-)

My goals are:

a) display a 'raw' database record with the delimiters intact, and
b) allow the client to create a string that represents a database record. S=
o, if they know the record format then they should be able to create a data=
base object like it does above, but with the chr(25x) characters. I will ha=
ndle the conversion of the chr(25x) characters internally.