Path: csiph.com!usenet.pasdenom.info!dedibox.gegeweb.org!gegeweb.eu!nntpfeed.proxad.net!proxad.net!feeder1-2.proxad.net!news.tele.dk!news.tele.dk!small.news.tele.dk!newsgate.cistron.nl!newsgate.news.xs4all.nl!post.news.xs4all.nl!not-for-mail
To: python-list@python.org
From: Ned Batchelder <ned@nedbatchelder.com>
Subject: Re: encode and decode builtins
Date: Sun, 16 Nov 2014 08:43:49 -0500
References: <CALW7ahxWU_N87oAz0JJoXEiyLO0Erx-YggVmQgggzxST6Ra6XQ@mail.gmail.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:24.0) Gecko/20100101 Thunderbird/24.6.0
In-Reply-To: <CALW7ahxWU_N87oAz0JJoXEiyLO0Erx-YggVmQgggzxST6Ra6XQ@mail.gmail.com>
Precedence: list
Newsgroups: comp.lang.python
Message-ID: <mailman.15885.1416145445.18130.python-list@python.org>
Lines: 62
NNTP-Posting-Host: 2001:888:2000:d::a6
Xref: csiph.com comp.lang.python:80880

On 11/16/14 2:39 AM, Garrett Berg wrote:
> I made the switch to python 3 about two months ago, and I have to say I
> love everything about it, /especially/ the change to using only bytes
> and str (no more unicode! or... everything is unicode!) As someone who
> works with embedded devices, it is great to know what data I am working
> with.

I am glad that you are excited about Python 3.  But I'm a little 
surprised to hear your characterization of the changes it brought.  Both 
Python 2 and Python 3 are the same in that they have two types for 
representing strings: one for byte strings, and one for Unicode strings.

The difference is that Python 2 called them str and unicode, with "" 
being a byte string; Python 3 calls them bytes and str, with "" being a 
unicode string.  Also, Python 2 happily converted between them 
implicitly, while Python 3 does not.

>
> However, there are times that I do not care what data I am working with,
> and I find myself writing something like:
>
>     if isinstance(data, bytes): data = data.decode()
>

This goes against a fundamental tenet of both Python 2 and 3: you should 
know what data you have, and deal with it properly.

> This is tedious and breaks the pythonic method of not caring about what
> your input is. If I expect that my input can always be decoded into
> valid data, then why do I have to write this?
>
> Instead, I would like to propose to add *encode* and *decode* as
> builtins. I have written simple code to demonstrate my desire:
>
> https://gist.github.com/cloudformdesign/d8065a32cdd76d1b3230

If you find these functions useful, by all means use them in your code. 
  BTW: looks to me like you have infinite recursion on lines 9 and 20, 
so that must be a simple oversight.

>
> There may be a few edge cases I am missing, which would all the more
> prove my point -- we need a function like this!

You are free to have a function like that.  Getting them added to the 
standard library is extremely unlikely.

>
> Basically, if I expect my data to be a string I can just write:
>
>     data = decode(data)
>
> ​Which would accomplish two goals: explicitly stating what I expect of
> my data, and doing so concisely and cleanly.
>
>
>


-- 
Ned Batchelder, http://nedbatchelder.com