Path: csiph.com!v102.xanadu-bbs.net!xanadu-bbs.net!news.mixmin.net!feeds.phibee-telecom.net!newsfeed.xs4all.nl!newsfeed4a.news.xs4all.nl!xs4all!post.news.xs4all.nl!not-for-mail Return-Path: X-Original-To: python-list@python.org Delivered-To: python-list@mail.python.org X-Spam-Status: OK 0.075 X-Spam-Evidence: '*H*': 0.85; '*S*': 0.00; 'explicitly': 0.05; 'string': 0.09; 'stating': 0.09; 'url:github': 0.09; 'python': 0.11; 'builtins.': 0.16; 'caring': 0.16; 'pythonic': 0.16; 'demonstrate': 0.16; 'written': 0.21; 'input': 0.22; 'this?': 0.23; 'bytes': 0.24; 'propose': 0.24; 'switch': 0.26; 'point': 0.28; 'function': 0.29; 'message-id:@mail.gmail.com': 0.30; 'code': 0.31; 'with,': 0.31; 'cases': 0.33; 'something': 0.35; 'received:google.com': 0.35; 'add': 0.35; 'there': 0.35; 'data,': 0.36; 'edge': 0.36; 'doing': 0.36; 'method': 0.36; 'two': 0.37; 'to:addr:python-list': 0.38; 'expect': 0.39; 'embedded': 0.39; 'to:addr:python.org': 0.39; 'is.': 0.60; 'ago,': 0.61; 'simple': 0.61; 'times': 0.62; 'myself': 0.63; 'more': 0.64; 'love': 0.65; 'great': 0.65; 'devices,': 0.84; 'or...': 0.84; 'write:': 0.91; 'this!': 0.93 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:from:date:message-id:subject:to:content-type; bh=rDvxB8drCe4vbTBMeGL5HxOlHEh9e+HyuEqb0feqxg8=; b=m2Q6bHnUHIIc+8K7tfmAhNbHHf3v7ufmhZb0MCpr4X0tMBSUXKz0bqsIaueaSMBfka 3ELDU4B5XHHK9eI6I7ECeluqNZu7z7Fzjz37dbJ8l2thE48CU+iFQaAIAb8dnV5XxvYo vOXWnem8+BxyGoNXkIKcBRsAvTUWRFgB3b+JfYvMAWQgTHCzp1vCRaoLuTBHoevJFkcI jiJLfqjCQErD/dXpXjFw30weaRf5+XPn7Ofmg/RYnLMXs+naI8RKueDVM9Y6fGCM+bQ6 LnQHTNoOsf01cL/onEoD9XO8NCEmNNGsqmPt9RD4kyx46um7qOwvgVgXmEzr4uFyy080 kT/A== X-Received: by 10.112.201.6 with SMTP id jw6mr10247024lbc.30.1416123610841; Sat, 15 Nov 2014 23:40:10 -0800 (PST) MIME-Version: 1.0 From: Garrett Berg Date: Sun, 16 Nov 2014 00:39:50 -0700 Subject: encode and decode builtins To: python-list@python.org Content-Type: multipart/alternative; boundary=001a11c372b0c848f90507f4f836 X-BeenThere: python-list@python.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: General discussion list for the Python programming language List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Newsgroups: comp.lang.python Message-ID: Lines: 91 NNTP-Posting-Host: 2001:888:2000:d::a6 X-Trace: 1416123614 news.xs4all.nl 2897 [2001:888:2000:d::a6]:47708 X-Complaints-To: abuse@xs4all.nl Xref: csiph.com comp.lang.python:80859 --001a11c372b0c848f90507f4f836 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable 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. 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 =3D data.decode() 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 There may be a few edge cases I am missing, which would all the more prove my point -- we need a function like this! Basically, if I expect my data to be a string I can just write: data =3D decode(data) =E2=80=8BWhich would accomplish two goals: explicitly stating what I expect= of my data, and doing so concisely and cleanly. --001a11c372b0c848f90507f4f836 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I made the switch t= o python 3 about two months ago, and I have to say I love everything about = it, especially=C2=A0the change to using only bytes and str (no more = unicode! or... everything is unicode!) As someone who works with embedded d= evices, it is great to know what data I am working with.

= However, there are times that I do not care what data I am working with, an= d I find myself writing something like:

if isinstance(data, by= tes): data =3D data.decode()

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=C2=A0and decode=C2=A0as builtins. I have written s= imple code to demonstrate my desire:

https://gist.github.com/cloudformdesign= /d8065a32cdd76d1b3230

=
There may be a few edge cases I am missing, whi= ch would all the more prove my point -- we need a function like this!

Basical= ly, if I expect my data to be a string I can just write:

data =3D decode(data)

=E2=80=8BWhich would accomplish two goals: explicitly st= ating what I expect of my data, and doing so concisely and cleanly.
--001a11c372b0c848f90507f4f836--