Xiang Zhang added the comment:
Sorry, after checking again, this is still needed but maybe `if (len ==
PY_SSIZE_T_MAX)` part is not necessary since the iterable's length should not
be larger than PY_SSIZE_T_MAX. But keep it to avoid theoretically bug is not a
bad idea.
--
s
Xiang Zhang added the comment:
Thanks for your comment Martin. I'll apply them later when we reach agreement
on functions.
I have already used object = NULL, the C default is not necessary here, and it
works as you like I think. In patch version 1, b'abc'.translate(None
Xiang Zhang added the comment:
Nice to see the real example. I don't think of that.
--
___
Python tracker
<http://bugs.python.org/issue27507>
___
___
Pytho
New submission from Xiang Zhang:
Attach a patch to add PathLike objects support to BZ2File.
--
files: add_PathLike_objects_support_to_BZ2File.patch
keywords: patch
messages: 270385
nosy: brett.cannon, ethan.furman, xiang.zhang
priority: normal
severity: normal
status: open
title: Add
Changes by Xiang Zhang :
--
components: +Library (Lib)
type: -> enhancement
versions: +Python 3.6
___
Python tracker
<http://bugs.python.org/issue27511>
___
_
New submission from Xiang Zhang:
When any exception is raised inside __fspath__, operations involving it like
os.fspath, open are certain to crash.
>>> import os
>>> class Test:
... def __fspath__(self):
... raise RuntimeError
...
>>> os.fspath(Test(
Xiang Zhang added the comment:
BTW, the code is also listed in PEP519. So maybe that also needs to be fixed.
--
___
Python tracker
<http://bugs.python.org/issue27
Xiang Zhang added the comment:
Ahh, adding tests is easy. But this seems to be just a careless omission, so
maybe tests is not a must.
--
___
Python tracker
<http://bugs.python.org/issue27
Xiang Zhang added the comment:
So would you like to merge it like this or Martin's alternative way? But
honestly speaking I don't get Martin's point, "without trying to allocate
Py_SSIZE_T_MAX first", where is this place?
--
_
Xiang Zhang added the comment:
I think such omissions are hard to predict and you won't know where is the
omission until you encounter it. So if you don't know, how do you know what to
put in the tests? And if it is encountered and fixed, such errors should not
ha
Xiang Zhang added the comment:
Thanks for the analysis Antti. I don't think if (len == PY_SSIZE_T_MAX) can be
moved inside the *other* if. Their handlings are different. if (len ==
PY_SSIZE_T_MAX) is True, it should exit immediately. But in the *other* if, you
can still have a try to all
Xiang Zhang added the comment:
The test requests for the whole fspath are reasonable. I just don't want to add
tests for these two lines.
1) and 3) have already been tested. I add 2) and reorganize the existing tests
a little.
--
Added file: http://bugs.python.org/file
Xiang Zhang added the comment:
I have to explain for myself.
First, I know tests *are* important. This is not the first time
uploading patches here. I don't want to add tests for this case
is because such codes: call something and test for failure appears
all the places in the code base.
Xiang Zhang added the comment:
Thanks Brett, also others. Restore the moving around.
--
Added file: http://bugs.python.org/file43723/fix_fspath_crash_v3.patch
___
Python tracker
<http://bugs.python.org/issue27
Xiang Zhang added the comment:
ping
--
___
Python tracker
<http://bugs.python.org/issue27130>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.pyth
Xiang Zhang added the comment:
Upload the v9 version. It applies your last comment and catch up with the hg
tip.
--
Added file: http://bugs.python.org/file43750/64bit_support_for_zlib_v9.patch
___
Python tracker
<http://bugs.python.org/issue27
Xiang Zhang added the comment:
I can't totally agree the point. The code means every time we increase the
buffer by half the current length. So when the length arrives 2/3 *
PY_SSIZE_T_MAX it's going to overflow. There is a 1/3 * PY_SSIZE_T_MAX gap
between the theoretical upper limi
Xiang Zhang added the comment:
How about other built-in classes? If repr does matter, maybe str, int, dict
should also respect this rule?
--
___
Python tracker
<http://bugs.python.org/issue27
Xiang Zhang added the comment:
Yes. So if we are not going to change other built-in types, maybe we'd better
not change bytearray either. My opinion is that don't change built-in classes,
even bytearray. If users would like a more reasonable repr, they can provide a
custom __repr
Xiang Zhang added the comment:
Could you post the error message and your platform? I just tried and everything
went fine.
--
nosy: +xiang.zhang
___
Python tracker
<http://bugs.python.org/issue27
Xiang Zhang added the comment:
So if it doesn't return an overflow message, what does it returns?
--
nosy: +xiang.zhang
___
Python tracker
<http://bugs.python.org/is
Changes by Xiang Zhang :
--
nosy: +xiang.zhang
___
Python tracker
<http://bugs.python.org/issue27558>
___
___
Python-bugs-list mailing list
Unsubscribe:
Xiang Zhang added the comment:
It seems the thread state is initialized in thread_PyThread_start_new_thread.
It calls _PyThreadState_Prealloc which initialize exc_type to NULL.
--
___
Python tracker
<http://bugs.python.org/issue27
Xiang Zhang added the comment:
I am curious why individual `raise` doesn't get the same problem in single
thread program.
--
___
Python tracker
<http://bugs.python.org/is
Xiang Zhang added the comment:
Compressing large data is born to be slow and it's highly possible to cause the
kernel halt then due to resource limit.
> This may be used to crash python remotely if a server takes user input and
> runs it through zlib.compress(b'variable&#x
Xiang Zhang added the comment:
Thanks for your work.
--
___
Python tracker
<http://bugs.python.org/issue27507>
___
___
Python-bugs-list mailing list
Unsubscribe:
Xiang Zhang added the comment:
I may be hard to test this change without enough memory. I upload the test
results with the latest change.
--
Added file: http://bugs.python.org/file43775/zlib_test_result
___
Python tracker
<http://bugs.python.
Xiang Zhang added the comment:
> Easiest fix would be to make do_raise test for both NULL and None, but I'd
> really consider fixing the new thread initialization if possible.
I think the easiest fix is OK. The new thread initialization is consistent and
should not be changed.
Xiang Zhang added the comment:
Upload a patch.
--
keywords: +patch
Added file: http://bugs.python.org/file43776/issue27558.patch
___
Python tracker
<http://bugs.python.org/issue27
Xiang Zhang added the comment:
It's reasonable but I'd still like to hear others' voices since it looks more
like to me it's the behaviour of raise itself rather than threading that
crashes.
--
___
Python tracker
<http://bug
Xiang Zhang added the comment:
A simple try ... except ... can set the variable to Py_None:
>>> import threading
>>> def foo():
... try:
... raise RuntimeError
... except:
... pass
... raise
...
>>> threading.Thread(target=fo
New submission from Xiang Zhang:
Right now, int() supports bytes-like objects when *base* is not given:
>>> int(memoryview(b'100'))
100
When *base* is given bytes-like objects are not supported:
>>> int(memoryview(b'100'), base=2)
Traceback (most re
Changes by Xiang Zhang :
--
type: -> enhancement
___
Python tracker
<http://bugs.python.org/issue27572>
___
___
Python-bugs-list mailing list
Unsubscrib
Changes by Xiang Zhang :
Removed file: http://bugs.python.org/file43789/bytes_like_support_to_int.patch
___
Python tracker
<http://bugs.python.org/issue27572>
___
___
Changes by Xiang Zhang :
Added file: http://bugs.python.org/file43790/bytes_like_support_to_int.patch
___
Python tracker
<http://bugs.python.org/issue27572>
___
___
Pytho
New submission from Xiang Zhang:
For tuple and list, their signatures are tuple([iterable]) and
list([iterable]). But actually they support keyword argument *sequence*. The
parameter names in doc are sometimes just placeholders but sometimes are real
parameter names. So I suggest make the
Changes by Xiang Zhang :
--
title: tuple and list parameter name conflicts between doc and implementation
-> Make implementation and doc of tuple and list more compliant
___
Python tracker
<http://bugs.python.org/issu
Xiang Zhang added the comment:
Hi, Martin. I replied your last comment and your patch looks good to me except
one test fails:
[1/1] test_zlib
test_abcdefghijklmnop (test.test_zlib.ChecksumTestCase)
test issue1202 compliance: signed crc32, adler32 in 2.x ... ok
test_adler32empty
New submission from Xiang Zhang:
Overflow check in PySequence_Tuple relies on undefined behaviour, fix it.
--
components: Interpreter Core
files: overflow_check_in_PySequence_Tuple.patch
keywords: patch
messages: 270909
nosy: martin.panter, serhiy.storchaka, xiang.zhang
priority: normal
Xiang Zhang added the comment:
All tests passed now. :) I think it's OK. Also upload the v10 version restore
the statement to avoid the crash you mentioned in comments.
[1/1] test_zlib
test_abcdefghijklmnop (test.test_zlib.ChecksumTestCase)
test issue1202 compliance: signed crc32, adler32
Xiang Zhang added the comment:
Thanks for the reviews Martin. Change the doc and test.
--
Added file: http://bugs.python.org/file43825/bytes_like_support_to_int_v2.patch
___
Python tracker
<http://bugs.python.org/issue27
Xiang Zhang added the comment:
It's reasonable. My original intention is to make the behaviour consistent. If
the single-argument behaviour is OK with bytes-like objects, why not others? So
I think we'd better wait for other developers to see what their opinions are.
-
Xiang Zhang added the comment:
@Martin, attach a patch to fix the overflow check you mentioned in tuple and
list objects.
--
nosy: +xiang.zhang
Added file: http://bugs.python.org/file43827/tuple_and_list.patch
___
Python tracker
<h
Xiang Zhang added the comment:
I'd prefer the size_t method. The others seems to make the logic not clear.
I've seen some codes using size_t to do overflow checking, such as
https://hg.python.org/cpython/file/tip/Python/bltinmodule.c#l1954. There are
more if you use a simple grep.
Xiang Zhang added the comment:
Thanks Martin too. Nobody than me knows how much work you have done to this. :)
I could have made it better at first. :( Sorry for the noise to everyone.
--
___
Python tracker
<http://bugs.python.org/issue27
Xiang Zhang added the comment:
Thanks Martin too. Nobody than me knows how much work you have done to this. :)
I could have made it better at first. :( Sorry for the noise to everyone.
--
___
Python tracker
<http://bugs.python.org/issue27
Xiang Zhang added the comment:
Change tuple_and_list.patch with empty curly braces. I don't add the test for
__length_hint__. According to the comment, when overflow happens, it is either
ignored or a MemoryError will finally be raised. I am not willing to test a
MemoryError in this
Xiang Zhang added the comment:
LGTM. Using b'' instead of the None as the default value of *delete* looks
better since it doesn't break backwards compatibility. As for the first
argument optional or not, actually it's both okay. You have changed
Xiang Zhang added the comment:
Thanks for replies. Attach a small documentation patch.
--
keywords: +patch
Added file: http://bugs.python.org/file43844/tuple_and_list_parameter_name.patch
___
Python tracker
<http://bugs.python.org/issue27
Xiang Zhang added the comment:
pypy seems so.
[PyPy 5.2.0-alpha0 with GCC 4.8.2] on linux
>>>> int(memoryview(b'123A'[1:3]))
23
>>>> int(memoryview(b'123 '[1:3]))
23
--
___
Python
Xiang Zhang added the comment:
It's cool, but I get one problem when writing tests. support.captured_stderr
cannot capture the runtime error message. So we have nothing to do with the
assertion and the test will always succeed even when overflow does happen (the
message will be output
Xiang Zhang added the comment:
It turns out you just want to see the output. That is easy. Patch v3 adding the
test.
--
Added file: http://bugs.python.org/file43862/tuple_and_list_v3.patch
___
Python tracker
<http://bugs.python.org/issue1
Xiang Zhang added the comment:
Ping again.
--
___
Python tracker
<http://bugs.python.org/issue26915>
___
___
Python-bugs-list mailing list
Unsubscribe:
Xiang Zhang added the comment:
Submit a patch to fix this. Hope it helps.
--
keywords: +patch
nosy: +xiang.zhang
Added file: http://bugs.python.org/file43876/odict_update.patch
___
Python tracker
<http://bugs.python.org/issue27
Xiang Zhang added the comment:
On Linux, it seems it's not an accident. inet_addr(3) explicitly says it can
handle octal or haxadecimal forms.
--
nosy: +xiang.zhang
___
Python tracker
<http://bugs.python.org/is
Xiang Zhang added the comment:
I didn't think about order. I just thought using concrete API may be faster.
But after your comment, I tested the performance and it seems PyDict_Items
makes it much slower (it does more work, eg, make tuples). So I agree it is not
needed a
Xiang Zhang added the comment:
A similar bug report can be seen at
https://github.com/dotnet/corefx/issues/8362. There someone makes a conclusion
that getaddrinfo (Python seems to use getaddrinfo to implement gethostbyname)
doesn't work correctly with octal form. They finally ignore
Xiang Zhang added the comment:
I write a new version restoring the fast path for dict. It now uses PyDict_Next
and seems to be much faster than the path using keys.
[cpython]$ ./python -m timeit -s 'from collections import OrderedDict; d =
{"a":1,"c":2,"b"
Xiang Zhang added the comment:
LGTM.
--
nosy: +xiang.zhang
___
Python tracker
<http://bugs.python.org/issue27626>
___
___
Python-bugs-list mailing list
Unsub
Xiang Zhang added the comment:
Nice to know your opinions. :) Adjust the patch to use Terry's sentence.
--
components: +Documentation -Interpreter Core
Added file:
http://bugs.python.org/file43934/tuple_and_list_parameter_name_v2.patch
___
P
Changes by Xiang Zhang :
Removed file: http://bugs.python.org/file43902/odict_update_v3.patch
___
Python tracker
<http://bugs.python.org/issue27576>
___
___
Python-bug
Xiang Zhang added the comment:
After totally studying OrderedDict, I get a better understanding of what Serhiy
means. So although we can get a better performance for dict, it's not needed at
all. Remove the v3 patch.
--
___
Python tracker
Xiang Zhang added the comment:
There seems to be some difference behaviours between C version and pure Python
version when it comes to subclass. Except popitem, the constructor also goes
different code path. There may be more. Should these differences be eliminated
or they are accepted
Xiang Zhang added the comment:
Martin, I upload a patch to fix another possible overflow in listextend.
--
Added file: http://bugs.python.org/file43956/overflow_fix_in_listextend.patch
___
Python tracker
<http://bugs.python.org/issue1
New submission from Xiang Zhang:
In list_resize, new_allocated is of type size_t but I think don't have to be
now since it finally have to assign back to self->allocated which is of type
Py_ssize_t. With Py_ssize_t, we can check some overflows in the first overflow
check and don&#x
Xiang Zhang added the comment:
Hmm, I don't tend to infer platform characteristics. IMHO, it's a simple
problem: sum up two lists' length which may overflow in logic.
With your argument, does it means it seems somewhat meaningless to have a List
a Py_ssize_t length since it can
Xiang Zhang added the comment:
:( Sorry David, my poor English doesn't enable me understand your message
totally. Is list.sort related to this problem? Do I miss something?
--
___
Python tracker
<http://bugs.python.org/is
Xiang Zhang added the comment:
So these checks are superfluous? Do we need to remove them?
Hmm, I still doubt such checks should consider platform characteristics first.
In theory List can be PY_SSIZE_T_MAX length. Do we have to put the PY_SIZE_MAX
// sizeof(PyObject *) limit on it
New submission from Xiang Zhang:
List_New checks against PY_SIZE_MAX. The upper bound of PyMem_Malloc is
PY_SSIZE_T_MAX.
Instead of simply changing the constant, another method is delegating overflow
check to PyMem_Calloc, so we can avoid the check in unnecessary check in
PyMem_Malloc. But I
Xiang Zhang added the comment:
Thanks for your replies.
I update the patch with PyMem_Calloc. I think it's better than PyMem_Resize
since we need to initialize the memory here, there is a memset(op->ob_item, 0,
nbytes) below.
--
Added file: http://bugs.python.org/f
Xiang Zhang added the comment:
Update the patch with Berker's suggestion: add test in test_threading instead
of test_raise. Hope someone is willing to merge this.
--
Added file: http://bugs.python.org/file43971/issue27558_v2.patch
___
Python tr
Xiang Zhang added the comment:
I agree. For multibytecode, how about switching the positions of the two
checks? If npendings + ctx->pendingsize overflows, the result can be anything,
larger, smaller than or equal to MAXDECPENDING. For ast, although a SystemError
may be raised but the mess
Xiang Zhang added the comment:
But if you use size_t, you are checking overflow against PY_SIZE_MAX, not
PY_SSIZE_T_MAX.
--
___
Python tracker
<http://bugs.python.org/issue27
Xiang Zhang added the comment:
So how about list_resize_v2.patch?
--
Added file: http://bugs.python.org/file43976/list_resize_v2.patch
___
Python tracker
<http://bugs.python.org/issue27
Changes by Xiang Zhang :
Removed file: http://bugs.python.org/file43970/List_New_Calloc.patch
___
Python tracker
<http://bugs.python.org/issue27662>
___
___
Python-bug
Xiang Zhang added the comment:
Add another PY_SIZE_MAX replacement I suggest in listobject.c.
--
Added file: http://bugs.python.org/file44002/List_New_Calloc.patch
___
Python tracker
<http://bugs.python.org/issue27
Xiang Zhang added the comment:
You have to exhausts the iterator to get the actual length. Some iterators have
__length_hint__ but it's not required to give the truth.
--
nosy: +xiang.zhang
___
Python tracker
<http://bugs.python.org/is
Changes by Xiang Zhang :
--
nosy: +rhettinger
___
Python tracker
<http://bugs.python.org/issue27678>
___
___
Python-bugs-list mailing list
Unsubscribe:
New submission from Xiang Zhang:
ImportError accepts name and path as keyword-only parameters, but when invalid
keyword argument passed, it emits wrong exception message saying that
ImportError does not take keyword arguments.
>>> ImportError(name='name', path=
Xiang Zhang added the comment:
I am a little uncomfortable with the empty tuple. It's only used as a
placeholder for PyArg_ParseTupleAndKeywords. But this way we can achieve
consistent error message. Don't know how to choose.
--
nosy: +x
New submission from Xiang Zhang:
While studying exceptions.c, find several unnecessary NULL checks that can be
removed.
--
components: Interpreter Core
files: small_cleanup_exceptions.patch
keywords: patch
messages: 272023
nosy: martin.panter, serhiy.storchaka, xiang.zhang
priority
Xiang Zhang added the comment:
It's good Martin. Just commit it.
--
___
Python tracker
<http://bugs.python.org/issue1621>
___
___
Python-bugs-list m
New submission from Xiang Zhang:
In do_raise, the two Py_XDECREFs at the final of the success branch seem doing
unnecessary NULL checks.
--
components: Interpreter Core
files: do_raise.patch
keywords: patch
messages: 272119
nosy: serhiy.storchaka, xiang.zhang
priority: normal
severity
Xiang Zhang added the comment:
Thanks for your reply Raymond. You always provide thoughtful feedbacks, though
it makes me somewhat more nervous. ;) (I am nervous about making noise here and
waste others' time.)
> Have you checked all the possibly code paths to be sure?
Yes. I did c
Changes by Xiang Zhang :
Added file: http://bugs.python.org/file44042/do_raise_v2.patch
___
Python tracker
<http://bugs.python.org/issue27703>
___
___
Python-bugs-list m
Xiang Zhang added the comment:
Thanks for the comment, Antti.
> would be nice to go see the call site and see asserts in place there,
> showing that the arguments never were NULL to begin with.
So is it still not enough getting the two asserts? IMHO I think the two asserts
have alread
Changes by Xiang Zhang :
--
assignee: docs@python
components: Documentation
files: import_doc.patch
keywords: patch
nosy: docs@python, xiang.zhang
priority: normal
severity: normal
status: open
title: Tiny typos in import.rst
type: behavior
versions: Python 3.6
Added file: http
Changes by Xiang Zhang :
--
nosy: +xiang.zhang
___
Python tracker
<http://bugs.python.org/issue16764>
___
___
Python-bugs-list mailing list
Unsubscribe:
Xiang Zhang added the comment:
I agree with Martin and suggest make the following changes:
1. Make wbits and bufsize of zlib.decompress keyword arguments.
2. Make max_length of decompressobj.decompress keyword argument.
I'd prefer others to stay position-only as now.
Attach a patch doin
Xiang Zhang added the comment:
Ping. Mind to merge?
--
___
Python tracker
<http://bugs.python.org/issue27558>
___
___
Python-bugs-list mailing list
Unsubscribe:
New submission from Xiang Zhang:
I think the doc of Py_CompileStringExFlags has two flaws:
1. Py_CompileStringExFlags should be replaced by Py_CompileStringObject from
the context. Py_CompileStringExFlags in the context is meaningless.
2. *filename* is a byte string that should be decoded but
Xiang Zhang added the comment:
OK. Simplest test with positional arguments.
Without patch:
./python -m timeit -s 'import zlib; a =
zlib.compress(b"abcdefghijklmnopqrstuvwxyz")' 'zlib.decompress(a, 15, 16384)'
100 loops, best of 3: 0.841 usec per loop
./pytho
Xiang Zhang added the comment:
So let's do a simple benchmark.
# without patch
./python -m timeit -s 'string=bytes(range(256));table=bytes(range(255, -1,
-1));delete=b"abcdefghijklmn"' 'string.translate(table, delete)'
100 loops, best of 3: 0.55 usec
Changes by Xiang Zhang :
Removed file: http://bugs.python.org/file44078/Py_CompileStringExFlags_doc.patch
___
Python tracker
<http://bugs.python.org/issue27740>
___
___
Changes by Xiang Zhang :
Added file: http://bugs.python.org/file44085/Py_CompileStringExFlags_doc.patch
___
Python tracker
<http://bugs.python.org/issue27740>
___
___
Xiang Zhang added the comment:
Thanks for your work too! :)
--
___
Python tracker
<http://bugs.python.org/issue27712>
___
___
Python-bugs-list mailing list
Unsub
Xiang Zhang added the comment:
It looks to me from the traceback Simon given that DirEntryType's dealloc
function is called. From the code, shouldn't we Py_INCREF DirEntryType before
PyModule_AddObject?
--
nosy: +xiang.zhang
___
Pyth
Xiang Zhang added the comment:
Try Simon's snippet I think I am right.
With the current code, the result is:
1..1
Segmentation fault (core dumped)
With Py_INCREF:
1..1
ok 1 - was able to loop 100 times
I upload the working patch.
--
keywords: +patch
Added file:
Xiang Zhang added the comment:
Maybe in the sentence, name should be named?
--
nosy: +xiang.zhang
___
Python tracker
<http://bugs.python.org/issue27753>
___
___
Changes by Xiang Zhang :
--
nosy: +xiang.zhang
___
Python tracker
<http://bugs.python.org/issue27414>
___
___
Python-bugs-list mailing list
Unsubscribe:
1101 - 1200 of 1760 matches
Mail list logo
