[issue24746] doctest 'fancy diff' formats incorrectly strip trailing whitespace

Change by miss-islington : -- pull_requests: +10982, 10983, 10984, 10985, 10986 ___ Python tracker ___ ___ Python-bugs-list mailing

[issue24746] doctest 'fancy diff' formats incorrectly strip trailing whitespace

Change by miss-islington : -- pull_requests: +10981 stage: test needed -> patch review ___ Python tracker ___ ___ Python-bugs-list m

[issue24746] doctest 'fancy diff' formats incorrectly strip trailing whitespace

Change by miss-islington : -- pull_requests: +10981, 10982, 10983, 10984, 10985 stage: test needed -> patch review ___ Python tracker ___ __

[issue24746] doctest 'fancy diff' formats incorrectly strip trailing whitespace

Change by miss-islington : -- pull_requests: +10981, 10982 stage: test needed -> patch review ___ Python tracker ___ ___ Python-bugs

[issue24746] doctest 'fancy diff' formats incorrectly strip trailing whitespace

Change by miss-islington : -- pull_requests: +10982, 10985 ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: ht

[issue24746] doctest 'fancy diff' formats incorrectly strip trailing whitespace

Change by miss-islington : -- pull_requests: +10981, 10982, 10983, 10985 stage: test needed -> patch review ___ Python tracker ___ _

[issue24746] doctest 'fancy diff' formats incorrectly strip trailing whitespace

Senthil Kumaran added the comment: New changeset cbb16459934eaf29c7c7d362939cd05550b2f21f by Senthil Kumaran (Sanyam Khurana) in branch 'master': bpo-24746: Avoid stripping trailing whitespace in doctest fancy diff (#10639) https://github.com/python/cpython/commit/cbb16459934eaf29c7c7d362939c

[issue35700] Place, Pack and Grid should return the widget

New submission from Peter Vex : When you want to simply place a widget on a window and you also want to store the reference for that widget in a variable you can't do that in one line, which is really unpleasant, because when you create a new widget these things are usually the first what you

[issue35697] _decimal: Implement the previously rejected changes from #7442.

STINNER Victor added the comment: Extract of Stefan Krah's msg333296 of bpo-35638: > So why would you think that I'm not aware of that issue? Oh, I never said that. I wrote "By the way, the decimal module doesn't support properly the following corner case: LC_NUMERIC using an encoding diffe

[issue35697] _decimal: Implement the previously rejected changes from #7442.

STINNER Victor added the comment: Oh, I forgot to mention the context: I reported this issue as follow-up to discussions on bpo-35638: "Introduce fixed point locale aware format type for floating point numbers". -- ___ Python tracker

[issue35638] Introduce fixed point locale aware format type for floating point numbers

STINNER Victor added the comment: > By the way, the decimal module doesn't support properly the following corner > case: LC_NUMERIC using an encoding different than LC_CTYPE encoding. I wrote > https://github.com/python/cpython/pull/5191 but I abandonned my change. FYI I opened bpo-35697 to

[issue35550] Some define guards for Solaris are wrong

STINNER Victor added the comment: > We don't plan to switch to gcc on 2.7 and so it doesn't affect us. Ok. I close the issue. If anyone wants to fix 2.7, please go ahead :-) -- stage: commit review -> resolved status: open -> closed ___ Python trac

[issue35697] _decimal: Implement the previously rejected changes from #7442.

STINNER Victor added the comment: Stefan Krah: > Don't you find it strange to close #7442 in mutual agreement and now mention the word "bug" 50 times? We agreed to close the bug in 2014. In the meanwhile, more and more people reported the same bug (multiple similar bug reports and more and mo

[issue35699] distutils cannot find Build Tools 2017 since 3.7.2

New submission from Marc Schlaich : vshwere.exe doesn't return Build Tools 2017 per default. This means Build Tools 2017 are not detected by distutils in 3.7.2 and you get the famous "Microsoft Visual C++ 14.0 is required" error. Please see https://github.com/Microsoft/vswhere/issues/125 for

[issue35697] _decimal: Implement the previously rejected changes from #7442.

