[issue10793] hashlib.hash.digest() documentation incorrect re return type
New submission from Thorsten Behrens : The documentation for hashlib.hash.digest() states that digest() will "[r]eturn the digest of the data passed to the update() method so far. This is a bytes array of size digest_size[...]". The returned object is of class 'bytes', not 'bytearray'. Documentation should reflect this. -- assignee: d...@python components: Documentation messages: 124892 nosy: d...@python, thorsten.behrens priority: normal severity: normal status: open title: hashlib.hash.digest() documentation incorrect re return type versions: Python 3.1, Python 3.2 ___ Python tracker <http://bugs.python.org/issue10793> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue7511] msvc9compiler.py: ValueError: [u'path']
Thorsten Behrens added the comment: Confirmed that this issue exists on Python 3.1 and 3.2b2. The exception thrown presents as: ValueError: ['path', 'include', 'lib'] -- ___ Python tracker <http://bugs.python.org/issue7511> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10773] "Building C and C++ Extensions on Windows" documentation shows 2.x way of initializing module
New submission from Thorsten Behrens : The documentation titled "Building C and C++ Extensions on Windows" at http://docs.python.org/py3k/extending/windows.html shows a Python 2.x way of handling static type object initializers, to whit: >> If your module creates a new type, you may have trouble with this line: PyVarObject_HEAD_INIT(&PyType_Type, 0) Static type object initializers in extension modules may cause compiles to fail with an error message like “initializer not a constant”. This shows up when building DLL under MSVC. Change it to: PyVarObject_HEAD_INIT(NULL, 0) and add the following to the module initialization function: MyObject_Type.ob_type = &PyType_Type; >> That last line will not function in Python 3.x. However, PyType_Ready will fill in the ob_type field if it is empty, if I understand PyType_Ready correctly. Therefore, the last few lines of this documentation snippet can become: >> and add the following to the module initialization function: if (PyType_Ready(&MyObject_Type) < 0) return NULL; >> -- assignee: d...@python components: Documentation messages: 124667 nosy: d...@python, thorsten.behrens priority: normal severity: normal status: open title: "Building C and C++ Extensions on Windows" documentation shows 2.x way of initializing module versions: Python 3.1 ___ Python tracker <http://bugs.python.org/issue10773> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9709] test_distutils warning: initfunc exported twice on Windows
Thorsten Behrens added the comment: Thank you for that patch, Stefan. I am currently tinkering with bringing pycrypto to 3.x and ran into this issue. initfunc2.patch resolves the issue on Win7-64, python31-64. I don't feel comfortable releasing code that requires the user to manually patch Python to build. What are my options here? Go back to void instead of PyMODINIT_FUNC? Is there aught else I can do to make sure pycrypto will build well "in the wild"? -- nosy: +thorsten.behrens ___ Python tracker <http://bugs.python.org/issue9709> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue7511] msvc9compiler.py: ValueError: [u'path']
Thorsten Behrens added the comment: You are right, this is not a bug in Python. The diff provides a workaround for a limitation in VC++ 2008 Express. This diff is a piece of user service. An equally as workable workaround is for the user to copy VC\bin\vcvars64.bat into VC\bin\amd64\vcvarsamd64.bat. Once that is done, distutils works without the workaround provided in this diff. Whether to provide a workaround within Python for an issue in VC++ 2008 Express can certainly be debated. I for one suggest to err on the side of being friendly, rather than insisting on purity. Consider that users of Python do include hobbyists and students. For them, VC++ Pro may be out of reach. And there are plenty of reasons for building 64-bit binaries, among them learning exercises. -- ___ Python tracker <http://bugs.python.org/issue7511> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue7511] msvc9compiler.py: ValueError: [u'path']
Thorsten Behrens added the comment: I can test this for 3.1, as all I have is the Express version of VC++. If you could point me towards a library that will work with 3.1 and has C components, that'll make the testing a lot easier. pycrypto and setuptools, the two libs mentioned in this issue, do not support Python 3.x. -- nosy: +sbehr...@gmx.li ___ Python tracker <http://bugs.python.org/issue7511> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
