[issue6869] Embedded python crashed on 4th run, if "ctypes" is used
nik added the comment: I can confirm that the patch fix this issue. I adapted the patch (variable names changed): 5523a5524 > Py_INCREF(&Struct_Type); 5529a5531 > Py_INCREF(&Union_Type); 5535a5538 > Py_INCREF(&Pointer_Type); 5541a5545 > Py_INCREF(&Array_Type); 5547a5552 > Py_INCREF(&Simple_Type); 5553a5559 > Py_INCREF(&CFuncPtr_Type); Platform: Linux (kubuntu 9.10 x64) Python: 2.6.4-0ubuntu3 -- nosy: +nik.l...@gmail.com ___ Python tracker <http://bugs.python.org/issue6869> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10038] Returntype of json.loads() on strings
New submission from Nik Tautenhahn :
Hi,
before 2.7, an
import json
json.loads('"abc"')
yielded u"abc".
in 2.7 I get
"abc" (a byte string).
I would have expected an entry in "news" or "What's new in 2.7" why this change
happened. In addition, all examples at http://docs.python.org/library/json are
wrong for Python 2.7 if json.loads is involved.
Any insight on this?
best regards,
Nik
--
assignee: d...@python
components: Documentation, Library (Lib)
messages: 118069
nosy: d...@python, llnik
priority: normal
severity: normal
status: open
title: Returntype of json.loads() on strings
type: behavior
versions: Python 2.7
___
Python tracker
<http://bugs.python.org/issue10038>
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10038] Returntype of json.loads() on strings
Nik Tautenhahn added the comment: Well, Ok, if I take bob's comment from the simplejson Issue, I can understand that some people want byte strings. But then I would like to have something like a "parse_str" hook, to enhance my json-Decoder or maybe a keyword argument for the default json-Decoder... -- ___ Python tracker <http://bugs.python.org/issue10038> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10038] Returntype of json.loads() on strings
Nik Tautenhahn added the comment: Well, then at least the documentation and the "What's changed" need to be updated. Furthermore, if such decisions are made, it would be at least nice to have some general "decode-hook" for json.JSONDecoder - the "object_hook" is only used for dict-objects - why is there no hook for strings or a general hook which is used on any objects? -- ___ Python tracker <http://bugs.python.org/issue10038> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10038] Returntype of json.loads() on strings
Nik Tautenhahn added the comment: Yep, the solution should not be "maybe it's str, maybe it's unicode" - I mean, if the decoder gives you a str if there are no fancy characters and unicode if it contains some, this might lead to some confusion... And yes, in my opinion, this is a bug, too. -- ___ Python tracker <http://bugs.python.org/issue10038> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10038] json.loads() on str should return unicode, not str
Nik Tautenhahn added the comment:
There is even more inconsistency here.
As already mentioned, we have this:
>>> import json
>>> json.loads(json.dumps("abc"))
'abc'
If, however, I am evil and hide _json.so (which is the C-part of the json
module for speedup), the JSON code falls back to its python implementation and
voila:
>>> import json
>>> json.loads(json.dumps("abc"))
u'abc'
Not so neat, if your fallback is not a fallback but shows such different
behaviour.
--
___
Python tracker
<http://bugs.python.org/issue10038>
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11564] pickle limits most datatypes
New submission from Nik Galitsky :
Python 3.2 on linux (RHEL 5.3) x86_64 build from source code.
Configure options:
./configure --prefix=/scratch/Python-3.2 --enable-big-digits=30
--with-universal-archs=all --with-fpectl --enable-shared
Built with GCC 4.3.3 with major options
-g3 -O3 -m64 -fPIC.
Testcase that shows the issue:
#import numpy
import pickle
print("begin")
#a = numpy.zeros((2.5e9 / 8,), dtype = numpy.float64)
a = ('a' * (2 ** 31))
print("allocated")
#print(a);
pickle.dumps(a, pickle.DEFAULT_PROTOCOL)
print("end")
The problem as I can see it is that in pickle.py most types defined either as 2
bytes, or 4 bytes.
For example it is peppered with lines like:
self.write(SOMETYPE + pack("\0\1\0\0\0\300>\0\0\0\0\0\0"...,
832) = 832
fstat(5, {st_mode=S_IFREG|0755, st_size=412939, ...}) = 0
mmap(NULL, 2185384, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 5, 0) =
0x2b05b5f68000
mprotect(0x2b05b5f7b000, 2093056, PROT_NONE) = 0
mmap(0x2b05b617a000, 16384, PROT_READ|PROT_WRITE,
MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 5, 0x12000) = 0x2b05b617a000
close(5)= 0
close(4)= 0
close(3)= 0
write(1, "begin\n", 6begin
) = 6
mmap(NULL, 4294971392, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0)
= 0x2b05b617e000
write(1, "allocated\n", 10allocated
) = 10
mmap(NULL, 8589938688, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0)
= 0x2b06b617f000
mremap(0x2b06b617f000, 8589938688, 2147487744, MREMAP_MAYMOVE) = 0x2b06b617f000
mmap(NULL, 4294971392, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0)
= 0x2b073618
munmap(0x2b06b617f000, 2147487744) = 0
munmap(0x2b073618, 4294971392) = 0
write(2, "Traceback (most recent call last"..., 35Traceback (most recent call
last):
) = 35
write(2, " File \"pickle_long.py\", line 9,"..., 45 File "pickle_long.py",
line 9, in
) = 45
open("pickle_long.py", O_RDONLY)= 3
fstat(3, {st_mode=S_IFREG|0644, st_size=251, ...}) = 0
ioctl(3, SNDCTL_TMR_TIMEBASE or TCGETS, 0x79f7c9e0) = -1 ENOTTY
(Inappropriate ioctl for device)
fstat(3, {st_mode=S_IFREG|0644, st_size=251, ...}) = 0
lseek(3, 0, SEEK_CUR) = 0
dup(3) = 4
fcntl(4, F_GETFL) = 0x8000 (flags O_RDONLY|O_LARGEFILE)
fstat(4, {st_mode=S_IFREG|0644, st_size=251, ...}) = 0
mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) =
0x2b06b617f000
lseek(4, 0, SEEK_CUR) = 0
read(4, "#import numpy\n\nimport pickle\npri"..., 4096) = 251
close(4)= 0
munmap(0x2b06b617f000, 4096)= 0
lseek(3, 0, SEEK_SET) = 0
lseek(3, 0, SEEK_CUR) = 0
read(3, "#import numpy\n\nimport pickle\npri"..., 4096) = 251
close(3)= 0
write(2, "pickle.dumps(a, pickle.DEFAU"..., 45pickle.dumps(a,
pickle.DEFAULT_PROTOCOL)
) = 45
write(2, "SystemError: error return withou"..., 48SystemError: error return
without exception set
) = 48
rt_sigaction(SIGINT, {SIG_DFL, [], SA_RESTORER, 0x2b05b118e4c0},
{0x2b05b0e7a570, [], SA_RESTORER, 0x2b05b118e4c0}, 8) = 0
munmap(0x2b05b617e000, 4294971392) = 0
exit_group(1) = ?
Why is this limitation?
Please advise.
--
components: Interpreter Core
messages: 131060
nosy: nyevik
priority: normal
severity: normal
status: open
title: pickle limits most datatypes
type: crash
versions: Python 3.2
___
Python tracker
<http://bugs.python.org/issue11564>
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11564] pickle not 64-bit ready
Nik Galitsky added the comment: Thank you all for your responses. While getting the meaningful error message in this case is very important, the main thing for us is to somehow fix this problem to allow larger objects serialization which is not at all uncommon on a 64-bit machines with large amounts of memory. This issue affects cPickle as well, I believe, as well cStringIO that uses pickle too, I believe. So, what are your plans/thoughts - would there be any action on fixing this problem in the near future? I think I grasp the extent of changes that need to be made to Python code, but I think this issue will have to bee addressed soonoer or later anyhow. -- ___ Python tracker <http://bugs.python.org/issue11564> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue40258] random module does not have type hints
Change by Nik Vaessen : -- nosy: nikvaes priority: normal severity: normal status: open title: random module does not have type hints type: enhancement ___ Python tracker <https://bugs.python.org/issue40258> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue40258] random module does not have type hints
Change by Nik Vaessen : -- keywords: +patch pull_requests: +18834 stage: -> patch review pull_request: https://github.com/python/cpython/pull/19480 ___ Python tracker <https://bugs.python.org/issue40258> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
