Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]


Groups > comp.lang.python > #80859 > unrolled thread

encode and decode builtins

Started byGarrett Berg <googberg@gmail.com>
First post2014-11-16 00:39 -0700
Last post2014-11-16 00:39 -0700
Articles 1 — 1 participant

Back to article view | Back to comp.lang.python


Contents

  encode and decode builtins Garrett Berg <googberg@gmail.com> - 2014-11-16 00:39 -0700

#80859 — encode and decode builtins

FromGarrett Berg <googberg@gmail.com>
Date2014-11-16 00:39 -0700
Subjectencode and decode builtins
Message-ID<mailman.15872.1416123614.18130.python-list@python.org>

[Multipart message — attachments visible in raw view] — view raw

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 = 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 = decode(data)

​Which would accomplish two goals: explicitly stating what I expect of my
data, and doing so concisely and cleanly.

[toc] | [standalone]


Back to top | Article view | comp.lang.python


csiph-web