Mailman 3 June 2018 - docs

[issue33934] locale.getlocale() seems wrong when the locale is yet unset (python3 on linux)
by STINNER Victor June 25, 2018

June 25, 2018

STINNER Victor <vstinner(a)redhat.com> added the comment: When testing this issue, I found a bug in Python :-( I opened bpo-33954: float.__format__('n') fails with _PyUnicode_CheckConsistency assertion error. ---------- _______________________________________ Python tracker <report(a)bugs.python.org> <https://bugs.python.org/issue33934> _______________________________________

1 0

[issue33934] locale.getlocale() seems wrong when the locale is yet unset (python3 on linux)
by Nicolas Hainaux June 25, 2018

June 25, 2018

Nicolas Hainaux <nh.techn(a)gmail.com> added the comment: I understand that the statement "when python starts, it runs using the C locale..." should not be correct anymore (and the doc should then be updated), but in fact this statement is still true on the systems I tested; only, the output of locale.getlocale() at start is in contradiction with the locale really set in fact. It looks like the setting done by setlocale(LC_ALL, "") at an early stage is lost at some point (only locale.getlocale() seems to "remember" it). For instance, my box locale is 'fr_FR.UTF-8', so the decimal point is a comma, but when starting python 3.7: >>> import locale >>> locale.str(2.4) '2.4' # Wrong: if the locale in use is 'fr_FR.UTF-8', then '2,4' is expected instead >>> locale.getlocale() ('fr_FR', 'UTF-8') >>> locale.localeconv() {'int_curr_symbol': '', 'currency_symbol': '', 'mon_decimal_point': '', 'mon_thousands_sep': '', 'mon_grouping': [], 'positive_sign': '', 'negative_sign': '', 'int_frac_digits': 127, 'frac_digits': 127, 'p_cs_precedes': 127, 'p_sep_by_space': 127, 'n_cs_precedes': 127, 'n_sep_by_space': 127, 'p_sign_posn': 127, 'n_sign_posn': 127, 'decimal_point': '.', 'thousands_sep': '', 'grouping': []} >>> Note that the output of localeconv() does match C locale, not 'fr_FR.UTF-8'. Compare this with the outputs of locale.str() and locale.localeconv() when the locale is explicitly set at start: >>> import locale >>> locale.setlocale(locale.LC_ALL, '') 'LC_CTYPE=fr_FR.utf8;LC_NUMERIC=fr_FR.UTF-8;LC_TIME=fr_FR.UTF-8;LC_COLLATE=fr_FR.utf8;LC_MONETARY=fr_FR.UTF-8;LC_MESSAGES=fr_FR.utf8;LC_PAPER=fr_FR.UTF-8;LC_NAME=fr_FR.UTF-8;LC_ADDRESS=fr_FR.UTF-8;LC_TELEPHONE=fr_FR.UTF-8;LC_MEASUREMENT=fr_FR.UTF-8;LC_IDENTIFICATION=fr_FR.UTF-8' >>> locale.str(2.4) '2,4' # Correct! >>> locale.localeconv() # Output of localeconv() does match 'fr_FR.UTF-8' locale {'int_curr_symbol': 'EUR ', 'currency_symbol': '€', 'mon_decimal_point': ',', 'mon_thousands_sep': '\u202f', 'mon_grouping': [3, 0], 'positive_sign': '', 'negative_sign': '-', 'int_frac_digits': 2, 'frac_digits': 2, 'p_cs_precedes': 0, 'p_sep_by_space': 1, 'n_cs_precedes': 0, 'n_sep_by_space': 1, 'p_sign_posn': 1, 'n_sign_posn': 1, 'decimal_point': ',', 'thousands_sep': '\u202f', 'grouping': [3, 0]} >>> Maybe the title of this issue should be turned to "at start, the C locale is in use in spite of locale.getlocale()'s output (python3 on linux)"? As to the behaviour on Windows, I guess this is another topic (locales belonging to another world on Windows)... but it may be interesting to note that it complies with the current documentation: at start python 3.6 also uses the C locale, and the output of locale.getlocale() is consistent with that. Here is a test on Windows 10: Python 3.6.3 (v3.6.3:2c5fed8, Oct 3 2017, 18:11:49) [MSC v.1900 64 bit (AMD64)] on win32 >>> import locale >>> locale.getlocale() (None, None) >>> locale.localeconv() {'decimal_point': '.', 'thousands_sep': '', 'grouping': [], 'int_curr_symbol': '', 'currency_symbol': '', 'mon_decimal_point': '', 'mon_thousands_sep': '', 'mon_grouping': [], 'positive_sign': '', 'negative_sign': '', 'int_frac_digits': 127, 'frac_digits': 127, 'p_cs_precedes': 127, 'p_sep_by_space': 127, 'n_cs_precedes': 127, 'n_sep_by_space': 127, 'p_sign_posn': 127, 'n_sign_posn': 127} >>> locale.str(2.4) '2.4' >>> locale.getdefaultlocale() ('fr_FR', 'cp1252') ---------- components: +Library (Lib) -Documentation _______________________________________ Python tracker <report(a)bugs.python.org> <https://bugs.python.org/issue33934> _______________________________________

1 0

[issue32554] random.seed(tuple) uses the randomized hash function and so is not reproductible
by Raymond Hettinger June 24, 2018

June 24, 2018

Raymond Hettinger <raymond.hettinger(a)gmail.com> added the comment: I'm thinking of something like this: $ git diff diff --git a/Lib/random.py b/Lib/random.py index 1e0dcc87ed..f479e66ada 100644 --- a/Lib/random.py +++ b/Lib/random.py @@ -136,12 +136,17 @@ class Random(_random.Random): x ^= len(a) a = -2 if x == -1 else x - if version == 2 and isinstance(a, (str, bytes, bytearray)): + elif version == 2 and isinstance(a, (str, bytes, bytearray)): if isinstance(a, str): a = a.encode() a += _sha512(a).digest() a = int.from_bytes(a, 'big') + elif not isinstance(a, (type(None), int, float, str, bytes, bytearray)): + _warn('Seeding based on hashing is deprecated.\n' + 'The only supported seed types are None, int, float, ' + 'str, bytes, and bytearray.', DeprecationWarning, 2) + super().seed(a) self.gauss_next = None ---------- _______________________________________ Python tracker <report(a)bugs.python.org> <https://bugs.python.org/issue32554> _______________________________________

1 0

(no subject)
by Angel Hiraldo June 24, 2018

June 24, 2018

theres a bug in 3.7 that makes asyncio.create_subprocess_exec crash the project

1 0

[issue32554] random.seed(tuple) uses the randomized hash function and so is not reproductible
by Serhiy Storchaka June 24, 2018

June 24, 2018

Serhiy Storchaka <storchaka+cpython(a)gmail.com> added the comment: This is what I meant. Emit a deprecation warning for input types other than explicitly supported types (but I didn't think about float), and raise an error in future. ---------- _______________________________________ Python tracker <report(a)bugs.python.org> <https://bugs.python.org/issue32554> _______________________________________

1 0

[issue32554] random.seed(tuple) uses the randomized hash function and so is not reproductible
by Raymond Hettinger June 24, 2018

June 24, 2018

Raymond Hettinger <raymond.hettinger(a)gmail.com> added the comment: > Maybe deprecate using a hash? Any deprecation will likely break some existing code, but it would be nice to restrict inputs types to int, float, bytes, bytearray, or str. Then we could remove all reference to hashing. ---------- _______________________________________ Python tracker <report(a)bugs.python.org> <https://bugs.python.org/issue32554> _______________________________________

1 0

[issue33934] locale.getlocale() seems wrong when the locale is yet unset (python3 on linux)
by Nick Coghlan June 24, 2018

June 24, 2018

Nick Coghlan <ncoghlan(a)gmail.com> added the comment: This statement is no longer correct: "when python starts, it runs using the C locale, on any platform (Windows, Linux, BSD), any python version (2, 3...), until locale.setlocale() is used to set another locale." The Python 3 text model doesn't work properly in the legacy C locale due to the assumption of ASCII as the preferred text encoding, so we run setlocale(LC_ALL, "") early in the startup sequence in order to switch to something more sensible. In Python 3.7+, we're even more opinionated about that, and explicitly coerce the C locale to a UTF-8 based one if there's one available. If our docs are still saying otherwise anywhere, then our docs are outdated, and need to be fixed. ---------- assignee: -> docs@python components: +Documentation -Library (Lib) nosy: +docs@python stage: -> needs patch _______________________________________ Python tracker <report(a)bugs.python.org> <https://bugs.python.org/issue33934> _______________________________________

1 0

[issue33885] doc Replace "hook function" with "callable" in urllib.request.urlretrieve
by Andrés Delfino June 24, 2018

June 24, 2018

New submission from Andrés Delfino <adelfino(a)gmail.com>: The reporthook of urllib.request.urlretrieve is treated as a function hook, while the right term is "callable". PR fixes this. ---------- assignee: docs@python components: Documentation messages: 319822 nosy: adelfino, docs@python priority: normal severity: normal status: open title: doc Replace "hook function" with "callable" in urllib.request.urlretrieve type: enhancement versions: Python 2.7, Python 3.6, Python 3.7, Python 3.8 _______________________________________ Python tracker <report(a)bugs.python.org> <https://bugs.python.org/issue33885> _______________________________________

5 11

[issue33887] doc Add TOC in Design and History FAQ
by Andrés Delfino June 23, 2018

June 23, 2018

New submission from Andrés Delfino <adelfino(a)gmail.com>: IHMO, having all questions put together is really useful. ---------- assignee: docs@python components: Documentation messages: 319824 nosy: adelfino, docs@python priority: normal severity: normal status: open title: doc Add TOC in Design and History FAQ type: enhancement versions: Python 2.7, Python 3.6, Python 3.7, Python 3.8 _______________________________________ Python tracker <report(a)bugs.python.org> <https://bugs.python.org/issue33887> _______________________________________

4 11

documentation bug: window htmlhelp display text
by 方工 June 23, 2018

June 23, 2018

in chm version of docs, there are many display errors, shown in picture attached. may be html encoding problem? docs.python.org online documentation has no such problem.

1 0