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
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
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
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
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
Changes by Martin Matusiak numero...@gmail.com:
--
nosy: +benjamin.peterson
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue22036
___
___
Python
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
Changes by Martin Matusiak numero...@gmail.com:
--
nosy: +numerodix
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue8083
___
___
Python-bugs-list
Changes by Martin Matusiak numero...@gmail.com:
--
nosy: +numerodix
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue7757
___
___
Python-bugs-list
Changes by Martin Matusiak numero...@gmail.com:
--
nosy: +numerodix
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue19318
___
___
Python-bugs-list
Changes by Martin Matusiak numero...@gmail.com:
--
nosy: +numerodix
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue19319
___
___
Python-bugs-list
Changes by Martin Matusiak numero...@gmail.com:
--
nosy: +numerodix
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue17951
___
___
Python-bugs-list
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
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
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
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
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
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
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
34 matches
Mail list logo
