[issue39365] Support (SEEK_END/SEEK_CUR) relative seeking in StringIO

random832 added the comment: That documentation isn't specific to StringIO, and in any case, the limitation in question isn't documented. The actual implementation is at https://github.com/python/cpython/blob/HEAD/Modules/_io/stringio.c#L484 But if examples would help, they're simple

[issue39365] Support (SEEK_END/SEEK_CUR) relative seeking in StringIO

New submission from random832 : Currently this fails with a (misleading in the case of SEEK_END) "Can't do nonzero cur-relative seeks" error, but there's no conceptual reason it shouldn't be possible. The offset should simply be taken as a character offset, without an

[issue36958] IDLE should print exit message or status if one is provided

New submission from Random832 : IDLE currently just returns to the interactive prompt when a script exits, even if SystemExit has arguments. This can be confusing to new users if they are using sys.exit to print a message. -- assignee: terry.reedy components: IDLE files: run.py.patch

[issue26821] array module "minimum size in bytes" table is wrong for int/long

random832 added the comment: It says *minimum* size for a reason. The *actual* sizes of the types used in array are platform-dependent. 2 is the smallest that an int can be (it is probably not that size on any currently supported platforms, but would have been in DOS), and 4 is the smallest

[issue26811] segfault due to null pointer in tuple

New submission from random832: I was writing something that iterates over all objects in gc.get_objects(). I don't know precisely where the offending tuple is coming from, but nearby objects in gc.get_objects() appear to be related to frozen_importlib. A tuple exists somewhere with a null

[issue17859] improve error message for saving ints to file

random832 added the comment: This bug should be closed since #16518 was accepted and the error is now "TypeError: a bytes-like object is required, not 'int'" -- nosy: +random832 ___ Python tracker <rep...@bugs.python.org> <htt

[issue26781] os.walk max_depth

random832 added the comment: Wouldn't the "symlink infinite loop" case be better handled by making it track where it's already been? This can be done by inode and dev number on Unix; I'm not sure what equivalent exists on Windows (though symlinks are uncommon on Windows) but you

[issue26158] File truncate() not defaulting to current position as documented

random832 added the comment: In the analogous C operations, ftell (analogous to .tell) actually causes the underlying file descriptor's position (analogous to the raw stream's position) to be reset to be at the same value that ftell has returned. Which means, yes, that you lose the benefits

Re: [issue26045] Improve error message for http.client when posting unicode string

Guido van Rossum writes: > UnicodeEncodeError: 'ascii' codec can't encode character '\u1234' in ^ ^ > position 3: Header ('ሴ') is not valid Latin-1. Use ^ ^^^ > header.encode('utf-8') if you want to

[issue26055] sys.argv[0] is the python file, not ""

random832 added the comment: By "when no script [is] given", it is referring to the use in the interactive interpreter, not in a python file. -- nosy: +random832 ___ Python tracker <rep...@bugs.python.org> <http://bugs.py

[issue25845] _ctypes\cfield.c identical subexpressions in Z_set

random832 added the comment: Looks like a result of searching and replacing PyInt with PyLong - the diff can be found here, if anyone cares. https://hg.python.org/cpython-fullhistory/rev/f324631462a2. Oddly, there was _another, older_ revision that fixed this correctly: https://hg.python.org

[issue25845] _ctypes\cfield.c identical subexpressions in Z_set

random832 added the comment: Sorry, my mistake, I was looking at z_set instead of Z_set. The earlier fix had left Z_set out for some reason. Anyway, just some historical interest anyway. -- ___ Python tracker <rep...@bugs.python.org>

[issue25810] Python 3 documentation for eval is incorrect

random832 added the comment: Oh, I just noticed, the help string is also wrong in 3.5 (which explains why you removed 3.5 from the versions list, which I hadn't noticed until after posting my previous comment). -- ___ Python tracker <

[issue25810] Python 3 documentation for eval is incorrect

random832 added the comment: What about fixing all methods so that they can take keywords? Are the functions with their current C signatures part of the stable ABI? Is there somewhere we could centrally add some magic "convert tuple+keywords to tuple, given list of names&

[issue25810] Python 3 documentation for eval is incorrect

random832 added the comment: I guess the next question is what the intent is. Was there an intent, which was not followed through on, to upgrade these methods to support keyword arguments? Or is there an intent (here and everywhere) that documentation using keyword argument syntax

[issue25810] Python 3 documentation for eval is incorrect

random832 added the comment: Whatever the case may be, it *doesn't* support keyword arguments. e.g.: >>> eval("a+b", globals={'a':1}, locals={'b':2}) TypeError: eval() takes no keyword arguments So as the current situation stands, the documentation is wrong, and the help s

[issue25778] winreg.EnumValue does not truncate strings correctly

random832 added the comment: Your "backward compatibility" argument makes me think of https://xkcd.com/1172/ 99% of programs written in C or other languages will cut the value off at the first null. One consequence of which is that no-one (except an unfortunate Python program) wil

[issue25778] winreg.EnumValue does not truncate strings correctly

random832 added the comment: > All registry values are blobs and it's up to the caller to decide how to read > it - the "types" are hints and are not binding. Just out of curiosity, what do we do if a REG_DWORD is more (or less?) than four bytes?

[issue25778] winreg.EnumValue does not truncate strings correctly

random832 added the comment: > I don't see why the original issue with matplotlib would only happen with > Python 3 and not Python 2, though. Is it possible that Python 2 is using a non-unicode Windows API to get the values, and the non-unicode API is converting the string

[issue25778] winreg.EnumValue does not truncate strings correctly

random832 added the comment: > The winreg module is a low-level interface High enough to return a string instead of bytes, an int for REG_DWORD, and to parse out REG_MULTI_SZ into a list. Maybe for if people really want the blob there should be an interface that always returns by

[issue25709] greek alphabet bug it is very disturbing...

random832 added the comment: I can't reproduce without pickle. I did some further digging, though, and it *looks like*... 1. Pickle causes the built-in UTF-8 representation of a string to be populated, whereas encode('utf-8') does not. Can anyone think of any other operations that do this? 2

[issue25709] greek alphabet bug it is very disturbing...

random832 added the comment: I've looked at the raw bytes [through a ctypes pointer to id(s)] of a string affected by the issue, and decoded enough to be able to tell that the bad string has an incorrect UTF-8 length and data, which pickle presumably relies on. HEADlength..hash

[issue25709] Problem with string concatenation and utf-8 cache.

random832 added the comment: > unicode_modifiable in Objects/unicodeobject.c should return 0 if there's > cached PyUnicode_UTF8 data. In this case PyUnicode_Append won't operate in > place but instead concatenate a new string. Shouldn't it still operate in place but clear it?