[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 to come up with:
>>> f = io.StringIO('t\xe9st')
>>> f.seek(-1, io.SEEK_END)
Traceback (most recent call last):
File "", line 1, in
OSError: Can't do nonzero cur-relative seeks
>>> f.seek(2, io.SEEK_CUR)
Traceback (most recent call last):
File "", line 1, in
OSError: Can't do nonzero cur-relative seeks
# demonstration that SEEK_SET works treating all characters as one unit
>>> f.seek(2, io.SEEK_SET)
2
>>> f.read()
'st'
As far as I know this is the case in all currently maintained versions of
Python 3, since the C-based unicode StringIO implementation was added in 2008.
--
___
Python tracker
<https://bugs.python.org/issue39365>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[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 any pretense that the "file" represents bytes in some Unicode encoding. This is already done for SEEK_START and tell, and has not caused any problems. -- components: IO messages: 360158 nosy: random832 priority: normal severity: normal status: open title: Support (SEEK_END/SEEK_CUR) relative seeking in StringIO type: behavior ___ Python tracker <https://bugs.python.org/issue39365> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[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 keywords: patch messages: 342809 nosy: Random832, terry.reedy priority: normal severity: normal status: open title: IDLE should print exit message or status if one is provided versions: Python 3.7 Added file: https://bugs.python.org/file48335/run.py.patch ___ Python tracker <https://bugs.python.org/issue36958> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[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 size a long can be (any 32-bit python build, and I think also any build on Windows, will have it be this size). -- nosy: +random832 ___ Python tracker <http://bugs.python.org/issue26821> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[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 pointer in it. Attempting to iterate over it or access its item results in a segmentation fault. I confirmed this on both Linux and OSX. Python 3.6.0a0 (default:778ccbe3cf74, Apr 20 2016, 20:17:38) -- components: Interpreter Core files: fnt.py messages: 263866 nosy: random832 priority: normal severity: normal status: open title: segfault due to null pointer in tuple versions: Python 3.6 Added file: http://bugs.python.org/file42545/fnt.py ___ Python tracker <http://bugs.python.org/issue26811> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[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 <http://bugs.python.org/issue17859> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[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 could fall back on realpath. -- nosy: +random832 ___ Python tracker <http://bugs.python.org/issue26781> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[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 of buffering if you're so foolish as to call ftell after every read. But in this case the sequence "read / tell / truncate" would be analogous to "fread(f) / ftell(f) / ftruncate(fileno(f)) Though, the fact that fread operates on the FILE * whereas truncate operates on a file descriptor serves as a red flag to C programmers... arguably since this is not the case with Python, truncate on a buffered stream should implicitly include this same "reset underlying position" operation before actually performing the truncate. -- nosy: +random832 ___ Python tracker <http://bugs.python.org/issue26158> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
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 send it encoded in UTF-8.
Er...
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[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 <http://bugs.python.org/issue26055> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue25984] Expose a simple "is IEEE 754" flag in sys.float_info
Changes by random832 : -- components: +Library (Lib) type: -> enhancement versions: +Python 3.6 ___ Python tracker <http://bugs.python.org/issue25984> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue25984] Expose a simple "is IEEE 754" flag in sys.float_info
New submission from random832: I think it would be useful for programs to be able to detect whether a system uses IEEE-754 double-precision values for the 'float' type. There is lots of detailed information about the float type in sys.float_info, but no simple "is IEEE" flag. On some C implementations, this is exposed as __STDC_IEC_559__. -- messages: 257260 nosy: random832 priority: normal severity: normal status: open title: Expose a simple "is IEEE 754" flag in sys.float_info ___ Python tracker <http://bugs.python.org/issue25984> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[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 <http://bugs.python.org/issue25845> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[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/cpython-fullhistory/rev/003d35215ef2 - looks like there was a bad merge somewhere along the line. -- nosy: +random832 ___ Python tracker <http://bugs.python.org/issue25845> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[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" code? -- ___ Python tracker <http://bugs.python.org/issue25810> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[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 is appropriate to use to document methods that have default values but do not in fact support keyword arguments? What does the "/" in the help text mean? According to PEP 0436 (Argument Clinic), the "/" here indicates that the preceding parameters are positional-only, despite the apparent use of keyword syntax. Should this convention also be used in the documentation? -- ___ Python tracker <http://bugs.python.org/issue25810> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[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 <http://bugs.python.org/issue25810> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[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
string is consistent with the code's actual behavior. Confirmed in Python 3.5.0.
--
nosy: +random832
versions: +Python 3.5
___
Python tracker
<http://bugs.python.org/issue25810>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[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) will _notice_ that one "was added improperly", which makes Python the squeaky wheel for breaking when encountering a value nothing else had any problem with. This behavior is "out-there" enough that I think the claim that someone is relying on it should be justified with a concrete example. -- ___ Python tracker <http://bugs.python.org/issue25778> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[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 bytes and doesn't strip *any* null, even the one (if present) at the end. -- ___ Python tracker <http://bugs.python.org/issue25778> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[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? Can that happen? -- ___ Python tracker <http://bugs.python.org/issue25778> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[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 (which is, of course, in UTF-16 in the registry itself) in a way that ignores characters after the first null? (And presumably likewise after the first double null in a REG_MULTI_SZ) This would be a pretty strong argument that embedded nulls aren't meant to be acceptable in REG_SZ values (as anything other than ignored garbage). -- nosy: +random832 ___ Python tracker <http://bugs.python.org/issue25778> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[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? Operating in place is only an option if the old string has no references and will be discarded, right? -- ___ Python tracker <http://bugs.python.org/issue25709> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[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. After the UTF-8 representation of the 2-character string is populated,
concatenating a new character to it does not update or clear it.
3. However, it worked just fine with the 1-character string - concatenating it
caused the UTF-8 representation to be cleared.
The actual operation that creates an inconsistent string is the concatenate
operation, but it only happens with a string that has been "primed" by having
its UTF-8 representation materialized.
--
___
Python tracker
<http://bugs.python.org/issue25709>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[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..hashflgswstru8len...u8ptr...wstrl...data 01003094ac640300a4000400d8144800e0e0e000 01003094ac640300e5d0030ca465060088144800e0e0e000 I've omitted the UTF-8 data, but both were null-terminated after four and six bytes respectively. -- nosy: +random832 ___ Python tracker <http://bugs.python.org/issue25709> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
