[Python-Dev] RFC: PEP 460: Add bytes % args and bytes.format(args) to Python 3.5
Antoine Pitrou
solipsis at pitrou.net
Wed Jan 8 11:26:12 CET 2014
More information about the Python-Dev mailing list
Wed Jan 8 11:26:12 CET 2014
- Previous message: [Python-Dev] RFC: PEP 460: Add bytes % args and bytes.format(args) to Python 3.5
- Next message: [Python-Dev] RFC: PEP 460: Add bytes % args and bytes.format(args) to Python 3.5
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
On Wed, 08 Jan 2014 13:51:36 +0900 "Stephen J. Turnbull" <stephen at xemacs.org> wrote: > Benjamin Peterson writes: > > > I agree. This is a very important, much-requested feature for low-level > > networking code. > > I hear it's much-requested, but is there any description of typical > use cases? The ones I've seen on this list and on -ideas are > typically stream-oriented, and seem like they would be perfectly > well-served in terms of code readability and algorithmic accuracy by > reading with .decode('ascii', errors='surrogateescape') and writing > with .encode() and the same parameters (or as latin1). It's a matter of convenience. Sometimes you're just interpolating bytes data together and it's a bit suboptimal to have to do a decode()-encode() dance around that. That said, the whole issue is slightly overblown as well: network programming in 3.x is perfectly reasonable, as the existence of Tornado and Tulip shows. Regards Antoine.
- Previous message: [Python-Dev] RFC: PEP 460: Add bytes % args and bytes.format(args) to Python 3.5
- Next message: [Python-Dev] RFC: PEP 460: Add bytes % args and bytes.format(args) to Python 3.5
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
More information about the Python-Dev mailing list