[issue42461] os.statvfs_result doesn't show f_fsid
New submission from hao <359062...@qq.com>: >From doc I see about os.statvfs "New in version 3.7: Added f_fsid.", but it >doesn't show up when print an object os.statvfs returned. So I think maybe we >can add the field when printing object. -- components: Library (Lib) messages: 381811 nosy: Rethan priority: normal severity: normal status: open title: os.statvfs_result doesn't show f_fsid type: behavior versions: Python 3.10 ___ Python tracker <https://bugs.python.org/issue42461> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue42461] os.statvfs_result doesn't show f_fsid
Change by hao <359062...@qq.com>: -- keywords: +patch pull_requests: +22397 stage: -> patch review pull_request: https://github.com/python/cpython/pull/23511 ___ Python tracker <https://bugs.python.org/issue42461> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue43581] array assignment error
New submission from Wen Hao : >>>mat = [[0]*4]*4 >>> mat [[0, 0, 0, 0], [0, 0, 0, 0], [0, 0, 0, 0], [0, 0, 0, 0]] >>> mat[1][2]=1 >>> mat [[0, 0, 1, 0], [0, 0, 1, 0], [0, 0, 1, 0], [0, 0, 1, 0]] -- components: Build messages: 389230 nosy: haowenqi.zz priority: normal severity: normal status: open title: array assignment error type: behavior versions: Python 3.8 ___ Python tracker <https://bugs.python.org/issue43581> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue39594] Typo in documentation for os.times
New submission from Chenyoo Hao : 1.Formatting error due to an extra space (After the MSDN link). 2.There are extra words. Original： See the Unix manual page :manpage:`times(2)` and :manpage:`times(3)` manual page on Unix or `the GetProcessTimes MSDN <https://docs.microsoft.com/windows/win32/api/processthreadsapi/nf-processthreadsapi-getprocesstimes>` _ on Windows. On Windows, only :attr:`user` and :attr:`system` are known; the other attributes are zero. After modification： See the manual page :manpage:`times(2)` and :manpage:`times(3)` on Unix or the `GetProcessTimes MSDN <https://docs.microsoft.com/windows/win32/api/processthreadsapi/nf-processthreadsapi-getprocesstimes>`_ on Windows. On Windows, only :attr:`user` and :attr:`system` are known; the other attributes are zero. -- assignee: docs@python components: Documentation messages: 361659 nosy: Chenyoo Hao, docs@python priority: normal severity: normal status: open title: Typo in documentation for os.times type: enhancement versions: Python 3.8 ___ Python tracker <https://bugs.python.org/issue39594> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue40773] DOC: Fix rendering for 'retval' on the pdb page
Change by Chenyoo Hao : -- keywords: +patch nosy: +Chenyoo Hao nosy_count: 3.0 -> 4.0 pull_requests: +20232 stage: needs patch -> patch review pull_request: https://github.com/python/cpython/pull/21055 ___ Python tracker <https://bugs.python.org/issue40773> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue40773] DOC: Fix rendering for 'retval' on the pdb page
Change by Chenyoo Hao : -- pull_requests: +20246 pull_request: https://github.com/python/cpython/pull/21080 ___ Python tracker <https://bugs.python.org/issue40773> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue40773] DOC: Fix rendering for 'retval' on the pdb page
Change by Chenyoo Hao : -- pull_requests: +20247 pull_request: https://github.com/python/cpython/pull/21081 ___ Python tracker <https://bugs.python.org/issue40773> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue26250] no document for sqlite3.Cursor.connection
New submission from hao Qing: it does have the Cursor.connection member in the pydoc result. $ pydoc sqlite3.Cursor.connection Help on member descriptor sqlite3.Cursor.connection in sqlite3.Cursor: sqlite3.Cursor.connection lines 1-3/3 (END) but there is no document about sqlite3.Cursor.connection at here. https://docs.python.org/2/library/sqlite3.html#sqlite3.Cursor and so to version 3 https://docs.python.org/3/library/sqlite3.html#sqlite3.Cursor -- components: Library (Lib) messages: 259292 nosy: hao Qing priority: normal severity: normal status: open title: no document for sqlite3.Cursor.connection type: enhancement versions: Python 2.7 ___ Python tracker <http://bugs.python.org/issue26250> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue24251] Different behavior for argparse between 2.7.8 and 2.7.9 when adding the same arguments to the root and the sub commands
New submission from Hao Huang:
When I was trying to add the same argument to both the root command and the sub
command and you put the arguments before the subcommand, In 2.7.8 the arguments
would be parsed correctly. But in 2.7.9, they wouldn't but these arguments
would show up in the help doc:(
For python2.7.8
~$ python2.7
Python 2.7.8 (default, Oct 29 2014, 13:45:48)
[GCC 4.2.1 (Apple Inc. build 5666) (dot 3)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> import argparse
>>>
>>> parser = argparse.ArgumentParser()
>>> parser.add_argument("-s", dest="start")
_StoreAction(option_strings=['-s'], dest='start', nargs=None, const=None,
default=None, type=None, choices=None, help=None, metavar=None)
>>>
>>> subparsers = parser.add_subparsers()
>>> subparser = subparsers.add_parser("command")
>>> subparser.add_argument("-s", dest="start")
_StoreAction(option_strings=['-s'], dest='start', nargs=None, const=None,
default=None, type=None, choices=None, help=None, metavar=None)
>>>
>>> parser.parse_args(["-s", "1", "command"])
Namespace(start='1')
>>> parser.parse_args(["command", "-s", "1"])
Namespace(start='1')
For python 2.7.9
~$ python2.7
Python 2.7.9 (default, Apr 2 2015, 15:33:21)
[GCC 4.9.2] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> import argparse
>>> parser = argparse.ArgumentParser()
>>> parser.add_argument("-s", dest="start")
_StoreAction(option_strings=['-s'], dest='start', nargs=None, const=None,
default=None, type=None, choices=None, help=None, metavar=None)
>>>
>>> subparsers = parser.add_subparsers()
>>> subparser = subparsers.add_parser("command")
>>> subparser.add_argument("-s", dest="start")
_StoreAction(option_strings=['-s'], dest='start', nargs=None, const=None,
default=None, type=None, choices=None, help=None, metavar=None)
>>>
>>> parser.parse_args(["-s", "1", "command"])
Namespace(start=None)
>>> parser.parse_args(["command", "-s", "1"])
Namespace(start='1')
--
components: Argument Clinic
messages: 243700
nosy: hhuang, larry
priority: normal
severity: normal
status: open
title: Different behavior for argparse between 2.7.8 and 2.7.9 when adding the
same arguments to the root and the sub commands
type: behavior
versions: Python 2.7
___
Python tracker
<http://bugs.python.org/issue24251>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue24251] Different behavior for argparse between 2.7.8 and 2.7.9 when adding the same arguments to the root and the sub commands
Hao Huang added the comment: I think this patch cause the difference: https://hg.python.org/cpython/rev/1a3143752db2 -- ___ Python tracker <http://bugs.python.org/issue24251> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12892] UTF-16 and UTF-32 codecs should reject (lone) surrogates
Kang-Hao (Kenny) Lu added the comment:
Attached patch does the following beyond what the patch from haypo does:
* call the error handler
* reject 0xd800~0xdfff when decoding utf-32
The followings are on my TODO list, although this patch doesn't depend on any
of these and can be reviewed and landed separately:
* make the surrogatepass error handler work for utf-16 and utf-32. (I should
be able to finish this by today)
* fix an error in the error handler for utf-16-le. (In, Python3.2
b'\xdc\x80\x00\x41'.decode('utf-16-be', 'ignore') returns "\x00" instead of "A"
for some reason)
* make unicode_encode_call_errorhandler return bytes so that we can simplify
this patch. (This arguably belongs to a separate bug so I'll file it when
needed)
> All UTF codecs should reject lone surrogates in strict error mode,
Should we really reject lone surrogates for UTF-7? There's a test in
test_codecs.py that tests "\udc80" to be encoded b"+3IA-" (. Given that UTF-7
is not really part of the Unicode Standard and it is more like a "data
encoding" than a "text encoding" to me, I am not sure it's a good idea.
> but let them pass using the surrogatepass error handler (the UTF-8
> codec already does) and apply the usual error handling for ignore
> and replace.
For 'replace', the patch now emits b"\x00?" instead of b"?" so that UTF-16
stream doesn't get corrupted. It is not "usual" and not matching
# Implements the ``replace`` error handling: malformed data is replaced
# with a suitable replacement character such as ``'?'`` in bytestrings
# and ``'\ufffd'`` in Unicode strings.
in the documentation. What do we do? Are there other encodings that are not
ASCII compatible besides UTF-7, UTF-16 and UTF-32 that Python supports? I think
it would be better to use encoded U+fffd whenever possible and fall back to
'?'. What do you think?
Some other self comments on my patch:
* In the STORECHAR macro for utf-16 and utf-32, I change all instances of "ch
& 0xFF" to (unsigned char) ch. I don't have enough C knowledge to know if this
is actually better or if this makes any difference at all.
* The code for utf-16 and utf-32 are duplicates of the uft-8 one. That one's
complexity comes from issue #8092 . Not sure if there are ways to simplify
these. For example, are there suitable functions there so that we don't need to
check integer overflow at these places?
--
nosy: +kennyluck
Added file: http://bugs.python.org/file24368/utf-16&32_reject_surrogates.patch
___
Python tracker
<http://bugs.python.org/issue12892>
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue7856] cannot decode from or encode to big5 \xf9\xd8
Changes by Kang-Hao (Kenny) Lu : -- nosy: +kennyluck ___ Python tracker <http://bugs.python.org/issue7856> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13913] utf-8 or utf8 or utf-8 (codec display name inconsistency)
New submission from Kang-Hao (Kenny) Lu :
Since Python 3.2.2 (I don't have earlier version to test with),
>>> "\udc80".encode("utf-8")
UnicodeEncodeError: *utf-8* codec can't encode character '\udc80'...
but
>>> b"\xff".decode("utf-8")
UnicodeDecodeError: *utf8* codec can't decode byte 0xff in position 0
and the table on the documentation of the codec module suggests *utf_8* as the
name of the codec, which I believe to be equivalent to "utf_8" because '-' is
not a valid character of an identifier.
Can we at least make the above two consistent? I would go for "utf-8", which
was probably introduced for rejecting surrogates, but "utf8" has been there for
years. What do we do? I am happy to submit patches for all branches. These are
one-liners anyway.
The backward compatibility risk should be pretty low as usually you don't get
encoding from these errors and I don't see any use of
PyUnicode(Encode|Decode)Error_GetEncoding in trunk, although I'm using it for
issue #12892.
Also, "latin_1" displays as *latin-1* but "iso2022-jp" displays as
*iso2022_jp*. I care less about this nit though.
--
components: Unicode
messages: 152399
nosy: ezio.melotti, kennyluck
priority: normal
severity: normal
status: open
title: utf-8 or utf8 or utf-8 (codec display name inconsistency)
versions: Python 2.7, Python 3.2, Python 3.3
___
Python tracker
<http://bugs.python.org/issue13913>
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13913] utf-8 or utf8 or utf-8 (codec display name inconsistency)
Changes by Kang-Hao (Kenny) Lu : -- type: -> behavior ___ Python tracker <http://bugs.python.org/issue13913> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13916] disallow the "surrogatepass" handler for non utf-* encodings
New submission from Kang-Hao (Kenny) Lu :
Currently the "surrogatepass" handler always encodes the surrogates in UTF-8
and hence the behavior for, say, "\udc80".encode("latin-1",
"surrogatepass").decode("latin-1") might be unexpected and I don't even know
what would, say, "\udc80\udc80".encode("big5", "surrogatepass").decode("big5"),
return. Regardless of the fact that the documentation says "surrogatepass" is
specific to utf-8", the currently behavior is arguably not too harmful thanks
to PyBytesObject's '\0' ending (so that ((p[0] & 0xf0) == 0xe0 || (p[1] & 0xc0)
== 0x80 || (p[2] & 0xc0) == 0x80) in PyCodec_SurrogatePassErrors would not
crash).
However, I suggest we have the system either 1) raise early LookupError 2)
raise the original Unicode(Decode|Encoding)Exception as soon as
PyCodec_SurrogatePassErrors is called. I prefer the former.
Having this could shorten PyCodec_SurrogatePassErrors significantly in the
patch I will shortly submit for issue #12892 as all the error conditions for
utf-8, utf-16 and utf-32 are predicable* and almost all the conditionals could
be removed. (The * statement is arguable if someone initializes
interp->codec_search_path before _PyCodecRegistry_Init and the utf-16/32
encoders are overwritten. I don't think we need to worry about this too much
though. Or am I wrong here?)
--
components: Unicode
messages: 152416
nosy: ezio.melotti, kennyluck
priority: normal
severity: normal
status: open
title: disallow the "surrogatepass" handler for non utf-* encodings
type: behavior
versions: Python 3.1, Python 3.2, Python 3.3
___
Python tracker
<http://bugs.python.org/issue13916>
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12892] UTF-16 and UTF-32 codecs should reject (lone) surrogates
Kang-Hao (Kenny) Lu added the comment:
> The followings are on my TODO list, although this patch doesn't depend
> on any of these and can be reviewed and landed separately:
> * make the surrogatepass error handler work for utf-16 and utf-32. (I
>should be able to finish this by today)
Unfortunately this took longer than I thought but here comes the patch.
>> * fix an error in the error handler for utf-16-le. (In, Python3.2
>> b'\xdc\x80\x00\x41'.decode('utf-16-be', 'ignore') returns "\x00"
>> instead of "A" for some reason)
>
> This should probably be done on a separate patch that will be applied
> to 3.2/3.3 (assuming that it can go to 3.2). Rejecting surrogates will
> go in 3.3 only. (Note that lot of Unicode-related code changed between
> 3.2 and 3.3.)
This turns out to be just two liners so I fixed that on the way. I can create
separate patch with separate test for 3.2 (certainly doable) and even for 3.3,
but since the test is now part of test_lone_surrogates, I feel less willing to
do that for 3.3.
You might notice the codec naming inconsistency (utf-16-be and utf16be for
encoding and decoding respectively). I have filed issue #13913 for this.
Also, the strcmps are quite crappy. I am working on issue #13916 (disallow the
"surrogatepass" handler for non utf-* encodings). As long as we have that we
can examine individual character instead...
In this patch, The "encoding" attribute for UnicodeDecodeException is now
changed to return utf16(be|le) for utf-16. This is necessary info for
"surrogatepass" to work although admittedly this is rather ugly. Any good idea?
A new attribute for Unicode(Decode|Encode)Exception might be helpful but
utf-16/32 are fairly uncommon encodings anyway and we should not add more
burden for, say, utf-8.
>> Should we really reject lone surrogates for UTF-7?
>
> No, I meant only UTF-8/16/32; UTF-7 is fine as is.
Good to know.
--
Added file: http://bugs.python.org/file24384/surrogatepass_for_utf-16&32.patch
___
Python tracker
<http://bugs.python.org/issue12892>
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13913] utf-8 or utf8 or utf-8 (codec display name inconsistency)
Kang-Hao (Kenny) Lu added the comment: > and the table on the documentation of the codec module suggests *utf_8* > as the name of the codec, which I believe to be equivalent to "utf_8" > because '-' is not a valid character of an identifier. typo: equivalent to "utf_8" → equivalent to "utf-8". -- ___ Python tracker <http://bugs.python.org/issue13913> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12100] Incremental encoders of CJK codecs reset the codec at each call to encode()
Changes by Kang-Hao (Kenny) Lu : -- nosy: +kennyluck ___ Python tracker <http://bugs.python.org/issue12100> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
