Changes by Mark Shannon :
Added file: http://bugs.python.org/file24510/691ce331f955.diff
___
Python tracker
<http://bugs.python.org/issue13903>
___
___
Python-bugs-list m
Changes by Mark Shannon :
Removed file: http://bugs.python.org/file24465/e50db1b7ad7b.diff
___
Python tracker
<http://bugs.python.org/issue13903>
___
___
Python-bug
Mark Shannon added the comment:
Fixed by revisions 224ebf9d428a and 38828f0c9312
--
resolution: -> fixed
status: open -> closed
___
Python tracker
<http://bugs.python.org/i
Changes by Mark Shannon :
Added file: http://bugs.python.org/file24670/49b7e7e4a27c.diff
___
Python tracker
<http://bugs.python.org/issue13903>
___
___
Python-bugs-list m
Mark Shannon added the comment:
Jim Jewett wrote:
> Jim Jewett added the comment:
>
> As of Feb 28, 2012, the PEP mentions an additional optimization of storing
> the values in an array indexed by (effectively) key insertion order, rather
> than key position. ("Altern
Mark Shannon added the comment:
Could you run the benchamrks at http://hg.python.org/benchmarks/
and report the results, for 3.3 (rather than 2.7), please?
Adding a new bytecode because it speeds up one 4 line program does not seem
such a good idea.
--
nosy: +Mark.Shannon
Mark Shannon added the comment:
I much prefer dict_lookup.patch to nomodify.patch.
It doesn't increase the memory use of dict. One extra word per dict could be a
lot of memory for a large application.
There is a very subtle semantic change, but I think it is a positive one.
Raising a run
Mark Shannon added the comment:
Looks good to me.
The INCREF/DECREFs are outside of the loops so will have negligible performance
impact.
--
nosy: +Mark.Shannon
___
Python tracker
<http://bugs.python.org/issue14
Mark Shannon added the comment:
Jim Jewett wrote:
> Jim Jewett added the comment:
>
> Can't this be triggered by non-malicious code that just happened to have a
> python comparison and get hit with a thread switch?
So, they are writing to a dict in one thread while read
Mark Shannon added the comment:
Jim Jewett wrote:
> http://bugs.python.org/review/13897/diff/4186/14521
> File Python/sysmodule.c (right):
>
> http://bugs.python.org/review/13897/diff/4186/14521#newcode211
> Python/sysmodule.c:211: while ((exc_info->exc_type == N
New submission from Mark Shannon :
Delegating generators do not show always up in stack traces, such as
inspect.stack().
The show up during the first delegation, but not thereafter.
I have attached a patch. It alters the way the YIELD_FROM bytecode works; it
loops back on itself. This ensures
Mark Shannon added the comment:
I've just added issue 14230 which overlaps with this issue somewhat.
--
___
Python tracker
<http://bugs.python.org/is
Mark Shannon added the comment:
Unmodified CPython (without the patch) already passes the new test in the patch.
The unmodified code already raises a Runtime error; a recursion limit exceeded
error!
--
___
Python tracker
<http://bugs.python.
New submission from Mark Shannon :
I get the following compiler warning (rev 2a142141e5fd)
Its not strictly an error, but an unitialised variable in such an
important function is dangerous.
Objects/object.c: In function ‘_PyObject_GenericSetAttrWithDict’:
Objects/object.c:1144: warning: ‘descr
Changes by Mark Shannon :
Added file: http://bugs.python.org/file24766/257e16e71654.diff
___
Python tracker
<http://bugs.python.org/issue13903>
___
___
Python-bugs-list m
New submission from Mark Shannon :
>>> io.UnsupportedOperation.__new__(io.UnsupportedOperation)
Traceback (most recent call last):
File "", line 1, in
TypeError: ValueError.__new__(UnsupportedOperation) is not safe, use
OSError.__new__()
Looking at the mro of io.U
Mark Shannon added the comment:
STINNER Victor wrote:
> STINNER Victor added the comment:
>
> Guido> Given all this I think we should keep it as you have committed
> Guido> and add it to the docs and whatsnew.
>
> I updated What's New in Python 3.3 docum
Mark Shannon added the comment:
Review of set-with-Set.patch:
Looks good overall.
I agree that restricting operations to instances of Set rather than Iterable is
correct.
Implementing "__rsub__" in terms of - (subtraction) means that infinite
recursion is a possibility. It also
Mark Shannon added the comment:
Updated Patch
--
Added file: http://bugs.python.org/file24870/yieldfrom.patch
___
Python tracker
<http://bugs.python.org/issue14
Changes by Mark Shannon :
Removed file: http://bugs.python.org/file24759/yieldfrom.patch
___
Python tracker
<http://bugs.python.org/issue14230>
___
___
Python-bugs-list m
Mark Shannon added the comment:
Could you try this new patch (with white space changes included)?
--
Added file: http://bugs.python.org/file24872/yieldfrom.patch
___
Python tracker
<http://bugs.python.org/issue14
Mark Shannon added the comment:
The magic number has not been updated
Patch attached.
--
Added file: http://bugs.python.org/file24889/magic.patch
___
Python tracker
<http://bugs.python.org/issue14
Changes by Mark Shannon :
Added file: http://bugs.python.org/file25096/372d0bca85ae.diff
___
Python tracker
<http://bugs.python.org/issue13903>
___
___
Python-bugs-list m
Mark Shannon added the comment:
I'm not bothered by the regression in "silent_logging",
as it is a micro benchmark with a very short running time.
The regression in "mako" is, I think, caused by competition for the
data cache between the new dict implementation and
Mark Shannon added the comment:
Antoine Pitrou wrote:
> Antoine Pitrou added the comment:
>
>> I'm not bothered by the regression in "silent_logging",
>> as it is a micro benchmark with a very short running time.
>
> I'm not concerned about the
Mark Shannon added the comment:
How about changing the method-cache size in a separate patch?
On my machine, reducing the method-cache size from 2**10 to 2**9 results
in a very small improvement in performance (with the original dict).
That way we don't get a performance regression wit
Mark Shannon added the comment:
3rd party code should not be accessing fields in the threadstate object,
but without the accessors proposed in issue 14098 there may be no alternative.
Once the patch for issue 14098 has been applied it, would it then be acceptable
to remove the surperfluous
Mark Shannon added the comment:
Rather than ensuring that f_tstate always points to the current frame,
just remove it altogether.
Patch attached
--
nosy: +Mark.Shannon
Added file: http://bugs.python.org/file25176/remove_f_tstate.patch
___
Python
Mark Shannon added the comment:
According to PEP 384 (Defining a Stable ABI) the thread state object is opaque,
so we should be free to add or remove fields.
Nevertheless, I have added a new patch that simply moves the f_exc... fields
from the frame object to the generator. It is not as
Mark Shannon added the comment:
I don't really understand your objection to changing the method-cache size. As
I said, I can remove the change, but that will cause the performance regression
that Antoine noticed.
--
___
Python tracker
Geoff Shannon added the comment:
@martin.panter I removed the mention of inserting null bytes and restricted the
documentation updates to more fully documenting the current behaviour.
--
___
Python tracker
<https://bugs.python.org/issue22
Change by Geoff Shannon :
--
pull_requests: +13364
___
Python tracker
<https://bugs.python.org/issue22865>
___
___
Python-bugs-list mailing list
Unsubscribe:
Mark Shannon added the comment:
New changeset 180dc1b0f4a57c3f66351568ae8488fa8576d7f0 by Mark Shannon (Julien
Palard) in branch 'master':
bpo-28866: No type cache for types with specialized mro, invalidation is hard.
(#13157)
https://github.com/python/cpyt
Mark Shannon added the comment:
New changeset f3d909428c7c61ea32e8fbb9c8b48344e7904a53 by Mark Shannon (Michael
Blahay) in branch '3.7':
BPO-27639: Correct return type for UserList slicing operation (#13203)
https://github.com/python/cpython/commit/f3d909428c7c61ea32e8fbb9c8b483
New submission from Mark Shannon :
PEP 590 allows us the short circuit the __new__, __init__ slow path for
commonly created builtin types.
As an initial step, we can speed up calls to range, list and dict by about 30%.
See https://gist.github.com/markshannon/5cef3a74369391f6ef937d52cca9bfc8
Change by Mark Shannon :
--
keywords: +patch
pull_requests: +13796
stage: -> patch review
pull_request: https://github.com/python/cpython/pull/13930
___
Python tracker
<https://bugs.python.org/issu
Change by Mark Shannon :
--
keywords: +patch
pull_requests: +14529
stage: -> patch review
pull_request: https://github.com/python/cpython/pull/14735
___
Python tracker
<https://bugs.python.org/issu
Geoff Shannon added the comment:
It is submitted @cheryl.sabella. Thanks for reviving this, I had totally lost
track of it.
--
___
Python tracker
<https://bugs.python.org/issue22
Mark Shannon added the comment:
This is either a "won't fix" or an "impossible to fix" depending on your point
of view.
PATIENT:
It hurts whenever I press ctrl-C
DOCTOR:
Then don't press ctrl-C
The problem is that ctrl-C can provoke an interrupt at
Mark Shannon added the comment:
This issue is rather old, so I will create a new GitHub PR for the code change.
This issue can be closed.
Note that https://bugs.python.org/issue25612 is a manifestation of the problem
that this was intended to solve.
--
nosy: +Mark Shannon
Mark Shannon added the comment:
If all you need is that
with foo:
pass
guarantees that either both or neither of __enter__ and __exit__ are called,
for C context managers, and only C context managers, then the fix is trivial.
To protect Python code would need a custom context manager
Mark Shannon added the comment:
Nathaniel,
Do you have any way to reliably test for this failure mode?
--
___
Python tracker
<http://bugs.python.org/issue29
Changes by Mark Shannon :
--
pull_requests: +1882
___
Python tracker
<http://bugs.python.org/issue29988>
___
___
Python-bugs-list mailing list
Unsubscribe:
Mark Shannon added the comment:
I'm not too keen on this.
Which frame is being executed is an implementation detail.
For example, we currently push a new frame for list comprehensions, but that is
an implementation detail. The language only specifies that list-comps execute
in a new
Change by Geoff Shannon :
--
pull_requests: +12074
___
Python tracker
<https://bugs.python.org/issue26228>
___
___
Python-bugs-list mailing list
Unsubscribe:
Geoff Shannon added the comment:
I took a shot at fixing this in a smaller more targeted patch. I think this
should still solve the major issue of pty.spawn hanging on platforms that don't
raise an error. In addition, pty.spawn should now _ALWAYS_ return the terminal
to the pre
Geoff Shannon added the comment:
I'm aware of it. I actually wrote that patch as well. :D
--
___
Python tracker
<https://bugs.python.org/issue26228>
___
___
Mark Shannon added the comment:
In general, I agree with Raymond that this is likely to counter-productive.
But let's not guess, let's measure :)
I expect that there are few live empty dicts at any time for most programs. In
which case there is no point in any change that attemp
Mark Shannon added the comment:
Serhiy, for {'a': None} the dict is created using _PyDict_NewPresized() so this
makes no difference.
--
___
Python tracker
<https://bugs.python.o
Mark Shannon added the comment:
This failure appears to be a symptom of recursively traversing __bases__ rather
scanning __mro__ in the implementation of type.__subclasses__
The MCACHE depends on type.__subclasses__ being correct and it is not correct
for weird.py
python -i weird.py
>&
Mark Shannon added the comment:
I'm closing this as a duplicate of https://bugs.python.org/issue6028
Making a recursive call in an except block cannot be handled sensibly by the
interpreter.
On exceeding the stack depth, the interpreter will raise a RecursionError.
Catch
Mark Shannon added the comment:
I can't reproduce on 2.7.15rc1 on an x64 machine.
Can you confirm that this is still an issue?
--
nosy: +Mark.Shannon
___
Python tracker
<https://bugs.python.org/is
Mark Shannon added the comment:
Any reason not to close this issue?
--
nosy: +Mark.Shannon
___
Python tracker
<https://bugs.python.org/issue34408>
___
___
Pytho
Mark Shannon added the comment:
New changeset b1c3167c232c36ed3543ca351ff10c613639b5f5 by Mark Shannon (Michael
Blahay) in branch 'master':
bpo-27639: Correct return type for UserList slicing operation (#13169)
https://github.com/python/cpython/commit/b1c3167c232c36ed3543ca351ff10c
Mark Shannon added the comment:
Do you have a reproducible way to cause this crash?
--
___
Python tracker
<https://bugs.python.org/issue25217>
___
___
Python-bug
New submission from Mark Shannon :
This occurs (on linux at least) when the the end of line sequence `\r\r\n`
occurs in a comment that is indented relative to the following lines.
The attached file demonstrates the problem.
--
components: Library (Lib)
files: tokenize_fail_test.py
New submission from Mark Shannon :
The STORE_ANNOTATION bytecode is used to implement annotations.
The code
name : ann
is equivalent to
__annotations__['name'] = ann
Consequently,
STORE_ANNOTATION name
can be trivially replaced with
LOAD_NAME __ann
Change by Mark Shannon :
--
keywords: +patch
pull_requests: +5034
stage: needs patch -> patch review
___
Python tracker
<https://bugs.python.org/issu
Mark Shannon added the comment:
PEP 526 explicitly states
"as with all dunder attributes, any undocummented use of __annotations__ is
subject to breakage without warning"
I consider deleting __annotations__ to be undocumented use.
Do you really think that an obscure differe
Mark Shannon added the comment:
> 3. It doesn't add a name constant. Instead it uses a name from the names list
> (which already has to contain this name).
This PR moves the constant for the name from `co_names` to `co_consts`. There
is no duplication.
>>> def
Mark Shannon added the comment:
Works as expected:
>>> class C:
... exec('x: int')
...
>>> C.__annotations__
{'x': }
>>> __annotations__
{}
--
___
Pyth
Mark Shannon added the comment:
If it can wait another hour, I will be at home and can do the rebase then.
--
___
Python tracker
<https://bugs.python.org/issue32
Mark Shannon added the comment:
Rebased, pushed and CI is green.
--
___
Python tracker
<https://bugs.python.org/issue32550>
___
___
Python-bugs-list mailin
New submission from Mark Shannon :
Python 3.7.0b1+ (heads/3.7:dfa1144, Feb 22 2018, 12:10:59)
>>> m = ast.parse("def foo():\n 'help'")
>>> m.body[0].body
[]
Correct behaviour (3.6 or earlier)
>>> m = ast.parse("def foo():\n
Mark Shannon added the comment:
This is an unnecessary and breaking change.
Changes like this should not be made unless necessary to fix a bug.
--
___
Python tracker
<https://bugs.python.org/issue32
Mark Shannon added the comment:
That issue has to do with bytecode generation, not the AST.
The AST should be an accurate representation of the Python source code.
Making a better representation of the source would be fine, but this makes it
worse.
Doc-strings may be semantically distinct
Mark Shannon added the comment:
Stating that "this is a feature not a bug" does not make it so.
This breaks existing code and reduces the capabilities of the `ast` module.
For example, how does one get the location of the docstring now?
>From a syntactic point of view.
def foo():
Mark Shannon added the comment:
Serhiy, thanks for reopening this issue.
It seems to be that there are three reasonable choices:
1. Revert to 3.6 behaviour, with the addition of `docstring` attribute.
2. Change the docstring attribute to an AST node, possibly by modifying the
grammar.
3. Do
Mark Shannon added the comment:
Nothing left to do. This is now obsolete.
--
resolution: -> out of date
stage: patch review -> resolved
status: pending -> open
___
Python tracker
<https://bugs.python.or
New submission from Mark Shannon :
The bytecodes WITH_CLEANUP_START and WITH_CLEANUP_FINISH are complex and
implement entirely different behavior depending on what is on the stack.
This is unnecessary as the same semantics can be implemented with much simpler
bytecodes and using the compiler
Change by Mark Shannon :
--
keywords: +patch
pull_requests: +5871
stage: -> patch review
___
Python tracker
<https://bugs.python.org/issue33072>
___
___
Py
Mark Shannon added the comment:
So you did.
Sorry for the duplication
--
___
Python tracker
<https://bugs.python.org/issue33072>
___
___
Python-bugs-list mailin
Mark Shannon added the comment:
I still think that option 2 would be best, but given that it is late in the
release cycle, I will accept the status quo.
A couple of comments for the record:
Constant folding occurs after AST creation, so doesn't make the AST worse.
The parse tree creat
New submission from Mark Shannon :
f-string expressions can be formatted in four ways:
with or without a conversion
and
with or without a format specifier
Rather than have one bytecode that parses the opcode argument at runtime it
would be more efficient and produce a cleaner
Change by Mark Shannon :
--
keywords: +patch
pull_requests: +5893
stage: -> patch review
___
Python tracker
<https://bugs.python.org/issue33092>
___
___
Py
Mark Shannon added the comment:
Even if doesn't speed things up by a significant amount, I would suggest that a
simper interpreter with smaller, simpler bytecodes is a worthy goal in itself.
--
___
Python tracker
<https://bugs.py
Mark Shannon added the comment:
We have two competing PRs for this issue. Again.
For comparison, using the same micro-benchmark, PR 5112 has these timings:
Master branch: Mean +- std dev: 252 ns +- 4 ns
PR 5112: Mean +- std dev: 216 ns +- 4 ns
Mark Shannon added the comment:
I intend to reuse RERAISE to implement the exceptional case for a finally
block. Something like:
SETUP_FINALLY final
body
finalbody
JUMP exit
final:
finalbody
RERAISE
exit:
--
___
Python tracker
Mark Shannon added the comment:
It is fiddly to get the frame-setlineno code right for duplicated catch blocks,
but it is far from impossible.
--
___
Python tracker
<https://bugs.python.org/issue32
Mark Shannon added the comment:
There seems to be an implicit assumption here that fewer bytecodes is better.
But that isn't always the case.
Do you have evidence that the sequence
0 LOAD_CONST 5 ((('a', 'b', 'c'), 3, 2, 1))
2 UNPACK_SEQUENCE
Mark Shannon added the comment:
The six complex bytecodes currently used for implementing 'with' and 'try'
statements can be replaced with just two simpler bytecodes.
The six bytecodes are WITH_CLEANUP_START, WITH_CLEANUP_FINISH,
BEGIN_FINALLY, END_FINALLY, CALL_FINALLY a
Change by Mark Shannon :
--
Removed message: https://bugs.python.org/msg315906
___
Python tracker
<https://bugs.python.org/issue33387>
___
___
Python-bugs-list m
New submission from Mark Shannon :
The six complex bytecodes currently used for implementing 'with' and 'try'
statements can be replaced with just two simpler bytecodes.
The six bytecodes are WITH_CLEANUP_START, WITH_CLEANUP_FINISH,
BEGIN_FINALLY, END_FINALLY, CALL_FINALLY a
Change by Mark Shannon :
--
keywords: +patch
pull_requests: +6337
stage: -> patch review
___
Python tracker
<https://bugs.python.org/issue33387>
___
___
Py
Change by Mark Shannon :
--
pull_requests: +6338
___
Python tracker
<https://bugs.python.org/issue33318>
___
___
Python-bugs-list mailing list
Unsubscribe:
Change by Mark Shannon :
--
pull_requests: -6338
___
Python tracker
<https://bugs.python.org/issue33318>
___
___
Python-bugs-list mailing list
Unsubscribe:
Change by Mark Shannon :
--
resolution: -> fixed
stage: patch review -> resolved
status: open -> closed
___
Python tracker
<https://bugs.python.or
New submission from Mark Shannon :
>>> os.spawnvpe(os.P_WAIT, "python2", ["python2", "-c", "print 'Hello
>>> World!'"], {})
Hello World!
0
>>> os.spawnvpe(os.P_WAIT, "python2", ["python2", "-c
New submission from Mark Shannon :
$ python3.7 -S
>>> import posixpath
Traceback (most recent call last):
File "", line 1, in
File "--/Lib/posixpath.py", line 13, in
import os
File "--/Lib/os.py", line 92, in
from os.path import (curdir
Mark Shannon added the comment:
Thanks Serhiy for spotting that.
'raise' should raise the same exception as sys.exc_info() returns.
I'll update the PR.
--
nosy: +Mark.Shannon
___
Python tracker
<https://bugs.pyt
New submission from Mark Shannon :
Here
https://github.com/python/cpython/blob/master/Lib/mimetypes.py#L416
and here
https://github.com/python/cpython/blob/master/Lib/mimetypes.py#L526
I have no idea which is the correct value for either, but the code is
misleading at best
Mark Shannon added the comment:
I hadn't noticed the comments on the lines above saying "Duplicates :(", so I'm
obviously not the first to notice.
--
___
Python tracker
<https://bug
Mark Shannon added the comment:
Looking at the docs:
https://docs.python.org/3.6/library/sys.html#sys.exc_info states:
If the current stack frame is not handling an exception, the information
is taken from the calling stack frame, or its caller, and so on until a stack
frame is found
Mark Shannon added the comment:
I plan to resurrect my original design over the Christmas break.
The reason that I want to get back to the original design is its consistency
and relative simplicity.
Duplicating the finally block for every exit from the try body might sound
expensive, but it
Mark Shannon added the comment:
Serhiy,
I assume that you plan to use something like the JVM's JSR/RET instruction
pair. https://docs.oracle.com/javase/specs/jvms/se9/html/jvms-6.html
Is that right?
My reasons for preferring the finally-block duplication approach is that it
keep
Mark Shannon added the comment:
On 04/12/17 16:56, Serhiy Storchaka wrote:
>
> Serhiy Storchaka added the comment:
>
> Right, this is similar to how the JSR/RET pair was used in for calling the
> finally block.
>
> It seems the main drawback of duplicating of th
Mark Shannon added the comment:
Actually looking back at the original patch, the gap between __enter__ and
SETUP_FINALLY *was* in the original patch. My mistake.
The fix would to be restore SETUP_WITH. The complexity we really want to get
rid of is at the end of the with statement not the
Mark Shannon added the comment:
On 04/12/17 17:53, Neil Schemenauer wrote:
> There is a bug with the PR regarding the final bodies. Exits from the final
> body cause the whole fblock stack to unwind, not just the blocks enclosing
> the final body. Unwind looks at 'c'
Mark Shannon added the comment:
0610860 doesn't include any tests. What is it fixing?
3794016 passes the same set of tests.
Do have an actual code example that produces erroneous behaviour?
--
___
Python tracker
<https://bugs.python.org/is
Mark Shannon added the comment:
Thanks, that example shows the essence of the problem. I understand you
perfectly now.
--
___
Python tracker
<https://bugs.python.org/issue17
1001 - 1100 of 1219 matches
Mail list logo
