5 ms·
I know it's a deeply subjective and personal thing unlikely to help anyone other than me, but I've always successfully relied on the following mnemonic for this
by cjauvin 11y ago
I know it's a deeply subjective and personal thing unlikely to help anyone other than me, but I've always successfully relied on the following mnemonic for this particular problem:
* unicode -> encode, u -> e (vowels)
* str -> decode, s -> d (consonants)
- deleted 11y ago[deleted]
- andrewstuart 11y agoThere should be one obvious way to do it.
- davidism 11y ago> Although that way may not be obvious at first unless you're Dutch. There is one obvious way: strings are encoded to bytes, bytes are decoded to strings.
- jes5199 11y agoI think that's backwards
- rspeer 11y agoIt's not backwards. I think that reveals that the names really do have a problem. The problem is that "encode" sounds like "make this Unicode" to people who aren't familiar with Unicode.
- andrewstuart 11y agoI don't think it is obvious and intuitive and unambiguous what the difference is between ENcoding and DEcoding.
- Veedrac 11y agoA string is an abstract bit of text. You need to encode this into a particular memory representation of the text. Bytes hold a bunch of data in some encoding. It could be an image, UTF-8 or LZMA compressed ASCII. Once you know the encoding, to reconstruct the data you decode into a semantically meaningful form. To put it another way, imagine the terms were "serialize" and "deserialize". Of course one serializes to and deserializes from binary data. Just replace "{,de}serialize" with "{en,de}code" and you're done.
- lawpoop 11y agoYou mean the prefixes 'en-' and 'de-'?
- odonnellryan 11y agoEncode and Decode are slightly subjective... why not something like to_bytes and from_bytes? Maybe not the best names, but definitely clearer on the meaning.
- takeda 11y agoNot really. Veedrac had a good analogy, think of text as something abstract, for example imagine text is an image or sound, if you want to store it in bytes you need to encode it, and to read back you decode it. As to_bytes/from_bytes, actually python provides it too: to_bytes -> bytes(<text>) from_bytes -> str(<bytes>)
- odonnellryan 11y agoIt makes sense for sure, just isn't super intuitive - if it was people wouldn't be so confused.
- daveguy 11y agoMy way of remembering str -> decode; (s->d); sad. sad that I have to remember this and that it is still the "future of the language" despite significant and ongoing resistance. EDIT: This last line of the article pretty much sums it up: "We structured the transition thinking the community would come along with us in leaving Python 2 behind, but that turned out not to be the case and instead we have taken some more time and are using a Python 2/3 compatible subset of the language to manage the transition." I wonder if python 3.6 or 3.7 will acquiesce to this and give an option for something like "from __past__ import str" like we have for __future__ in 2.7 to make these backward incompatibilities easier to deal with.
- s73v3r 11y agoWhy? What possible reason would there be to use the old behavior, except for laziness?
- daveguy 11y agoNice. Thanks for attributing a negative personality trait as the only reason someone would prefer any other way.
- chc 11y agoI don't know if it's been edited since you posted this, but at the moment, the comment is a question asking why somebody would want this other than laziness.
- daveguy 11y agoTrue. I guess some would consider this a positive personality trait in a programmer. I think that's only for system design though (lazy for minimizing future effort required).
- squeaky-clean 11y agoBecause I'd like to be able to use the googleads Python client library within Python 3 without needing to fix 62,000 lines of code? I guess you could call that laziness if you want.