Mailman 3 March 2014 - Python-Dev

Dead code in json/encoder?
by anatoly techtonik March 21, 2014

March 21, 2014

It looks like _one_shot parameter is always called with True argument and unused. What is the purpose of it? https://github.com/python/cpython/blob/de1b33f6e6071816a1fc52cd5f0c6cd47d70… -- anatoly t.

1 0

'Add/Remove Programs' entry missing for 'current user only' 32-bit installations on 64-bit Windows
by Jurko Gospodnetić March 21, 2014

March 21, 2014

Hi all. This seems like it should be an 'old' issue, but I have not been able to find anything related to it on the web. When you install 32-bit CPython 'for the current user only' on 64-bit Windows, the installation does not show up in the Windows 'Add/Remove Programs' dialog (a.k.a. 'Programs and Features' dialog on Windows 7). It does not show up there even for the current user. As a consequence it is possible for the user to end up in a situation where it is impossible to … [View More]install a 32-bit Python installation without manually cleaning up a previous 32-bit Python installation's Windows Installer related registry entries (more on this a bit later). I tested this CPython installation behaviour with the following CPython versions: * 2.3.4 - works correctly * 2.5.4 - works correctly * 2.6.0 - works correctly * 2.6.2 - works correctly * 2.6.3 - does not work correctly * 2.6.4 - does not work correctly * 2.6.6 - does not work correctly * 2.7.6 - does not work correctly * 3.3.3 - does not work correctly * 3.3.5 - does not work correctly * 3.4.0 - does not work correctly Several related observations, indicating that this could be some sort of a Windows Installer misconfiguration issue possibly solvable in the CPython installer: * The same does not occur when you install a 64-bit CPython version - their entry is correctly displayed in the 'Add/Remove Programs' dialog. * 32-bit CPython installer still correctly detects that a specific 32-bit version has already been installed, even if that previous installation is not listed in the 'Add/Remove Programs' dialog. * When you ask Windows using its WMI interface to list all the products installed on it (e.g. by running 'wmic product list' on the command-line), all the installed CPython versions are correctly displayed, even those 32-bit versions not displayed in the 'Add/Remove Programs' dialog. I started looking into this because I had a 32-bit CPython 3.4.0rc3 installation on my system that I wanted to remove, and since I did not see it registered in the 'Add/Remove Programs' dialog, I directly deleted its installation folder. That left my system in a state where a replacement 32-bit CPython 3.4.0 installation would always fail because it would detect that there was already a valid CPython 3.4 installation on the system, and then it would fail attempting to uninstall it. Fixing this required manually cleaning up leftover CPython 3.4.0rc3 windows installer registry entries. Note that the issue could not be fixed by using the CPython 3.4.0rc3 installer as it failed due to the same problem. This situation would suggest that something should be done in the Windows installer so it does not 'fail miserably' if a previous CPython installation can not removed. Possibly allow it to detect that the previous CPython installation has already been removed and simply clean up its Windows Installer registry entries. While working on this, I did discover a 'workaround' for the 'Add/Remove Programs' dialog issue, but it will take someone more knowledgeable about the Windows Installer infrastructure to say if the workaround can be applied directly as a clean solution or if it could have hidden consequences: Each 32-bit installation on 64-bit Windows has its own 'Uninstall' registry key under: > HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Microsoft\Windows\CurrentVersion\Uninstall named after its Windows Installer assigned GUID, e.g.: > HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Microsoft\Windows\CurrentVersion\Uninstall\{A37F2D73-72D1-364D-BA5D-CEA430BCC040} In that key there is a value named 'WindowsInstaller' which for CPython installations has the value '1' (of type REG_DWORD). If you change that value to '0' (again, of type REG_DWORD), the installation's 'Add/Remove Programs' dialog entry will get displayed correctly, and user will be able to run the installation (reinstall/change/uninstall) from there. I compared MSI packaging related CPython source code (Tools/msi folder) in 2.6.2 & 2.6.3 releases but I can not see anything suspicious there. It could be that the observed beaviour change between those two versions is a result of the final release packager changing his used Windows Installer version, but I have not rebuilt CPython, and its MSI installer to test this theory out. Anyone have any more information on this? Should I open a 'Add/Remove Programs' dialog related issue in the CPython issue tracker? And possibly a separate one for making CPython installations not fail without possible recovery if a previous CPython installation has already been removed? Many thanks. Best regards, Jurko Gospodnetić P.S. All this has been tested using Windows 7 SP1 (x64). [View Less]

