[issue29945] decode string:u"\ufffd" UnicodeEncodeError
New submission from webber:
I use python on linux, version is 2.7.13:
[root@localhost bin]# ./python2.7
Python 2.7.13 (default, Mar 30 2017, 00:54:08)
[GCC 4.4.7 20120313 (Red Hat 4.4.7-17)] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> a=u"\ufffd"
>>> a.decode("utf=8")
Traceback (most recent call last):
File "", line 1, in
File "/opt/python2.7.13/lib/python2.7/encodings/utf_8.py", line 16, in decode
return codecs.utf_8_decode(input, errors, True)
UnicodeEncodeError: 'ascii' codec can't encode character u'\ufffd' in position
0: ordinal not in range(128)
but,windows version run success!
--
components: Unicode
messages: 290834
nosy: ezio.melotti, foxscheduler, haypo
priority: normal
severity: normal
status: open
title: decode string:u"\ufffd" UnicodeEncodeError
versions: Python 2.7
___
Python tracker
<http://bugs.python.org/issue29945>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue29945] decode string:u"\ufffd" UnicodeEncodeError
Changes by webber : Added file: http://bugs.python.org/file46767/windows.jpg ___ Python tracker <http://bugs.python.org/issue29945> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46388] Improve test coverage of functools.total_ordering
New submission from Russel Webber : A few lines of the functools.total_ordering implementation are not covered by the tests. Specifically, coverage.py shows the returns of NotImplemented: ... if op_result is NotImplemented: return op_result ... as not covered in the functions: _gt_from_lt, _ge_from_le, _lt_from_le, _lt_from_gt, _le_from_ge and _gt_from_ge I have a PR for this. -- components: Tests messages: 410639 nosy: RusselWebber, rhettinger priority: normal severity: normal status: open title: Improve test coverage of functools.total_ordering type: enhancement versions: Python 3.11 ___ Python tracker <https://bugs.python.org/issue46388> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46388] Improve test coverage of functools.total_ordering
Change by Russel Webber : -- keywords: +patch pull_requests: +28819 stage: -> patch review pull_request: https://github.com/python/cpython/pull/30616 ___ Python tracker <https://bugs.python.org/issue46388> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46098] Missing test for multi-line errors in traceback
Russel Webber added the comment: I have added a test that I think covers this case. -- keywords: +patch message_count: 1.0 -> 2.0 nosy: +RusselWebber nosy_count: 3.0 -> 4.0 pull_requests: +28893 stage: -> patch review pull_request: https://github.com/python/cpython/pull/30695 ___ Python tracker <https://bugs.python.org/issue46098> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue31582] Add _pth breadcrumb to sys.path documentation
Russel Webber added the comment: I am happy to take a look at improving the documentation. I see the new getpath.py has very extensive commenting. Should I simply mention ._pth files as in the original issue from 5 years ago, or are you looking for documentation of how sys.path is initialised based on the comments in getpath.py? -- nosy: +RusselWebber ___ Python tracker <https://bugs.python.org/issue31582> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue31582] Add _pth breadcrumb to sys.path documentation
Russel Webber added the comment: I agree wholeheartedly, an explantation of sys.path initialisation would be very helpful. I've seen too many hacks in end user Python code due to misunderstandings around sys.path initialisation and the available ways to customise sys.path. I'll work on this, try to write an easy to follow explanantion and see where the other documentation needs to be amended to point to a new section. -- ___ Python tracker <https://bugs.python.org/issue31582> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue31582] Add _pth breadcrumb to sys.path documentation
Change by Russel Webber : -- keywords: +patch pull_requests: +29265 stage: needs patch -> patch review pull_request: https://github.com/python/cpython/pull/31082 ___ Python tracker <https://bugs.python.org/issue31582> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46828] math.prod can return integers (contradicts doc)
New submission from Neil Webber : The math module documentation says: Except when explicitly noted otherwise, all return values are floats. But this code returns an integer: from math import prod; prod((1,2,3)) Doc should "explicitly note otherwise" here, I imagine. The issue being wanting to know that the result on all-integer input will be an exact (integer) value not a floating value. -- assignee: docs@python components: Documentation messages: 413741 nosy: docs@python, neilwebber priority: normal severity: normal status: open title: math.prod can return integers (contradicts doc) type: behavior ___ Python tracker <https://bugs.python.org/issue46828> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46909] Update getpath.py to look for os.pyc in __pycache__ folders
New submission from Russel Webber :
The STDLIB_LANDMARKS in Modules/getpath,py refers to os.pyc in an old location:
STDLIB_LANDMARKS = [f'{STDLIB_SUBDIR}/os.py', f'{STDLIB_SUBDIR}/os.pyc']
Since https://www.python.org/dev/peps/pep-3147 the .pyc files are in
__pycache__ folders.
The STDLIB_LANDMARKS should be updated.
--
assignee: docs@python
components: Documentation, Extension Modules, Interpreter Core
messages: 414421
nosy: RusselWebber, docs@python, ned.deily, steve.dower
priority: normal
severity: normal
status: open
title: Update getpath.py to look for os.pyc in __pycache__ folders
type: behavior
versions: Python 3.11
___
Python tracker
<https://bugs.python.org/issue46909>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue18358] update links to Apple Style Guide
Russ Webber added the comment: So it is. Sorry, should have searched first. -- ___ Python tracker <http://bugs.python.org/issue18358> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue14182] collections.Counter equality test thrown-off by zero counts
Stephen Webber added the comment: This is intentional handling of non-existant variables, and is not resticted to '==' operations. Returning the value of a Counter parameter that has not yet been set returns 0 by default. See the documentation here: http://docs.python.org/library/collections.html "Counter objects have a dictionary interface except that they return a zero count for missing items instead of raising a KeyError:" Since this is intended behavior, I recommend this bug become closed. -- nosy: +ForeverBacchus ___ Python tracker <http://bugs.python.org/issue14182> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue14182] collections.Counter equality test thrown-off by zero counts
Stephen Webber added the comment:
Hmm, that is odd behavior indeed.
I think having keys that point to zero values is important for iterating over a
set. For example:
>>> x = Counter(a=10, b=0)
>>> for k in set(x):
... x[k] += 1
...
>>> x
Counter({'a': 11, 'b': 1})
is probably preferable to
>>> x = Counter(a=10, b=0)
>>> for k in set(x):
... x[k] += 1
...
>>> x
Counter({'a': 11})
Perhaps to ensure intuitive behavior we could ensure that
>>> Counter(a = 3) + Counter(b = 0) == Counter(a = 3, b = 0)
True
by aggregating all keys into the new Counter object, even those with zero
values? I would be happy to make such a patch, as it would be good experience
for me to learn. Would this be an acceptable solution, and is there other odd
behavior at work here?
--
___
Python tracker
<http://bugs.python.org/issue14182>
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
