[issue23005] typos on heapq doc
New submission from Martin Matusiak: - which are pre-sorted sequences, which size is usually related to the amount of CPU memory whose size - Tournaments are a good way to that. Tournaments are a good way to achieve that. -- components: Library (Lib) files: heapq_docs_typos.diff keywords: patch messages: 232273 nosy: ned.deily, numerodix priority: normal severity: normal status: open title: typos on heapq doc type: enhancement versions: Python 2.7, Python 3.2, Python 3.3, Python 3.4, Python 3.5 Added file: http://bugs.python.org/file37381/heapq_docs_typos.diff ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue23005 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22195] Make it easy to replace print() calls with logging calls
Martin Matusiak added the comment: Would it make sense for the logging module to supply something like the LoggerWriter class you wrote? With a section in the documentation that says something like have you been logging using print() this whole time? No problem, just do sys.stdout = LoggerWriter()? -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue22195 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22195] Make it easy to replace print() calls with logging calls
Martin Matusiak added the comment: Hm, on this model you still have to go and update all your print() statements with the file= argument. That's less invasive than replacing them with logger.info(), but still not very elegant. You're also repeating the stream on every occurrence, so easy to leave it out by mistake. -- nosy: +numerodix ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue22195 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22205] debugmallocstats test is cpython only
New submission from Martin Matusiak: sys._debugmallocstats is a cpython specific feature, so test_debugmallocstats should be marked as such. -- files: debugmallocstats.diff keywords: patch messages: 225362 nosy: numerodix, serhiy.storchaka priority: normal severity: normal status: open title: debugmallocstats test is cpython only Added file: http://bugs.python.org/file36379/debugmallocstats.diff ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue22205 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22076] csv module bad grammar in exception message
New submission from Martin Matusiak: The csv module has an exception message with bad grammar: - delimiter must be an 1-character string an should be a -- components: Library (Lib) files: csv_grammar_fix.diff keywords: patch messages: 224028 nosy: haypo, numerodix, serhiy.storchaka priority: normal severity: normal status: open title: csv module bad grammar in exception message type: enhancement versions: Python 3.5 Added file: http://bugs.python.org/file36103/csv_grammar_fix.diff ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue22076 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22036] Obsolete reference to stringobject in comment
Changes by Martin Matusiak numero...@gmail.com: -- nosy: +benjamin.peterson ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue22036 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22036] Obsolete reference to stringobject in comment
New submission from Martin Matusiak: bits shared by the stringobject and unicodeobject implementations (and possibly other modules, in a not too distant future). stringobject should be bytesobject -- components: Interpreter Core files: fix_typo_stringlib.diff keywords: patch messages: 223669 nosy: numerodix priority: normal severity: normal status: open title: Obsolete reference to stringobject in comment type: enhancement versions: Python 3.5 Added file: http://bugs.python.org/file36034/fix_typo_stringlib.diff ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue22036 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue19311] devguide: hg bisect section could be clearer
New submission from Martin Matusiak: The offending section: http://docs.python.org/devguide/faq.html#how-do-i-find-which-changeset-introduced-a-bug-or-regression I think this could be improved a bit. The key point is that hg bisect --bad/good is a command relative to the checked out changeset. So the instructions tell me to run hg bisect --bad and then hg bisect --good, but they could do with a more explicit instruction to run hg update ref-id in between. - You can conveniently choose a faraway changeset (for example a former release), and check that it is indeed “good” This could be construed as just peeking at the changeset using hg log or whatever, not actually checking it out. - Mercurial will automatically bisect so as to narrow the range of possible culprits, until a single changeset is isolated. Here too it could be made more explicit that mercurial will navigate to (ie. check out each changeset) as it's doing this, so that at every invocation of hg bisect --bad/good the changeset to be tested is checked out for you, not merely computed. -- components: Devguide messages: 200565 nosy: ezio.melotti, numerodix priority: normal severity: normal status: open title: devguide: hg bisect section could be clearer ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue19311 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue19312] Typo in devguide - compiler
New submission from Martin Matusiak: - The purpose of this document is to outline how the latter three steps of the process works. work -- components: Devguide files: typo_compiler.diff keywords: patch messages: 200567 nosy: ezio.melotti, numerodix priority: normal severity: normal status: open title: Typo in devguide - compiler Added file: http://bugs.python.org/file32243/typo_compiler.diff ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue19312 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue19314] Typo in devguide - compiler
New submission from Martin Matusiak: - Querying data from the node structs can be done with the following macros (which are all defined in Include/token.h They are actually in Include/node.h, which is logical, because that is where node is defined. -- components: Devguide files: typo_compiler_nodeh.diff keywords: patch messages: 200569 nosy: ezio.melotti, numerodix priority: normal severity: normal status: open title: Typo in devguide - compiler Added file: http://bugs.python.org/file32244/typo_compiler_nodeh.diff ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue19314 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue19315] devguide: compiler - poor wording
New submission from Martin Matusiak: Location: http://docs.python.org/devguide/compiler.html#parse-trees - To tie all of this example, consider the rule for ‘while’: Probably meant to be: To tie all of this together with an example, ... - The node representing this will have TYPE(node) == while_stmt and the number of children can be 4 or 7 depending on if there is an ‘else’ statement. s/if/whether/g is slightly better English imo - To access what should be the first ‘:’ and require it be an actual ‘:’ token, (REQ(CHILD(node, 2), COLON)`. Understandable with some effort on the reader's part, but it's not very well worded. Notice also the closing backtick: markup typo. -- components: Devguide messages: 200570 nosy: ezio.melotti, numerodix priority: normal severity: normal status: open title: devguide: compiler - poor wording ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue19315 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue19316] devguide: compiler - wording
New submission from Martin Matusiak: - All code relating to the arena is in either Include/pyarena.h or Python/pyarena.c . I propose: All code relating to the arena is either in Include/pyarena.h or in Python/pyarena.c . -- components: Devguide files: wording_compiler.diff keywords: patch messages: 200572 nosy: ezio.melotti, numerodix priority: normal severity: normal status: open title: devguide: compiler - wording Added file: http://bugs.python.org/file32246/wording_compiler.diff ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue19316 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue19316] devguide: compiler - wording
Martin Matusiak added the comment: - This needs to only be called in strategic areas where the compiler exits. I propose: This only needs to be called in strategic areas where the compiler exits. -- Added file: http://bugs.python.org/file32247/wording_compiler2.diff ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue19316 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue19316] devguide: compiler - wording
Martin Matusiak added the comment: - The functions called to generate AST nodes from the parse tree all have the name ast_for_xx where xx is what the grammar rule that the function handles (alias_for_import_name is the exception to this). I'm not sure if this ought to be where xx is the grammar rule that the function handles or where xx is the name of the grammar rule that the function handles. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue19316 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue19316] devguide: compiler - wording
Martin Matusiak added the comment: - Function and macros for creating and using asdl_seq * types as found in Python/asdl.c and Include/asdl.h: I propose: The following are functions and macros for creating and using asdl_seq * types as found in Python/asdl.c and Include/asdl.h: -- Added file: http://bugs.python.org/file32248/wording_compiler3.diff ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue19316 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue19316] devguide: compiler - wording
Martin Matusiak added the comment: - As for handling the line number on which a statement is defined, is handled by compiler_visit_stmt() and thus is not a worry. I don't understand the final clause here. What is not a worry and why would it be a worry? The grammar is awkward as well. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue19316 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue19316] devguide: compiler - wording
Martin Matusiak added the comment: - But you will also need to change the ‘compiler’ package. The key files to do that are Lib/compiler/pyassem.py and Lib/compiler/pycodegen.py . compiler was removed in 2.6 or 2.7 iirc. I think it's safe to remove these two sentences. -- Added file: http://bugs.python.org/file32249/wording_compiler_oldpackage.diff ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue19316 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue19316] devguide: compiler - wording
Martin Matusiak added the comment:
- If you wish to make changes that affect the output of bytecode without having
to update the magic number each time (while testing your changes) you can just
delete your old .py(c|o) files! Even though you will end up changing the magic
number if you change the bytecode, while you are debugging your work you will
be changing the bytecode output without constantly bumping up the magic number.
This means you end up with stale .pyc files that will not be recreated. Running
find . -name '*.py[co]' -exec rm -f {} ';' should delete all .pyc files you
have, forcing new ones to be created and thus allow you test out your new
bytecode properly.
I propose:
Any time you make changes that affect the output of bytecode you will need to
update the magic number as well, otherwise Python will reuse your old .pyc
files and you will not be able to test your new bytecode properly. If you do
not wish to constantly bump the magic number you can just delete the old .pyc
files each time by running find . -name '*.py[co]' -exec rm -f {} ';'
--
Added file: http://bugs.python.org/file32250/wording_compiler4.diff
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue19316
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue19316] devguide: compiler - wording
Martin Matusiak added the comment: - marshaling marshalling -- Added file: http://bugs.python.org/file32251/wording_typo.diff ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue19316 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue19316] devguide: compiler - wording
Martin Matusiak added the comment: - import.c - Home of the magic number (named MAGIC) for bytecode versioning Probably out of date. I cannot find MAGIC being defined in this file. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue19316 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue19316] devguide: compiler - wording
Martin Matusiak added the comment: - Lib/ - compiler/ - pyassem.py - One of the files that must be modified if Include/opcode.h is changed. - pycodegen.py - One of the files that must be modified if Include/opcode.h is changed. More mentions of the compiler package. -- Added file: http://bugs.python.org/file32252/wording_compiler_oldpackage2.diff ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue19316 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue18401] Tests for pdb import ~/.pdbrc
Martin Matusiak added the comment: I have been thinking about a fix for this. A straightforward fix would be to add a kwarg readrc=True to the constructor of Pdb that will default to reading the rc files as it does now, and allows disabling this default. The implication is that all tests in stdlib will need to use pdb.Pdb(readrc=False).set_trace() instead of just pdb.set_trace(). This would impact (from what I can see) doctest.py, test_pdb.py and test_doctest.py, and would also require some kind of warning/notice instructing test writers to follow this convention. I started working on a patch for this (attached), which works for test_pdb, but I can't get the tests in test_doctest to work yet. It would also be useful to have a test that demonstrates this problem and I'm not sure what the best approach is... should it show that doctests fail? If so, and knowing that Pdb reads rc files from a) $HOME/.pdbrc and b) ./.pdbrc, the test could: a) unset os.environ['HOME'] b) use a tmpdir and put a temporary .pdbrc file there, with some invalid Python code c) chdir to that tmpdir Then to trigger the problem it could write a small script containing a doctest that internally does pdb.set_trace(), run the module and demonstrate that the doctest failed. And then teardown all the temporary resources in a finally block. -- keywords: +patch nosy: +numerodix Added file: http://bugs.python.org/file32260/pdb_add_readrc_kwarg.diff ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue18401 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue8083] urllib proxy interface is too limited
Changes by Martin Matusiak numero...@gmail.com: -- nosy: +numerodix ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue8083 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue7757] sys.path is incorrect when prefix is
Changes by Martin Matusiak numero...@gmail.com: -- nosy: +numerodix ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue7757 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue19318] break more than once
Changes by Martin Matusiak numero...@gmail.com: -- nosy: +numerodix ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue19318 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue19319] misleading comment regarding C
Changes by Martin Matusiak numero...@gmail.com: -- nosy: +numerodix ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue19319 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue17951] TypeError during gdb backtracing
Changes by Martin Matusiak numero...@gmail.com: -- nosy: +numerodix ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue17951 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue19318] break more than once
Martin Matusiak added the comment: I see one potential problem with this, namely that refactoring code that contains break n statements would become more error prone whenever the depth of the code block gets modified. So if you had something like: for i in range(10): for j in range(10): for k in range(10): if cond: break 2 And then you decided to remove the middle loop (on j), the break 2 would send you to the top level, whereas you might have meant for it to break to the first level, inside the loop on i. This is a micro example, of course, but if you imagine the bodies of these loops being quite long then it could get complicated fast. -- components: +Interpreter Core ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue19318 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue8964] platform._sys_version does not parse correctly IronPython 2.x version
Martin Matusiak added the comment: Attaching a v3 which uses in and startswith. Just for good measure I ran this module on IronPython 1.0 and it fails on import: - bytes literal: b'(__libc_init)' - if as infix operator: line 177 - unexpected token open: use of with context manager on line 334 - as keyword: except OSError as why: line 430 - ImportError: No module named os. os and subprocess are missing altogether in IronPython 1.0. That's as far as I looked - there may be other issues still. So I decided to isolate this one function and see if it works. It fails because re.ASCII does not exist. If I remove that then the function runs and parses its own sys.version correctly. But it may be a bit of a stretch at this point to stay compatible that far back. -- Added file: http://bugs.python.org/file32221/issue8964_v3.diff ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue8964 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue8964] platform._sys_version does not parse correctly IronPython 2.x version
Martin Matusiak added the comment: Double checked that the test passes against both default and 2.7 branches. Is there anything else that needs to happen here or are you satisfied, Marc-Andre? -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue8964 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue19303] Typo in devguide - coverage
New submission from Martin Matusiak: - Another option is to use an installed copy of coverage.py if you already have an installed copy. -- components: Devguide files: typo_coverage.diff keywords: patch messages: 200474 nosy: ezio.melotti, numerodix priority: normal severity: normal status: open title: Typo in devguide - coverage Added file: http://bugs.python.org/file32228/typo_coverage.diff ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue19303 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue8964] platform._sys_version does not parse correctly IronPython 2.x version
Martin Matusiak added the comment: It seems the versions of IronPython 1.0 mentioned in test cases do actually support the in keyword, so the first version of the patch is probably sufficient. Example session: sys.version IronPython 1.0.60816 on .NET 2.0.50727.3643 IronPython in sys.version True sys.version.startswith(IronPython) True -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue8964 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue8964] platform._sys_version does not parse correctly IronPython 2.x version
Martin Matusiak added the comment: Hm, I see. Actually, in is already used in this function a little further down: elif PyPy in sys_version: So we should change both occurrences then. I'm attaching a v2 with these changes. -- Added file: http://bugs.python.org/file32154/issue8964_v2.diff ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue8964 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue8964] platform._sys_version does not parse correctly IronPython 2.x version
Martin Matusiak added the comment: I've checked sys.version on IronPython 2.6.1, 2.6.2 (same format) and 2.7.4 (slightly different). The patch includes two new test cases. I've also taken the liberty of adding some newlines in between the items in the dict as I found this code very hard to read otherwise. -- keywords: +patch nosy: +numerodix Added file: http://bugs.python.org/file32146/issue8964.diff ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue8964 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
