[issue37828] Fix default mock_name in unittest.mock.assert_called error message
Change by Abraham : -- keywords: +patch pull_requests: +15775 stage: -> patch review pull_request: https://github.com/python/cpython/pull/16166 ___ Python tracker <https://bugs.python.org/issue37828> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1124] Webchecker not parsing css "@import url"
New submission from Edward Abraham: webchecker and its dependent, websucker, which are distributed with the python tools, are not following references to stylesheets given with the @import url(mystyle.css); declaration ... This means that the websucker isn't copying across stylesheets ... -- components: Demos and Tools messages: 55722 nosy: ready.eddy severity: normal status: open title: Webchecker not parsing css "@import url" versions: Python 2.5 __ Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue1124> __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11835] python (x64) ctypes incorrectly pass structures parameter
New submission from Abraham Soedjito :
void __cdecl foo(unsigned __int32 a,
unsigned __int32 b,
unsigned __int32 c,
unsigned __int32 d,
unsigned __int32 e,
unsigned __int32 f,
unsigned __int32 g);
struct myStruct
{
unsigned __int32 a;
unsigned __int32 b;
unsigned __int32 c;
unsigned __int32 d;
unsigned __int32 e;
unsigned __int32 f;
unsigned __int32 g;
}
void __cdecl bar(myStruct s);
void __cdecl errorPassingParameter(myStruct s1,
myStruct s2,
unsigned __int32 x);
Calling foo and bar from python completed successfully, calling
errorParsingParameter resulted in stack corruption. It seems that python passed
an extra pointer in the stack for s2.
--
assignee: theller
components: ctypes
messages: 133583
nosy: Abraham.Soedjito, theller
priority: normal
severity: normal
status: open
title: python (x64) ctypes incorrectly pass structures parameter
type: crash
versions: Python 2.6
___
Python tracker
<http://bugs.python.org/issue11835>
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue43626] SIGSEV in PyErr_SetObject
New submission from Abraham Macias :
Hi, I'm dealing with random crashes when using pymongo in Python 3.7.3 in a
Debian Buster.
This is the python backtrace:
(gdb) thread apply all py-bt
Thread 2 (Thread 0x7f9817d95700 (LWP 221)):
Traceback (most recent call first):
File "/usr/local/lib/python3.7/dist-packages/gevent/_threading.py", line 80,
in wait
waiter.acquire() # Block on the native lock
File "/usr/local/lib/python3.7/dist-packages/gevent/_threading.py", line 162,
in get
self._not_empty.wait()
File "/usr/local/lib/python3.7/dist-packages/gevent/threadpool.py", line 270,
in _worker
task = task_queue.get()
File "/usr/local/lib/python3.7/dist-packages/gevent/threadpool.py", line 254,
in __trampoline
g.switch()
Thread 1 (Thread 0x7f981fdfd740 (LWP 216)):
Traceback (most recent call first):
File "/usr/local/lib/python3.7/dist-packages/bson/__init__.py", line 1089, in
_decode_all_selective
return decode_all(data, codec_options)
File "/usr/local/lib/python3.7/dist-packages/pymongo/message.py", line 1616,
in unpack_response
self.payload_document, codec_options, user_fields)
File "/usr/local/lib/python3.7/dist-packages/pymongo/cursor.py", line 1080,
in _unpack_response
legacy_response)
File "/usr/local/lib/python3.7/dist-packages/pymongo/server.py", line 131, in
run_operation_with_response
user_fields=user_fields)
File "/usr/local/lib/python3.7/dist-packages/pymongo/mongo_client.py", line
1366, in _cmd
unpack_res)
File "/usr/local/lib/python3.7/dist-packages/pymongo/mongo_client.py", line
1471, in _retryable_read
return func(session, server, sock_info, slave_ok)
File "/usr/local/lib/python3.7/dist-packages/pymongo/mongo_client.py", line
1372, in _run_operation_with_response
exhaust=exhaust)
File "/usr/local/lib/python3.7/dist-packages/pymongo/cursor.py", line 1001,
in __send_message
address=self.__address)
File "/usr/local/lib/python3.7/dist-packages/pymongo/cursor.py", line 1124,
in _refresh
self.__send_message(q)
File "/usr/local/lib/python3.7/dist-packages/pymongo/cursor.py", line 1207,
in next
if len(self.__data) or self._refresh():
File "/usr/local/lib/python3.7/dist-packages/pymongo/collection.py", line
1319, in find_one
for result in cursor.limit(-1):
File "/usr/local/lib/python3.7/dist-packages/gecoscc/userdb.py", line 119, in
create_user
user = self.collection.find_one({'email': email})
File
"/usr/local/lib/python3.7/dist-packages/gecoscc/commands/create_adminuser.py",
line 95, in command
{'is_superuser': self.options.is_superuser}
File "/usr/local/lib/python3.7/dist-packages/gecoscc/management.py", line 90,
in __call__
self.command()
File "/usr/local/lib/python3.7/dist-packages/gecoscc/management.py", line 48,
in main
command()
File "/usr/local/bin/pmanage", line 10, in
sys.exit(main())
(gdb)
And this is the builtin-code backtrace:
Core was generated by `/usr/bin/python3 /usr/local/bin/pmanage
/opt/gecosccui/gecoscc.ini create_admin'.
Program terminated with signal SIGSEGV, Segmentation fault.
#0 PyErr_SetObject (exception=0x7ff9c0 <_PyExc_AttributeError.lto_priv.2311>,
value=0x7f1ab49cb098) at ../Python/errors.c:101
101 Py_INCREF(exc_value);
[Current thread is 1 (Thread 0x7f1abc823740 (LWP 370))]
(gdb) bt
#0 PyErr_SetObject (exception=, value="type object
'dict' has no attribute '_type_marker'") at ../Python/errors.c:101
#1 0x0052c23b in PyErr_FormatV (vargs=0x7ffedff77c40,
format=, exception=) at
../Python/errors.c:852
#2 PyErr_Format (exception=, format=)
at ../Python/errors.c:852
#3 0x0058717d in type_getattro (type=, name=) at ../Objects/typeobject.c:3223
#4 0x0054baae in _PyObject_LookupAttr (result=,
name=, v=) at ../Objects/object.c:949
#5 builtin_getattr (self=, args=,
nargs=) at ../Python/bltinmodule.c:1121
#6 0x0053 in _PyMethodDef_RawFastCallKeywords (method=0x89d160
, self=, args=0x1237208,
nargs=, kwnames=)
at ../Objects/call.c:651
#7 0x005463e3 in _PyCFunction_FastCallKeywords (kwnames=0x0, nargs=3,
args=0x1237208, func=) at ../Objects/call.c:730
#8 call_function (kwnames=0x0, oparg=3, pp_stack=) at
../Python/ceval.c:4568
#9 _PyEval_EvalFrameDefault (f=, throwflag=) at
../Python/ceval.c:3124
#10 0x005cd68c in PyEval_EvalFrameEx (throwflag=0,
f=Frame 0x1237088, for file
/usr/local/lib/python3.7/dist-packages/bson/codec_options.py, line 35, in
_raw_document_class (document_class=)) at
../Python/ceval.c:547
#11 function_code_fastcall (globals=, nargs=,
args=, co=) at ../Objects/call.c:283
#12 _PyFunction_FastCallKeywords (func=, stack=,
nargs=, kwnames=) at ../Objects/call
[issue43626] SIGSEV in PyErr_SetObject
Abraham Macias added the comment:
Thank you Victor for your response.
I follow your advice but the output was an error in a different point of the
code and I couldn't see any information about memory allocations.
But, I compiled Python 3.7 from source and modified the "Python/errors.c" code
where the problem is detected in the following way:
void
PyErr_SetObject(PyObject *exception, PyObject *value)
{
PyThreadState *tstate = PyThreadState_GET();
PyObject *exc_value;
PyObject *tb = NULL;
_PyErr_StackItem *exc_info = NULL;
if (exception != NULL &&
!PyExceptionClass_Check(exception)) {
PyErr_Format(PyExc_SystemError,
"exception %R not a BaseException subclass",
exception);
return;
}
Py_XINCREF(value);
exc_info = _PyErr_GetTopmostException(tstate);
exc_value = exc_info->exc_value;
if (exc_value != NULL && exc_value != Py_None) {
/* Implicit exception chaining */
printf("exc_value=%p\n", exc_value);
printf("exc_info=%p\n", exc_info);
printf("tstate=%p\n", tstate);
printf("traceback=%p\n", exc_info->exc_traceback);
printf("exc_value.ob_type=%p\n", exc_value->ob_type);
Py_INCREF(exc_value);
In this way I had the pointer printed just before the error happening:
exc_value=0x73726573756e69
exc_info=0x7f83bfafacb8
tstate=0x5605dcd41330
traceback=0x6b6f0100
Segmentation fault (core dumped)
And by using gdb I printed the memory contents:
(gdb) x/32c 0x7f83bfafacb8
0x7f83bfafacb8: 111 'o' 115 's' 99 'c' 99 'c' 46 '.' 97 'a' 100 'd' 109 'm'
0x7f83bfafacc0: 105 'i' 110 'n' 117 'u' 115 's' 101 'e' 114 'r' 115 's' 0 '\000'
0x7f83bfafacc8: 0 '\000'1 '\001'111 'o' 107 'k' 0 '\000'
0 '\000'0 '\000'0 '\000'
0x7f83bfafacd0: 0 '\000'0 '\000'0 '\000'-16 '\360'
63 '?' 0 '\000'0 '\000'0 '\000'
If you check the original post you will see:
#15 0x0053f732 in PyEval_EvalFrameEx (throwflag=0,
f=Frame 0x17882e8, for file
/usr/local/lib/python3.7/dist-packages/bson/__init__.py, line 1013, in
decode_all
(data=b'V\x00\x00\x00\x03cursor\x00=\x00\x00\x00\x04firstBatch\x00\x05\x00\x00\x00\x00\x12id\x00\x00\x00\x00\x00\x00\x00\x00\x00\x02ns\x00\x13\x00\x00\x00gecoscc.adminusers\x00\x00\x01ok\x00\x00\x00\x00\x00\x00\x00\xf0?\x00',
codec_options=, view=, data_len=86, docs=[], position=0, end=85)) at
../Python/ceval.c:547
So, somehow the "oscc.adminusers\x00\x00\x01ok\x00" part of the message is
written over the exc_info memory.
That makes me think that this is a problem in pymongo module. I will report
this bug to them.
Thank you very much!
--
resolution: -> not a bug
stage: -> resolved
status: open -> closed
___
Python tracker
<https://bugs.python.org/issue43626>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue43884] Cannot cleanly kill a subprocess using high-level asyncio APIs
New submission from Ronal Abraham :
There doesn't appear to be a way to prematurely kill a subprocess using the
high-level asyncio subprocess APIs
(https://docs.python.org/3.9/library/asyncio-subprocess.html) without getting a
traceback on exit.
On exit, the attached program writes the following to stderr:
$ python3.9 kill_subprocess.py
Exception ignored in:
Traceback (most recent call last):
...
raise RuntimeError('Event loop is closed')
RuntimeError: Event loop is closed
If I uncomment `# process._transport.close()` or comment `asyncio.sleep(1)`,
the walkback disappears. (I get the same behavior in python 3.8. I haven't
tried other python versions.)
--
components: asyncio
files: kill_subprocess.py
messages: 391349
nosy: asvetlov, rabraham, yselivanov
priority: normal
severity: normal
status: open
title: Cannot cleanly kill a subprocess using high-level asyncio APIs
type: behavior
versions: Python 3.8, Python 3.9
Added file: https://bugs.python.org/file49965/kill_subprocess.py
___
Python tracker
<https://bugs.python.org/issue43884>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue43884] Cannot cleanly kill a subprocess using high-level asyncio APIs
Ronal Abraham added the comment: Reproducing the program here: import asyncio async def test(): process = await asyncio.create_subprocess_shell( "sleep 2 && echo done", stdout=asyncio.subprocess.PIPE, ) await asyncio.sleep(1) process.kill() await process.wait() # process._transport.close() asyncio.run(test()) Can I use the high-level API to kill a subprocess cleanly without having to access the protected member process._transport? Seems like an oversight perhaps? -- ___ Python tracker <https://bugs.python.org/issue43884> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue43884] Cannot cleanly kill a subprocess using high-level asyncio APIs
Ronal Abraham added the comment: I see this on MacOS and Linux, but I suspect any Unix-like system would have the same behavior. -- ___ Python tracker <https://bugs.python.org/issue43884> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue39335] round Decimal edge case
New submission from Hrvoje Abraham :
>>> from decimal import Decimal
>>> round(Decimal('-123.49'))
-124.0
I would expect -123.0, even considering Py2 rounding convention details (away
from zero), Decimal rounding convention (default rounding=ROUND_HALF_EVEN),
floating point specifics...
Works as expected in Py3. Both Py2 and Py3 use same default Decimal
rounding=ROUND_HALF_EVEN.
Could be I'm missing some detail...
--
components: Library (Lib)
messages: 35
nosy: ahrvoje
priority: normal
severity: normal
status: open
title: round Decimal edge case
versions: Python 2.7
___
Python tracker
<https://bugs.python.org/issue39335>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue37139] Inconsistent behavior of email.header.decode_header
New submission from Louis Abraham : Hi, (this is my first issue btw) I think <https://docs.python.org/3/library/email.header.html#email.header.decode_header> has a broken behavior. It returns a list of `(decoded_string, charset)` pairs. However, `decoded_string` can be either a string or bytes. I have no preference but it should really be of one type. -- messages: 344392 nosy: louis.abra...@yahoo.fr priority: normal severity: normal status: open title: Inconsistent behavior of email.header.decode_header ___ Python tracker <https://bugs.python.org/issue37139> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue37139] Inconsistent behavior of email.header.decode_header
Louis Abraham added the comment: Indeed, this is exactly the same (I should have researched more, my bad). The problem is that I'm using mailbox.Maildir which uses the Compat32 API. Do you think I should create an issue for Maildir to support the new EmailMessage API? -- ___ Python tracker <https://bugs.python.org/issue37139> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue35332] shutil.rmtree(..., ignore_errors=True) doesn't ignore errors from os.close()
New submission from Ronal Abraham : These lines throw intermittently for me on AIX when removing a directory on NFS (python version 3.6.6-1), even when "ignore_errors=True": https://github.com/python/cpython/blob/v3.6.6rc1/Lib/shutil.py#L433 https://github.com/python/cpython/blob/v3.6.6rc1/Lib/shutil.py#L492 Should there be try-except blocks around these lines and calls to onerror(...)? -- components: Library (Lib) messages: 330553 nosy: rabraham priority: normal severity: normal status: open title: shutil.rmtree(..., ignore_errors=True) doesn't ignore errors from os.close() type: behavior versions: Python 3.6, Python 3.7, Python 3.8 ___ Python tracker <https://bugs.python.org/issue35332> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue35332] shutil.rmtree(..., ignore_errors=True) doesn't ignore errors from os.close()
Ronal Abraham added the comment: I forgot to mention: the exception raised is an OSError and the errno is 52 (ESTALE on AIX). -- ___ Python tracker <https://bugs.python.org/issue35332> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue16582] Tkinter calls SystemExit with string
New submission from Abraham Karplus: Exiting a Tkinter application normally results in printing '0' and exiting with error code 1. This is a result of Tkinter's _exit function, whose default argument for code is the string '0'. It then calls SystemExit with the code argument. However, according to the SystemExit documentation "if [the argument] has another type (such as a string), the object’s value is printed and the exit status is one". A simple fix for this would be to change the Tkinter _exit function to convert code to an int before passing it to SystemExit. -- components: Tkinter messages: 176696 nosy: Abraham Karplus priority: normal severity: normal status: open title: Tkinter calls SystemExit with string type: behavior versions: Python 2.6, Python 2.7, Python 3.1, Python 3.2, Python 3.3, Python 3.4 ___ Python tracker <http://bugs.python.org/issue16582> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue16583] Tkinter nested SystemExit
New submission from Abraham Karplus: When a callback function gets called from Tkinter and raises SystemExit (either directly or through sys.exit), a new SystemExit exception is raised with the original exception as its code field, such as SystemExit(SystemExit(),) This is due to a bug in Tkinter's CallWrapper, where it has except SystemExit as msg: raise SystemExit(msg) which since msg is a SystemExit instance, creates the nesting. This bug did not exist in Python 2 because there the code was except SystemExit, msg: raise SystemExit, msg and this raises msg, as it already is a SystemExit instance. I suspect the bug was introduced by using the 2to3 tool, as it will do the conversion. If so, this is a bug in 2to3, as the two snippets are not functionally identical. -- components: Tkinter messages: 176698 nosy: Abraham Karplus priority: normal severity: normal status: open title: Tkinter nested SystemExit type: behavior versions: Python 3.1, Python 3.2, Python 3.3, Python 3.4 ___ Python tracker <http://bugs.python.org/issue16583> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue16582] Tkinter calls SystemExit with string
Abraham Karplus added the comment:
I'd be fine with having it fixed just in 3.4, as it is easy enough to work
around for now. (Call deletecommand('exit') and then createcommand('exit',
working_exit_function) with working_exit function being the patched version of
_exit.)
--
___
Python tracker
<http://bugs.python.org/issue16582>
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue23406] interning and list comprehension leads to unexpected behavior
New submission from Abraham Smith: Some students were working on matrix routines for practice. The following code: >>> L = [ [0]*3 ]*3 >>> for i in range(3): ...for j in range(3): ...if i==j: L[i][j]=1 was expected to return [[1,0,0],[0,1,0],[0,0,1]] but it returned [[1,1,1],[1,1,1],[1,1,1]] because the list [0]*3 was being interned silently, so all three rows were the same memory! To see this, I did >>> map(id, L) [139634871681464, 139634871681464, 139634871681464] On the other hand >>> M=[ [ 0 for i in range(3) ] for j in range(3) ] does not intern: >>> map(id, L) [139634871631672, 139634871681608, 139634871681680] so the above loop works as expected. This is true in both python 2.7 and 3.4. This is very confusing to users! If this intern behavior with [0]*3 is intended, it should be documented more clearly, because this is something that new students of python might encounter right away when playing with the language's list methods. I didn't see any reference to interning in the discussion of lists in the standard library reference. Moreover, I also could not find any reference to the automatic interning of mutable objects, such as lists. Personally, I cannot see any reason to silently and automatically intern a mutable object; however, if this behavior is really desired, it should be documented. -- assignee: docs@python components: Documentation messages: 235520 nosy: Abraham.Smith, docs@python priority: normal severity: normal status: open title: interning and list comprehension leads to unexpected behavior versions: Python 2.7, Python 3.4 ___ Python tracker <http://bugs.python.org/issue23406> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue23406] interning and list comprehension leads to unexpected behavior
Abraham Smith added the comment: (Obviously, there's a copy/paste mistake in the second case; it should read map(id, M).) -- ___ Python tracker <http://bugs.python.org/issue23406> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue23406] interning and list comprehension leads to unexpected behavior
Abraham Smith added the comment: Thanks for the helpful responses and correcting my misunderstanding. Regarding improved documentation, I see now that the table at https://docs.python.org/2/library/stdtypes.html#id2 indeed says "shallow copies"; however, the footnote seems to bury the lede. Perhaps the footnote should be expanded to either link to the FAQ entry or provide an abbreviated version of it. The FAQ entry is actually very good, but I would guess that most readers (like me) skip the FAQs and jump straight to the library reference.Internet users have been trained for 20 years to believe that FAQs are full of useless, snarky answers to questions at a much shallower level, like "what do I do with a .tar.gz file?". The fact that Python's FAQ is extremely well-written and helpful is a pleasant surprise, but a surprise none-the-less. -- resolution: not a bug -> ___ Python tracker <http://bugs.python.org/issue23406> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue24663] ast.literal_eval does not handle empty set literals
Hrvoje Abraham added the comment: I believe this is the issue. ast.literal_eval sets support can not be considered complete until it also handles empty sets. I do not consider it valid for me to explicitly handle this case in my projects using some weird hacks. Python community settled on not introducing empty set literal because one can simply use set(), as discussed a few times before. But no corresponding alternative was defined for ast.literal_eval, maybe it should handle 'set()' as such. I strongly advise reopening this issue and finding functional solution for empty set case. I need it! -- nosy: +ahrvoje type: -> enhancement versions: +Python 3.5 -Python 3.4 ___ Python tracker <http://bugs.python.org/issue24663> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue24663] ast.literal_eval does not handle empty set literals
Hrvoje Abraham added the comment: I use communication protocol based on Python literals and ast.literal_eval for deserialization. I'm avoiding sets because empty set value is not supported in a clean consistent manner on language level. If I write repr(set()) i get 'set()', this should matter, maybe. I know I can handle it as a special case, None for empty set, and close my eyes on fact that I lose None value reserved for some other cases. But this really is not a nice thing to do. Please reconsider... -- ___ Python tracker <http://bugs.python.org/issue24663> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue24663] ast.literal_eval does not handle empty set literals
Hrvoje Abraham added the comment: For now I'll implement my_literal_eval via AST filtering, reproducing ast.literal_eval + 'set()' functionality. -- ___ Python tracker <http://bugs.python.org/issue24663> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue26785] repr of -nan value should contain the sign
New submission from Hrvoje Abraham:
repr of -nan value should contain the sign so the round-trip could be assured.
NaN value sign (bit) could be seen as not relevant or even uninterpretable
information, but it is actually used in real-life situations, the fact
substantiated by section 6.3 of IEEE-754 2008 standard.
>>> from math import copysign
>>> x = float("-nan")
>>> copysign(1.0, x)
-1.0
This is correct. Also proves the value contains the sign information.
>>> repr(x)
nan
Not correct. Should be '-nan'.
--
components: Interpreter Core
messages: 263576
nosy: ahrvoje
priority: normal
severity: normal
status: open
title: repr of -nan value should contain the sign
type: behavior
versions: Python 2.7, Python 3.2, Python 3.3, Python 3.4, Python 3.5, Python 3.6
___
Python tracker
<http://bugs.python.org/issue26785>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue26785] repr of -nan value should contain the sign
Hrvoje Abraham added the comment:
Reported issue was created in 64-bit Python 3.5.1 (v3.5.1:37a07cee5969, Dec 6
2015, 01:54:25) [MSC v.1900 64 bit (AMD64)] on win32.
Now I noticed that in Py 2.7 even copysign part does not work as expected.
Python 2.7.11 (v2.7.11:6d1b6a68f775, Dec 5 2015, 20:40:30) [MSC v.1500 64 bit
(AMD64)] on win32:
>>> from math import copysign
>>> x = float("-nan")
>>> copysign(1.0, x)
1.0
Not correct.
--
___
Python tracker
<http://bugs.python.org/issue26785>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue26785] repr of -nan value should contain the sign
Hrvoje Abraham added the comment:
Python 2.7.11 (v2.7.11:6d1b6a68f775, Dec 5 2015, 20:40:30) [MSC v.1500 64 bit
(AMD64)] on win32:
>>> import struct
>>> x=float("-nan")
>>> struct.pack('
<http://bugs.python.org/issue26785>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue26785] repr of -nan value should contain the sign
Hrvoje Abraham added the comment:
Regarding NaN sign bit, IEEE-754 states:
"Note, however, that operations on bit strings—copy, negate, abs,
copySign—specify the sign bit of a NaN result, sometimes based upon the sign
bit of a NaN operand. The logical predicate totalOrder is also affected by the
sign bit of a NaN operand."
So NaN sign bit information is used in the standard itself (section 5.10.d):
1) totalOrder(−NaN, y) is true where −NaN represents a NaN with negative sign
bit and y is a
floating-point number.
2) totalOrder(x, +NaN) is true where +NaN represents a NaN with positive sign
bit and x is a
floating-point number.
This fact alone implies the importance of its round-trip safety. I believe the
quote you picked states this information doesn't have universal (standardized)
meaning, not it is not important or used at all. It is reasonable to assume
some will need to preserve it.
There are also some real-life usages, similar as signed zero, in determining
the correct complex plane branch cut:
http://stackoverflow.com/questions/8781072/sign-check-for-nan-value
http://docstore.mik.ua/manuals/hp-ux/en/B2355-60130/catan.3M.html
catan(inf + iNAN) => π/2 + i0; catan(inf - iNAN) => π/2 - i0;
MSVC 2015 and MinGW-W64 v4.9.2 output (source below) for '-nan' values are:
MSVC: -nan(ind)
MinGW-W64: -1.#IND00
#include
int main()
{
double x = 0.0;
x = - x / x;
printf("%lf\n", x);
return 0;
}
--
___
Python tracker
<http://bugs.python.org/issue26785>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue26785] repr of -nan value should contain the sign
Hrvoje Abraham added the comment: Sage: http://doc.sagemath.org/html/en/reference/rings_numerical/sage/rings/complex_number.html >>> log(ComplexNumber(NaN,1)) NaN - NaN*I -- ___ Python tracker <http://bugs.python.org/issue26785> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue26785] repr of -nan value should contain the sign
Hrvoje Abraham added the comment: IEEE & C/C++ standards allow and explicitly mention it, some people and projects are using it, many compilers preserve it... I believe it's reasonable to support it despite the fact it does not have standardized semantic meaning. Maybe one day... -- ___ Python tracker <http://bugs.python.org/issue26785> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
