A RetroSearch Logo

Home - News ( United States | United Kingdom | Italy | Germany ) - Football scores

Search Query:

Showing content from https://mail.python.org/pipermail/python-dev/2007-May/072993.html below:

[Python-Dev] Byte literals (was Re: [Python-checkins] Changing string constants to byte arrays ( r55119

[Python-Dev] Byte literals (was Re: [Python-checkins] Changing string constants to byte arrays ( r55119 - in python/branches/py3k-struni/Lib: codecs.py test/test_codecs.py ))Fred L. Drake, Jr. fdrake at acm.org
Sat May 5 19:34:44 CEST 2007
On Saturday 05 May 2007, Aahz wrote:
 > I'm with MAL and Fred on making literals immutable -- that's safe and
 > lots of newbies will need to use byte literals early in their Python
 > experience if they pick up Python to operate on network data.

Yes; there are lots of places where bytes literals will be used the way str 
literals are today.  buffer(b'...') might be good enough, but it seems more 
than a little idiomatic, and doesn't seem particularly readable.

I'm not suggesting that /all/ literals result in constants, but bytes literals 
seem like a case where what's wanted is the value.  If b'...' results in a 
new object on every reference, that's a lot of overhead for a network 
protocol implementation, where the data is just going to be written to a 
socket or concatenated with other data.  An immutable bytes type would be 
very useful as a dictionary key as well, and more space-efficient than 
tuple(b'...').

Whether there should be one type with a flag indicating mutability, or two 
separate types (as with set and frozenset), I'm not sure.  The later offers 
some small performance benefits, but I don't expect there's enough to really 
matter there.


  -Fred

-- 
Fred L. Drake, Jr.   <fdrake at acm.org>
More information about the Python-Dev mailing list

RetroSearch is an open source project built by @garambo | Open a GitHub Issue

Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo

HTML: 3.2 | Encoding: UTF-8 | Version: 0.7.4