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/2009-February/086556.html below:

[Python-Dev] What type of object mmap.read_byte should return on py3k?

[Python-Dev] What type of object mmap.read_byte should return on py3k?Hirokazu Yamamoto ocean-city at m2.ccsnet.ne.jp
Sat Feb 28 16:23:28 CET 2009
Victor Stinner wrote:
> About m.read_byte(), we have two choices:
>  (a) Py_BuildValue("b", value) => 0
>  (b) Py_BuildValue("y#", &value, 1) => b"\x00"
> 
> About m.write_byte(x), we have also two choices:
>  (a) PyArg_ParseTuple(args, "b:write_byte", &value): write_byte(0)
>  (b) PyArg_ParseTuple(args, "y#:write_byte", &value, &length) and
>      check for length=1: write_byte(b"\x00")
> 
> (b) choices are close to Python 2.x API. But we can already use 
> m.read(1)->b"\x00" and m.write(b"\x00") to use byte string of 1 byte. So it 
> would be better to break the API and use integers, (a) choices which require 
> also documentation changes:

I'm +1 for (a) because mmap.__getitem__ already returns integer not 
1-length bytes. And as I wrote in http://bugs.python.org/msg82912, it 
seems that more bytes cleanup is needed in mmap 
documentaion/implementation. I hope someone else will look into other 
modules' ones. ;-)
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