Xiang Zhang added the comment:
It's server side behaviour. Asking here may not get results. I think it's
normal for the server to return error if it thinks the header is invalid.
--
___
Python tracker
<http://bugs.python.o
Xiang Zhang added the comment:
Hello Martin. I've finished a patch to add 64bit support to zlib. I think it
solves the 9 problems you mentioned and let the input and output both be larger
than UINT_MAX. Hope you are willing to review and we can move this forward. :)
--
key
Xiang Zhang added the comment:
Attach a patch to add this feature to Py3.6.
--
nosy: +xiang.zhang
Added file: http://bugs.python.org/file43396/issue27177.patch
___
Python tracker
<http://bugs.python.org/issue27
Changes by Xiang Zhang :
--
nosy: +xiang.zhang
___
Python tracker
<http://bugs.python.org/issue7769>
___
___
Python-bugs-list mailing list
Unsubscribe:
Xiang Zhang added the comment:
Hi, I've written a patch to accomplish this in Py3.6.
This patch is much cleaner but has one drawback, when used as decorator
factory, you have to specify name as a keyword argument. But considering the
codes that have to been imported to check argumen
Xiang Zhang added the comment:
I'm willing to and thanks for your work too :) I have replied to your comments
and adjusted my patch accordingly. But there are still several I am confused or
want to negotiate more.
I now upload the adjusted patch.
--
Added file:
Xiang Zhang added the comment:
Sorry, I suddenly find that I've misunderstood one of your comments. I changed
according then. Please use the new version.
--
Added file: http://bugs.python.org/file43408/64bit_support_for_zlib_v3.patch
___
P
Xiang Zhang added the comment:
Hmm, when I am going to delete the list in the docstring, I find other
functions get lists too in inspect.py. So maybe we should open another issue to
clean them after first merging this thread?
--
___
Python tracker
New submission from Xiang Zhang:
Here is a drawback in validate_step of rangeobject. PyNumber_AsSsize_t returns
clipped value and won't set an exception when the argument *exc* is set NULL.
So if step overflows, istep is always PY_SSIZE_MAX or PY_SSIZE_MIN. But the
following code is to
Changes by Xiang Zhang :
--
components: +Interpreter Core
type: -> behavior
versions: +Python 2.7, Python 3.5, Python 3.6
___
Python tracker
<http://bugs.python.org/issu
New submission from Xiang Zhang:
Some Py_XDECREFs in rangeobject.c and bltinmodule.c are not necessary.
Py_DECREF is enough. Clean up them.
--
files: cleanup_some_xdecrefs.patch
keywords: patch
messages: 268711
nosy: xiang.zhang
priority: normal
severity: normal
status: open
title
Xiang Zhang added the comment:
This looks fine. But maybe code like this looks more clear:
if (step && _PyLong_Sign(step) == 0) {
PyErr_SetString(PyExc_ValueError,
"range() arg 3 must not be zero");
Py_CLEAR(step);
}
I think assert(PyLong_Check(
Xiang Zhang added the comment:
Thanks for review. Eliminate the wrongs ones.
--
Added file: http://bugs.python.org/file43440/cleanup_some_xdecrefs_v2.patch
___
Python tracker
<http://bugs.python.org/issue27
Changes by Xiang Zhang :
--
nosy: +loewis, serhiy.storchaka
___
Python tracker
<http://bugs.python.org/issue7769>
___
___
Python-bugs-list mailing list
Unsub
Xiang Zhang added the comment:
Upload the new patch to fix bugs and make improvements. I'll add tests later.
--
Added file: http://bugs.python.org/file43450/64bit_support_for_zlib_v4.patch
___
Python tracker
<http://bugs.python.org/is
Changes by Xiang Zhang :
Added file: http://bugs.python.org/file43459/64bit_support_for_zlib_v4.patch
___
Python tracker
<http://bugs.python.org/issue27130>
___
___
Pytho
Changes by Xiang Zhang :
Removed file: http://bugs.python.org/file43450/64bit_support_for_zlib_v4.patch
___
Python tracker
<http://bugs.python.org/issue27130>
___
___
Xiang Zhang added the comment:
Attach patch to restore argument parsing support for __int__.
--
Added file: http://bugs.python.org/file43460/64bit_support_for_zlib_v5.patch
___
Python tracker
<http://bugs.python.org/issue27
Changes by Xiang Zhang :
Removed file: http://bugs.python.org/file43460/64bit_support_for_zlib_v5.patch
___
Python tracker
<http://bugs.python.org/issue27130>
___
___
Changes by Xiang Zhang :
Added file: http://bugs.python.org/file43461/64bit_support_for_zlib_v5.patch
___
Python tracker
<http://bugs.python.org/issue27130>
___
___
Pytho
Xiang Zhang added the comment:
The doc tells ConfigParser.read accepts a filename or a list of filenames. Why
do you pass it fileobject? If you want to use fileobject, why not read_file?
--
nosy: +lukasz.langa, xiang.zhang
___
Python tracker
<h
Xiang Zhang added the comment:
Upload the near-final patch. This one adds large buffer tests on 64bit
platforms. I have tested them on a server with enough memory.
I don't add the @support.requires_resource('cpu') since large memory tests are
born to be slow. And actually wh
Xiang Zhang added the comment:
ping
--
___
Python tracker
<http://bugs.python.org/issue26537>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.pyth
New submission from Xiang Zhang:
There is a redundant ')' in zipfile doc. Remove it.
--
assignee: docs@python
components: Documentation
files: zipfile_doc.patch
keywords: patch
messages: 269166
nosy: docs@python, xiang.zhang
priority: normal
severity: normal
status: open
titl
Xiang Zhang added the comment:
I think we can start from index 1 instead of 0.
--
nosy: +xiang.zhang
___
Python tracker
<http://bugs.python.org/issue22
Xiang Zhang added the comment:
In the mro list I think the first is always the type itself which has already
been checked to be a statically allocated type if we can touch the loop.
Starting from 0 checks it twice and it's not a base either.
BTW, I don't receive an email from t
Xiang Zhang added the comment:
Add the newest version applying Martin's comments.
--
Added file: http://bugs.python.org/file43538/64bit_support_for_zlib_v7.patch
___
Python tracker
<http://bugs.python.org/is
Xiang Zhang added the comment:
Of course, I know it. But doesn't the local variable `bases` refer to mro[1]?
[1] https://hg.python.org/cpython/file/tip/Objects/typeobject.c#l4900
--
___
Python tracker
<http://bugs.python.org/is
Xiang Zhang added the comment:
I thought that too at first. But if we use __bases__, can we still guarantee
that 'all bases of statically allocated type should be statically allocated'?
How about its grand bases? Is it possible that a statically allocated type
inherit a dynamic typ
Xiang Zhang added the comment:
Oh yes. The mro list can be customized so we can not even guarantee the type
appears at index 0 and object at index n-1. It seems we should still keep what
it is now, iterating the whole mro list.
Sorry that my previous comments seem to be noise. But maybe we
Xiang Zhang added the comment:
This is the v8 patch. It does two things:
[1] Apply Martin's comment about decompressobj.decompress so when user passes
in PY_SSIZE_T_MAX and there is enough memory, no error will be raised.
[2] Now decompressobj.flush can still work ev
Changes by Xiang Zhang :
Added file: http://bugs.python.org/file43563/64bit_support_for_zlib_v8.patch
___
Python tracker
<http://bugs.python.org/issue27130>
___
___
Pytho
Changes by Xiang Zhang :
Removed file: http://bugs.python.org/file43561/64bit_support_for_zlib_v8.patch
___
Python tracker
<http://bugs.python.org/issue27130>
___
___
Changes by Xiang Zhang :
Removed file: http://bugs.python.org/file43563/64bit_support_for_zlib_v8.patch
___
Python tracker
<http://bugs.python.org/issue27130>
___
___
Xiang Zhang added the comment:
Make v8 patch consistent with the latest changeset.
--
Added file: http://bugs.python.org/file43564/64bit_support_for_zlib_v8.patch
___
Python tracker
<http://bugs.python.org/issue27
Changes by Xiang Zhang :
Added file: http://bugs.python.org/file43565/64bit_support_for_zlib_v8.patch
___
Python tracker
<http://bugs.python.org/issue27130>
___
___
Pytho
Changes by Xiang Zhang :
Removed file: http://bugs.python.org/file43564/64bit_support_for_zlib_v8.patch
___
Python tracker
<http://bugs.python.org/issue27130>
___
___
Changes by Xiang Zhang :
--
nosy: +larry
___
Python tracker
<http://bugs.python.org/issue27401>
___
___
Python-bugs-list mailing list
Unsubscribe:
New submission from Xiang Zhang:
Usually when we access an object's __dict__, it will finally reach
subtype_dict[0]. When involving builtin base, it may delegates to the
base's __dict__ descriptor. In such a case, it is possible for the
__dict__ descriptor to initialize the dict
Changes by Xiang Zhang :
--
nosy: +ezio.melotti, pitrou, rhettinger
___
Python tracker
<http://bugs.python.org/issue27414>
___
___
Python-bugs-list mailin
Xiang Zhang added the comment:
I get the same feeling. Add Larry.
--
nosy: +larry
___
Python tracker
<http://bugs.python.org/issue26664>
___
___
Python-bugs-list m
Xiang Zhang added the comment:
Since the bug is fixed, we can also close issue26348.
--
___
Python tracker
<http://bugs.python.org/issue26664>
___
___
Python-bug
Changes by Xiang Zhang :
--
nosy: +xiang.zhang
___
Python tracker
<http://bugs.python.org/issue27429>
___
___
Python-bugs-list mailing list
Unsubscribe:
Xiang Zhang added the comment:
EVENT_* and KQ_FILTER_* are two different sets of constants. EVENT_* represent
event types of the abstract event and KQ_FILTER_* represent the kevent filter
type. EVENT_* can be combined while kevent.filter can only get one type.
--
nosy: +xiang.zhang
Xiang Zhang added the comment:
What I am saying is that EVENT_* (1, 2) are bit_masks while KQ_FILTER_* not
(-1, -2, -3, -4). So you should use |= with EVENT_* and == with KQ_FILTER_*. It
seems not a bug. :)
--
___
Python tracker
<h
Xiang Zhang added the comment:
But EVENT_* are. If you use =, events can only be either EVENT_READ or
EVENT_WRITE, not EVENT_READ & EVENT_WRITE. EVENT_* != KQ_FILTER_*.
--
___
Python tracker
<http://bugs.python.org/iss
Xiang Zhang added the comment:
Oh, sorry. My focus seem to be on the wrong place. I thought David is arguing
something about the constants are bitmasks or not. It's my fault. But actually
the current code looks very clearly and I can tell from it that EVENT_* are
bitmasks and KQ_FILTER_
Xiang Zhang added the comment:
I think this a bug. There should be no override when escape or unescape. Upload
a patch to fix this.
--
keywords: +patch
nosy: +martin.panter, serhiy.storchaka
Added file: http://bugs.python.org/file43616/issue27429.patch
Xiang Zhang added the comment:
I thought of that too. But the doc doesn't tell you that you can not put any
characters in the entities, so I think we should make the implementation right
when some unexpected characters are passed in. If you don't like the
implementation to be change
Xiang Zhang added the comment:
Put a not in escape's doc.
--
Added file: http://bugs.python.org/file43617/sax_escape_doc.patch
___
Python tracker
<http://bugs.python.org/is
Xiang Zhang added the comment:
Doesn't this the expected behaviour of shlex.quote, return a shell-escaped
version of the string s? If && is not quoted, how about "pwd && rm -rf ~"? I
think in your case there is no need to use shlex.quote.
Xiang Zhang added the comment:
ping
--
___
Python tracker
<http://bugs.python.org/issue7769>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.pyth
Xiang Zhang added the comment:
ping
--
___
Python tracker
<http://bugs.python.org/issue27248>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.pyth
Xiang Zhang added the comment:
ping
--
___
Python tracker
<http://bugs.python.org/issue26915>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.pyth
New submission from Xiang Zhang:
I suggest change `bytes` exception message when an iterable containing overflow
integers.
Right now, bytes([sys.maxsize+1]) emits ValueError: cannot fit 'int' into an
index-sized integer "ValueError: cannot fit 'int' into an index
Changes by Xiang Zhang :
--
type: -> enhancement
versions: +Python 3.6
___
Python tracker
<http://bugs.python.org/issue27460>
___
___
Python-bugs-list mai
Changes by Xiang Zhang :
Added file: http://bugs.python.org/file43643/bytes_exception_msg.patch
___
Python tracker
<http://bugs.python.org/issue27460>
___
___
Python-bug
Changes by Xiang Zhang :
Removed file: http://bugs.python.org/file43637/bytes_exception_msg.patch
___
Python tracker
<http://bugs.python.org/issue27460>
___
___
Python-bug
Xiang Zhang added the comment:
The constructor has been well tested in
https://hg.python.org/cpython/file/tip/Lib/test/test_bytes.py#l111. It looks
like that the original author only wants to guarantee the exception type but
not message. So I didn't add a assertRaisesRegex
Xiang Zhang added the comment:
>From the old comments from Brian it seems he's willing to accept such a
>feature. But unfortunately Brian seems not interested in this now. IMHO, this
>is good feature especially to people familiar with Bottle and Flask. Writing
>in a decorat
Xiang Zhang added the comment:
I think it's intentional. You can see issue20120.
--
nosy: +xiang.zhang
___
Python tracker
<http://bugs.python.org/is
Xiang Zhang added the comment:
Berker, what doc needs to be changed? Although RawConfigParser is legacy but
that does not mean it's deprecated, right? We can still use it although the doc
suggests us use ConfigParser.
--
___
Python tracker
Changes by Xiang Zhang :
--
type: -> behavior
versions: +Python 3.6
___
Python tracker
<http://bugs.python.org/issue27473>
___
___
Python-bugs-list mai
New submission from Xiang Zhang:
bytes_concat uses following code to check overflow:
size = va.len + vb.len;
if (size < 0): {
PyErr_NoMemory();
goto done;
}
This is wrong since signed ints overflow is undefined bahaviour.
But one point is that Python's Makefile defines -fwr
New submission from Xiang Zhang:
Now, `sys.maxsize+1 in b'foo'` raises "TypeError: 'int' does not support the
buffer interface" which seems weird. In such case, I don't think there is any
difference between sys.maxsize+1 and 256. So I suggest make it emits th
Xiang Zhang added the comment:
Attach a patch to fix this.
--
keywords: +patch
Added file: http://bugs.python.org/file43671/bytes_concat_overflow_check.patch
___
Python tracker
<http://bugs.python.org/issue27
Xiang Zhang added the comment:
Yes, the current code is valid with -fwrapv. But I am not sure if every
compiler supports this feature. So maybe we can't totally rely on it. And in
issue1621, some efforts seem to have worked to factor thes
Xiang Zhang added the comment:
Of course. I forgot to check bytearray. :(
The new patch now also includes bytearray.
--
Added file:
http://bugs.python.org/file43675/bytes_concat_overflow_check_v2.patch
___
Python tracker
<http://bugs.python.
Xiang Zhang added the comment:
Sorry. v3 now includes iconcat.
--
Added file:
http://bugs.python.org/file43676/bytes_concat_overflow_check_v3.patch
___
Python tracker
<http://bugs.python.org/issue27
Xiang Zhang added the comment:
Left a comment.
--
___
Python tracker
<http://bugs.python.org/issue27473>
___
___
Python-bugs-list mailing list
Unsubscribe:
Xiang Zhang added the comment:
Does this need to be backport to py2.7? It suffers from the same problem.
--
___
Python tracker
<http://bugs.python.org/issue26
New submission from Xiang Zhang:
Errors regarding "embedded NUL character" were changed from TypeError to
ValueError, in r92365, issue22215, but the doc doesn't get updated. Add a patch
to apply the change in doc.
--
assignee: docs@python
components: Docu
Xiang Zhang added the comment:
Just for a note, there has already been an issue26401 fixing the function.rst.
Upload a new patch adding versionchanged tag.
--
Added file: http://bugs.python.org/file43686/null_characters_doc_v2.patch
___
Python
Xiang Zhang added the comment:
Yes. I noticed the change but didn't change it. Now add it.
--
Added file: http://bugs.python.org/file43689/null_characters_doc_v3.patch
___
Python tracker
<http://bugs.python.org/is
Xiang Zhang added the comment:
Sorry, I didn't notice the difference.
--
Added file: http://bugs.python.org/file43690/null_characters_doc_v4.patch
___
Python tracker
<http://bugs.python.org/is
New submission from Xiang Zhang:
Right now bytearray_repr's implementation mimics old string_repr, but it has a
drawback: It arbitrarily checks overflow using four times the bytearray
object's length, but the representation length of the value can range from 1 to
4. I think
Xiang Zhang added the comment:
I considered that too. But I was not sure what code could go into
bytes_methods.c then, Python level methods, all common parts or only
tp->methods? I'll try to factor the common part out later.
--
___
Python
Xiang Zhang added the comment:
Hi, Serhiy. I've tried one version factoring the common parts out. I make them
one function but it seems not very elegant. I also think about passing the
object and use it to get the type and then determine how to get the string,
what the pre/postfix are
New submission from Xiang Zhang:
Write a patch to make bytes/bytearray.translate's delete argument support
acting as keyword arguments. This won't break any backwards compatibility and
make the method more flexible to use. Besides, in the C code level, it stops
using argument clini
Xiang Zhang added the comment:
Hmm, David, that may be not quite right. Users only reading the doc never know
it's deletechars not delete. The doc is always delete, though conflicting with
__doc__.
>>> print(bytes.translate.__doc__)
B.translate(table[, deletechars]) -
Xiang Zhang added the comment:
Please review the new version. It makes two changes comparing with the last one.
1. It exposes Python parameter as "delete" (which the document always uses so I
think it's the API) while still use "deletechars" (which I prefer as a C
var
New submission from Xiang Zhang:
As the title, bytearray.extend simply use `buf_size = len + (len >> 1) + 1;` to
determine next *buf_size* when increasing buffer. But this can overflow in
theory. So I suggest adding overflow check.
--
components: Interpreter Core
Xiang Zhang added the comment:
Ohh, sorry for the disturb. I made a mistake. This is not needed and now close
it.
--
resolution: -> not a bug
status: open -> closed
___
Python tracker
<http://bugs.python.org/i
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
901 - 1000 of 1629 matches
Mail list logo
