[issue23581] unittest.mock.MagicMock doesn't support matmul (@) operator

2015-03-04 Thread Zygmunt Krynicki
New submission from Zygmunt Krynicki: Hi. I'm the upstream of Padme, a mostly transparent proxy library for Python. I was adding support for the new matmul/@ operator when I noticed that MagicMock doens't support it yet. form unittest.mock import MagicMock MagicMock() @ 1 Traceback (most

[issue23569] unittest.mock.MagicMock.__div__ works but __truediv__ doesn't (3.3 only)

2015-03-03 Thread Zygmunt Krynicki
New submission from Zygmunt Krynicki: Hey. I'm the upstream developer of padme https://github.com/zyga/padme -- the mostly transparent proxy class for Python. While working on unit tests for proxying numeric methods I realized that there are a few bugs in the mock library. The bug I'd like

[issue23568] unittest.mock.MagicMock doesn't support __rdivmod__

2015-03-03 Thread Zygmunt Krynicki
Changes by Zygmunt Krynicki zygmunt.kryni...@canonical.com: -- title: unittest.mock.MagicMock doesn't support __rdivmod__t - unittest.mock.MagicMock doesn't support __rdivmod__ ___ Python tracker rep...@bugs.python.org http://bugs.python.org

[issue23568] unittest.mock.MagicMock doesn't support __rdivmod__t

2015-03-03 Thread Zygmunt Krynicki
New submission from Zygmunt Krynicki: Hey. I'm the upstream developer of padme https://github.com/zyga/padme -- the mostly transparent proxy class for Python. While working on unit tests for proxying numeric methods I realized that there are a few bugs in the mock library. The bug I'd like

[issue23568] unittest.mock.MagicMock doesn't support __rdivmod__

2015-03-03 Thread Zygmunt Krynicki
Changes by Zygmunt Krynicki zygmunt.kryni...@canonical.com: -- type: - behavior versions: +Python 3.3 -Python 3.4, Python 3.5 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue23568

[issue19888] possible memory corruption caused by for-loop iteration over namespace.items() in a metaclass defining __new__

2013-12-04 Thread Zygmunt Krynicki
New submission from Zygmunt Krynicki: It seems that a particular code sequence causes memory corruption (but not a crash so far) in the interpreter. I've attached a test case that fails assertion on python3.2 (tested on current amd64 12.04 builds) and works on python3.3 (tested on current

[issue19888] possible memory corruption caused by for-loop iteration over namespace.items() in a metaclass defining __new__

2013-12-04 Thread Zygmunt Krynicki
Zygmunt Krynicki added the comment: 2.7 test program -- Added file: http://bugs.python.org/file32976/issue-19888.py27.py ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue19888

[issue19888] possible memory corruption caused by for-loop iteration over namespace.items() in a metaclass defining __new__

2013-12-04 Thread Zygmunt Krynicki
Zygmunt Krynicki added the comment: Experimenting with a few modifications lead to the following observations: 1) objects with short names (defined inside the Obj class) tend to be ignored and don't trigger the bug 2) Longer names tend to trigger the bug, ordering is not deterministic 3

[issue19888] possible memory corruption caused by for-loop iteration over namespace.items() in a metaclass defining __new__

2013-12-04 Thread Zygmunt Krynicki
Zygmunt Krynicki added the comment: This is not a bug, name spills out of for ... loop and then gets passed to __new__ -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue19888

[issue19888] possible memory corruption caused by for-loop iteration over namespace.items() in a metaclass defining __new__

2013-12-04 Thread Zygmunt Krynicki
Changes by Zygmunt Krynicki zygmunt.kryni...@canonical.com: -- resolution: - invalid status: open - closed ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue19888