[issue30216] xdrlib.Unpacker.unpack_string returns bytes (docs say should be str)

2017-05-29 Thread Serhiy Storchaka
Serhiy Storchaka added the comment: Partially. Thank you for pointing on the predecessor Jan. -- ___ Python tracker ___

[issue30216] xdrlib.Unpacker.unpack_string returns bytes (docs say should be str)

2017-05-29 Thread Serhiy Storchaka
Changes by Serhiy Storchaka : -- resolution: -> duplicate stage: needs patch -> resolved status: open -> closed superseder: -> xdrlib.Packer().pack_fstring throws a TypeError when called with a str() ___ Python tracker

[issue30216] xdrlib.Unpacker.unpack_string returns bytes (docs say should be str)

2017-05-29 Thread Jan Hnatek
Jan Hnatek added the comment: There's a patch for xdrlib documentation in Issue9544. Would that solve this issue? -- nosy: +hnhn ___ Python tracker ___

[issue30216] xdrlib.Unpacker.unpack_string returns bytes (docs say should be str)

2017-04-30 Thread Xiang Zhang
Changes by Xiang Zhang : -- stage: -> needs patch versions: +Python 3.5, Python 3.7 ___ Python tracker ___

[issue30216] xdrlib.Unpacker.unpack_string returns bytes (docs say should be str)

2017-04-30 Thread Serhiy Storchaka
Serhiy Storchaka added the comment: The term "string" in names like "pack_string" refers to the XDR standard (RFC 1014). They have to stay, but the documentation must be updated to make clear that they work with bytes. -- ___ Python tracker

[issue30216] xdrlib.Unpacker.unpack_string returns bytes (docs say should be str)

2017-04-30 Thread Xiang Zhang
Xiang Zhang added the comment: xdrlib doc seems still remain in 2.x world. 'string' is used to represent 'bytes'. And some methods' names like pack_fstring, pack_string seem not suitable in 3.x world. -- nosy: +haypo, serhiy.storchaka, xiang.zhang

[issue30216] xdrlib.Unpacker.unpack_string returns bytes (docs say should be str)

2017-04-30 Thread Rupert Nash
New submission from Rupert Nash: According to the docs this method should return a str, but it returns bytes https://docs.python.org/3.6/library/xdrlib.html#xdrlib.Unpacker.unpack_string I can see three options: a default encoding should be applied the documentation updated to make clear this