Stefan Krah added the comment: Also Marc-Andre does not consider this a bug in #31900. The presentation of this issue is increasingly bizarre. -- ___ Python tracker ___ _

[issue35697] _decimal: Implement the previously rejected changes from #7442.

Change by Stefan Krah : -- title: decimal: formatter error if LC_NUMERIC uses a different encoding than LC_CTYPE -> _decimal: Implement the previously rejected changes from #7442. ___ Python tracker

[issue35697] decimal: formatter error if LC_NUMERIC uses a different encoding than LC_CTYPE

Stefan Krah added the comment: Don't you find it strange to close #7442 in mutual agreement and now mention the word "bug" 50 times? -- ___ Python tracker ___

[issue35698] Division by 2 in statistics.median

STINNER Victor added the comment: > When len(data) is odd, median returns the average of the two middle values. I'm not sure that I understand your issue. Do you consider that it's a bug? It's part of the definition of the median function, no? https://en.wikipedia.org/wiki/Median#Finite_set_o

[issue25812] locale.nl_langinfo() can't decode value

STINNER Victor added the comment: Since this bug has been reported, locale.localeconv() has been fixed in bpo-31900 to temporarily set LC_CTYPE to LC_NUMERIC to decode numeric fields of localeconv() from the proper encoding. I guess that a similar fix can be applied to locale.nl_langinfo():

[issue35697] decimal: formatter error if LC_NUMERIC uses a different encoding than LC_CTYPE

STINNER Victor added the comment: Stefan Krah: > Since #7442 (again, *I* discovered this and it is *mentioned* in the _decimal sources), ... I closed bpo-7442 in the meanwhile, so I opened this new issue specific to the decimal module. > ... there have been zero bug reports about decimal. W

[issue35697] decimal: formatter error if LC_NUMERIC uses a different encoding than LC_CTYPE

STINNER Victor added the comment: Ok, I wrote PR 11474. Correct result with this PR: $ ./python decimal_locale.py LC_NUMERIC locale: uk_UA.koi8u decimal_point: ',' = ',' = U+002c thousands_sep: '\xa0' = '\xa0' = U+00a0 format: '1\xa0200,5' = 1 200,5 = U+0031 U+00a0 U+0032 U+0030 U+0030 U+002c

[issue35698] Division by 2 in statistics.median

New submission from Jonathan Fine : When len(data) is odd, median returns the average of the two middle values. This average is computed using i = n//2 return (data[i - 1] + data[i])/2 This results in the following behaviour >>> from fractions import Fraction >>> from statisti

[issue35697] decimal: formatter error if LC_NUMERIC uses a different encoding than LC_CTYPE

Change by STINNER Victor : -- keywords: +patch, patch, patch pull_requests: +10977, 10978, 10979 stage: -> patch review ___ Python tracker ___

[issue35697] decimal: formatter error if LC_NUMERIC uses a different encoding than LC_CTYPE

Change by STINNER Victor : -- keywords: +patch, patch pull_requests: +10977, 10978 stage: -> patch review ___ Python tracker ___ __

[issue35697] decimal: formatter error if LC_NUMERIC uses a different encoding than LC_CTYPE

Change by STINNER Victor : -- keywords: +patch pull_requests: +10977 stage: -> patch review ___ Python tracker ___ ___ Python-bugs-

[issue35697] decimal: formatter error if LC_NUMERIC uses a different encoding than LC_CTYPE

Stefan Krah added the comment: Since #7442 (again, *I* discovered this and it is *mentioned* in the _decimal sources), there have been zero bug reports about decimal. -- ___ Python tracker __

[issue35697] decimal: formatter error if LC_NUMERIC uses a different encoding than LC_CTYPE

Change by Stefan Krah : -- assignee: -> skrah nosy: +skrah ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: h

[issue35697] decimal: formatter error if LC_NUMERIC uses a different encoding than LC_CTYPE

STINNER Victor added the comment: Oh, I was wrong: bpo-25812 has not been fixed yet. -- ___ Python tracker ___ ___ Python-bugs-list

[issue35697] decimal: formatter error if LC_NUMERIC uses a different encoding than LC_CTYPE

