[Python-Dev] Pythong 3.6.5 Tests failed
I got error message that test_dtrace and test_normalization failed. Below is
the messages when I reran the test. Please let me know whether these errors are
okay.
Thanks,
Haritha
[root@mrkdlvaiaas2882 Python-3.6.5]# ./python -m test -v test_normalization
== CPython 3.6.5 (default, Mar 8 2019, 14:29:13) [GCC 4.8.5 20150623 (Red Hat
4.8.5-36)]
== Linux-3.10.0-957.1.3.el7.x86_64-x86_64-with-redhat-7.6-Maipo little-endian
== cwd: /tmp/python/Python-3.6.5/build/test_python_123679
== CPU count: 2
== encodings: locale=UTF-8, FS=utf-8
Run tests sequentially
0:00:00 load avg: 0.39 [1/1] test_normalization
test_bug_834676 (test.test_normalization.NormalizationTest) ... ok
test_main (test.test_normalization.NormalizationTest) ... skipped "Use of the
'urlfetch' resource not enabled"
--
Ran 2 tests in 0.003s
OK (skipped=1)
1 test OK.
Total duration: 51 ms
Tests result: SUCCESS
[root@mrkdlvaiaas2882 Python-3.6.5]# ./python -m test -v test_dtrace
== CPython 3.6.5 (default, Mar 8 2019, 14:29:13) [GCC 4.8.5 20150623 (Red Hat
4.8.5-36)]
== Linux-3.10.0-957.1.3.el7.x86_64-x86_64-with-redhat-7.6-Maipo little-endian
== cwd: /tmp/python/Python-3.6.5/build/test_python_124133
== CPU count: 2
== encodings: locale=UTF-8, FS=utf-8
Run tests sequentially
0:00:00 load avg: 0.36 [1/1] test_dtrace
skipped 'dtrace(1) failed: /bin/dtrace invalid option -q\nUsage /bin/dtrace
[--help] [-h | -G] [-C [-I]] -s File.d [-o ]'
skipped 'dtrace(1) failed: /bin/dtrace invalid option -q\nUsage /bin/dtrace
[--help] [-h | -G] [-C [-I]] -s File.d [-o ]'
test_function_entry_return (test.test_dtrace.SystemTapNormalTests) ... FAIL
test_gc (test.test_dtrace.SystemTapNormalTests) ... FAIL
test_line (test.test_dtrace.SystemTapNormalTests) ... FAIL
test_verify_call_opcodes (test.test_dtrace.SystemTapNormalTests)
Ensure our call stack test hits all function call opcodes ... ok
test_function_entry_return (test.test_dtrace.SystemTapOptimizedTests) ... FAIL
test_gc (test.test_dtrace.SystemTapOptimizedTests) ... FAIL
test_line (test.test_dtrace.SystemTapOptimizedTests) ... FAIL
test_verify_call_opcodes (test.test_dtrace.SystemTapOptimizedTests)
Ensure our call stack test hits all function call opcodes ... ok
==
FAIL: test_function_entry_return (test.test_dtrace.SystemTapNormalTests)
--
Traceback (most recent call last):
File "/tmp/python/Python-3.6.5/Lib/test/test_dtrace.py", line 32, in
normalize_trace_output
result.sort(key=lambda row: int(row[0]))
File "/tmp/python/Python-3.6.5/Lib/test/test_dtrace.py", line 32, in
result.sort(key=lambda row: int(row[0]))
ValueError: invalid literal for int() with base 10: "semantic error: while
resolving probe point: identifier 'process' at
/tmp/python/Python-3.6.5/Lib/test/dtracedata/call_stack.stp:13:7"
During handling of the above exception, another exception occurred:
Traceback (most recent call last):
File "/tmp/python/Python-3.6.5/Lib/test/test_dtrace.py", line 118, in
test_function_entry_return
self.run_case("call_stack")
File "/tmp/python/Python-3.6.5/Lib/test/test_dtrace.py", line 114, in run_case
name, optimize_python=self.optimize_python)
File "/tmp/python/Python-3.6.5/Lib/test/test_dtrace.py", line 50, in run_case
optimize_python=optimize_python))
File "/tmp/python/Python-3.6.5/Lib/test/test_dtrace.py", line 37, in
normalize_trace_output
"tracer produced unparseable output:\n{}".format(output)
AssertionError: tracer produced unparseable output:
semantic error: while resolving probe point: identifier 'process' at
/tmp/python/Python-3.6.5/Lib/test/dtracedata/call_stack.stp:13:7
source: probe process.mark("function__entry")
^
semantic error: no match
Pass 2: analysis failed. [man error::pass2]
Number of similar error messages suppressed: 3.
Rerun with -v to see them.
==
FAIL: test_gc (test.test_dtrace.SystemTapNormalTests)
--
Traceback (most recent call last):
File "/tmp/python/Python-3.6.5/Lib/test/test_dtrace.py", line 32, in
normalize_trace_output
result.sort(key=lambda row: int(row[0]))
File "/tmp/python/Python-3.6.5/Lib/test/test_dtrace.py", line 32, in
result.sort(key=lambda row: int(row[0]))
ValueError: invalid literal for int() with base 10: "semantic error: while
resolving probe point: identifier 'process' at
/tmp/python/Python-3.6.5/Lib/test/dtracedata/gc.stp:3:7"
During handling of the above exception, another exception occurred:
Traceback (most recent call last):
File "/tmp/python/Python-3.6.5/Lib/test/test_dtrace.py", line 146, in test_gc
self.run_case("gc")
File "/tmp/python/Python-3.6.5/Lib/test/test_dtrace.py", line 114, in run_case
name,
Re: [Python-Dev] PEPs from non-core devs now need a sponsor
On Fri, Mar 8, 2019 at 5:46 AM Richard Damon wrote: > On 3/8/19 8:09 AM, Alex Walters wrote: > > I'm confused about this. Didn't you need someone with merge permissions > already to merge a pep into the pep repo? Isn't this just adding a layer > of paperwork to something that was already the case for all practical > purposes? > Nope. We don't like paperwork anymore than you or anyone else. > > > > > I would say the difference that before, the non-committer proposer just > needed to convince some committer that the PEP was 'a good idea' and > worth being discussed. Now, that person needs to persuade some committer > that not only is it a good idea, but that it is worth the committer > committing themselves to supporting the proposer through the process. > What Richard said. Before, PEP editors would make sure a PEP was basically grammatically correct and not totally bonkers, but otherwise didn't make judgments. Now we're saying there needs to be a core dev to help you through the process to help make sure you will be successful and at least *someone* thinks it's a good idea. -Brett > > -- > Richard Damon > > ___ > Python-Dev mailing list > Python-Dev@python.org > https://mail.python.org/mailman/listinfo/python-dev > Unsubscribe: > https://mail.python.org/mailman/options/python-dev/brett%40python.org > ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 12 updated with templates for header fields and sections
This is all OT for this thread. If you would like to start a new discussion about changing the PEP process so discussion threads are tracked more thoroughly then please do. On Fri, Mar 8, 2019 at 12:29 AM Victor Stinner wrote: > Hi Brett, > > I like to see discussions where a PEP has been discussed. There is > the "Post History" just gives dates. The problem is that PEPs are > discussed on 3 mailing lists: python-ideas, python-dev and > python-committers. Maybe some PEP are now also discussed on > discuss.python.org. > > Do you have any recommendation to refer to these discussions? > > I would like to suggest to add URLs to the first messages of all > threads about a PEP... Well... I know that for PEP 572, this list > would be hard to create and maybe not really useful. Maybe not add > links to *all* threads, but only the most actives or most "useful" > threads? The PEP author would be free to decide which threads are > important or not ;-) > > The status quo (Post History header) is fine, if I really want to find > these discussions, I'm able to find them from dates :-) > > Victor > > Le ven. 8 mars 2019 à 01:42, Brett Cannon a écrit : > > > > https://github.com/python/peps/blob/master/pep-0012.rst now has a > complete list of header fields along with format clues for easier > copy-and-paste use in creating a new PEP. There is also a section template > with one-liner explanations for what each section is for so people don't > accidentally leave anything out. They are not in a single, unified template > to copy to partially make sure people actually read the PEP before they > start writing. :) > > ___ > > Python-Dev mailing list > > Python-Dev@python.org > > https://mail.python.org/mailman/listinfo/python-dev > > Unsubscribe: > https://mail.python.org/mailman/options/python-dev/vstinner%40redhat.com > > > > -- > Night gathers, and now my watch begins. It shall not end until my death. > ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] Summary of Python tracker Issues
ACTIVITY SUMMARY (2019-03-01 - 2019-03-08) Python tracker at https://bugs.python.org/ To view or respond to any of the issues listed below, click on the issue. Do NOT respond to this message. Issues counts and deltas: open7031 (+19) closed 40963 (+65) total 47994 (+84) Open issues with patches: 2793 Issues opened (55) == #33329: sigaddset() can fail on some signal numbers https://bugs.python.org/issue33329 reopened by larry #36097: Use only public C-API in _xxsubinterpreters module. https://bugs.python.org/issue36097 reopened by eric.snow #36125: Cannot cross-compile to more featureful but same tune https://bugs.python.org/issue36125 reopened by xdegaye #36160: Multiple errors in test_site.py on sysconfig._CONFIG_VARS.clea https://bugs.python.org/issue36160 opened by Ivan.Pozdeev #36161: Use thread-safe functions instead of unsafe ones (crypt, ttyna https://bugs.python.org/issue36161 opened by twouters #36164: Updating Py_InspectFlag programmatically https://bugs.python.org/issue36164 opened by ishimoto #36165: DOC: ssl.rst is missing formatting on two links https://bugs.python.org/issue36165 opened by cheryl.sabella #36166: DOC: Fix markup on function parameter on datamodel.rst https://bugs.python.org/issue36166 opened by cheryl.sabella #36167: DOC: Incorrect capitalization in Programming FAQ https://bugs.python.org/issue36167 opened by cheryl.sabella #36168: DOC: Fix capitalization in string.rst https://bugs.python.org/issue36168 opened by cheryl.sabella #36172: csv module internal consistency https://bugs.python.org/issue36172 opened by Shane Smith #36174: Remove licenseUrl field from nuget packages https://bugs.python.org/issue36174 opened by steve.dower #36176: Make IDLE Autocomplete / Calltip Window Colors Configurable https://bugs.python.org/issue36176 opened by greylaw89 #36179: _hashopenssl has reference leaks in OOM case https://bugs.python.org/issue36179 opened by christian.heimes #36180: mboxMessage.get_payload throws TypeError on malformed content https://bugs.python.org/issue36180 opened by enrico #36182: Path.write_text() docs do not include the case that a file exi https://bugs.python.org/issue36182 opened by lys.nikolaou #36184: [EASY] test_gdb.test_threads() is specific to _POSIX_THREADS, https://bugs.python.org/issue36184 opened by vstinner #36189: DOC: Correct word in tutorial introduction https://bugs.python.org/issue36189 opened by cheryl.sabella #36194: Add "make regen-configure" https://bugs.python.org/issue36194 opened by vstinner #36195: initializer is not a valid param in ThreadPoolExecutor https://bugs.python.org/issue36195 opened by harman786 #36201: AssertCountEqual does not work for nested dictionaries. https://bugs.python.org/issue36201 opened by walterqian #36202: Calling Py_DecodeLocale() before _PyPreConfig_Write() can prod https://bugs.python.org/issue36202 opened by vstinner #36203: PyWeakref_NewRef docs are misleading https://bugs.python.org/issue36203 opened by Maxwell Bernstein #36204: Deprecate calling Py_Main() after Py_Initialize()? Add Py_Init https://bugs.python.org/issue36204 opened by vstinner #36205: Python 3.7 and 3.8 process_time is not reported correctly when https://bugs.python.org/issue36205 opened by Nitapol #36207: robotsparser deny all with some rules https://bugs.python.org/issue36207 opened by quentin-maire #36208: AsyncIO V4MAPPED addresses with V6ONLY. https://bugs.python.org/issue36208 opened by jeeger #36210: ncurses versus cursus integration - platform differences and d https://bugs.python.org/issue36210 opened by Michael.Felt #36211: show full url when execute "make -C Doc/ serve" https://bugs.python.org/issue36211 opened by matrixise #36212: [2.7] Coverity scan: Modules/_hotshot.c , Variable "s1" going https://bugs.python.org/issue36212 opened by cstratak #36213: subprocess.check_output() fails with OSError: [WinError 87] wh https://bugs.python.org/issue36213 opened by Geoff.Alexander #36214: AC_RUN_IFELSE macros not used as arguments of AC_CACHE_VAL et https://bugs.python.org/issue36214 opened by xdegaye #36215: Should AppVeyor run compile Python in debug mode? https://bugs.python.org/issue36215 opened by vstinner #36216: urlsplit does not handle NFKC normalization https://bugs.python.org/issue36216 opened by steve.dower #36217: recvmsg support on Windows https://bugs.python.org/issue36217 opened by chrysn #36218: .sort() segfaults consistently on crafted input https://bugs.python.org/issue36218 opened by Lyn Levenick #36219: Add edit option in IDLE to convert smart quotes to ascii quote https://bugs.python.org/issue36219 opened by rhettinger #36220: LOAD_NAME and LOAD_GLOBAL handle dict subclasses for globals() https://bugs.python.org/issue36220 opened by Kevin Shweh #36221: Setting PYTHONASYNCIODEBUG breaks warnings https://bugs.python.org/issue36221 opened by ods #36225: Lingering subinterpreters should be implicitly
Re: [Python-Dev] Using CLA assistant for Python contributions
On Thu, Mar 7, 2019 at 11:25 PM Paul Moore wrote: > > My preference would be to just re-sign the CLA *immediately*, and not > wait for when I have a PR - I presume that would be > possible/supported. > Yes this is possible, and once the switchover happens, I will post the link with instructions on how to do that. ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] configparser: should optionxform be idempotent?
I just have one thing to add to the discussion, which is this: https://youtu.be/hAnCiTpxXPg?t=6339 Yes, people actually read and interpret our documentation :) So discussions like this are probably a good thing in terms of getting the best descriptions in there, but if we use a specific technical term *not quite right* then we will be found out. (A few of us core devs chatted with Al afterwards and there's no bad blood, so don't worry about that.) Cheers, Steve ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEPs from non-core devs now need a sponsor
On 3/8/19 8:09 AM, Alex Walters wrote: > I'm confused about this. Didn't you need someone with merge permissions > already to merge a pep into the pep repo? Isn't this just adding a layer of > paperwork to something that was already the case for all practical purposes? > > I would say the difference that before, the non-committer proposer just needed to convince some committer that the PEP was 'a good idea' and worth being discussed. Now, that person needs to persuade some committer that not only is it a good idea, but that it is worth the committer committing themselves to supporting the proposer through the process. -- Richard Damon ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEPs from non-core devs now need a sponsor
I'm confused about this. Didn't you need someone with merge permissions already to merge a pep into the pep repo? Isn't this just adding a layer of paperwork to something that was already the case for all practical purposes? > -Original Message- > From: Python-Dev list=sdamon@python.org> On Behalf Of Brett Cannon > Sent: Monday, March 4, 2019 8:44 PM > To: python-dev > Subject: [Python-Dev] PEPs from non-core devs now need a sponsor > > The steering council has implemented a new idea called sponsors to the PEP > process (added in > https://github.com/python/peps/commit/c58d32c33bd06eb386d3f33963a14 > 34510528f68). The thinking is that to help make sure PEPs from non-core > developers receive appropriate guidance through the PEP process, a core > developer needs to sign on to be a sponsor of the PEP. Being a sponsor does > not preclude the core dev from eventually becoming a co-author or BDFL- > delegate later on (but obviously not both), but the expectation is the > sponsor is supportive of the idea (because if a single core dev won't sign on > to help then what chance does the PEP have of being accepted?). > > > If this doesn't turn out well we can obviously revert this, but hopefully this > will make things smoother for those who are new to the PEP process. ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Using CLA assistant for Python contributions
On Fri, 8 Mar 2019 at 10:39, Steven D'Aprano wrote: > > On Fri, Mar 08, 2019 at 07:25:37AM +, Paul Moore wrote: > > > PS I would also prefer not to have to re-sign, but just have my > > existing confirmation carried over. I don't *know* if there are any > > implications at my end around re-signing, and my preference is simply > > to not ask that question (on the basis of why make things harder for > > myself). But if it's needed, then fair enough. > > Because what you don't know can't hurt you? > > You're signing a legal document. Shouldn't you understand the > implications of signing it before you sign? Sigh. Trust me that I know what I'm saying, please. I do understand the implications. And re-signing a CLA *will* involve different processes for me than a simple continuance of an existing CLA - even if that CLA is confirmed by the PSF as legally identical to the new one. I can, and will, negotiate that difficulty myself if necessary - but honestly, it's not really the place of anyone on this list to tell me what I need to do in order to ensure my compliance with the CLA and with my employer's policies. I offered the information for awareness, to ensure that the people proposing this change knew that it had the potential to incur extra work for people being asked to re-sign, beyond the mere mechanics of re-signing. I did not expect arguments over my understanding of what I needed to do (nor did I expect the Spanish Inquisition, but *nobody* expects that ;-)) Paul ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Using CLA assistant for Python contributions
On Fri, Mar 08, 2019 at 07:25:37AM +, Paul Moore wrote: > PS I would also prefer not to have to re-sign, but just have my > existing confirmation carried over. I don't *know* if there are any > implications at my end around re-signing, and my preference is simply > to not ask that question (on the basis of why make things harder for > myself). But if it's needed, then fair enough. Because what you don't know can't hurt you? You're signing a legal document. Shouldn't you understand the implications of signing it before you sign? -- Steven ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 12 updated with templates for header fields and sections
Yeah, such list is more convenient than just "Post-History: 14-Aug-2001, 03-Sept-2001". Victor Le ven. 8 mars 2019 à 09:40, Jeroen Demeyer a écrit : > > On 2019-03-08 09:29, Victor Stinner wrote: > > I would like to suggest to add URLs to the first messages of all > > threads about a PEP... > > Like this? > > https://www.python.org/dev/peps/pep-0580/#discussion > ___ > Python-Dev mailing list > Python-Dev@python.org > https://mail.python.org/mailman/listinfo/python-dev > Unsubscribe: > https://mail.python.org/mailman/options/python-dev/vstinner%40redhat.com -- Night gathers, and now my watch begins. It shall not end until my death. ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 12 updated with templates for header fields and sections
On 2019-03-08 09:29, Victor Stinner wrote: I would like to suggest to add URLs to the first messages of all threads about a PEP... Like this? https://www.python.org/dev/peps/pep-0580/#discussion ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 12 updated with templates for header fields and sections
Hi Brett, I like to see discussions where a PEP has been disccussed. There is the "Post History" just gives dates. The problem is that PEPs are discussed on 3 mailing lists: python-ideas, python-dev and python-committers. Maybe some PEP are now also discussed on discuss.python.org. Do you have any recommendation to referer to these discussions? I would like to suggest to add URLs to the first messages of all threads about a PEP... Well... I know that for PEP 572, this list would be hard to create and maybe not really useful. Maybe not add links to *all* threads, but only the most actives or most "useful" threads? The PEP author would be free to decide which threads are important or not ;-) The status quo (Post History header) is fine, if I really want to find these discussions, I'm able to find them from dates :-) Victor Le ven. 8 mars 2019 à 01:42, Brett Cannon a écrit : > > https://github.com/python/peps/blob/master/pep-0012.rst now has a complete > list of header fields along with format clues for easier copy-and-paste use > in creating a new PEP. There is also a section template with one-liner > explanations for what each section is for so people don't accidentally leave > anything out. They are not in a single, unified template to copy to partially > make sure people actually read the PEP before they start writing. :) > ___ > Python-Dev mailing list > Python-Dev@python.org > https://mail.python.org/mailman/listinfo/python-dev > Unsubscribe: > https://mail.python.org/mailman/options/python-dev/vstinner%40redhat.com -- Night gathers, and now my watch begins. It shall not end until my death. ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] configparser: should optionxform be idempotent?
> On Mar 8, 2019, at 12:12 AM, Steven D'Aprano wrote: > >> On Fri, Mar 08, 2019 at 12:56:13PM +1300, Greg Ewing wrote: >> >> In any case, the word is easy enough to avoid in this case. > > I don't think we should avoid using standard terminology even if we can. > Knowledge of standard terminology is useful, and we don't generally make > a practice of talking about (e.g.) "simultaneously running subtasks" > when we can say "threads" instead. > > You are happy to use the jargon terms "function" and "canonical form" > without explanation, which I think proves that one person's jargon is > another's obvious, clear, precise technical terminology. > > >> We could say something like: >> >> "The optionxform function transforms option names to a >> canonical form. If the name is already in canonical form, >> it should be returned unchanged." > > How about: > >"The optionxform function transforms option names to a >canonical form. This should be an idempotent function: >if the name is already in canonical form, it should be >returned unchanged." I’d prefer something less passive than “it should remain unchanged” (as my high school English teacher would say: “by whom?”). Something like “If optionxform is called on a name that is already in canonical form, then it should return that name unchanged”. Then add something like “That is, optionxform should be idempotent”. Eric > > > requires six extra words, but it uses the correct technical term which > will be familiar to some proportion of users, while also explaining the > term for those who aren't familiar with it. We all win! > > > -- > Steven > ___ > Python-Dev mailing list > Python-Dev@python.org > https://mail.python.org/mailman/listinfo/python-dev > Unsubscribe: > https://mail.python.org/mailman/options/python-dev/eric%2Ba-python-dev%40trueblade.com ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
