Hubert Tournier added the comment:
The storage format used under Windows is completely different from the one used
under Unix (or *BSD).
Apart from the .dat datafile, there is a .dir index file with CSV lines such as
"'key', (offset, length)".
Whereas under Unix (or *B
Hubert Tournier added the comment:
Additional note: the test code WORKS under Windows 8.1 / Python 3.9.1 (though
the data file is suffixed .dat instead of .db) resulting in a 4 MB database
with 1065 records, some of them > 11 KB.
So maybe the bug is system dependent.
--
compone
Hubert Tournier added the comment:
I modified the test program to better reflect the size of the data structures
stored in shelve (sys.getsizeof() which I used was far off the real size).
I saw that the database was corrupted with big records, though even bigger
previous records had not
Hubert Tournier added the comment:
Hello,
Same results with Python 3.10.4:
[...]
Adding 185.220.102.6
Database has 62 records for 442368 bytes. Last record was 640 bytes long
Traceback (most recent call last):
File "./shelve-test.py", line 84, in
_verify_whois_cache()
File
New submission from Hubert Tournier :
After adding a few records, the shelve module corrupts the database keys (the
database is still readable if an element key is known, but no more iterable):
Traceback (most recent call last):
File "./shelve-test.py", line 81, in
_verify_w
Change by Hubert Badocha :
--
nosy: +badochov
nosy_count: 9.0 -> 10.0
pull_requests: +25547
pull_request: https://github.com/python/cpython/pull/26985
___
Python tracker
<https://bugs.python.org/issu
New submission from Hubert Bonnisseur-De-La-Bathe :
Reading first at the documentation of difflib, I thought that the use of junks
would have produced the result
s = SequenceMatcher(lambda x : x == " ", "abcd efgh", "abcdefgh")
s.get_matching_blocks()
>&
Hubert Pineault added the comment:
Thanks Joannah, I confirm this is a duplicate of
https://bugs.python.org/issue40456
The issue is better tracked in 40456, so you can close here.
--
___
Python tracker
<https://bugs.python.org/issue38
Hubert Pineault added the comment:
The bug is still there in python 3.8.4rc1
It has nothing to do with the doc.
As pointed by Kaoru, it is introduced in line 200 of commit
2e33ecd7c9b0cac3efc6fcbdd4547fd086b4e2d1
see this comment, also by Kaoru:
https://github.com/python/cpython/commit
Change by Hubert Jasudowicz :
--
type: -> behavior
___
Python tracker
<https://bugs.python.org/issue37990>
___
___
Python-bugs-list mailing list
Unsubscrib
New submission from Hubert :
Example:
Python 3.9.0a0 (heads/master:39d87b5471, Aug 30 2019, 23:19:13)
[GCC 9.1.0] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> import gc
>>> gc.set_debug(gc.DEBUG
Hubert Holin added the comment:
Yes, the error turned out to be that I had indeed forgotten to remove the
--with-system-libmpdec along with the library and header. Now _decimal compiles
fine. I will see if I can get Python to run with my system's mpdecimal (once I
have updated it), b
Hubert Holin added the comment:
This is correct: I had an older version of mpdecimal in /usr/local. However,
when removed mpdecimal is (manually) removed from /usr/local (the libs and the
header), making a "make clean", a config and make, the _decimal build still
fails, but this
New submission from Hubert Holin :
_decimal fails to build on my platform due to lack of support:
In file included from
/Developer/Python/3.6/Python/Python-3.6.5/Modules/_decimal/_decimal.c:34:
/usr/local/include/mpdecimal.h:201:4: error: "unsupported platform: need
mpd_size_t == mpd_u
14 matches
Mail list logo
