Changes by Mark Shannon m...@hotpy.org:
--
nosy: +Mark.Shannon
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue19335
___
___
Python-bugs-list
New submission from Mark Shannon:
If a dict is used a cache, e.g. in functools.lru_cache,
the reduced resize factor in 3.3 can cause excessive resizing.
This can lead to a significant performance regression.
When the the number of deletions and insertions is roughly in balance
the reduced head
New submission from Mark Shannon:
The test_urllib2_localnet test fails when run with a clean build from a clean
checkout.
Machine:
Ubuntu 12.04 LTS, 64 bit
Intel i3-2370M CPU @ 2.40GHz × 4
Test output:
$ ./python -m test -v test_urllib2_localnet
== CPython 3.4.0a0 (default:53cc3dbb1918
Mark Shannon added the comment:
Bah, stupid BT :(
I opened the URL in my browser and got a helpful message telling me Sorry,
the website sadflkjsasf.i.nvali.d. cannot be found
Perhaps we should just remove this test?
I suspect this is only going to become more common
Mark Shannon added the comment:
This issue should be considered closed.
PyType_GenericNew is a convenience function for typeobjects to put in their
tp_new slots. Calling it directly only works for some types.
It worked in 3.2 for dict, but that was happenstance.
You could use
((PyTypeObject
Mark Shannon added the comment:
Mark, it was written 20 years ago. Who knows (or cares) why it was written that
way?
Let's just write it correctly this time.
Py_INCREF, Py_DECREF, Py_XDECREF and Py_XINCREF should all expand their
argument exactly once.
Py_CLEAR should expand its argument
New submission from Mark Shannon:
The handling of pseudo exceptions (return, break and continue) are currently
handled in the interpreter. This make the interpreter loop more complex and
slower than it needs to be. This change moves the handling of pseudo exceptions
into the compiler
Changes by Mark Shannon m...@hotpy.org:
--
keywords: +patch
Added file: http://bugs.python.org/file29646/b16527f84774.diff
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue17611
Mark Shannon added the comment:
Stefan,
I tried running your pi_bench (increasing the numer of iterations by x10 to
reduce jitter). The run to run variation exceed the difference between the two
versions. Here are the fastest of 7 runs on my machine.
i3-2370M CPU @ 2.40GHz × 4. linux 64bit
Mark Shannon added the comment:
Antoine,
Two bytecode examples.
For the following function:
def f(x):
... try:
... return x
... except:
... pass
Without the patch:
2 0 SETUP_EXCEPT 8 (to 11)
3 3 LOAD_FAST0 (x
Mark Shannon added the comment:
The register qualifier on the parameter does not alter the calling convention,
it determines the storage class of the parameter variable within the function.
Having said that I am all in favour in removing any and all register
declarations
Mark Shannon added the comment:
I think blaming the crash in test_marshall
http://buildbot.python.org/all/builders/AMD64%20Windows7%20SP1%203.x/builds/2009/steps/test/logs/stdio
on the new macros (change aff41a6421c2) is correct.
It may be the proximate cause, but that doesn't make
Mark Shannon added the comment:
There seems to be an ongoing confusion about scopes on this thread.
The __class__ variable used by super() is a non-local variable in the scope of
any function using super(), whereas the __class__ used to define the type of an
object is a class attribute like
Mark Shannon added the comment:
I don't think there is any need for a scaling factor.
Expressions in auto-generated trees will tend to be trees of binary operator
rather lists of purely unary operators. A tree of a billion items only has a
depth of ~30.
There is no way an expression tree 1000
Mark Shannon added the comment:
Well spotted.
I don't think that the line
COPYVAL(tp_dictoffset);
should be removed.
inherit_special() is called from PyType_Ready
which is used to initialise static TypeObjects.
So builtin class B which doesn't set tp_dictoffset,
but has builtin class A as its
Mark Shannon added the comment:
This looks good to me.
Also, I think this should go into 3.4
It is a tiny patch and could result in significant memory saving for OO
programs with inheritance (e.g. Django)
--
___
Python tracker rep
New submission from Mark Shannon:
Modules/pyexpat.c includes some archaic code to create temporary frames
so that, in even of an exception being raised, expat appears in the traceback.
The way this is implemented is a problem for three reasons:
1. It violates PEP 384.
2. It is incorrect, see
Changes by Mark Shannon m...@hotpy.org:
--
nosy: +nedbat
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue22462
___
___
Python-bugs-list mailing list
Mark Shannon added the comment:
W.r.t PEP 384:
Every module, except pyexpat, in the stdlib library treats frames as opaque
objects, as PEP 384 requires.
(I'm exempting builtins and sys here)
I think it is unreasonable to expect authors of 3rd party modules to respect
PEP 384 if the standard
Mark Shannon added the comment:
The assertion on line 855
is a duplicate of the assertion on line 821, which is just before the reentrant
DECREF.
The assertion on line 821 appears to be correct.
I don't know why the assertion is at the end of the function rather than
earlier, but hg blame
Mark Shannon added the comment:
This is caused by https://hg.python.org/cpython/rev/7c5c678e4164/
which is a supposed fix for http://bugs.python.org/issue16795
which claims to make some changes to AST to make it more useful for static
language analysis, seemingly by breaking all existing static
Mark Shannon added the comment:
It is now very hard to determine accurate locations for an expression such as
(x+y).attr as the column offset of leftmost subexpression of the expression is
not the same as the column offset of the location
Mark Shannon added the comment:
This also breaks the col_offset for subscripts like x[y] and, of course any
statement with one of these expressions as its leftmost sub-expression.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org
Mark Shannon added the comment:
The column offset has always been the offset of the start of the expression.
Therefore the expression `x.y` should have the same offset as the
sub-expresssion `x`.
Likewise for calls, `f(args)` should have the same offset as the `f` sub
expression.
Our static
Mark Shannon added the comment:
How do I get the start of `(x+y).bit_length()` in
`total += (x+y).bit_length()`?
With your change, I can't get it from `x`, `x+y`, or from the whole statement.
The primary purpose of the locations are for tracebacks, not for static tools.
Also, most tools need
Mark Shannon added the comment:
You are on the nosy list. You should have got sent an email.
This bug is the regression.
https://hg.python.org/cpython/rev/7c5c678e4164/ resulted in incorrect column
offsets for many compound expressions
Mark Shannon added the comment:
I would say yes, it is too late. Any change to the AST is a breaking change.
The current AST is full of missing line numbers, incorrect column offsets and
other inconsistencies. To fix them all would be a major undertaking with no
obvious benefit to the core
Mark Shannon added the comment:
I don't remember why PyMem_Malloc rather than PyObject_MALLOC was used, it may
have been inherited from the allocation of dict tables in the earlier
implementation.
My only concern is that the benchmark only tests performance for very small
dictionaries
Changes by Mark Shannon m...@hotpy.org:
--
nosy: +Mark.Shannon
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue23601
___
___
Python-bugs-list
Mark Shannon added the comment:
This looks like the expected behaviour to me.
re.sub matches the leftmost occurence and the regular expression is greedy so
(x|xy) will always match xy if it can.
--
nosy: +Mark.Shannon
___
Python tracker rep
Mark Shannon added the comment:
Comments don't belong on the AST. Where would you attach them?
The tokenizer module provides all information about comments. Tools can get the
information quite easily if they need it.
--
nosy: +Mark.Shannon
Mark Shannon added the comment:
There are two parts to this fix.
First, we raise a runtime exception if the other dict is modified during the
update/merge.
Second, refcounts must be incremented around the PyDict_GetItem and insertdict
calls in case the key or value is otherwise deallocated
Mark Shannon added the comment:
If the tracker had let me assign the issue, you need not have wasted your time.
Oh well.
Indeed, your patch looks very similar to mine.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue24407
Mark Shannon added the comment:
If type.coroutine is not the first and only decorator, then things may be even
worse.
Code objects are currently immutable.
This change would mean that a call to types.coroutine in one place in the code
would change the semantics of another piece of code
Mark Shannon added the comment:
Does this have a measurable performance impact?
I'd be surprised if it did.
W.r.t. to profiling, the undecorated form will never be visible to any code
other than the decorator, so won't show up in the profiler.
--
nosy: +Mark.Shannon
Mark Shannon added the comment:
The tracker won't let me assign this to myself.
Consider it assigned.
--
nosy: +Mark.Shannon
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue24407
Mark Shannon added the comment:
I don't understand why this has been closed.
I agree with Jim's analysis.
Lookups do not change the dict and the choice of lookdict_* variant depends
solely on the set of keys.
In fact, lookdict_split *doesn't* replace itself, it merely calls look_dict
Mark Shannon added the comment:
I realise that I am bit late to the party, but I would like to point out that a
smaller, arguably simpler, and almost certainly faster alternative design
exists.
This design simply consists of an array of (prev, next, key) nodes attached to
the base dict
Mark Shannon added the comment:
If there is another issue for this, then it doesn't seem to be a release
blocker. I think it should be.
--
nosy: +Mark.Shannon
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue24912
Changes by Mark Shannon m...@hotpy.org:
--
nosy: +Mark.Shannon
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue24272
___
___
Python-bugs-list
Mark Shannon added the comment:
I think this is a bug. This is not a normal case of subclassing as the
interpreter calls the C API PyDict_XXX() in many cases where a dictionary
subclass is passed in.
For example:
class C: pass
c = C()
# Liskov substitution principle says this is OK.
c
New submission from Mark Shannon:
Setting an item in an ordered dict via dict.__setitem__, or by using it as an
object dictionary and setting an attribute on that object, creates a dictionary
whose repr is:
OrderedDict([NULL])
Test case attached.
--
components: Library (Lib)
files
Mark Shannon added the comment:
The attached test case raises a KeyError for __str__()
--
nosy: +Mark.Shannon
Added file: http://bugs.python.org/file40019/test.py
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue24667
Mark Shannon added the comment:
Updated patch to support exception chaining and to merge cleanly.
--
versions: +Python 3.6 -Python 3.4
Added file: http://bugs.python.org/file40015/exc_info3.patch
___
Python tracker rep...@bugs.python.org
http
Mark Shannon added the comment:
+1 from me.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue23601
___
___
Python-bugs-list mailing list
New submission from Mark Shannon:
Issue 23601 advocates using the small object allocator for dict-keys objects
and the results of tests are good.
Using the small object allocator for dict value-arrays as well seems like the
obvious next step.
--
components: Interpreter Core
keywords
Mark Shannon added the comment:
Yes, but that shouldn't block this issue.
I've opened issue 24648 instead.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue23601
Mark Shannon added the comment:
I still think that this is a good idea, but I would like to see a small speed
test for large objects. Just to be sure that it is no slower.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org
Mark Shannon added the comment:
Indeed there is no *obvious* reason why they should be slower.
But when it comes to optimisation, *never* trust your (or anyone else's)
intuition.
Running a simple check is always worth the effort.
--
___
Python
Mark Shannon added the comment:
Please revert c0d25de5919e.
Breaking the interpreter in order to facilitate some obscure use case is
unacceptable.
If you want to do fancy stuff with modules, fine. Take a look at the source of
the six module
https://bitbucket.org/gutworth/six/src
Mark Shannon added the comment:
Nathaniel, I'm hostile to this patch remaining in the code base.
I'm not hostile to you, sorry that I came across as that way.
The proper way to deal with issues like this is to revert the change and then
create a new patch, otherwise it becomes impossible
Mark Shannon added the comment:
Eek! indeed :)
I intend to track down the cause of this on Monday, and hopefully come up with
a fix, unless anyone beats me to it.
Does anyone know if there is another issue for this?
--
___
Python tracker rep
Mark Shannon added the comment:
I think Nathaniel and Eugene argument that you cannot replace the module in
sys.modules safely in erroneous.
Immediately after the module is created by importlib it is inserted into
sys.modules. The code object for the module is then executed.
At that point
Mark Shannon added the comment:
Larry, of the two choices, I prefer rolling back the change entirely.
I would like to see the bug fixes for typeobject.c applied, but I see no reason
why making the __class__ of module objects assignable should be included
Mark Shannon added the comment:
Why has the change allowing the __class__ attribute of modules been merged?
It is not necessary (as I have stated repeatedly) and not known to be safe.
--
___
Python tracker <rep...@bugs.python.org>
Mark Shannon added the comment:
Well, there are important reasons why not to make the __class__ attribute of
modules mutable.
First of all, there is no valid rationale.
How do know for sure that modifying the class of the sys or builtins module is
not going to cause much the same problems
Mark Shannon added the comment:
Guido,
I just think this change is misguided. The original rationale for the change
just doesn't hold water.
If you want the change anyway, then fine, but this seems an odd way to
introduce it.
--
status: closed -> o
Mark Shannon added the comment:
Oh, and has anyone considered the potential impact this might have on Jython or
PyPy? Modules are quite fundamental to the way that Python works.
--
___
Python tracker <rep...@bugs.python.org>
<http://bugs.p
Changes by Mark Shannon <m...@hotpy.org>:
--
nosy: +Mark.Shannon
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/issue25217>
___
__
Mark Shannon added the comment:
+1 for special casing None.
--
nosy: +Mark.Shannon
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/i
Mark Shannon added the comment:
I seemed to have been added to the nosy list. I guess that means that my
opinions are wanted ;)
I have wanted to clean up the code around making calls for quite a while. I
just haven't had time.
I agree that adding a simpler opcode for making calls
New submission from Mark Shannon:
In Python 2.7.6 and 3.2.3:
>>> "{ {{ 0} }}".format(**{' {{ 0} }': 'X'})
'X'
In Python 3.4.3:
>>> "{ {{ 0} }}".format(**{' {{ 0} }': 'X'})
Traceback (most recent call last):
File "", line 1, in
ValueError: un
Mark Shannon added the comment:
This problem is the parsing of f-strings.
The expressions in an f-string are not "eval"ed in the sense of the eval()
function. They are evaluated exactly the same as any other Python expression.
However the parsing of f-strings does not provide co
Mark Shannon added the comment:
It is also worth mentioning that incorrect line numbers means that tools like
pyflakes, pylint, mypy, lgtm, etc, need to reimplement parsing of f-strings.
--
___
Python tracker <rep...@bugs.python.org>
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 any p
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:
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 scope
Changes by Mark Shannon <m...@hotpy.org>:
--
pull_requests: +1882
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/issue29988>
___
__
Mark Shannon added the comment:
Nathaniel,
Do you have any way to reliably test for this failure mode?
--
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/i
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
New submission from Mark Shannon <m...@hotpy.org>:
$ 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
Mark Shannon <m...@hotpy.org> 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 <rep...@bugs.python.or
Mark Shannon <m...@hotpy.org> 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 look
Mark Shannon <m...@hotpy.org> added the comment:
On 04/12/17 16:56, Serhiy Storchaka wrote:
>
> Serhiy Storchaka <storchaka+cpyt...@gmail.com> added the comment:
>
> Right, this is similar to how the JSR/RET pair was used in for calling the
> finally block.
>
Mark Shannon <m...@hotpy.org> 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 t
Mark Shannon <m...@hotpy.org> added the comment:
Thanks, that example shows the essence of the problem. I understand you
perfectly now.
--
___
Python tracker <rep...@bugs.python.org>
<https://bugs.python
Mark Shannon <m...@hotpy.org> 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 tracke
Mark Shannon <m...@hotpy.org> 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
Mark Shannon <m...@hotpy.org> 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 ap
Mark Shannon <m...@hotpy.org> 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
New submission from Mark Shannon <m...@hotpy.org>:
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 a
Mark Shannon <m...@hotpy.org> 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 <rep...@bugs.python.org>
<https://b
New submission from Mark Shannon <m...@hotpy.org>:
>>> os.spawnvpe(os.P_WAIT, "python2", ["python2", "-c", "print 'Hello
>>> World!'"], {})
Hello World!
0
>>> os.spawnvpe(os.P_WAIT, "python2", ["pytho
Mark Shannon added the comment:
This looks like a Greenlet bug to me.
Possibly
https://github.com/python-greenlet/greenlet/commit/780a12b51fcef9adcc4f2c9a4cc5b05c2d652ba4
is incomplete.
It is not clear to me why greenlets hold their own exception state, but I
suspect that if they didn't
Mark Shannon added the comment:
Strange.
I could only reproduce this intermittently with 3.7 build.
But with a debug build, I cannot reproduce this at all.
Rebuilding Python (optimised, but without PGO) I cannot reproduce at all now.
--
___
Python
Change by Mark Shannon <m...@hotpy.org>:
--
keywords: +patch
pull_requests: +6337
stage: -> patch review
___
Python tracker <rep...@bugs.python.org>
<https://bugs.pyt
Change by Mark Shannon <m...@hotpy.org>:
--
resolution: -> fixed
stage: patch review -> resolved
status: open -> closed
___
Python tracker <rep...@bugs.python.org>
<https://bu
Change by Mark Shannon <m...@hotpy.org>:
--
Removed message: https://bugs.python.org/msg315906
___
Python tracker <rep...@bugs.python.org>
<https://bugs.python
New submission from Mark Shannon <m...@hotpy.org>:
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_F
Mark Shannon <m...@hotpy.org> 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_F
Change by Mark Shannon <m...@hotpy.org>:
--
pull_requests: +6338
___
Python tracker <rep...@bugs.python.org>
<https://bugs.python.org/issue33318>
___
__
Change by Mark Shannon <m...@hotpy.org>:
--
pull_requests: -6338
___
Python tracker <rep...@bugs.python.org>
<https://bugs.python.org/issue33318>
___
_
Mark Shannon <m...@hotpy.org> added the comment:
When I said "significant", I meant from a statistically, not as a judgement
meaning "useful" or "worthwhile". The code duplication approach is
significantly faster in the tests. Whether the small speed
Mark Shannon <m...@hotpy.org> added the comment:
Why all these competing pull requests? It does feel like my original patch has
been hijacked.
Also, before any more PRs, we need to decide whether to use subroutines or code
duplication for finally blocks.
Here is my attempt at an obj
Mark Shannon <m...@hotpy.org> added the comment:
Can we stick to the one PR, please?
Once it is merged then we can improve things.
Also, I don't like leaving NULLs on the stack, they are an invitation to
seg-fault. PR 5143 leaves more NULLs on the stack for
Change by Mark Shannon <m...@hotpy.org>:
--
keywords: +patch
pull_requests: +5034
stage: needs patch -> patch review
___
Python tracker <rep...@bugs.python.org>
<https://bugs.pyt
Mark Shannon <m...@hotpy.org> 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 duplicatio
New submission from Mark Shannon <m...@hotpy.org>:
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
LOA
Mark Shannon <m...@hotpy.org> 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
Mark Shannon <m...@hotpy.org> added the comment:
Works as expected:
>>> class C:
... exec('x: int')
...
>>> C.__annotations__
{'x': }
>>> __annotations__
{}
--
___
Python tracker <rep...@bugs.python.org&
101 - 200 of 1194 matches
Mail list logo