3 7

unit tests for error messages
by Ethan Furman March 20, 2014

March 20, 2014

I just made a change to some error messages [1] (really, just one): old behavior: '%o' % 3.14 'float' object cannot be interpreted as an integer new behavior: '%o' % 3.14 %o format: an integer is required, not float Would we normally add a test for that? -- ~Ethan~ [1] Issue 19995: http://bugs.python.org/issue19995

4 3

unittest assertRaisesRegex bug?
by Ethan Furman March 19, 2014

March 19, 2014

Here's the code in question: class PsuedoFloat: def __init__(self, value): self.value = float(value) def __int__(self): return int(self.value) pi = PsuedoFloat(3.1415) self.assertRaisesRegex(TypeError, '%x format: an integer is required, not PsuedoFloat', '%x'.__mod__, pi), Here's the exception: ====================================================================== ERROR: test_formatting (test.… [View More]

4 7

asyncio.wait(FIRST_COMPLETED) returns more than one completions - 3.4rc2
by Imran Geriskovan March 19, 2014

March 19, 2014

Code below has been written with the intension of acquiring ONLY one lock. There are two issues: 1- Sometimes it returns more than one lock in done. 2- Sometimes, even if wait exits with zero or one locks, it seems there are other locks are acquired too. Though, I couldn't isolate the exact case for this. It sounds like some background shield() is at works. I kindly request your comments. locks = [some asyncio.Locks...] sel = [Pack(l.acquire(), l) for l in locks] done, pend = asyncio.wait(… [View More]

2 1

Issues about relative& absolute import way for Porting from python2.4 to python2.7
by 北冰洋 March 19, 2014

March 19, 2014

Dear, I just wrote a sample like this: testPy/ __init__.py client.py SoamFactory.c SoamFactory.so soamapi.py sample/testP.py export PYTHONPATH=$(TEST_LOCATION):$(TEST_LOCATION)/testPy Here's the source codes: __init__.py: import client client.py import soamapi class Client(soamapi.SessionCallback): def __init__(self): print "----class Client----" super(Client, self).__init__() soamapi.initialize() def create_session(… [View More]self): sec_cb = soamapi.DefaultSecurityCallback() self.connection = soamapi.connect(sec_cb) soamapi.py import SoamFactory class ConnectionSecurityCallback(object): def __init__(self): print "----class ConnectionSecurityCallback----" def __del__(self): pass def test_P(self): print "test_P in class ConnectionSecurityCallback" class DefaultSecurityCallback(ConnectionSecurityCallback): def __init__(self): super(DefaultSecurityCallback, self).__init__() print "----class DefaultSecurityCallback----" def __del__(self): super(DefaultSecurityCallback, self).__del__() def test(self): print "test in class DefaultSecurityCallback" class SessionCallback(object): def __init__(self): pass def __del__(self): pass def connect(security_callback): return SoamFactory.SoamFactory_connect(security_callback) def initialize(): SoamFactory.SoamFactory_initialize() print "call soamapi" SoamFactory.c #include "Python.h" #include "PythonLoop.c" PyObject* SOAM_API_MODULE = NULL; PyObject* pyModule = NULL; static PyObject* SoamFactory_initialize(PyObject* self, PyObject* args){ PyEval_InitThreads(); init(); Py_RETURN_NONE; } static PyObject* SoamFactory_connect(PyObject* self, PyObject* args){ PyObject* pySecCallback = NULL; int ok = PyArg_ParseTuple(args, "O", &pySecCallback); if (!ok){ printf("parse tuple error!\n"); Py_RETURN_NONE; } if (! PyObject_IsInstance(pySecCallback, connectSecCallback)){ printf("pySecCallback is not an instance of ConnectionSecurityCallback!\n"); Py_RETURN_NONE; } printf("Successful!\n"); Py_RETURN_NONE; } static PyMethodDef SoamFactory[] = { {"SoamFactory_connect", SoamFactory_connect, METH_VARARGS, "connection function"}, {"SoamFactory_initialize", SoamFactory_initialize, METH_VARARGS, "SoamFactory_initialize"}, {NULL, NULL} }; void initSoamFactory(){ PyEval_InitThreads(); Py_Initialize(); pyModule = Py_InitModule("SoamFactory", SoamFactory); SOAM_API_MODULE = PyImport_ImportModule("soamapi"); } sample/testP.py import testPy print "========================================" submitter = testPy.client.Client() submitter.create_session() print "========================================" When I ran it on python2.4, it worked well, and the result was call soamapi after import soamapi------client.py ======================================== ----class Client---- ----class ConnectionSecurityCallback---- ----class DefaultSecurityCallback---- Successful! ======================================== But when I ran it on python2.7, it worked beyond my expectation, the result was call soamapi call soamapi ======================================== ----class Client---- ----class ConnectionSecurityCallback---- ----class DefaultSecurityCallback---- pySecCallback is not an instance of ConnectionSecurityCallback! ======================================== I found that soamapi was imported twice, and I investigated this is related to absolute&relative import way. PyImport_ImportModule in python2.7 uses absolute import way, it will look up sys.path to get soamapi module, and when testP.py file import testPy module, it will find local module soamapi under testPy package, and binds module's name to package, as testPy.soamapi. There are two ways to correct it for python2.7, 1) Don't use import testPy, use import client directly to avoid using relative; 2) Use from __future__ import absolute_import to enable absolute import feature. But there are two Pre-conditions: 1) Should not modify testP.py; 2) Should be ran on both python2.4 and 2.7. I don't know how to fix it. Is there any official way about how to porting this scenario or better idea? Thanks, Vatel [View Less]

