Changes by Nitish <nitishchandrachi...@gmail.com>:
--
nosy: +nitishch
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/issue30664>
___
_
Nitish <nitishchandrachi...@gmail.com> added the comment:
Try 'tar xvf test.tar'. On Linux machine at least, it is in fact producing a
tree of directories. Not a single file. So - in a way what Python is reporting
is correct.
--
___
Python t
Change by Nitish <nitishchandrachi...@gmail.com>:
--
nosy: +nitishch
___
Python tracker <rep...@bugs.python.org>
<https://bugs.python.org/issue31780>
___
_
New submission from Nitish <nitishchandrachi...@gmail.com>:
Ellipsis object documentation[1] specifies that Ellipsis is mainly used by
Slicings. But Slicing's documentation[2] doesn't mention anything about
Ellipsis. Consequently - it is not immediately clear from Ellipsis
documentatio
Change by Nitish <nitishchandrachi...@gmail.com>:
--
nosy: +nitishch
___
Python tracker <rep...@bugs.python.org>
<https://bugs.python.org/issue31774>
___
_
Nitish <nitishchandrachi...@gmail.com> added the comment:
Sorry. My bad. There *is* an argument 'copybufsize' in TarFile.
--
___
Python tracker <rep...@bugs.python.org>
<https://bugs.python
Nitish <nitishchandrachi...@gmail.com> added the comment:
Seems like bufsize is used only in streaming modes. Even in the documentation
bufsize is described only in the context of streaming modes.
Even TarFile constructor doesn't take bufsize as an argument. Why is
Nitish <nitishchandrachi...@gmail.com> added the comment:
The problem is that while documentation for other objects like Null object,
NotImplemented object make it clear what they are used for, documentation for
Ellipsis object only says that it's used in slicings and the sl
Change by Nitish <nitishchandrachi...@gmail.com>:
--
keywords: +patch
pull_requests: +3800
stage: -> patch review
___
Python tracker <rep...@bugs.python.org>
<https://bugs.pyt
Nitish <nitishchandrachi...@gmail.com> added the comment:
The problem is with the following check:
n = digits * bits_per_char + PyLong_SHIFT - 1;
if (n / bits_per_char < p - start) {
PyErr_SetString(PyExc_ValueError,
"int string too la
Nitish <nitishchandrachi...@gmail.com> added the comment:
> This check was the source of a bug that caused tarfile to report a regular as
> a directory because the file path was extra long, and when the tar write
> truncated the path to the first 100B, it so happened to end on
Nitish <nitishchandrachi...@gmail.com> added the comment:
> PR 3816 fixes the symptom, but not the core issue -- an overflow check
> depending on undefined behaviour.
I don't understand this check completely actually. When exactly is an int too
larg
Nitish <nitishchandrachi...@gmail.com> added the comment:
>> PR 3816 fixes the symptom, but not the core issue -- an overflow check
>> depending on undefined behaviour.
> I don't understand this check completely actually. When exactly is an int too
> large to co
Change by Nitish <nitis...@protonmail.com>:
--
nosy: +nitishch
___
Python tracker <rep...@bugs.python.org>
<https://bugs.python.org/issue17852>
___
__
Change by Nitish <nitis...@protonmail.com>:
--
keywords: +patch
pull_requests: +4747
stage: -> patch review
___
Python tracker <rep...@bugs.python.org>
<https://bugs.pyt
Change by Nitish <nitishchandrachi...@gmail.com>:
--
keywords: +patch
pull_requests: +4326
stage: needs patch -> patch review
___
Python tracker <rep...@bugs.python.org>
<https://bugs.pyt
Change by Nitish <nitishchandrachi...@gmail.com>:
--
keywords: +patch
pull_requests: +4239
stage: needs patch -> patch review
___
Python tracker <rep...@bugs.python.org>
<https://bugs.pyt
Change by Nitish <nitishchandrachi...@gmail.com>:
--
nosy: +nitishch
___
Python tracker <rep...@bugs.python.org>
<https://bugs.python.org/issue31942>
___
_
Nitish <nitishchandrachi...@gmail.com> added the comment:
Any comments on the PR?
--
___
Python tracker <rep...@bugs.python.org>
<https://bugs.python
Nitish <nitishchandrachi...@gmail.com> added the comment:
Any comments on the PR?
--
nosy: +nitishch
___
Python tracker <rep...@bugs.python.org>
<https://bugs.python
Change by Nitish <nitishchandrachi...@gmail.com>:
--
keywords: +patch
pull_requests: +4659
stage: -> patch review
___
Python tracker <rep...@bugs.python.org>
<https://bugs.pyt
Change by Nitish <nitishchandrachi...@gmail.com>:
--
nosy: +nitishch
___
Python tracker <rep...@bugs.python.org>
<https://bugs.python.org/issue22589>
___
_
Change by Nitish <nitis...@protonmail.com>:
--
nosy: +nitishch
___
Python tracker <rep...@bugs.python.org>
<https://bugs.python.org/issue32255>
___
__
Change by Nitish <nitis...@protonmail.com>:
--
nosy: +nitishch
___
Python tracker <rep...@bugs.python.org>
<https://bugs.python.org/issue26414>
___
__
Change by Nitish <nitis...@protonmail.com>:
--
nosy: +nitishch
___
Python tracker <rep...@bugs.python.org>
<https://bugs.python.org/issue30718>
___
__
Change by Nitish <nitis...@protonmail.com>:
--
nosy: +nitishch
___
Python tracker <rep...@bugs.python.org>
<https://bugs.python.org/issue32228>
___
__
Change by Nitish <nitis...@protonmail.com>:
--
nosy: +nitishch
___
Python tracker <rep...@bugs.python.org>
<https://bugs.python.org/issue32270>
___
__
Nitish <nitis...@protonmail.com> added the comment:
Which scenario you think is the wrong behaviour in this case? First one or
second one?
I don't know much about csv module, but I thought it was a deliberate choice
made to quote all empty lines and hence considered the second sc
Nitish <nitis...@protonmail.com> added the comment:
What is six.reraise in except block?
--
nosy: +nitishch
___
Python tracker <rep...@bugs.python.org>
<https://bugs.python
Change by Nitish <nitis...@protonmail.com>:
--
nosy: +nitishch
___
Python tracker <rep...@bugs.python.org>
<https://bugs.python.org/issue32511>
___
__
Change by Nitish <nitis...@protonmail.com>:
--
nosy: +nitishch
___
Python tracker <rep...@bugs.python.org>
<https://bugs.python.org/issue31368>
___
__
Change by Nitish <nitis...@protonmail.com>:
--
nosy: +nitishch
___
Python tracker <rep...@bugs.python.org>
<https://bugs.python.org/issue32536>
___
__
Nitish <nitis...@protonmail.com> added the comment:
It appears some files like Lib/tokenize.py changes the mode of TextIOWrapper:
text = TextIOWrapper(buffer, encoding, line_buffering=True)
text.mode = 'r'
setting of mode via _PyObject_SetAttrId(wrapper, _mode, modeobj) i
Nitish <nitis...@protonmail.com> added the comment:
This seems to have been fixed in the latest master.
Commit I tested: 37420deb80dcf0fc41a728838b0340b93ca01d90
--
nosy: +nitishch
___
Python tracker <rep...@bugs.python.org>
<https://
Change by Nitish <nitis...@protonmail.com>:
--
nosy: +nitishch
___
Python tracker <rep...@bugs.python.org>
<https://bugs.python.org/issue19915>
___
__
Change by Nitish <nitis...@protonmail.com>:
--
nosy: +nitishch
___
Python tracker <rep...@bugs.python.org>
<https://bugs.python.org/issue29317>
___
__
Nitish <nitis...@protonmail.com> added the comment:
> For the right offset, I think we'll want to drop the initial XStrip call
> added for bpo-32028 entirely, and instead calculate the right offset as a
> PyUnicode_FindChar search for ";" (replacing it with the leng
Nitish <nitis...@protonmail.com> added the comment:
RFC 5322[1] says that header field's name can't have space in it and the must
be immediately followed by the ':' character.
Is it common for SMTP servers to accept messages with ' ' before ':'?
[1] https://tools.ietf.org/html/r
Change by Nitish <nitis...@protonmail.com>:
--
keywords: +patch
pull_requests: +5216
stage: needs patch -> patch review
___
Python tracker <rep...@bugs.python.org>
<https://bugs.pyt
Change by Nitish <nitis...@protonmail.com>:
--
nosy: +nitishch
___
Python tracker <rep...@bugs.python.org>
<https://bugs.python.org/issue20082>
___
__
Change by Nitish <nitis...@protonmail.com>:
--
nosy: +nitishch
___
Python tracker <rep...@bugs.python.org>
<https://bugs.python.org/issue32806>
___
__
Change by Nitish <nitis...@protonmail.com>:
--
nosy: +nitishch
___
Python tracker <rep...@bugs.python.org>
<https://bugs.python.org/issue32755>
___
__
Nitish <nitis...@protonmail.com> added the comment:
This can be traced back to the following issue:
>>> c = compile("(lambda: re.findall('a', 'aaa'))()", "", "single")
>>> import re as rea
>>> exec(c, None, {'re': rea})
NameError
Nitish <nitis...@protonmail.com> added the comment:
Sorry. I didn't finish my last message. Is the behaviour described in that
message a bug? If yes, that would explain the original behaviour. If no, why
not?
--
___
Python tracke
Change by Nitish <nitis...@protonmail.com>:
--
nosy: +nitishch
___
Python tracker <rep...@bugs.python.org>
<https://bugs.python.org/issue32836>
___
__
Change by Nitish <nitis...@protonmail.com>:
--
nosy: +nitishch
___
Python tracker <rep...@bugs.python.org>
<https://bugs.python.org/issue32489>
___
__
Change by Nitish <nitis...@protonmail.com>:
--
keywords: +patch
pull_requests: +5476
stage: -> patch review
___
Python tracker <rep...@bugs.python.org>
<https://bugs.pyt
Change by Nitish <nitis...@protonmail.com>:
--
nosy: +nitishch
___
Python tracker <rep...@bugs.python.org>
<https://bugs.python.org/issue32391>
___
__
Nitish <nitis...@protonmail.com> added the comment:
What should happen ideally? The stray '\r' be treated like a whitespace?
--
___
Python tracker <rep...@bugs.python.org>
<https://bugs.python
Change by Nitish <nitis...@protonmail.com>:
--
nosy: +nitishch
___
Python tracker <rep...@bugs.python.org>
<https://bugs.python.org/issue33222>
___
__
Change by Nitish <nitis...@protonmail.com>:
--
nosy: +nitishch
___
Python tracker <rep...@bugs.python.org>
<https://bugs.python.org/issue33211>
___
__
Change by Nitish <nitis...@protonmail.com>:
--
nosy: +nitishch
___
Python tracker <rep...@bugs.python.org>
<https://bugs.python.org/issue33223>
___
__
Change by Nitish <nitis...@protonmail.com>:
--
nosy: +nitishch
___
Python tracker <rep...@bugs.python.org>
<https://bugs.python.org/issue25433>
___
__
Nitish <nitis...@protonmail.com> added the comment:
@Antony Lee since you know the fix, do you want to submit a PR?
--
nosy: +nitishch
___
Python tracker <rep...@bugs.python.org>
<https://bugs.python
Change by Nitish <nitis...@protonmail.com>:
--
nosy: +nitishch
___
Python tracker <rep...@bugs.python.org>
<https://bugs.python.org/issue33162>
___
__
Nitish <nitis...@protonmail.com> added the comment:
Also, _ParameterKind class has a __str__ method. So, I guess it's better to use
"{!s}" in the format string instead of using kind.name.
--
___
Python tracker <rep...@bugs
Nitish <nitis...@protonmail.com> added the comment:
@Ethan Furman how can Flag do that? IntFlag can deal with int values too. Would
it be possible to deal with int values in this case in Flag.__contains__?
--
nosy: +nitishch
___
Python tracke
Change by Nitish :
--
nosy: +nitishch
___
Python tracker
<https://bugs.python.org/issue36697>
___
___
Python-bugs-list mailing list
Unsubscribe:
Nitish Sharma added the comment:
Yeah, are you talking about this PR?
https://github.com/python/cpython/pull/28254
--
nosy: +nitss007
___
Python tracker
<https://bugs.python.org/issue45
59 matches
Mail list logo