New submission from STINNER Victor : The decimal module support formatting a number in the "n" formatting type if the LC_NUMERIC locale uses a different encoding than the LC_CTYPE locale. Example with attached decimal_locale.py on Fedora 29 with Python 3.7.2: $ python3 decimal_locale.py LC_

[issue35550] Some define guards for Solaris are wrong

Jakub Kulik added the comment: We are building previous versions of Python with Solaris Studio which works with define guards as they are right now. 3.7 is first version build with gcc. We don't plan to switch to gcc on 2.7 and so it doesn't affect us. But I guess if this fix can be done eas

[issue35687] The unittest module diff is missing/forgetting/not putting newline before + and ? for some inputs

Addons Zz added the comment: I applied the patch from https://bugs.python.org/file44679 and it fixed the issue for this example using the unittest module: ```python import unittest class StdErrUnitTests(unittest.TestCase): def test_function_name(self): expected = "testing.main_un

[issue35687] The unittest module diff is missing/forgetting/not putting newline before + and ? for some inputs

Addons Zz added the comment: * Correction ```python import difflib def bugged_diff(expected, actual): expected = expected.splitlines( 1 ) actual = actual.splitlines( 1 ) # diff = difflib.ndiff( expected, actual ) if expected != actual: diff = difflib.context_diff( expe

[issue35687] The unittest module diff is missing/forgetting/not putting newline before + and ? for some inputs

Addons Zz added the comment: The issue is also reproducible, by directly using difflib: ```python import difflib def bugged_diff(expected, actual): expected = expected.splitlines( 1 ) actual = actual.splitlines( 1 ) # diff = difflib.ndiff( expected, actual ) if expected != act

[issue35638] Introduce fixed point locale aware format type for floating point numbers

Łukasz Stelmach added the comment: I'd appreciate, if we continued the discussion at python-ideas, where I posted the idea[1]. There has already been several valuable comments. [1] https://mail.python.org/pipermail/python-ideas/2019-January/054793.html --

[issue35638] Introduce fixed point locale aware format type for floating point numbers

Stefan Krah added the comment: > Since it seems like we are still at the "idea" stage, would it make sense to > add a function which accept options to choose how to format a number? Maybe, but I think for format() Eric's latest proposal on python-ideas is great ("*f" for "f + LC_NUMERIC", "$

[issue24780] unittest assertEqual difference output foiled by newlines

Karthikeyan Singaravelan added the comment: Thanks @chris.jerdonek. I have reverted the title to original report. Since CPython now accepts PR if any one of the original authors can convert their patch to a PR with tests then it will be great. -- title: difflib.ndiff produces unreada

[issue34656] memory exhaustion in Modules/_pickle.c:1393

Serhiy Storchaka added the comment: I am not sure this issue should be classified as a security issue. It can cause DDOS, because pickle should not be used with untrusted data. If it is used, the program has more severe security issues than just DDOS. The crash could be triggered by accident

[issue35696] remove unnecessary operation in long_compare()

Change by Ma Lin : -- keywords: +patch, patch, patch pull_requests: +10974, 10975, 10976 stage: -> patch review ___ Python tracker ___

[issue35696] remove unnecessary operation in long_compare()

Change by Ma Lin : -- keywords: +patch, patch pull_requests: +10974, 10975 stage: -> patch review ___ Python tracker ___ ___ Python

[issue35696] remove unnecessary operation in long_compare()

Change by Ma Lin : -- keywords: +patch pull_requests: +10974 stage: -> patch review ___ Python tracker ___ ___ Python-bugs-list mai

[issue35696] remove unnecessary operation in long_compare()

New submission from Ma Lin : static int long_compare(PyLongObject *a, PyLongObject *b) { } This function in /Objects/longobject.c is used to compare two PyLongObject's value. We only need the sign, converting to -1 or +1 is not necessary. -- messages: 333293 nosy: Ma Lin prio

[issue34656] memory exhaustion in Modules/_pickle.c:1393

Miro Hrončok added the comment: Should this go to 3.4 and 3.5 as well, since it is a security thing? http://people.canonical.com/~ubuntu-security/cve/2018/CVE-2018-20406.html -- nosy: +hroncok ___ Python tracker

<    1   2