2 1

Python 3.5 now uses surrogateescape for the POSIX locale
by Victor Stinner March 19, 2014

March 19, 2014

Hi, I modified Python 3.5 to use the "surrogateescape" error handler (PEP 383) for stdin and stdout when the LC_CTYPE locale is POSIX ("C" locale): http://bugs.python.org/issue19977 New behaviour: --- $ mkdir z $ touch z/abcé $ LC_CTYPE=C ./python -c 'import os; print(os.listdir("z")[0])' abcé --- Old behaviour, before the change (test with Python 3.3): --- $ LC_CTYPE=C python3 -c 'import os; print(os.listdir("z")[0])' Traceback (most recent call last): File "<string>", line 1, in &… [View More]

4 7

Issues about relative& absolute import way for Porting from python2.4 to python2.7
by 北冰洋 March 19, 2014

March 19, 2014

Dear, I just wrote a sample like this: testPy/ __init__.py client.py SoamFactory.c SoamFactory.so soamapi.py sample/testP.py export PYTHONPATH=$(TEST_LOCATION):$(TEST_LOCATION)/testPy Here's the source codes: __init__.py: import client client.py import soamapi class Client(soamapi.SessionCallback): def __init__(self): print "----class Client----" super(Client, self).__init__() soamapi.initialize() def create_session(… [View More]self): sec_cb = soamapi.DefaultSecurityCallback() self.connection = soamapi.connect(sec_cb) soamapi.py import SoamFactory class ConnectionSecurityCallback(object): def __init__(self): print "----class ConnectionSecurityCallback----" def __del__(self): pass def test_P(self): print "test_P in class ConnectionSecurityCallback" class DefaultSecurityCallback(ConnectionSecurityCallback): def __init__(self): super(DefaultSecurityCallback, self).__init__() print "----class DefaultSecurityCallback----" def __del__(self): super(DefaultSecurityCallback, self).__del__() def test(self): print "test in class DefaultSecurityCallback" class SessionCallback(object): def __init__(self): pass def __del__(self): pass def connect(security_callback): return SoamFactory.SoamFactory_connect(security_callback) def initialize(): SoamFactory.SoamFactory_initialize() print "call soamapi" SoamFactory.c #include "Python.h" #include "PythonLoop.c" PyObject* SOAM_API_MODULE = NULL; PyObject* pyModule = NULL; static PyObject* SoamFactory_initialize(PyObject* self, PyObject* args){ PyEval_InitThreads(); init(); Py_RETURN_NONE; } static PyObject* SoamFactory_connect(PyObject* self, PyObject* args){ PyObject* pySecCallback = NULL; int ok = PyArg_ParseTuple(args, "O", &pySecCallback); if (!ok){ printf("parse tuple error!\n"); Py_RETURN_NONE; } if (! PyObject_IsInstance(pySecCallback, connectSecCallback)){ printf("pySecCallback is not an instance of ConnectionSecurityCallback!\n"); Py_RETURN_NONE; } printf("Successful!\n"); Py_RETURN_NONE; } static PyMethodDef SoamFactory[] = { {"SoamFactory_connect", SoamFactory_connect, METH_VARARGS, "connection function"}, {"SoamFactory_initialize", SoamFactory_initialize, METH_VARARGS, "SoamFactory_initialize"}, {NULL, NULL} }; void initSoamFactory(){ PyEval_InitThreads(); Py_Initialize(); pyModule = Py_InitModule("SoamFactory", SoamFactory); SOAM_API_MODULE = PyImport_ImportModule("soamapi"); } sample/testP.py import testPy print "========================================" submitter = testPy.client.Client() submitter.create_session() print "========================================" When I ran it on python2.4, it worked well, and the result was call soamapi after import soamapi------client.py ======================================== ----class Client---- ----class ConnectionSecurityCallback---- ----class DefaultSecurityCallback---- Successful! ======================================== But when I ran it on python2.7, it worked beyond my expectation, the result was call soamapi call soamapi ======================================== ----class Client---- ----class ConnectionSecurityCallback---- ----class DefaultSecurityCallback---- pySecCallback is not an instance of ConnectionSecurityCallback! ======================================== I found that soamapi was imported twice, and I investigated this is related to absolute&relative import way. PyImport_ImportModule in python2.7 uses absolute import way, it will look up sys.path to get soamapi module, and when testP.py file import testPy module, it will find local module soamapi under testPy package, and binds module's name to package, as testPy.soamapi. There are two ways to correct it for python2.7, 1) Don't use import testPy, use import client directly to avoid using relative; 2) Use from __future__ import absolute_import to enable absolute import feature. But there are two Pre-conditions: 1) Should not modify testP.py; 2) Should be ran on both python2.4 and 2.7. I don't know how to fix it. Is there any official way about how to porting this scenario or better idea? Thanks, Vatel [View Less]

1 0

Call for Python Developers for our humanoid Robot NAO
by Xavier Salort March 18, 2014

March 18, 2014

Hi, We are the manufacturer of the humanoid robot NAO : http://www.youtube.com/watch?v=nNbj2G3GmAo We are now offering great opportunities for developers to use NAO and would like to get in touch with you and your members : http://www.youtube.com/watch?v=_AxErdP0YI8 Let me know if you may be interested. Thank you! Xavier -- Xavier Salort Area Sales Manager M + 1 857 247 7777

7 7

Poll: Py_REPLACE/Py_ASSIGN/etc
by Serhiy Storchaka March 18, 2014

March 18, 2014

There were several suggestions for naming new macros which replace old value with new value and then (x)decref old value. #define Py_XXX(ptr, value) \ { \ PyObject *__tmp__ = ptr; \ ptr = new_value; \ Py_DECREF(__tmp__); \ } Listed in order of receipt: 1. Py_(X)SETREF. 2. Py_(X)ASSIGN. 3. Py_(X)DECREC_REPLACE. 4. Py_REF_ASSIGN (Py_XREF_ASSIGN? Py_REF_XASSIGN?). 5. Py_(X)REPLACE. 6. Py_(X)STORE 7. … [View More]

10 20