[issue27546] Integrate tkinter and asyncio (and async)
Change by Skip Montanaro : -- nosy: -skip.montanaro ___ Python tracker <https://bugs.python.org/issue27546> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue27546] Integrate tkinter and asyncio (and async)
Skip Montanaro added the comment: See also (perhaps) https://bugs.python.org/issue47190 -- nosy: +skip.montanaro ___ Python tracker <https://bugs.python.org/issue27546> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue47190] Integrating tkinter and asyncio event loops
Skip Montanaro added the comment: That's fine. My brief search didn't turn up https://bugs.python.org/issue27546 I'm happy to close this. -- stage: patch review -> resolved status: open -> closed ___ Python tracker <https://bugs.python.org/issue47190> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue47190] Integrating tkinter and asyncio event loops
Change by Skip Montanaro : -- keywords: +patch pull_requests: +30355 stage: -> patch review pull_request: https://github.com/python/cpython/pull/32293 ___ Python tracker <https://bugs.python.org/issue47190> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue47190] Integrating tkinter and asyncio event loops
New submission from Skip Montanaro : After looking around and asking, it appears there is no built-in integration of the tkinter and asyncio event loops. That would seem to be a good thing, at least as an example. I wrote a simple hello world which creates an AsyncTk class and uses asyncio-driven event handling. This is clearly incomplete, but might be a useful starting point, even if just as a seed for discussion or as an example for tkinter or asyncio documentation. Discussion/thread references: https://mail.python.org/pipermail/python-list/2022-March/905783.html https://discuss.python.org/t/connecting-asyncio-and-tkinter-event-loops/14722/7 The code in its most basic form is attached. (I have another version which uses pynput to track keyboard and mouse events.) -- components: Tkinter files: tkasyncio.py messages: 416500 nosy: skip.montanaro priority: normal severity: normal status: open title: Integrating tkinter and asyncio event loops versions: Python 3.11 Added file: https://bugs.python.org/file50712/tkasyncio.py ___ Python tracker <https://bugs.python.org/issue47190> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue23041] csv needs more quoting rules
Skip Montanaro added the comment: Further question... All the discussion has been on the writer side of the csv module. Is there any reason that using QUOTE_STRINGS or QUOTE_NOTNULL should have an effect when reading? For example, should this line on input "",,1,'a' produce this list ["", None, "1", "a"] with QUOTE_NOTNULL in effect, and ["", "", 1, "a"] or ["", None, 1, "a"] with QUOTE_STRINGS in effect? -- ___ Python tracker <https://bugs.python.org/issue23041> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue23041] csv needs more quoting rules
Skip Montanaro added the comment: Note to @samwyse and @krypten: I updated the patches and created a pull request on GitHub, but I have no way of knowing if at least krypten has signed a CLA for Python. Since you're the author of the original patches, we need to verify that you have. -- ___ Python tracker <https://bugs.python.org/issue23041> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue23041] csv needs more quoting rules
Change by Skip Montanaro : -- pull_requests: +27722 stage: needs patch -> patch review pull_request: https://github.com/python/cpython/pull/29469 ___ Python tracker <https://bugs.python.org/issue23041> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue45745] ./python -m test --help output for refleaks seems wrong
Skip Montanaro added the comment: Thanks, I get that. My issue is with the apparent mismatch between the English meaning of "find leaks" and "fail env changed." It seems to me that the help message(s) for one or both of those options is probably incorrect and needs to be changed. -- ___ Python tracker <https://bugs.python.org/issue45745> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue45745] ./python -m test --help output for refleaks seems wrong
New submission from Skip Montanaro : Just preparing to make a refleaks test run, so I ran: ./python -m test --help The output related to refleaks seemed suspicious: ... Special runs: -l, --findleaks deprecated alias to --fail-env-changed ... --fail-env-changedif a test file alters the environment, mark the test as failed It's not obvious that "--fail-env-changed" has anything to do with "--findleaks". Does the -l/--findleaks message need to be corrected? -- components: Build messages: 405916 nosy: skip.montanaro priority: normal severity: normal status: open title: ./python -m test --help output for refleaks seems wrong versions: Python 3.11 ___ Python tracker <https://bugs.python.org/issue45745> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue45714] test_multiprocessing_spawn hangs sometimes
Skip Montanaro added the comment: Took me a while to notice the -i flag to regrtest.py. I think that solves my particular problem, so I will close this. Is there a place to see how 'make test' is run on the buildbots? -- stage: -> resolved status: open -> closed ___ Python tracker <https://bugs.python.org/issue45714> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue45714] test_multiprocessing_spawn hangs sometimes
New submission from Skip Montanaro :
I find that test_multiprocessing_spawn frequently hangs. Hitting Ctl-C then
rerunning "make test" generally works. Still, this behavior makes it
problematic to run testing unattended. I don't think I have an unusual
environment (XUbuntu 20.04, GCC 9.3.0). Here's some output from the currently
running/hanging process, just after the last other unit test completed.
0:03:42 load avg: 4.96 [421/422/21] test_concurrent_futures passed (2 min 57
sec) -- running: test_multiprocessing_spawn (2 min 59 sec)
0:04:12 load avg: 3.19 running: test_multiprocessing_spawn (3 min 29 sec)
0:04:42 load avg: 1.93 running: test_multiprocessing_spawn (3 min 59 sec)
0:05:12 load avg: 1.23 running: test_multiprocessing_spawn (4 min 29 sec)
0:05:42 load avg: 0.74 running: test_multiprocessing_spawn (4 min 59 sec)
...
0:22:12 load avg: 0.42 running: test_multiprocessing_spawn (21 min 29 sec)
0:22:42 load avg: 0.27 running: test_multiprocessing_spawn (21 min 59 sec)
0:23:12 load avg: 0.37 running: test_multiprocessing_spawn (22 min 29 sec)
I'm currerntly mostly messing around with the nogil code and 3.9 tip, but I've
noticed this problem on other branches as well. The fact that this seems not to
have been reported before suggests that I'm somehow an outlier. If it was
common, my guess is that the buildbots would experience this problem on a
regular basis.
Here is the current python process info (output of pgrep -fla python).
1572195 /home/skip/src/python/cpython/python -u -W default -bb -E -m test -r -w
-j 0 -u all,-largefile,-audio,-gui
1575193 /home/skip/src/python/cpython/python -bb -E -Wdefault -u -m
test.regrtest --worker-args [{"testdir": null, "verbose": 0, "quiet": false,
"exclude": false, "single": false, "randomize": true, "fromfile": null,
"findleaks": 1, "use_resources": ["curses", "network", "decimal", "cpu",
"subprocess", "urlfetch"], "trace": false, "coverdir": "coverage", "runleaks":
false, "huntrleaks": false, "verbose2": true, "print_slow": false,
"random_seed": 2495022, "use_mp": 10, "verbose3": false, "forever": false,
"header": false, "failfast": false, "match_tests": null, "ignore_tests": null,
"pgo": false, "timeout": null, "wait": false, "worker_args": null, "start":
null, "match_filename": null, "ignore_filename": null, "use": [["all",
"-largefile", "-audio", "-gui"]], "memlimit": null, "threshold": null,
"nowindows": false, "list_tests": false, "list_cases": false, "pgo_extended":
false, "fail_env_changed": false, "xmlpath": null, "tempdir":
"/home/skip/src/python/cpython/build/test_python_1
572195", "cleanup": false, "args": []}, "test_multiprocessing_spawn"]
1575489 /home/skip/src/python/cpython/python -bb -E -Wdefault -c from
multiprocessing.resource_tracker import main;main(3)
1575547 /home/skip/src/python/cpython/python -bb -E -Wdefault -c from
multiprocessing.forkserver import main; main(6, 7, ['__main__',
'test.test_multiprocessing_forkserver'], **{'sys_path':
['/home/skip/src/python/cpython',
'/home/skip/tmp/nogilpgo_build/lib/python39.zip',
'/home/skip/src/python/cpython/Lib',
'/home/skip/src/python/cpython/build/lib.linux-x86_64-3.9',
'/home/skip/.local/lib/python3.9/site-packages',
'/home/skip/tmp/nogilpgo_build/lib/python3.9/site-packages']})
1589033 /home/skip/src/python/cpython/python -bb -E -Wdefault -c from
multiprocessing.spawn import spawn_main; spawn_main(tracker_fd=4,
pipe_handle=12) --multiprocessing-fork
1589034 /home/skip/src/python/cpython/python -bb -E -Wdefault -c from
multiprocessing.spawn import spawn_main; spawn_main(tracker_fd=4,
pipe_handle=14) --multiprocessing-fork
At the moment I can't pstack either of the last two processes. Unfortunately, I
think I need to tweak ptrace.conf and reboot.
--
messages: 405718
nosy: skip.montanaro
priority: normal
severity: normal
status: open
title: test_multiprocessing_spawn hangs sometimes
___
Python tracker
<https://bugs.python.org/issue45714>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue45638] Does ccbench still require 2.6 compatibility?
Skip Montanaro added the comment: CCbench was mentioned recently in the discussion about Sam Gross's nogil branch: https://mail.python.org/archives/list/python-...@python.org/message/WRT7F2RHHCQ3N2TYEDC6JSIJ4T2ZM6F7/ I'm not convinced that deleting it is a no-brainer. Maybe if it landed somewhere generally useful (pyperformance?). -- ___ Python tracker <https://bugs.python.org/issue45638> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue45669] An 'ascii_alphanumerics' variable is missing in the 'strings' lib
Skip Montanaro added the comment: I'll be the wet blanket here and say -1. This doesn't seem at all necessary. 81 occurrences in ~3.5k PyPI packages? That's a hardly overwhelming endorsement. To top it off, since this can't be backported to 3.10 and earlier, it creates a needless (trivial) difference. Package authors who would like to use this but support earlier versions of Py3 will need to do something like this: try: from string import ascii_alphanumerics except ImportError: ascii_alphanumerics = string.ascii_letters + string.digits They get no benefit from the addition. In fact, their code gets marginally harder to read. -- nosy: +skip.montanaro ___ Python tracker <https://bugs.python.org/issue45669> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue45638] Does ccbench still require 2.6 compatibility?
New submission from Skip Montanaro : At the top of Tools/ccbench/ccbench.py is this comment dating from 2010 (probably in the initial version): # This file should be kept compatible with both Python 2.6 and Python >= 3.0. Is there still a need for 2.6 compatibility in what is essentially a test script? There are probably only a few changes necessary to remove 2.x compatibility, but it seems odd to retain them when even the Python library documentation no longer has versionchanged/versionadded directives referencing Python 2.x. -- messages: 405141 nosy: skip.montanaro priority: normal severity: normal status: open title: Does ccbench still require 2.6 compatibility? versions: Python 3.11 ___ Python tracker <https://bugs.python.org/issue45638> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue23041] csv needs more quoting rules
Skip Montanaro added the comment: Update version - too late for anything older than 3.11. -- versions: -Python 3.10, Python 3.6, Python 3.7, Python 3.8, Python 3.9 ___ Python tracker <https://bugs.python.org/issue23041> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue43941] Unit test failure in test_gdb only with -O0
Skip Montanaro added the comment: Unfortunately, I'm currently not able to build Python 3.8, 3.9 or 3.10 and get a non-failing test_gdb. I'll mess around a bit more, but I'm skeptical I'll find something simple. (I wonder if something changed in GDB which is causing the failure.) -- ___ Python tracker <https://bugs.python.org/issue43941> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue43941] Unit test failure in test_gdb only with -O0
Skip Montanaro added the comment: I routinely build with -O0 and have been getting test_gdb failures building the 3.10 branch. I tried adding -g3 to my configure flags: nice ./configure OPT="-O0 -g3 -Wall" --with-pydebug --with-trace-refs but test_gdb still fails. Output attached. Note that I have been getting CRC mismatches between a couple files. They are copious in the test output, so I won't elaborate here. -- nosy: +skip.montanaro Added file: https://bugs.python.org/file50140/test_gdb.out ___ Python tracker <https://bugs.python.org/issue43941> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue43625] CSV has_headers heuristic could be improved
Skip Montanaro added the comment: Here's a NEWS entry. -- Added file: https://bugs.python.org/file50132/2021-06-29-07-27-08.bpo-43625.ZlAxhp.rst ___ Python tracker <https://bugs.python.org/issue43625> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue43625] CSV has_headers heuristic could be improved
Skip Montanaro added the comment: Here is a change to the has_header documentation and an extra test case documenting the behavior when the sample contains strings. I'm not sure about the wording of the doc change, perhaps you can tweak it? Seems kind of clumsy to me. If it seems okay to you @andrei.avk, can you fold it into your PR? -- Added file: https://bugs.python.org/file50131/hasheader.diff ___ Python tracker <https://bugs.python.org/issue43625> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue43625] CSV has_headers heuristic could be improved
Skip Montanaro added the comment: I retract my comment about fixed length strings in the non-numeric case. There are clearly test cases (which I probably wrote, considering the values) where the sample as a header but the values are of varying length. Misread of the code on my part. I have obviously not had enough coffee yet this morning. -- ___ Python tracker <https://bugs.python.org/issue43625> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue43625] CSV has_headers heuristic could be improved
Skip Montanaro added the comment: Thanks @andrei.avk. You are right, only the complex test is required. I suppose it's okay to commit this, but reviewing the full code of the has_header method leaves me thinking this is just putting lipstick on a pig. If I read the code correctly, there are two (undocumented) tacit assumptions: 1. The non-header values are numeric. 2. If not numeric, they are fixed length strings whose length generally differs from the length of the putative header. The second criterion means this has a header: ab,de ghi,jkl ghi,jkl but this doesn't: abc,def ghi,jkl ghi,jkl It seems to me that it would be a good idea to at least expand on the documentation of that method and maybe add at least one test case where the CSV sample doesn't have a header. I'll try to get that done and attach a patch. -- versions: +Python 3.11 -Python 3.7 ___ Python tracker <https://bugs.python.org/issue43625> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue23041] csv needs more quoting rules
Skip Montanaro added the comment: Ugh... s/QUOTE_NONNULL/QUOTE_NOTNULL/ Not, Non, None... Perl would treat them all the same, right? -- ___ Python tracker <https://bugs.python.org/issue23041> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue23041] csv needs more quoting rules
Skip Montanaro added the comment: Missed tweaking a couple settings. -- resolution: rejected -> stage: resolved -> needs patch versions: +Python 3.11 -Python 3.8 ___ Python tracker <https://bugs.python.org/issue23041> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue23041] csv needs more quoting rules
Skip Montanaro added the comment:
Okay, I'll reopen this, at least for the discussion of QUOTE_NONNULL.
@erdnaxeli please given an example of how PostgreSQL distinguishes between the
empty string and None cases. Is it a quoted empty string vs an empty field? If
so, modifying @samwyse's original example, is this what you are after?
>>> csv.register_dialect('quote_notnull', quoting=csv.QUOTE_NOTNULL)
>>> csv.writer(sys.stdout, dialect='quote_notnull').writerow(['', None, 42])
"",,"42"
? Can you modify the original two patches to restrict to QUOTE_NONNULL?
--
status: closed -> open
___
Python tracker
<https://bugs.python.org/issue23041>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue44058] 'master' refs in 3.10 version of .azure-pipelines
Skip Montanaro added the comment: Perhaps I should point out that this doesn't matter to me. I just noticed the old name. I can't claim anything is broken that I need. -- ___ Python tracker <https://bugs.python.org/issue44058> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue44060] Define TARGET macro the same even when computed goto support is not enabled
Change by Skip Montanaro : -- keywords: +patch pull_requests: +24612 stage: -> patch review pull_request: https://github.com/python/cpython/pull/25949 ___ Python tracker <https://bugs.python.org/issue44060> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue44060] Define TARGET macro the same even when computed goto support is not enabled
New submission from Skip Montanaro : When the interpreter is compiled with computed goto support, the TARGET macro is defined like this: #define TARGET(op) op: TARGET_##op If computed gotos are disabled, the implementation is simpler: #define TARGET(op) op I'm finding it useful to use those labels as gdb breakpoint targets. Is there some reason not to always define the TARGET_##op label? -- components: Interpreter Core messages: 393099 nosy: skip.montanaro priority: normal severity: normal status: open title: Define TARGET macro the same even when computed goto support is not enabled type: enhancement versions: Python 3.11 ___ Python tracker <https://bugs.python.org/issue44060> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue44058] 'master' refs in 3.10 version of .azure-pipelines
New submission from Skip Montanaro : Should these references to "master" be changed to "main"? % git co 3.10 Switched to branch '3.10' Your branch is up to date with 'origin/3.10'. % egrep master .azure-pipelines/* .azure-pipelines/ci.yml:trigger: ['master', '3.10', '3.9', '3.8', '3.7'] .azure-pipelines/pr.yml:pr: ['master', '3.10', '3.9', '3.8', '3.7'] -- messages: 393092 nosy: skip.montanaro priority: normal severity: normal status: open title: 'master' refs in 3.10 version of .azure-pipelines versions: Python 3.10 ___ Python tracker <https://bugs.python.org/issue44058> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue41111] [C API] Convert a few stdlib extensions to the limited C API (PEP 384)
Skip Montanaro added the comment: > > Skip: By the way, I'm curious, why do you use --with-trace-refs? > I'm still horsing around with register opcodes and got in the habit of building with pydebug and trace refs enabled. -- ___ Python tracker <https://bugs.python.org/issue4> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue41111] [C API] Convert a few stdlib extensions to the limited C API (PEP 384)
Skip Montanaro added the comment: I should revise that comment. The xxlimited and xxlimited_35 modules fail to build. That seems suboptimal, but perhaps is to be expected. Perhaps it would be better that compiling them not be attempted with configuring --with-trace-refs? -- ___ Python tracker <https://bugs.python.org/issue4> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue41111] [C API] Convert a few stdlib extensions to the limited C API (PEP 384)
Skip Montanaro added the comment: The latest commit seems to break the build if configured --with-trace-refs. -- nosy: +skip.montanaro ___ Python tracker <https://bugs.python.org/issue4> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue43627] What are the requirements for a test_sundry-testable script in Tools/scripts?
Change by Skip Montanaro : -- title: What are the requirements for a test_sunry-testable script in Tools/scripts? -> What are the requirements for a test_sundry-testable script in Tools/scripts? ___ Python tracker <https://bugs.python.org/issue43627> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue43625] CSV has_headers heuristic could be improved
Skip Montanaro added the comment:
I assume the OP is referring to this sort of usage:
>>> sniffer = csv.Sniffer()
>>> raw = open("mixed.csv").read()
>>> sniffer.has_header(raw)
False
*sigh*
I really wish the Sniffer class had never been added to the CSV module. I can't
recall who wrote it (the author is long gone). Though I am responsible for the
initial commits, it wasn't me or the main authors of csvmodule.c. As far as I
know, it never really worked well. I can't recall ever using it.
A simpler heuristic would be if the first row contains a bunch of strings and
the second row contains a bunch of numbers, then the file has a header. That
assumes that CSV files consist mostly of numeric data.
Looking at has_header, I see this:
for thisType in [int, float, complex]:
I think this particular problem would be solved if the order of those types
were reversed. The attached diff suggests that as well. Note that the Sniffer
class currently contains no test cases, so that the test I added failed before
the change and passes after doesn't mean it doesn't break someone's mission
critical Sniffer usage.
(Sorry, Raymond. My Github-foo is insufficient to allow me to fork, apply the
diff and create a PR.)
--
keywords: +patch
Added file: https://bugs.python.org/file49915/csv.diff
___
Python tracker
<https://bugs.python.org/issue43625>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue43627] What are the requirements for a test_sunry-testable script in Tools/scripts?
New submission from Skip Montanaro : In my fork of python/cpython I recently created a simple script to help me with my work (I am messing around in the internals and sometimes get blindsided by opcode changes). I stuck the script in Tools/script which caused test_tools.test_sundry to hang. (I suspect it's because my script reads from sys.stdin, but I'm not certain. The old Unix pipeline ways die hard.) Looking around to see how I could modify my script to make it acceptable to test_sundry, I saw nothing about requirements. I tossed it in the TestSundryScripts.other list and now that test completes. Still, it seems there should be a bit written about what it takes for a script to be amenable to the minimal testing test_sundry.py performs. -- components: Tests messages: 389526 nosy: skip.montanaro priority: normal severity: normal status: open title: What are the requirements for a test_sunry-testable script in Tools/scripts? versions: Python 3.10 ___ Python tracker <https://bugs.python.org/issue43627> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue43494] Minor changes to Objects/lnotab_notes.txt
Skip Montanaro added the comment: Closing, per Terry's comment. -- stage: patch review -> resolved status: open -> closed ___ Python tracker <https://bugs.python.org/issue43494> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue43494] Minor changes to Objects/lnotab_notes.txt
Skip Montanaro added the comment: When I submitted the PR one check failed with this error: No news entry in Misc/NEWS.d/next/ or "skip news" label found I'd be surprised if this was important enough for a news entry, and I'm pretty sure I can't add a "skip news" label. -- ___ Python tracker <https://bugs.python.org/issue43494> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue43494] Minor changes to Objects/lnotab_notes.txt
Change by Skip Montanaro : -- keywords: +patch pull_requests: +23621 stage: -> patch review pull_request: https://github.com/python/cpython/pull/24861 ___ Python tracker <https://bugs.python.org/issue43494> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue43494] Minor changes to Objects/lnotab_notes.txt
New submission from Skip Montanaro : For the VM work I'm doing I need to adapt to Mark's new line number table format. (I stalled for several months, hence this rather late report.) As I was reading Objects/lnotab_notes.txt I noticed a couple typos, fixed those and threw in a couple other minor edits. A PR is incoming. -- assignee: Mark.Shannon messages: 388688 nosy: Mark.Shannon, skip.montanaro priority: low severity: normal status: open title: Minor changes to Objects/lnotab_notes.txt versions: Python 3.10 ___ Python tracker <https://bugs.python.org/issue43494> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue42325] UnicodeDecodeError executing ./setup.py during build
New submission from Skip Montanaro :
I recently replaced Ubuntu 20.04 with Manjaro 20.2. In the process my Python
builds broke in the sharedmods target of the Makefile. The tail end of the
traceback is:
File "/home/skip/src/python/cpython/./setup.py", line 246, in grep_headers_for
if function in f.read():
File "/home/skip/src/python/cpython/Lib/codecs.py", line 322, in decode
(result, consumed) = self._buffer_decode(data, self.errors, final)
UnicodeDecodeError: 'utf-8' codec can't decode byte 0xb4 in position 1600:
invalid start byte
The grep_headers_for() function in setup.py appeared to be the culprit, so I
added a print statement to its loop:
def grep_headers_for(function, headers):
for header in headers:
print("***", header, file=sys.stderr)
with open(header, 'r') as f:
if function in f.read():
return True
return False
which printed these lines:
*** /usr/include/umfpack_report_perm.h
*** /usr/include/dbstl_dbc.h
*** /usr/include/itclTclIntStubsFcn.h
*** /usr/include/dbstl_vector.h
*** /usr/include/cholmod_blas.h
*** /usr/include/amd.h
*** /usr/include/m17n-X.h
Sure enough, that m17n-X.h file (attached) doesn't contain utf-8 (my
environment's encoding). According to the Emacs coding cookie at the end, the
file is euc-japan encoded. Would simply catching the exception in
grep_headers_for() be the correct way to deal with this?
--
components: Build
files: m17n-X.h
messages: 380761
nosy: skip.montanaro
priority: normal
severity: normal
status: open
title: UnicodeDecodeError executing ./setup.py during build
versions: Python 3.10
Added file: https://bugs.python.org/file49593/m17n-X.h
___
Python tracker
<https://bugs.python.org/issue42325>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue41826] test_peg_generator compilation warnings
Skip Montanaro added the comment: I created a PR from my patch, but it includes all the merges to my smontanaro/cpython master branch from python/cpython. I thought I was following the instructions properly (https://devguide.python.org/gitbootcamp/#creating-a-pull-request), but I guess I'm missing something. See: https://github.com/python/cpython/pull/22412 Can someone help me make a PR which only differs from the current python/cpython master? -- ___ Python tracker <https://bugs.python.org/issue41826> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue41826] test_peg_generator compilation warnings
Change by Skip Montanaro : -- pull_requests: +21450 stage: -> patch review pull_request: https://github.com/python/cpython/pull/22412 ___ Python tracker <https://bugs.python.org/issue41826> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue41826] test_peg_generator compilation warnings
Skip Montanaro added the comment: Possible patch. All this does is add some C casts. @pablogsal suggested there was more to be done, but my glance at the reference he gave suggested that's already been done. My apologies if I misinterpreted his reference. -- keywords: +patch Added file: https://bugs.python.org/file49474/test_peg_gen.diff ___ Python tracker <https://bugs.python.org/issue41826> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue41826] test_peg_generator compilation warnings
Skip Montanaro added the comment:
> This is because the types of the grammars in
Lib/test/test_peg_generator/test_c_parser.py needs to be updated to use the
new sequences
I'm sorry, that doesn't mean much to me. Is it simply a matter of applying
suitable casts to the various parameters in the C code fragments in those?
For example:
*** /tmp/ediffGoXpTW 2020-09-23 08:06:38.671061988 -0500
---
/home/skip/src/python/cpython/Lib/test/test_peg_generator/test_c_parser.py
2020-09-21 15:54:43.106258797 -0500
***
*** 325,331
compound_stmt[stmt_ty]: with_stmt
with_stmt[stmt_ty]: (
a='with' '(' b=','.with_item+ ')' ':' c=block {
! _Py_With(b, _PyPegen_singleton_seq(p, c), NULL, EXTRA) }
)
with_item[withitem_ty]: (
e=NAME o=['as' t=NAME { t }] { _Py_withitem(e,
_PyPegen_set_expr_context(p, o, Store), p->arena) }
--- 325,331
compound_stmt[stmt_ty]: with_stmt
with_stmt[stmt_ty]: (
a='with' '(' b=','.with_item+ ')' ':' c=block {
! _Py_With((asdl_withitem_seq *)b, *(asdl_stmt_seq
*)*_PyPegen_singleton_seq(p,
c), NULL, EXTRA) }
)
with_item[withitem_ty]: (
e=NAME o=['as' t=NAME { t }] { _Py_withitem(e,
_PyPegen_set_expr_context(p, o, Store), p->arena) }
If so, that's pretty mechanical. Even a dummy like me could produce a patch.
--
___
Python tracker
<https://bugs.python.org/issue41826>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue41826] test_peg_generator compilation warnings
New submission from Skip Montanaro :
I don't see anything like this while building Python proper, but when
test_peg_generator is run, it spews a few compiler warnings. Platform is Ubuntu
20.04. Seems low-ish priority, but I saw no mention of it in a quick bpo
search, so thought I would toss it out there.
-
% ./python ./Tools/scripts/run_tests.py test_peg_generator
/home/skip/src/python/cpython/python -u -W default -bb -E -m test -r -w -j 0 -u
all,-largefile,-audio,-gui test_peg_generator
Using random seed 1793668
0:00:00 load avg: 0.09 Run tests in parallel using 10 child processes
0:00:30 load avg: 0.45 running: test_peg_generator (30.0 sec)
0:00:54 load avg: 0.64 [1/1] test_peg_generator passed (54.8 sec)
In file included from /home/skip/src/python/cpython/Parser/pegen.h:7,
from /tmp/tmp3fq3wryo/parse.c:2:
/tmp/tmp3fq3wryo/parse.c: In function ‘start_rule’:
/tmp/tmp3fq3wryo/parse.c:59:29: warning: passing argument 1 of ‘_Py_Module’
from incompatible pointer type [-Wincompatible-pointer-types]
59 | _res = Module ( a , NULL , p -> arena );
| ^
| |
| asdl_seq * {aka struct *}
/home/skip/src/python/cpython/Include/Python-ast.h:541:39: note: in definition
of macro ‘Module’
541 | #define Module(a0, a1, a2) _Py_Module(a0, a1, a2)
| ^~
/home/skip/src/python/cpython/Include/Python-ast.h:542:35: note: expected
‘asdl_stmt_seq *’ {aka ‘struct *’} but argument is of type
‘asdl_seq *’ {aka ‘struct *’}
542 | mod_ty _Py_Module(asdl_stmt_seq * body, asdl_type_ignore_seq *
type_ignores,
| ^~~~
In file included from /home/skip/src/python/cpython/Parser/pegen.h:7,
from /tmp/tmpybnujtsb/parse.c:2:
/tmp/tmpybnujtsb/parse.c: In function ‘start_rule’:
/tmp/tmpybnujtsb/parse.c:61:29: warning: passing argument 1 of ‘_Py_Module’
from incompatible pointer type [-Wincompatible-pointer-types]
61 | _res = Module ( a , NULL , p -> arena );
| ^
| |
| asdl_seq * {aka struct *}
/home/skip/src/python/cpython/Include/Python-ast.h:541:39: note: in definition
of macro ‘Module’
541 | #define Module(a0, a1, a2) _Py_Module(a0, a1, a2)
| ^~
/home/skip/src/python/cpython/Include/Python-ast.h:542:35: note: expected
‘asdl_stmt_seq *’ {aka ‘struct *’} but argument is of type
‘asdl_seq *’ {aka ‘struct *’}
542 | mod_ty _Py_Module(asdl_stmt_seq * body, asdl_type_ignore_seq *
type_ignores,
| ^~~~
In file included from /home/skip/src/python/cpython/Parser/pegen.h:7,
from /tmp/tmpgbehpd3_/parse.c:2:
/tmp/tmpgbehpd3_/parse.c: In function ‘start_rule’:
/tmp/tmpgbehpd3_/parse.c:77:29: warning: passing argument 1 of ‘_Py_Module’
from incompatible pointer type [-Wincompatible-pointer-types]
77 | _res = Module ( a , NULL , p -> arena );
| ^
| |
| asdl_seq * {aka struct *}
/home/skip/src/python/cpython/Include/Python-ast.h:541:39: note: in definition
of macro ‘Module’
541 | #define Module(a0, a1, a2) _Py_Module(a0, a1, a2)
| ^~
/home/skip/src/python/cpython/Include/Python-ast.h:542:35: note: expected
‘asdl_stmt_seq *’ {aka ‘struct *’} but argument is of type
‘asdl_seq *’ {aka ‘struct *’}
542 | mod_ty _Py_Module(asdl_stmt_seq * body, asdl_type_ignore_seq *
type_ignores,
| ^~~~
/tmp/tmpgbehpd3_/parse.c: In function ‘import_from_rule’:
/tmp/tmpgbehpd3_/parse.c:148:58: warning: passing argument 2 of
‘_Py_ImportFrom’ from incompatible pointer type [-Wincompatible-pointer-types]
148 | _res = _Py_ImportFrom ( c -> v . Name . id , d , 0 , EXTRA
);
| ^
| |
| asdl_seq *
{aka struct *}
In file included from /home/skip/src/python/cpython/Parser/pegen.h:7,
from /tmp/tmpgbehpd3_/parse.c:2:
/home/skip/src/python/cpython/Include/Python-ast.h:625:60: note: expected
‘asdl_alias_seq *’ {aka ‘struct *’} but argument is of type
‘asdl_seq *’ {aka ‘struct *’}
625 | stmt_ty _Py_ImportFrom(identifier module, asdl_alias_seq * names, int
level,
| ~^
/tmp/tmpgbehpd3_/parse.c:190:44: warning: passing argument 2 of
‘_Py_ImportFrom’ from incompatible pointer type [-Wincompatible-pointer-types]
190 | _res = _Py_ImportFrom ( NUL
[issue41561] test_ssl fails in Ubuntu 20.04: test_min_max_version_mismatch
Skip Montanaro added the comment:
> Could you please modify the test case to check for TLS 1.0 and run it Ubuntu?
>
> @requires_minimum_version
> @requires_tls_version('TLSv1_2')
> @requires_tls_version('TLSv1')
> def test_min_max_version_mismatch(self):
Confirmed. test_min_max_version_mismatch passes with those three decorators.
--
___
Python tracker
<https://bugs.python.org/issue41561>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue41561] test_ssl fails in Ubuntu 20.04: test_min_max_version_mismatch
Skip Montanaro added the comment: > > I confirm that Tal Einat's workaround also works. > Should workarounds be required to successfully run the test suite? I routinely unset PYTHONSTARTUP, but that's because I can and sometimes do weird things to support interactive use. It concerns me a bit that any system settings need to be overridden. That suggests to me that it will eventually bite users at runtime. > -- ___ Python tracker <https://bugs.python.org/issue41561> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue41561] test_ssl fails in Ubuntu 20.04: test_min_max_version_mismatch
Skip Montanaro added the comment: @Vladyslav.Bondar I can't tell where you are suggesting MinProtocol should be set. I don't see that particular string in any .c, .h or .py file in the Python source. -- ___ Python tracker <https://bugs.python.org/issue41561> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue41561] test_ssl fails in Ubuntu 20.04: test_min_max_version_mismatch
Skip Montanaro added the comment: This skips the breaking tests (but doesn't actually fix anything). -- keywords: +patch versions: +Python 3.10 -Python 3.8 Added file: https://bugs.python.org/file49450/test_ssl_ubuntu.diff ___ Python tracker <https://bugs.python.org/issue41561> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue41561] test_ssl fails in Ubuntu 20.04: test_min_max_version_mismatch
Skip Montanaro added the comment: Has any progress been made on the Ubuntu 20.04 test_ssl failures? Is there any consensus about it being a Python or Ubuntu problem? -- nosy: +skip.montanaro ___ Python tracker <https://bugs.python.org/issue41561> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue41474] Missing dependency on Include/cpython/frameobject.h
Skip Montanaro added the comment: > > I don't know how to get rid of all those commit messages. > > I suggest you to create a local branch per change, rather than using "master". > > I consider that "origin" is g...@github.com:python/cpython.git. Check your > remotes with "git remote -v". Hmmm... Seems like a bunch of extra work for a one-line change to a Makefile... There's no easier way to create PRs for these trivial changes? -- ___ Python tracker <https://bugs.python.org/issue41474> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue41474] Missing dependency on Include/cpython/frameobject.h
Skip Montanaro added the comment: > they all look to be of the form "Merge remote-tracking branch > 'upstream/master'". Aside from one where I erroneously committed a change to the wrong branch, then backed it out immediately. -- ___ Python tracker <https://bugs.python.org/issue41474> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue41474] Missing dependency on Include/cpython/frameobject.h
Skip Montanaro added the comment: I see what @vstinner is talking about. If you look at those commit messages, they all look to be of the form "Merge remote-tracking branch 'upstream/master'". That is, they are me syncing python/cpython/master to python/smontanaro/master. There is, in fact, just the one file changed, Makefile.pre.in, with the addition of a single dependency. I don't know how to get rid of all those commit messages. -- ___ Python tracker <https://bugs.python.org/issue41474> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue41474] Missing dependency on Include/cpython/frameobject.h
Skip Montanaro added the comment: > Your PR has 124 commits, that looks strange. Funny, it told me just one file had changed (Makefile.pre.in). I was attempting to make a PR against that one change from my fork of master to the main repo. Let me take another crack at it. -- ___ Python tracker <https://bugs.python.org/issue41474> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue41474] Missing dependency on Include/cpython/frameobject.h
Skip Montanaro added the comment: Created a pull request. Hopefully I didn't muff the protocol too badly. -- stage: patch review -> ___ Python tracker <https://bugs.python.org/issue41474> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue41474] Missing dependency on Include/cpython/frameobject.h
Change by Skip Montanaro : -- keywords: +patch pull_requests: +20877 stage: -> patch review pull_request: https://github.com/python/cpython/pull/21732 ___ Python tracker <https://bugs.python.org/issue41474> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue41474] Missing dependency on Include/cpython/frameobject.h
New submission from Skip Montanaro : When Include/cpython/frameobject.h was created, there was no dependency added to Makefile.pre.in. -- components: Build messages: 374809 nosy: skip.montanaro priority: normal severity: normal status: open title: Missing dependency on Include/cpython/frameobject.h type: compile error versions: Python 3.10 ___ Python tracker <https://bugs.python.org/issue41474> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue27580] CSV Null Byte Error
Skip Montanaro added the comment: Looks like my comment removed Remi from the nosy list. Restoring that... -- nosy: +remi.lapeyre ___ Python tracker <https://bugs.python.org/issue27580> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue27580] CSV Null Byte Error
Skip Montanaro added the comment: I'm sorry, but why is this issue coming up again after nearly four years? Especially without a patch? (I apologize. I've gotten a bit more grumpy as I've aged.) Let me summarize a bit of history. Back in the early 2000s, Dave Cole at Object Craft in Australia implemented a C-based CSV module for Python. I don't know exactly what version was his initial target, but I have a vague memory that it was Python 1.5-ish. A few years later that was cleaned up and adapted for inclusion into the Python standard library, being added to Python 2.3. I helped with some of the Python stuff and steered it into the core. Much later (Python 3.x - with the great Unicode unification), it acquired Unicode support. At the time of creation, the only "standard" for CSV files was what Excel could read and write. One of the initial requirements as I recall was that CSV files generated by the module had to be able to survive a round trip to Excel and back. As I indicated in at least one of my previous messages to this thread, knowing how Excel handles CSV files with NUL bytes would be (at least) interesting. I still think so. Can anyone test that? I'm not trying to suggest that gracefully handling NUL bytes wouldn't be useful in certain contexts (I also use find with -print0 routinely to preserve filenames with spaces), and if the CSV module was being written from scratch today, perhaps NUL support would be included. I am happy with the current CSV module as it exists today. I still use it routinely. Adding NUL support wouldn't scratch any itch I have. If you want NUL byte support, either as a delimiter or as a character in a cell, I think you're going to have to submit a patch. Otherwise I suggest this be closed rather than languishing for another four years. -- nosy: -remi.lapeyre ___ Python tracker <https://bugs.python.org/issue27580> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue40762] Writing bytes using CSV module results in b prefixed strings
Skip Montanaro added the comment: I would also that tweaking Python to make this work with no change in Pandas would be a case of the tail wagging the dog. A big tail, but a tail nonetheless. -- ___ Python tracker <https://bugs.python.org/issue40762> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue40762] Writing bytes using CSV module results in b prefixed strings
Skip Montanaro added the comment: This likely worked in the past because bytes == str in Python 2.x. This is just a corner case people porting from 2 to 3 need to address in their code. Papering over it so people using Pandas don't have to do the right thing is no reason to make changes. Bytes aren't strings any longer. A huge effort was undertaken to clean up this aspect of Python's data model in the move to Python 3. Conflating bytes and strings at this point (no matter which way you try to accomplish that conflation) makes no sense to me. The current behavior should not be changed. -- ___ Python tracker <https://bugs.python.org/issue40762> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue40315] Incorrect stacksize in code object
Skip Montanaro added the comment: Thanks, Serhiy. -- resolution: -> not a bug stage: -> resolved status: open -> closed ___ Python tracker <https://bugs.python.org/issue40315> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue40315] Incorrect stacksize in code object
New submission from Skip Montanaro : Consider this trivial function: >>> def f(): ... while True: ... pass ... and its disassembly: >>> dis.dis(f) 3 >> 0 JUMP_ABSOLUTE 0 2 LOAD_CONST 0 (None) 4 RETURN_VALUE Despite its infinite-loop-ness, the generated LOAD_CONST/RETURN_VALUE pair suggests the code object's stacksize should be 1, but it's 0: >>> print(f.__code__.co_stacksize) 0 I understand that the compiler might have decided the code was unreachable and the LOAD_CONST instruction would never be reached, but if that was the case, why would that instruction pair be generated? This is only of interest because my register virtual machine translator trusts that the co_nlocals and co_stacksize attributes of the code object reflect the actual space allocation in the frame object. I can use max(1, f.__code__.co_stacksize + f.__code__.co_nlocals) as the allocated locals+stack space. (That first slot in the frame object will always be available.) That makes this example translate, but doesn't guarantee there's not a bug in determination of the stack size which could pop up again later. -- components: Interpreter Core messages: 366692 nosy: skip.montanaro priority: normal severity: normal status: open title: Incorrect stacksize in code object type: compile error versions: Python 3.9 ___ Python tracker <https://bugs.python.org/issue40315> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue39583] Remove superfluous "extern C" bits from Include/cpython/*.h
Change by Skip Montanaro : -- nosy: +ncoghlan, vstinner ___ Python tracker <https://bugs.python.org/issue39583> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue39583] Remove superfluous "extern C" bits from Include/cpython/*.h
Change by Skip Montanaro : -- keywords: +patch pull_requests: +17787 stage: -> patch review pull_request: https://github.com/python/cpython/pull/18413 ___ Python tracker <https://bugs.python.org/issue39583> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue39583] Remove superfluous "extern C" bits from Include/cpython/*.h
New submission from Skip Montanaro : I noticed that the files in Include/cpython also have extern C declarations, despite the fact that the only files which #include them do as well. Seems like a small bit of cleanup. PR incoming... -- components: C API messages: 361628 nosy: skip.montanaro priority: normal severity: normal status: open title: Remove superfluous "extern C" bits from Include/cpython/*.h type: enhancement versions: Python 3.9 ___ Python tracker <https://bugs.python.org/issue39583> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue36051] Drop the GIL during large bytes.join operations?
Skip Montanaro added the comment: I think to avoid compiler warnings about 'save' perhaps being used uninitialized, it should be initialized to NULL when declared on line 21 of Objects/stringlib/join.h. -- nosy: +skip.montanaro status: closed -> open Added file: https://bugs.python.org/file48873/join.diff ___ Python tracker <https://bugs.python.org/issue36051> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue37709] CSVReader ignores dialect.lineterminator
Change by Skip Montanaro : Added file: https://bugs.python.org/file48522/lfmapper.py ___ Python tracker <https://bugs.python.org/issue37709> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue37709] CSVReader ignores dialect.lineterminator
Skip Montanaro added the comment: Looking at your sample file, it seems stranger than you first indicated. Your line terminator actually appears to be '\x07\r\n', not just '\x07'. Opening your file in text mode will leave you with '\x07' as the last character of the last cell in each row. I've attached two files, bell.csv, which has just '\x07' as the line terminator, and lfmapper.py, which provides a class (suboptimally named LFMapper) which takes a file object opened in binary mode and optional line_terminator and encoding args, and performs the necessary slicing of the input bytes, decoding them and returning strings. Unless Python grows a way for you to tell the open() function what string to use as the line terminator in text mode, I don't think your example is ever going to work without some sort of shim class. -- Added file: https://bugs.python.org/file48521/bell.csv ___ Python tracker <https://bugs.python.org/issue37709> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue37709] CSVReader ignores dialect.lineterminator
Skip Montanaro added the comment: I imagine this is a corner case which will continue to cause problems. At the time the csv module was originally written, I believe the authors' intent was to read and write CSV files which were compatible with Excel. In Python 3, you have to open input files in text mode (that provides the underlying line splitting behavior). Consequently, you're not going to see proper line splitting with unadorned files. Have you only tried this with Python 3? If you have tried Python 2, were you able to get it to work without your workaround? -- ___ Python tracker <https://bugs.python.org/issue37709> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue27497] csv module: Add return value to DictWriter.writeheader
Skip Montanaro added the comment: I think this is ready to go. I added a comment to PR12306. As I am no longer a committer, I'm not sure what the next step is. -- ___ Python tracker <https://bugs.python.org/issue27497> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue17267] datetime.time support for '+' and '-'
Change by Skip Montanaro : -- nosy: -skip.montanaro ___ Python tracker <https://bugs.python.org/issue17267> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue30825] csv.Sniffer does not detect lineterminator
Skip Montanaro added the comment: A couple comments. 1. Terry Reedy wrote: > The csv expert listed in https://devguide.python.org/experts/ is marked as > inactive That would be me. I am indeed inactive w.r.t. fixing broken stuff, and don't want to feel obligated to jump in with both feet when a CSV ticket is raised. Still, I keep half an eye on things. If people are actually interested in my opinion on such stuff, drop me a line. 2. Regarding the csv.Sniffer class... I've personally never found it useful, and would be happy to see it deprecated. I occasionally define a delimiter other than comma, and never specify the quotechar. (I've never seen anything other than quotation marks used anyway.) As others have indicated, the line terminator is kind of unnecessary with Python 3 (unless you need something really weird). If you actually need to specify a delimiter, I think giving a set of candidate delimiters would be sufficient. The first one encountered wins. Maybe I'm just getting old and cranky, but deprecation is the fork in the road I'd take, given the choice. Second choice would be to simplify the delimiter sniffing logic and get rid of anything to do with line terminators. Skip -- ___ Python tracker <https://bugs.python.org/issue30825> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue34132] Obscure netrc parser "bug"
Change by Skip Montanaro : Added file: https://bugs.python.org/file47697/netrc-blank-comment ___ Python tracker <https://bugs.python.org/issue34132> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue34132] Obscure netrc parser "bug"
New submission from Skip Montanaro : Not sure I can really call this a bug, however there is a behavioral change between 2.7 and at least 3.6 and 3.7 (probably earlier versions of the 3.x series as well). There is no spec for .netrc files that I can find, certainly nothing which mentions comment or blank lines. Still, Python's netrc file parser seems happy with both. However, in 3.x a blank line followed immediately by a comment line containing actual comment text causes the parser to raise a parse error. I've attached two netrc files, netrc-comment-blank, and netrc-blank-comment, identical save for the ordering of a blank line and a comment line. Here's what a 2.7.14 session looks like: Python 2.7.14 |Anaconda, Inc.| (default, Mar 27 2018, 17:29:31) [GCC 7.2.0] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> import netrc >>> rc = netrc.netrc(file="/home/skip/tmp/netrc-comment-blank") >>> rc = netrc.netrc(file="/home/skip/tmp/netrc-blank-comment") Here's 3.7.0: Python 3.7.0 (default, Jun 28 2018, 13:15:42) [GCC 7.2.0] :: Anaconda, Inc. on linux Type "help", "copyright", "credits" or "license" for more information. >>> import netrc >>> rc = netrc.netrc(file="/home/skip/tmp/netrc-comment-blank") >>> rc = netrc.netrc(file="/home/skip/tmp/netrc-blank-comment") Traceback (most recent call last): File "", line 1, in File "/home/skip/miniconda3/envs/python3/lib/python3.7/netrc.py", line 30, in __init__ self._parse(file, fp, default_netrc) File "/home/skip/miniconda3/envs/python3/lib/python3.7/netrc.py", line 63, in _parse "bad toplevel token %r" % tt, file, lexer.lineno) netrc.NetrcParseError: bad toplevel token 'Comment' (/home/skip/tmp/netrc-blank-comment, line 2) -- components: Library (Lib) files: netrc-comment-blank messages: 321779 nosy: skip.montanaro priority: normal severity: normal stage: needs patch status: open title: Obscure netrc parser "bug" type: behavior versions: Python 3.6, Python 3.7, Python 3.8 Added file: https://bugs.python.org/file47696/netrc-comment-blank ___ Python tracker <https://bugs.python.org/issue34132> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue33556] leftover thread crumb in threading.ident docstring
Change by Skip Montanaro : -- keywords: +patch pull_requests: +6622 stage: needs patch -> patch review ___ Python tracker <https://bugs.python.org/issue33556> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue33556] leftover thread crumb in threading.ident docstring
New submission from Skip Montanaro : There is a leftover reference to "thread.get_ident" in the docstring for threading.ident. I believe it needs a leading underscore. Hopefully a PR isn't required for this. I'm not equipped to generate one at the moment, and this seems like a pretty trivial/obvious fix. -- components: Library (Lib) keywords: easy messages: 316931 nosy: skip.montanaro priority: normal severity: normal stage: needs patch status: open title: leftover thread crumb in threading.ident docstring versions: Python 3.6, Python 3.7, Python 3.8 ___ Python tracker <https://bugs.python.org/issue33556> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue33099] test_poplib hangs with the changes done in PR
Skip Montanaro added the comment: @christian.heimes I figured you probably didn't need it, but I did that work before I discovered this ticket. And as a nice bonus, I got to learn git bisect. :-) -- ___ Python tracker <https://bugs.python.org/issue33099> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue33099] test_poplib hangs with the changes done in PR
Skip Montanaro added the comment: Just in case this would be useful to others, git bisect led me to this commit as the source of the problem: 61d478c71c5341cdc54e6bfb4ace4252852fd972 is the first bad commit commit 61d478c71c5341cdc54e6bfb4ace4252852fd972 Author: Christian Heimes Date: Sat Jan 27 15:51:38 2018 +0100 bpo-31399: Let OpenSSL verify hostname and IP address (#3462) bpo-31399: Let OpenSSL verify hostname and IP The ssl module now uses OpenSSL's X509_VERIFY_PARAM_set1_host() and X509_VERIFY_PARAM_set1_ip() API to verify hostname and IP addresses. * Remove match_hostname calls * Check for libssl with set1_host, libssl must provide X509_VERIFY_PARAM_set1_host() * Add documentation for OpenSSL 1.0.2 requirement * Don't support OpenSSL special mode with a leading dot, e.g. ".example.org" matches "www.example.org". It's not standard conform. * Add hostname_checks_common_name Signed-off-by: Christian Heimes :04 04 09f4c8a18941f926c1f79e2f07dfd7731edf74c2 798ae3fab880e3365c490d56935901a4c18fd3bd M Doc :04 04 f35a1b4e2144050dfc4c7dbb02b7d92e3de1c2d0 7af4e4a8e82eafc6e7f2f4392c951213777f12c4 M Lib :04 04 e287c27f4db61beae905c21b9194bb930c13 59e6fc63d296f7fe3187ff0987a04ce2d1d0 M Misc :04 04 95250f4c1009b5f10ec392c186908698d78f9cd3 160ebeb2c63d1ca305c7e37a0b555900b5084d20 M Modules :04 04 8adc7f664a8eaa667f4540f537304d7f9de672d4 41ea621f5433077f6dd776f4c2c51f7a8e4cab0f M PC :100644 100644 a6f4488cc99941abaa8b6fb7c53079b7cc292f9f ba0a7624cfcd0129e73bc218510f398001514df8 M setup.py -- nosy: +skip.montanaro ___ Python tracker <https://bugs.python.org/issue33099> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue27805] io.open('/dev/stdout', 'a') raises OSError with errno=ESPIPE
Skip Montanaro added the comment: I was bitten by this porting a system from Python 2.7 to 3.6. "/dev/stderr" is a very nice default for logfiles. Users will frequently override the default, so you really want to open the logfile in append mode. Having to jump through hoops to avoid blasting a user's logfile is kinda dumb, and as others have pointed out, error-prone. os.open works just fine with O_WRONLY|O_APPEND as the flags. /dev/null can be opened in append mode, but not /dev/stderr or /dev/stdout. -- nosy: +skip.montanaro ___ Python tracker <https://bugs.python.org/issue27805> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15817] Misc/gdbinit: Expose command documentation to gdb help
Change by Skip Montanaro : -- versions: +Python 3.7 -Python 3.4 ___ Python tracker <https://bugs.python.org/issue15817> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15817] Misc/gdbinit: Expose command documentation to gdb help
Skip Montanaro added the comment: This looks good to me. I added a pull request with a couple minor tweaks. Unfortunately, I can't tell how to add a "skip news" label. This doesn't seem "big" enough to warrant it. -- nosy: +skip.montanaro ___ Python tracker <https://bugs.python.org/issue15817> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15817] Misc/gdbinit: Expose command documentation to gdb help
Change by Skip Montanaro : -- pull_requests: +6094 stage: -> patch review ___ Python tracker <https://bugs.python.org/issue15817> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15257] Misc/.gdbinit:pystack is too brittle
Skip Montanaro added the comment: I would prefer if these macros remain standalone (and thus fragile). Despite Python support in gdb, not everyone (more than five years after the bug report) don't use a gdb which was built --with-python. There is better support for gdb integration elsewhere in the CPython code base: Tools/gdb/libpython.py. -- nosy: +skip.montanaro resolution: -> rejected stage: -> resolved status: open -> closed ___ Python tracker <https://bugs.python.org/issue15257> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue29673] Some gdb macros are broken in 3.6
Change by Skip Montanaro : -- nosy: -skip.montanaro ___ Python tracker <https://bugs.python.org/issue29673> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1818] Add named tuple reader to CSV module
Skip Montanaro added the comment: FWIW, I relinquished my check-in privileges quite awhile ago. This should almost certainly no longer be assigned to me. S -- ___ Python tracker <https://bugs.python.org/issue1818> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue32594] File object 'name' attribute inconsistent type and not obviously documented
Skip Montanaro added the comment:
I'm not terribly concerned with the end result, only that we wind up with a
more consistent system. As I see it, there are two main problems:
1. The type of the name attribute varies
2. The name attribute appears to be undocumented, at least not in the obvious
place.
Of lesser importance, but still unintuitive, is that the "name" attribute
doesn't refer to an actual name in the filesystem. (I realize that the "name"
of sys.std{in,out,err} is also meaningless when interpreted as an actual
filename, but that ship sailed long ago.)
I realize that it might well be infeasible to modify behavior at this point. I
do think it important to document the "name" attribute (item #2). After all, it
doesn't appear to be obviously private.
I live in a Linux-only world, so this workaround in my own code is likely not
useful everywhere, but, when I try to convert a builtin file object to an
io.TextIOWrapper object using io.open(f.fileno()), I actually do this:
io.open("/dev/fd/{}".format(f.fileno()), ...)
This gives me a meaningful "name" attribute in that it is a string, and that it
names an actual filename. How this might work on systems without "/dev/fd", I
don't know, but might be worth thinking about for a couple minutes before
dismissing it out-of-hand.
--
___
Python tracker
<https://bugs.python.org/issue32594>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue32594] File object 'name' attribute inconsistent type and not obviously documented
Skip Montanaro added the comment: Apologies for the incomplete report. In 2.7 this anomaly exists in the io.open() function. You are correct, builtin open() in 2.x doesn't support opening by file descriptor. -- ___ Python tracker <https://bugs.python.org/issue32594> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue32594] File object 'name' attribute inconsistent type and not obviously documented
New submission from Skip Montanaro : I stumbled on what I think is an inconsistency in the "name" attribute of file objects. When a file is opened with an existing file descriptor, the "name" attribute is of type int (this from a 3.6.4 session, but it also exists in 2.7): >>> import sys >>> sys.stderr.name '' >>> f = open(sys.stderr.fileno()) >>> f.name 2 >>> type(f.name) I thought it odd that the standard I/O objects would be blessed with string filenames (despite not representing real filesystem paths), but that files opened by file descriptor would have that file descriptor as their name. I looked in the documentation for open(): https://docs.python.org/3/library/functions.html#open but saw no mention of the "name" attribute at all. In fact, the first argument to open() is called "file", so it's not obvious that the "name" attribute needs to be a copy of that parameter. It seems to me that "name" attributes of open file objects should be of a consistent type, even if they might not represent an actual path in the filesystem. Even if this dual-type behavior is retained, it should be documented. -- assignee: docs@python components: Documentation, IO, Interpreter Core messages: 310237 nosy: docs@python, skip.montanaro priority: normal severity: normal status: open title: File object 'name' attribute inconsistent type and not obviously documented type: behavior versions: Python 2.7, Python 3.6, Python 3.7, Python 3.8 ___ Python tracker <https://bugs.python.org/issue32594> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue30129] functools.partialmethod should look more like what it's impersonating.
Skip Montanaro added the comment: Again, my apologies for the crappy initial bug report. Hopefully this comment and the two files I just attached demonstrate what I am getting at. I just uploaded a stupid little example, partial3.py. Stupid, but still, it demonstrates part of how I think docstrings on these partial methods could be improved. If you run it (I'm using Python 3.6.1), note that the doc strings for the sum method (instance and class), look wrong: Child.sum doc: None c.sum doc: partial(func, *args, **keywords) - new function with partial application of the given arguments and keywords. The file, ft.diff, includes a one-line patch to partialmethod.__get__ which corrects the docstring for the instance of the Child class: Child.sum doc: None c.sum doc: sum doc I haven't looked to see where the docstring of Child.sum could be set, but I believe it should be fairly straightforward for someone more familiar with this code. Also, the patch doesn't improve the output of pydoc: partial3.Child = class Child(builtins.object) | Methods defined here: | | diff(self, arg1, arg2) | diff doc | | sum = _method(self, arg2) | | -- | Data descriptors defined here: | | __dict__ | dictionary for instance variables (if defined) | | __weakref__ | list of weak references to the object (if defined) -- ___ Python tracker <http://bugs.python.org/issue30129> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue30129] functools.partialmethod should look more like what it's impersonating.
Changes by Skip Montanaro : -- keywords: +patch Added file: http://bugs.python.org/file46824/ft.diff ___ Python tracker <http://bugs.python.org/issue30129> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue30129] functools.partialmethod should look more like what it's impersonating.
Changes by Skip Montanaro : Added file: http://bugs.python.org/file46823/partial3.py ___ Python tracker <http://bugs.python.org/issue30129> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue30129] functools.partialmethod should look more like what it's impersonating.
Skip Montanaro added the comment: Yeah, sorry about that. I work in an environment where I can't "eject" any code from my work computer. I've come up with a simple Python3 example, but it will have to wait until I can recreate it from scratch on my home computer. -- ___ Python tracker <http://bugs.python.org/issue30129> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue30129] functools.partialmethod should look more like what it's impersonating.
New submission from Skip Montanaro:
I needed to create a partial method in Python 2.7, so I grabbed
functools.partialmethod from a Python 3.5.2 install. For various reasons, one
of the reasons I wanted this was to suck in some methods from a delegated class
so they appeared in dir() and help() output on the primary class (the one
containing the partialmethod objects). Suppose I have
class Something:
def meth(self, arg1, arg2):
"meth doc"
return arg1 + arg2
then in the metaclass for another class I construct an attribute (call it
"mymeth") which is a partialmethod object. When I (for example), run pydoc,
that other class's attribute appears as:
mymeth =
It would be nice if it at least included the doc string from meth, something
like:
mymeth =
meth doc
Even better would be a proper signature:
mymeth(self, arg1, arg2)
meth doc
In my copy of functools.partialmethod, I inserted an extra line in __get__,
right after the call to partial():
results.__doc__ = self.func.__doc__
That helps a bit, as I can
print("mymeth doc:", inst.mymeth.__doc__)
and see
mymeth doc: meth doc
displayed. That's not enough for help()/pydoc though.
I suspect the heavy lifting will have to be done in pydoc.Doc.document().
inspect.isroutine() returns False for functools.partial objects. I also see
_signature_get_partial() in inspect.py. That might be the source of the
problem. When I create a partialmethod object in my little example, it actually
looks like a functools.partial object, not a partialmethod object. It's not
clear that this test:
if isinstance(partialmethod, functools.partialmethod):
in inspect._signature_from_callable() is testing for the correct type.
Apologies that I can't easily provide a detailed example. My Python 2.x
metaclass example (where I'm smashing methods from one class into another)
doesn't work in Python 3.x for some reason, the whole partialmethod thing isn't
available in Python 2.x (inspect doesn't know about partialmethod or partial)
and it's not really a "hello world"-sized example anyway. I'll beat on things a
bit more to try and craft a workable Python 3.x example.
--
components: Library (Lib)
messages: 292050
nosy: skip.montanaro
priority: normal
severity: normal
status: open
title: functools.partialmethod should look more like what it's impersonating.
type: enhancement
versions: Python 3.7
___
Python tracker
<http://bugs.python.org/issue30129>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue29955] logging decimal point should come from locale
Skip Montanaro added the comment: Vinay> I would like to close this issue now... Go for it. As I indicated in a previous comment, the exercise was as much to try and come to grips with the process as to actually make the change. There certainly appear to be good reasons to leave well enough alone. My primary (though minor) concerns at this point are: * the datetime module hard-coded it one way (period) while the logging package hard-coded it the other way. * other logging packages I've used/inherited in other languages (admittedly, pretty much Americo-centric) all seem to have used periods. This only became an issue for me because I recently started using Flask, which sets up the logging environment and provides no straightforward API for me to reconfigure its logger. (Peter Otten demonstrated a way to do this using functools.partial, which, while doable, certainly doesn't strike me as straightforward.) In cases where I'm in complete control, configuring my own logging environment makes sense. (In reality, when I'm in complete control, I tend to roll my own 20-line Logger class and not use the logging module at all, but that's a historical artifact of me discovering performance issues several years ago in applications which logged heavily. Those issues may well not exist today.) Skip -- status: pending -> open ___ Python tracker <http://bugs.python.org/issue29955> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue29955] logging decimal point should come from locale
Skip Montanaro added the comment: One example demonstrating that the datetime module at least prefers a decimal point: >>> import dateutil.parser >>> t = '1993-04-21 08:03:00,123' >>> dateutil.parser.parse(t) datetime.datetime(1993, 4, 21, 8, 3, 0, 123000) >>> dateutil.parser.parse(t).isoformat() '1993-04-21T08:03:00.123000' Looking at datetime.py, it appears the dot is hard-coded there. Maybe there would be value in the right hand (logging) and the left hand (datetime) doing things the same way? -- ___ Python tracker <http://bugs.python.org/issue29955> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue29955] logging decimal point should come from locale
Skip Montanaro added the comment: It's Vinay's code, so what he wants should carry the most weight. I did this as much as an exercise in figuring out the whole pull request/bug report process as anything. -- ___ Python tracker <http://bugs.python.org/issue29955> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue29955] logging decimal point should come from locale
New submission from Skip Montanaro: The logging module hard codes the decimal point for timestamps to be ",". It should use locale.localeconv()["decimal_point"] instead. -- components: Library (Lib) messages: 290927 nosy: skip.montanaro priority: normal severity: normal status: open title: logging decimal point should come from locale type: behavior versions: Python 3.7 ___ Python tracker <http://bugs.python.org/issue29955> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue29673] Some gdb macros are broken in 3.6
Skip Montanaro added the comment: Note that these macros were always expected to be fragile. They depend to a great extent on the layout of the functions in Python/ceval.c. I've had to tweak them a couple times over the years. I'm pretty sure the gdb instance I have available to me at work wasn't configured --with-python, and corporate policies would prevent me from downloading the source and building my own private version. For me, Misc/gdbinit is likely to be the best I can do for the foreseeable future. If the layout of ceval.c has changed sufficiently between Python 2.x and 3.x, perhaps two versions of gdbinit are warranted, with the version delivered for Python 3 being appropriate for the current release. -- nosy: +skip.montanaro ___ Python tracker <http://bugs.python.org/issue29673> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue28487] missing _math.o target in 2.7 Makefile
Skip Montanaro added the comment: The problem is solved. It seems there were changes in my 2.7 checkout which hg update wouldn't overwrite. I vaguely remember applying somebody's patch for a bug quite awhile ago. Apparently, I failed to revert that change before moving on. I obviously wasn't paying close attention, but I'm still kind of surprised that hg update wouldn't tell me about files it couldn't update based on local changes. -- ___ Python tracker <http://bugs.python.org/issue28487> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
