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 ver
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://
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
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
- "unexpect
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
<http://bugs.python.
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
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 c
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: Devg
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
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
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.
--
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
<http://bugs.python.org/issue19
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
<http://bugs.python.org/issue19
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 in
Changes by Martin Matusiak :
--
nosy: +numerodix
___
Python tracker
<http://bugs.python.org/issue8083>
___
___
Python-bugs-list mailing list
Unsubscribe:
Changes by Martin Matusiak :
--
nosy: +numerodix
___
Python tracker
<http://bugs.python.org/issue7757>
___
___
Python-bugs-list mailing list
Unsubscribe:
Changes by Martin Matusiak :
--
nosy: +numerodix
___
Python tracker
<http://bugs.python.org/issue19318>
___
___
Python-bugs-list mailing list
Unsubscribe:
Changes by Martin Matusiak :
--
nosy: +numerodix
___
Python tracker
<http://bugs.python.org/issue19319>
___
___
Python-bugs-list mailing list
Unsubscribe:
Changes by Martin Matusiak :
--
nosy: +numerodix
___
Python tracker
<http://bugs.python.org/issue17951>
___
___
Python-bugs-list mailing list
Unsubscribe:
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 i
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.
Changes by Martin Matusiak :
--
nosy: +benjamin.peterson
___
Python tracker
<http://bugs.python.org/issue22036>
___
___
Python-bugs-list mailing list
Unsubscribe:
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: 2240
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
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,
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.s
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
34 matches
Mail list logo
