Ma Lin added the comment:
Today, I investigated these popular programming languages, all are the latest
version.
iconv-1.14 wrong version
php-5.6.8 wrong version (php is using iconv)
ActivePerl-5.20.2wrong version
GoLang-1.4.2 no GB2312, only has GBK
Ma Lin added the comment:
Andre Lemburg,
We don't need any modify, A844 is in GBK but not in GB2312, so no need to add
it into GB2312.
Your logic is right, it's hard to judge which one is wrong.
But U+30FB (· KATAKANA MIDDLE DOT) and U+2015 (— HORIZONTAL BAR) have no reason
among
New submission from Ma Lin:
While I was trying to optimize GB2312/GBK/GB18030-2000 codecs (they are three
encodings that widely used in China), I found there is a bug.
The three encodings, their relation should be: GB2312 ⊂ GBK ⊂ GB18030-2000.
However, in Python's implement: GB2312 ⊄ GBK
Ma Lin added the comment:
Since MIDDLE DOT is a common character, this bug is annoying.
Sorry, it's MIDDLE DOT, not DASH.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue24036
New submission from Ma Lin:
Hi,
There is a small bug in GB18030 decoder.
For 4-byte sequence, the legal range is:
0x81-0xFE for the 1st byte
0x30-0x39 for the 2nd byte
0x81-0xFE for the 3rd byte
0x30-0x39 for the 4th byte
The current code forgets to check 0xFE of the 1st and 3rd byte
Changes by Ma Lin wjss...@sohu.com:
--
type: - behavior
Added file: http://bugs.python.org/file39278/forpy3.patch
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue24117
Changes by Ma Lin wjss...@sohu.com:
--
title: A small bug in GB18030 decoder. - Wrong range checking in GB18030
decoder.
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue24117
Ma Lin added the comment:
I found another bug in hz codec.
hz encoding uses 7-bit ASCII to represent Chinese characters, it was popular in
USENET networks in the late 1980s and early 1990s.
I will do more check and fix them together, then I will invite you to review
the patch.
u = 'hi
Changes by Ma Lin wjss...@sohu.com:
Added file: http://bugs.python.org/file39319/forpy34.patch
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue24117
Changes by Ma Lin wjss...@sohu.com:
Added file: http://bugs.python.org/file39320/forpy35.patch
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue24117
Changes by Ma Lin wjss...@sohu.com:
Removed file: http://bugs.python.org/file39278/forpy3.patch
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue24117
Changes by Ma Lin wjss...@sohu.com:
Removed file: http://bugs.python.org/file39277/forpy27.patch
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue24117
Ma Lin added the comment:
I examined all Chinese codecs, here are the patches, please review them, feel
free to ask me your question.
Thanks to Hye-Shik, your framework is very easy to understand :)
--
Added file: http://bugs.python.org/file39318/forpy27.patch
Ma Lin added the comment:
Good question.
GB2312:
I tested those programming languages one by one.
GBK/CP936/GB18030-2000:
I gathered data via Internet as much as I can, then compare them to Python3's
codecs. I check key points with authoritative source, and verify every appeared
conflicts
Ma Lin added the comment:
This is not a de-facto standard, it should be fixed.
I already posted this infomation on a Taiwan Python community, let's wait their
inspection.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue24117
Ma Lin added the comment:
If you could provide links to the relevant pages/section we can verify that
the codecs are indeed incorrect.
Here is CP950, 0xC6A1 is not in it.
https://msdn.microsoft.com/zh-cn/goglobal/cc305155
I can provide one link, but there are many variants of BIG5 convert
Ma Lin added the comment:
I examined all Chinese codecs
I said it above, but I forgot Taiwan and HongKong are using Chinese as well.
BIG5 and CP950 are using a wrong convert table, test this:
u = b'\xC6\xA1'.decode('big5')
hex(ord(u))
'0x30fe'
This should not happen, 0xC6A1 is neither
Ma Lin added the comment:
I agree with you, "won't fix".
--
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/issue24036>
___
__
Ma Lin added the comment:
I posted in a Taiwanese forum: https://groups.google.com/forum/#!forum/pythontw
no reply yet.
--
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/i
Ma Lin added the comment:
After my MS-Windows 10 updated to 10586.218 this day, it occurs again.
It hung, the console cursor was flashing at the beginning of the current line.
I pressed ENTER key on the console window, then it printed the supposed content
and went on.
I have read issue26624
Ma Lin added the comment:
ok, I will try faulthandler module.
>> Are you running your program in the Windows console (cmd.exe)? In IDLE? In
>> PowerShell?
One runs in pure command line mode, cmd.exe.
The other is a simple tkinter GUI with a console for output message.
To be hones
Ma Lin added the comment:
>> It looks like a bug in your application. Can you provide a short script to
>> reproduce the bug?
It's hard to believe it, the code has no way to behavior like that.
I think this is not reproducible, it's random hang.
As my subjective feelings, I
New submission from Ma Lin:
My OS is MS-Windows 10 X86-64 (Home edition), with the lastest update (now it's
10586.164).
I have two programs, they occasionally infinite hang.
After a few months observation, I provide these infomation:
1, print() function cause the infinite hang.
2, If it hangs
Ma Lin added the comment:
I'm afraid not. If run it 1000 times, only about <5 times occurs, the others
are quite fine.
I have installed faulthandler, let's wait the hunting.
--
___
Python tracker <rep...@bugs.python.org>
<http://bug
Ma Lin added the comment:
Hang everytime?
When it hangs, try to press ENTER of keyboard on the console window, does it
work?
If it works, see issue26744: print() function hangs on MS-Windows 10
--
nosy: +Ma Lin
___
Python tracker <
Ma Lin added the comment:
faulthandler module caught a hang just now:
Timeout (0:01:00)!
Thread 0x0eb0 (most recent call first):
File "D:\git\tz2txt\tz2txt\gui.py", line 262 in delfile
File "C:\Python35\lib\tkinter\__init__.py", line 1549 in __
Ma Lin added the comment:
Let me give a summary.
Before 3.6.0 (before 284676cf2ac8):
implicit begin: st in (INSERT, UPDATE, DELETE, REPLACE)
implicit commit: st not in (SELECT, INSERT, UPDATE, DELETE, REPLACE)
In 3.6.0 (after 284676cf2ac8):
implicit begin: (not sqlite3_stmt_readonly(st
Ma Lin added the comment:
How about this? Is it too long?
@Matthew Barnett, I'm animalize on your repository.
.. seealso::
Third-party module `regex <https://pypi.python.org/pypi/regex>`_,
is a substitute for re module, it offers some mainstream features
which re module
Ma Lin added the comment:
If the answer is (no, no) , the behavior strictly follows the doc changes in
commit 284676cf2ac8.
Anyway, I'm not a deep user of SQLite, I can't give further advices. :(
--
___
Python tracker <rep...@bugs.python.org>
Ma Lin added the comment:
Just remind, there is a chance to remove sqlite3_stmt_readonly(). :)
--
nosy: +berker.peksag, palaviv
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/i
New submission from Ma Lin:
In CPython 3.6.0, sqlite3 module uses sqlite3_stmt_readonly(), however this
function is only available on SQLite 3.7.4+ (release on 2010-12-07).
Then CPython 3.6.0 can not be compiled on RHEL6 (with SQLite 3.6.x),
complaints: issue29098, issue29325
Changes by Ma Lin <malin...@163.com>:
--
nosy: +Ma Lin
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/issue29121>
___
___
Python
Ma Lin added the comment:
You can set isolation_level = None in sqlite3.connect() parameters, then
sqlite3 module will not begin a transaction implicitly.
Another way is disabling auto-begin-transaction temporarily:
sql.isolation_level = None
sql.execute('VACUUM')
sql.isolation_level
Ma Lin added the comment:
After read some issues, there are two major concerns:
1, backward compatibility.
2, implicit commit is bad, tolerates bug-prone codes.
However they are not contradictory if we print a warning when doing an implicit
commit. Some messages like this:
Warning: sqlite3
Ma Lin added the comment:
> Is there currently a solution to build Python 3.6 with sqlite3 support?
I installed SQLite 3.16.2 on a Debian-based system with this way:
http://stackoverflow.com/questions/26261080
No idea whether it will work on RHE
Ma Lin added the comment:
The "old way" is not using sqlite3_stmt_readonly().
Before 3.6.0, we only count rowcount for INSERT, UPDATE, DELETE, REPLACE:
https://hg.python.org/cpython/file/3.5/Modules/_sqlite/cursor.c#l689
These four statements can be representd by is_dml in PR
Ma Lin added the comment:
some comments on Aviv Palivoda's patch.
--
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/issue28518>
___
___
Ma Lin added the comment:
RHEL6's life-cycle is around 10 years [1], it will be alive until 2020.
https://access.redhat.com/support/policy/updates/errata/
Let's wait issue28518, IMO, that issue will decide whether we can get around
sqlite3_stmt_readonly
Ma Lin added the comment:
sqlite3 module in CPython 3.6.0 also uses sqlite3_stmt_readonly(). see
284676cf2ac8.
sqlite3_stmt_readonly() was used twice [1][2], but it seems that we can avoid
using this function in both of them.
[1] https://hg.python.org/cpython/file/3.6/Modules/_sqlite/cursor.c
Ma Lin added the comment:
I'm using Python 3.6.0 RC2, I don't know if it's a bug.
When I try to run VACUUM command, an exception raised:
conn.execute('begin') # <- remove this line get the same result
conn.execute('VACUUM')
sqlite3.OperationalError: cannot VACUUM from within a transact
New submission from Ma Lin:
I'm using Python 3.6.0 RC2.
When I try to run VACUUM command, an exception raised:
conn.execute('begin') # <- remove this line get the same result
conn.execute('VACUUM')
sqlite3.OperationalError: cannot VACUUM from within a transaction
On Python 3.5, everyth
Ma Lin added the comment:
#29003 created
--
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/issue10740>
___
___
Python-bugs-list
Ma Lin added the comment:
I have no idea about how to fix it, but I would like to suggest that add back
this test which was removed in commit 284676cf2ac8 :
file: /Lib/sqlite3/test/transactions.py
def CheckVacuum(self):
self.cur.execute("create table test(i)")
self.cur.execu
Ma Lin added the comment:
I'm trying to catch up with you.
Does it mean, if I want execute VACUUM, I have to commit manually? Like this:
if conn.in_transaction:
conn.commit()
conn.execute("vacuum")
--
___
Python tracker <rep...@bu
Changes by Ma Lin <malin...@163.com>:
--
nosy: +Ma Lin
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/issue24821>
___
___
Python
Changes by Ma Lin <malin...@163.com>:
--
pull_requests: +1171
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/issue29990>
___
__
New submission from Ma Lin:
hz is a Simplified Chinese codec, available in Python since around 2004.
However, hz encoder has a serious bug, it forgets to escape ~
>>> 'hi~'.encode('hz')
b'hi~'# the correct output should be b'hi~~'
As a result, we can't finish a roundtrip:
>>
Ma Lin added the comment:
> except 0x80 (€)
I suppose the English edition is not the final release of GB18030-2000.
At the end of official Chinese edition of GB18030-2005, listed the difference
between GB18030-2000 and GB18030-2005 clearly, it doesn't mention 0x80 (€), so
GB18030-2000 sho
Ma Lin added the comment:
I tried to fix this two years ago, here is the patch (not merged):
http://bugs.python.org/review/24117/diff/14803/Modules/cjkcodecs/_codecs_cn.c
But later, I thought it's a good opportunity to remove this codec, this serious
bug indicates that almost no one is using
Ma Lin added the comment:
This is a very trivial bug, it's hard to imagine a scene that someone trying to
decode those 8630 illegal 4-byte sequences with GB18030 decoder.
And I think this bug can't lead to security vulnerabilities.
As far as I can see, GB2312/GBK/GB18030 codecs are bugfree
Ma Lin added the comment:
This is an invalid issue, very sorry for waste your time! Especially apologize
to Stinner.
After enabling `QuickEdit Mode`, then click the console will suspend the
program.
--
resolution: -> not a bug
stage: -> resolved
status: open -&g
Ma Lin added the comment:
>From my subjective feelings, probably no old archives still exist, but I can't
>assert it. That's why I suggest remove it, or at least don't fix it.
Ah, let's slow down the pace, this bug exists over a dacade, we don't need to
solve it at once.
I closed
Ma Lin added the comment:
I closed this issue, because it involved too many things.
1, for GB18030 decoder bug, see issue29990.
2, for hz encoder bug, see issue30003.
3, for problem in Traditional Chinese codecs, please create a new issue
New submission from Ma Lin:
This issue is split from issue24117, that issue became a soup of small issues,
so I'm going to close it.
For 4-byte GB18030 sequence, the legal range is:
0x81-0xFE for the 1st byte
0x30-0x39 for the 2nd byte
0x81-0xFE for the 3rd byte
0x30-0x39 for the 4th byte
Changes by Ma Lin <malin...@163.com>:
--
stage: patch review -> resolved
status: open -> closed
___
Python tracker <rep...@bugs.python.org>
<http://bugs.
Ma Lin added the comment:
> We have a ucd_3_2_0 in unicodedata.
Probably this 3.2 unicodedata is used for IDNA2003.
In IDNA2003 there is a step: normalize the domain_name string to Unicode
Normalization Form C.
Now we changed the Composition code of Hangul to Unicode Standard
Ma Lin added the comment:
You are right.
I found a Normalization Test Suite for Unicode 3.2
http://www.unicode.org/Public/3.2-Update/NormalizationTest-3.2.0.txt
\u1176 is not in the range of the second character.
\u11a7, \u11c3 are not in the range of the third character
Ma Lin added the comment:
This issue can be closed, already fixed in issue29456
Also, PyPy's current code is correct.
--
___
Python tracker
<https://bugs.python.org/issue26
Ma Lin <malin...@163.com> added the comment:
Glad to see PR 5468 not merged, I found it makes socket.py complicated.
Now I'm inclined to patch the code in PyInit__socket(void) of socketmodule.c
https://github.com/python/cpython/blob/3.6/Modules/socketmodule.c#L6504
There already ha
Ma Lin <malin...@163.com> added the comment:
> Or the issue is specific for TCP_KEEPCNT for Windows only?
Four flags involved.
In this table, result column is search results from GitHub.
keyword available result
TCP_FASTOPEN win10 1607+ 778
TCP_KEEPCNTwin10 170
Ma Lin <malin...@163.com> added the comment:
Base on Kamil's code, a little improvements.
if hasattr(sys, 'getwindowsversion'):
WIN_MAJOR, _, WIN_BUILD, *_ = sys.getwindowsversion()
if WIN_MAJOR == 10:
if WIN_BUILD >= 15063:# Windows 10 1703
pass
Change by Ma Lin <malin...@163.com>:
--
keywords: +patch
pull_requests: +5294
stage: test needed -> patch review
___
Python tracker <rep...@bugs.python.org>
<https://bugs.pyt
Ma Lin <malin...@163.com> added the comment:
So we either need to explicitly exclude this symbol on Windows (at least until
we drop support for pre-Windows 10 versions) or silently ignore setsockopt
errors for future good arguments. I'm inclined to do the former - other
op
Ma Lin <malin...@163.com> added the comment:
> We don't remove unsupported socket flags on Unix, why should we do it for
> Windows?
We have this problem because: compile with new Windows SDK, but run on old
version Windows.
On Linux/Unix, the compile-time headers al
Change by Ma Lin <malin...@163.com>:
--
pull_requests: +5403
___
Python tracker <rep...@bugs.python.org>
<https://bugs.python.org/issue32394>
___
__
Ma Lin <malin...@163.com> added the comment:
Here is PR 5585 for 3.6 branch.
For 3.7+, I would suggest patch in socketmodule.c like this:
PyMODINIT_FUNC
PyInit__socket(void)
{
PyObject *m, *has_ipv6;
...
...
...
+#ifdef MS_WINDOWS
+ return remove_unusable_flags(m);
Ma Lin <malin...@163.com> added the comment:
> What's about other OS/flags?
> Should we commit that every exposed socket flag is supported in runtime?
> It looks like very heavy burden.
Let alone run-time check. Flags only depend on .C code and the building SDK,
therefore
Ma Lin <malin...@163.com> added the comment:
I create a new one (PR 5523), I'm not a C & socket expert, so if you want to
improve/polish the patch, feel free to create a new PR based on (or not) it.
--
___
Python tracker <rep...@bu
Change by Ma Lin <malin...@163.com>:
--
pull_requests: +5352
___
Python tracker <rep...@bugs.python.org>
<https://bugs.python.org/issue32394>
___
__
Ma Lin <malin...@163.com> added the comment:
segmentfault conditions:
64bit Windows + 32bit Python + Compatibility Mode enabled.
some infomation:
1, 64bit Python doesn't segmentfault.
2, 3.7.0a3 is ok, 3.7.0a4 segmentfaults.
3, unrelated to Windows SDK, switch from 1709 SDK to 1703 SD
Ma Lin <malin...@163.com> added the comment:
Here is two traceback messages:
D:\git\cpython\PCbuild\win32>python.exe -X dev
d:\git\cpython\Lib\test\test_multiprocess
ing_main_handling.py
ss
Ma Lin <malin...@163.com> added the comment:
PR 5523 is prepared for master/3.7 branches.
PR 5585 is prepared for 3.6 branch.
--
___
Python tracker <rep...@bugs.python.org>
<https://bugs.python
New submission from Ma Lin <malin...@163.com>:
Reproduce:
Right click python.exe -> properties -> compatibility tab -> enable
compatibility mode (e.g. Windows 7)
Then run this test will get a segmentfault:
test_multiprocessing_main_handling.py
CPython 3.6 is Ok.
--
Ma Lin <malin...@163.com> added the comment:
Git bisect says this is the first bad commit:
https://github.com/python/cpython/commit/b2a6083eb0384f38839d3f1ed32262a3852026fa
--
___
Python tracker <rep...@bugs.python.org>
<https://
Ma Lin added the comment:
This bug generates wrong results silently, so I suggest mark it as release
blocker for 3.7.1
--
nosy: +Ma Lin
___
Python tracker
<https://bugs.python.org/issue34
Ma Lin added the comment:
> I expect that the root cause is missing libffi(-dev[el]) on your system
Yes, on my Ubuntu 18.04, `make` failed to compile _ctypes module.
After install libffi-dev, it was compiled successfully:
One more word, full necessary dependencies on my Ubuntu 18.04:
s
Ma Lin <malin...@163.com> added the comment:
Here is a solution:
1, open a page(whatever) with Internet Explorer.
2, right click the page -> Encoding -> check "Auto-Select"
Then the wrong characters (�/抯) will disappear forever.
> Does anyone else see this problem?
Prob
Change by Ma Lin <malin...@163.com>:
Added file: https://bugs.python.org/file47476/screenshot.PNG
___
Python tracker <rep...@bugs.python.org>
<https://bugs.python
Ma Lin <malin...@163.com> added the comment:
The source code of .chm changed between 3.6.2 and 3.6.3, the former uses
escaped html entities.
I couldn't find out which commit caused this change.
3.6.2 chm: Whats New In Python 3.6
3.6.3 chm: What抯 New In Python 3.6
3.6.2 chm: Summary R
Ma Lin <malin...@163.com> added the comment:
There was a discussion about "Latin Capital Letter I with Dot Above"
https://bugs.python.org/issue17252
----------
nosy: +Ma Lin
___
Python tracker <rep...@bugs.python.org>
<https://b
Ma Lin <malin...@163.com> added the comment:
> Victor's patch is correct.
I'm afraid you are wrong.
Please see PR 1958 in issue29456, IMO this PR can be merged.
--
nosy: +Ma Lin
___
Python tracker <rep...@bugs.python.org>
<https
Change by Ma Lin <malin...@163.com>:
--
title: multiprocessing segmentfault under Windows compatibility mode ->
subprocess crash under Windows compatibility mode
___
Python tracker <rep...@bugs.python.org>
<https://bugs.pyt
Ma Lin <malin...@163.com> added the comment:
3.7.0 beta2 still segmentfault.
Finer, please have a look.
segmentfault conditions:
64bit Windows 10 (1709) + 32bit Python 3.7.0 Beta2 + Compatibility Mode enabled.
(64bit Python doesn't segmentfault)
--
nosy: +Segev
Ma Lin <malin...@163.com> added the comment:
ping, this was forgotten.
--
nosy: +Ma Lin
___
Python tracker <rep...@bugs.python.org>
<https://bugs.python
Ma Lin added the comment:
I will create a PR to fix this within a day.
--
___
Python tracker
<https://bugs.python.org/issue32174>
___
___
Python-bugs-list mailin
Change by Ma Lin :
--
keywords: +patch
pull_requests: +9143
stage: -> patch review
___
Python tracker
<https://bugs.python.org/issue32174>
___
___
Python-
Ma Lin added the comment:
It seems impossible to specify the encoding of .chm to ASCII [1], the available
encodings of .chm are limited to a list [2].
So I wrote a Sphinx extension for .chm output, it escapes the characters which
(codepoint > 0x7F) to 7-bit ASCII. Most escaped charact
Change by Ma Lin :
Added file: https://bugs.python.org/file47858/PR 9758 effects.png
___
Python tracker
<https://bugs.python.org/issue32174>
___
___
Python-bugs-list m
Ma Lin added the comment:
> It seems to me that this adds escape4chm as unconditional dependency on all
> platforms.
`Doc/Makefile` also includes `htmlhelp` command, it generates .chm materials.
BTW, the related navigation bar still has corrputed characters, see the
attache
Ma Lin added the comment:
Yes, I can reproduce on my Windows 10 (Simplfied Chinese).
The file is a pure ASCII file, and doesn't have a BOM prefix.
--
___
Python tracker
<https://bugs.python.org/issue35
Ma Lin added the comment:
Let me give an explanation.
Run encoding_problem_gbk.py, get an error:
D:\>encoding_problem_gbk.py
File "D:\encoding_problem_gbk.py", line 1
SyntaxError: encoding problem: gbk
If remove the comment line, run as expected.
------
Ma Lin added the comment:
I debugged, this is a duplicate of issue 20844 and issue 27797.
Eryk Sun analyzed this detailedly, it's a problem of Windows CRT.
--
versions: +Python 3.5, Python 3.6, Python 3.8
___
Python tracker
<ht
Ma Lin added the comment:
I searched on Google, an article [1] said: Of note, Mac OS X defines keepidle
and keepintvl in terms of milliseconds as opposed to Linux using seconds.
On Windows, it's also seconds. Will this option make trouble for cross-platform
programs?
[1]
http
Ma Lin added the comment:
Every non-empty str will be checked twice at present.
--
components: +Interpreter Core
type: -> enhancement
versions: +Python 3.8
___
Python tracker
<https://bugs.python.org/issu
Change by Ma Lin :
--
versions: +Python 3.6, Python 3.7
___
Python tracker
<https://bugs.python.org/issue35636>
___
___
Python-bugs-list mailing list
Unsub
New submission from Ma Lin :
Please see the PR
--
messages: 332857
nosy: Ma Lin
priority: normal
severity: normal
status: open
title: remove redundant code in unicode_hash(PyObject *self)
___
Python tracker
<https://bugs.python.org/issue35
Change by Ma Lin :
--
keywords: +patch, patch, patch
pull_requests: +10783, 10784, 10785
stage: -> patch review
___
Python tracker
<https://bugs.python.org/issu
Change by Ma Lin :
--
keywords: +patch
pull_requests: +10783
stage: -> patch review
___
Python tracker
<https://bugs.python.org/issue35636>
___
___
Python-
Change by Ma Lin :
--
keywords: +patch, patch
pull_requests: +10783, 10784
stage: -> patch review
___
Python tracker
<https://bugs.python.org/issu
Ma Lin added the comment:
Thanks for review.
Don't know why bytes and str generates the same hash value for ASCII sequence.
>>> hash('abc') == hash(b'abc')
True
This may brings some hash collisions, does it affect performance
1 - 100 of 394 matches
Mail list logo
