Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.python > #109915
| From | Gregory Ewing <greg.ewing@canterbury.ac.nz> |
|---|---|
| Newsgroups | comp.lang.python |
| Subject | Re: base64.b64encode(data) |
| Date | 2016-06-14 11:12 +1200 |
| Message-ID | <ds8sulF9u79U1@mid.individual.net> (permalink) |
| References | (3 earlier) <mailman.26.1465788060.2288.python-list@python.org> <575e4198$0$1588$c3e8da3$5496439d@news.astraweb.com> <bb6da4a8-165b-6fc7-700e-4c1855bc36fd@gmail.com> <CAPTjJmrCfoKQ7zAVQY9dh=es8q8CJnn8euDpTxF+GYAszfKUWQ@mail.gmail.com> <mailman.42.1465837657.2288.python-list@python.org> |
Chris Angelico wrote: > Maybe what Python needs is an "ascii" type that's a subclass of both > str and bytes, and requires that the contents be <0x80. It is text, so > it can be combined with text strings; but it is also bytes, so when > you combine it with bytes strings, it'll behave as most people expect. That would be asking for trouble, I think. It would be letting back in a bit of the text/bytes confusion that Python 3 worked hard to get rid of. What happens if the bytes that you combine it with aren't in an ascii-compatible encoding? Nothing would detect that error. The only thing you might gain is a bit of efficiency by removing some encoding/decoding operations. But since the FSR, these are pretty cheap anyway when the characters are all ascii. They could maybe be made a bit cheaper still by arranging some way for a bytes object and an ascii-only str object to share underlying storage. -- Greg
Back to comp.lang.python | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread
base64.b64encode(data) Marcin Rak <mrak@sightlineinnovation.com> - 2016-06-12 11:56 -0700
Re: base64.b64encode(data) Marko Rauhamaa <marko@pacujo.net> - 2016-06-12 22:26 +0300
Re: base64.b64encode(data) Steven D'Aprano <steve@pearwood.info> - 2016-06-13 12:22 +1000
Re: base64.b64encode(data) Random832 <random832@fastmail.com> - 2016-06-12 23:20 -0400
Re: base64.b64encode(data) Steven D'Aprano <steve@pearwood.info> - 2016-06-13 15:16 +1000
Re: base64.b64encode(data) Random832 <random832@fastmail.com> - 2016-06-13 01:33 -0400
Re: base64.b64encode(data) Marko Rauhamaa <marko@pacujo.net> - 2016-06-13 09:45 +0300
Re: base64.b64encode(data) Steven D'Aprano <steve@pearwood.info> - 2016-06-13 20:35 +1000
Re: base64.b64encode(data) Random832 <random832@fastmail.com> - 2016-06-13 09:36 -0400
Re: base64.b64encode(data) Steven D'Aprano <steve@pearwood.info> - 2016-06-22 01:56 +1000
Re: base64.b64encode(data) Dennis Lee Bieber <wlfraed@ix.netcom.com> - 2016-06-13 20:20 -0400
Re: base64.b64encode(data) Michael Torrie <torriem@gmail.com> - 2016-06-13 09:15 -0600
Re: base64.b64encode(data) Gregory Ewing <greg.ewing@canterbury.ac.nz> - 2016-06-14 11:04 +1200
Re: base64.b64encode(data) Chris Angelico <rosuav@gmail.com> - 2016-06-14 03:07 +1000
Re: base64.b64encode(data) Gregory Ewing <greg.ewing@canterbury.ac.nz> - 2016-06-14 11:12 +1200
Re: base64.b64encode(data) Random832 <random832@fastmail.com> - 2016-06-13 21:19 -0400
csiph-web