[issue15182] find_library_file() should try to link
Jeroen Demeyer added the comment: Sorry for the late answer, but yes: I found this out using an actual compilation. I must admit it was in a bit of an usual situation (32-bit userspace on a mixed 32/64-bit mutilib installation), but most other software packages have no problems configuring correctly in such a situation. I can imagine that it's not a trivial change and would require some redesign. Some more context: this was discovered when building Python as part of Sage, see http://trac.sagemath.org/sage_trac/ticket/12725 for the downstream bug report. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15182 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1222585] C++ compilation support for distutils
Changes by Jeroen Demeyer jdeme...@cage.ugent.be: -- nosy: +jdemeyer ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue1222585 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15182] find_library_file() should try to link
New submission from Jeroen Demeyer jdeme...@cage.ugent.be: The find_library_function() in Lib/distutils/unixccompiler.py does a very simple-minded check to determine the existence of a library. It basically only checks that a certain .so file exists. This may lead to false positives: the mere existence of a .so file does not imply that we can actually link against that library. In addition to (or even better: instead of) checking the existence of the file, you should try to (in the spirit of autoconf) compile a simple program using $CC -l$LIB prog.c -o prog One particular instance of where things can go wrong is with a 32-bit/64-bit multilib installation. Python might find a 64-bit library in /usr/lib when we're actually compiling 32-bit with libraries in /usr/lib32. -- assignee: eric.araujo components: Distutils messages: 163968 nosy: eric.araujo, jdemeyer, tarek priority: normal severity: normal status: open title: find_library_file() should try to link type: compile error versions: Python 2.7 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15182 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue17998] internal error in regular expression engine
New submission from Jeroen Demeyer:
On Linux Ubuntu 13.04, i686:
$ uname -a
Linux arando 3.5.0-26-generic #42-Ubuntu SMP Fri Mar 8 23:20:06 UTC 2013 i686
i686 i686 GNU/Linux
$ python
Python 2.7.5 (default, May 17 2013, 18:43:24)
[GCC 4.7.3] on linux2
Type help, copyright, credits or license for more information.
import re
re.compile('(.*)\.[0-9]*\.[0-9]*$', re.I|re.S).findall('3.0.0')
Traceback (most recent call last):
File stdin, line 1, in module
RuntimeError: internal error in regular expression engine
This is a 2.7.5 regression, 2.7.4 worked fine.
--
components: Library (Lib)
messages: 189461
nosy: jdemeyer
priority: normal
severity: normal
status: open
title: internal error in regular expression engine
versions: Python 2.7
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue17998
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue18000] _md5 should be built if _ssl cannot be built
New submission from Jeroen Demeyer: I have an Itanium Linux system where compiling Python's _ssl module fails for some reason, with the consequence that there is no md5 support at all in the resulting Python 2.7.5 installation. With Python 2.7.4, setup.py didn't even try to compile _ssl, instead it compiled the _sha, _md5, _sha256, _sha512 modules and it worked. With Python 2.7.5, setup.py somehow thinks that _ssl should work, tries to compile _ssl, which fails and (this is the real failure): it doesn't try anymore to compile the _sha, _md5, _sha256, _sha512 modules. -- components: Build messages: 189479 nosy: jdemeyer priority: normal severity: normal status: open title: _md5 should be built if _ssl cannot be built versions: Python 2.7 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue18000 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue18000] _md5 should be built if _ssl cannot be built
Jeroen Demeyer added the comment: Sure, building _ssl fails with: building '_ssl' extension gcc -pthread -fPIC -fno-strict-aliasing -g -O2 -DNDEBUG -g -fwrapv -O3 -Wall -I. -IInclude -I./Include -I/usr/include -I/home/buildbot/build/sage/iras-1/iras_full/build /sage-5.10.beta4/local/include -I/home/buildbot/local/iras/include -I/home/buildbot/build/sage/iras-1/iras_full/build/sage-5.10.beta4/spkg/build/python-2.7.5.p0/src/Inc lude -I/home/buildbot/build/sage/iras-1/iras_full/build/sage-5.10.beta4/spkg/build/python-2.7.5.p0/src -c /home/buildbot/build/sage/iras-1/iras_full/build/sage-5.10.bet a4/spkg/build/python-2.7.5.p0/src/Modules/_ssl.c -o build/temp.linux-ia64-2.7/home/buildbot/build/sage/iras-1/iras_full/build/sage-5.10.beta4/spkg/build/python-2.7.5.p0 /src/Modules/_ssl.o gcc -pthread -shared -L/home/buildbot/build/sage/iras-1/iras_full/build/sage-5.10.beta4/local/lib -L/home/buildbot/build/sage/iras-1/iras_full/build/sage-5.10.beta4/loc al/lib build/temp.linux-ia64-2.7/home/buildbot/build/sage/iras-1/iras_full/build/sage-5.10.beta4/spkg/build/python-2.7.5.p0/src/Modules/_ssl.o -L/usr/lib -L/lib -L/home /buildbot/build/sage/iras-1/iras_full/build/sage-5.10.beta4/local/lib -L/home/buildbot/local/iras/lib -L. -lssl -lcrypto -lpython2.7 -o build/lib.linux-ia64-2.7/_ssl.so /usr/bin/ld: /home/buildbot/local/iras/lib/libcrypto.a(obj_dat.o): @gprel relocation against dynamic symbol obj_cleanup_defer /usr/bin/ld: /home/buildbot/local/iras/lib/libcrypto.a(obj_dat.o): @gprel relocation against dynamic symbol obj_cleanup_defer /usr/bin/ld: final link failed: Nonrepresentable section on output collect2: error: ld returned 1 exit status But really: I think the main problem here is that _md5 isn't even attempted to build. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue18000 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue18000] _md5 should be built if _ssl cannot be built
Jeroen Demeyer added the comment: The problem on the machine that I mentioned was a regression from 2.7.4 to 2.7.5, probably due to #17086. Whether you consider a patch a bugfix or new feature is quite subjective, right? If #17086 is a bugfix, then this can also be a bugfix. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue18000 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue17086] backport cross-build patches to the 2.7 branch
Jeroen Demeyer added the comment: This is causing breakage, see #17990 and #18000. -- nosy: +jdemeyer ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue17086 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue16202] sys.path[0] security issues
New submission from Jeroen Demeyer: There is a serious security problem with Python's default sys.path. If I execute $ python /tmp/somescript.py then Python will add /tmp as sys.path[0], such that an import foobar will cause Python to read /tmp/foobar (or variations). This vulnerability exists in particular in distutils.util.byte_compile() with direct=False. Since the Python test suite calls this function, users running the Python test suite are vulnerable. I think the root of this issue should be fixed: Python should not simply add stuff to sys.path without checking. In prepared a patch for CPython-2.7 which only adds sys.path[0] if it seems secure to do so, by looking at file/directory permissions and ownership. In particular, it would never add /tmp to sys.path, but it would still keep the current behaviour when running a script in a directory owned by the current user with 0755 permissions. See the patch for details. I realize this goes against documented Python behaviour, but I think that a broken spec needs to be fixed. I also think that in most use cases, nothing is going to change because normally one doesn't need to import from /tmp. In any case, users can still manipulate sys.path directly. Feel free to fix this issue in a different way than my patch, but I hope you at least implement the spirit of my patch. The patch has only been tested on Linux systems. Credit goes to Volker Braun for first discovering this issue in Sage, see http://trac.sagemath.org/sage_trac/ticket/13579 -- components: Interpreter Core files: sys_path_security.patch keywords: patch messages: 172686 nosy: jdemeyer priority: normal severity: normal status: open title: sys.path[0] security issues type: security versions: Python 2.7 Added file: http://bugs.python.org/file27536/sys_path_security.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue16202 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue16202] sys.path[0] security issues
Jeroen Demeyer added the comment: Robert: I don't think that running scripts in /tmp is inherently unsafe. It is Python's sys.path handling which makes it unsafe. That being said, I am not against distutils being fixed but I do think the root issue should be fixed. And of course you're right about complicated permission checking and ACLs and what not. But I think my patch does the Right Thing in 99% of the cases, in particular for /tmp. I tried to err on the safe side. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue16202 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue16202] sys.path[0] security issues
Jeroen Demeyer added the comment: If you don't plan any further Python-2 releases, it would be pity that this cannot be fixed. If you do plan a further Python-2 release, I find backwards compatibility a poor excuse. I'm not saying that backwards compatibility should be totally ignored, but it certainly should not trump everything either, especially for security issues. I carefully designed my patch to have no impact for most existing secure setups (but as I said, I'm open for improvements). -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue16202 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue16202] sys.path[0] security issues
Jeroen Demeyer added the comment: It's sort of the same as #946373, except that bug report deals with other bad consequences of sys.path[0], unrelated to security. #5753 is specifically about the C API, not about running plain Python. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue16202 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue16202] sys.path[0] security issues
Jeroen Demeyer added the comment: I should point out that there is also dangerous code in Lib/test/test_subprocess.py in the test_cwd() function. There, the following is executed from /tmp: python -c 'import sys,os; sys.stdout.write(os.getcwd())' As Python luckily knows where to import sys and os from, this doesn't seem exploitable, but it should be fixed. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue16202 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue16202] sys.path[0] security issues
Changes by Jeroen Demeyer jdeme...@cage.ugent.be: Added file: http://bugs.python.org/file27923/sys_path_security.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue16202 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue16202] sys.path[0] security issues
Changes by Jeroen Demeyer jdeme...@cage.ugent.be: Removed file: http://bugs.python.org/file27536/sys_path_security.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue16202 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue16202] sys.path[0] security issues
Jeroen Demeyer added the comment: I updated sys_path_security.patch by a newer version. This version will be merged in the Python package of Sage (http://www.sagemath.org/). I realise that it looks unlikely that it will be merged in CPython, but at least it's here for reference. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue16202 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue25592] distutils docs: data_files always uses sys.prefix
New submission from Jeroen Demeyer: The documentation for distutils claims that sys.exec_prefix is used in certain cases to install data_files, but this is simply not true (maybe it was true in the past or this sentence was copy/pasted from somewhere else?) -- assignee: docs@python components: Documentation files: data_files_doc.patch keywords: patch messages: 254432 nosy: docs@python, jdemeyer priority: normal severity: normal status: open title: distutils docs: data_files always uses sys.prefix versions: Python 2.7 Added file: http://bugs.python.org/file40993/data_files_doc.patch ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue25592> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue25750] tp_descr_get(self, obj, type) is called without owning a reference to "self"
Changes by Jeroen Demeyer <jdeme...@cage.ugent.be>: -- type: -> crash ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue25750> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue25750] tp_descr_get(self, obj, type) is called without owning a reference to "self"
Jeroen Demeyer added the comment: Thanks for the pointer. My patch does fix the crash in Lib/test/crashers/borrowed_ref_2.py on Python 2.7.10. -- ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue25750> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue27177] re match.group should support __index__
Jeroen Demeyer added the comment: I would still argue that it's a bug. The intention of PEP 357 is that __index__ should be used whenever some object needs to be converted to a Py_ssize_t, which is exactly what you do here. -- ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue27177> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue27177] re match.group should support __index__
New submission from Jeroen Demeyer:
```
>>> class zero(object):
... def __index__(self):
... return 0
...
>>> z = zero()
>>> import re
>>> p = re.compile('(a)b')
>>> m = p.match('ab')
>>> m.group(0)
'ab'
>>> m.group(z)
Traceback (most recent call last):
File "", line 1, in
IndexError: no such group
```
--
components: Regular Expressions
files: re_match_index.patch
keywords: patch
messages: 266817
nosy: ezio.melotti, jdemeyer, mrabarnett
priority: normal
severity: normal
status: open
title: re match.group should support __index__
versions: Python 2.7
Added file: http://bugs.python.org/file43084/re_match_index.patch
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/issue27177>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue27177] re match.group should support __index__
Jeroen Demeyer added the comment: My use case is SageMath: http://trac.sagemath.org/ticket/20750 -- ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue27177> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4949] Constness in PyErr_NewException
Jeroen Demeyer added the comment: Follow-up: #26476 -- nosy: +jdemeyer ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue4949> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue26476] Constness in _PyErr_BadInternalCall
New submission from Jeroen Demeyer: PyErr_BadInternalCall() calls _PyErr_BadInternalCall(__FILE__, __LINE__). Since __FILE__ is a string constant, the first argument of _PyErr_BadInternalCall should be a "const char*" instead of a "char*". This is a follow-up to #4949. Most of the patch from #4949 was applied, but not the change to _PyErr_BadInternalCall on Python 2. -- components: Interpreter Core files: PyErr_BadInternalCall_const.patch keywords: patch messages: 261156 nosy: jdemeyer priority: normal severity: normal status: open title: Constness in _PyErr_BadInternalCall versions: Python 2.7 Added file: http://bugs.python.org/file42068/PyErr_BadInternalCall_const.patch ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue26476> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue26476] Constness in _PyErr_BadInternalCall
Jeroen Demeyer added the comment: > It is questionable wherever it should be backported to 2.7. It violates the C++ standard (for extension modules written in C++), so it's clearly a bug. -- ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue26476> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue26476] Constness in _PyErr_BadInternalCall
Jeroen Demeyer added the comment: > CPython is written on C and provides C API. If you look at the title of https://docs.python.org/2/extending/extending.html clearly C++ extensions are also supported. > Even if change the signature of one function, this will not help much, > because a lot of other functions require "char *" instead of "const char *". I don't know which functions you mean, I only encountered this problem for PyErr_BadInternalCall(). I should also add that the problem cannot be avoided or worked around for PyErr_BadInternalCall() because it's a CPython header itself which does an illegal conversion of a string constant to char*. > This will lead to incompatibility of your extension with older bugfix > releases. I don't see why there would be ABI incompatibility. My patch is only adding "const" in the call of a C function. -- ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue26476> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13285] signal module ignores external signal changes
Jeroen Demeyer added the comment: Let me add that this "low-level opaque object" would be rather easy to implement on POSIX systems (I have no clue about other systems such as Windows). I could implement it, but it would be good to have some pre-approval from Python devs that it's a good idea to do this. -- nosy: +jdemeyer ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue13285> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13285] signal module ignores external signal changes
Jeroen Demeyer added the comment: Here is a proposal for an API: * getsignal: return the Python-level signal handler (this is an existing function) * setsignal: set the Python-level signal handler (but not the OS-level signal handler) * getossignal: get the OS-level signal handler as opaque object * setossignal: set the OS-level signal handler with an opaque object Using these primitives, you could implement anything that you want on a higher level. -- ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue13285> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue29588] importing ssl can fail with NameError: name 'PROTOCOL_TLS' is not defined
New submission from Jeroen Demeyer: This is a regression introduced in Python 2.7.13: Importing the ssl module can fail with >>> import ssl Traceback (most recent call last): File "", line 1, in File "/Users/jdemeyer/sage/local/lib/python/ssl.py", line 133, in PROTOCOL_SSLv23 = PROTOCOL_TLS NameError: name 'PROTOCOL_TLS' is not defined While getting an ImportError from the ssl module is expected if SSL is not available (httplib for example handles that fine), a NameError is not. -- assignee: christian.heimes components: SSL messages: 287989 nosy: christian.heimes, jdemeyer priority: normal severity: normal status: open title: importing ssl can fail with NameError: name 'PROTOCOL_TLS' is not defined versions: Python 2.7 ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue29588> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue5755] "-Wstrict-prototypes" is valid for Ada/C/ObjC but not for C++"
Changes by Jeroen Demeyer <jdeme...@cage.ugent.be>: -- keywords: +patch Added file: http://bugs.python.org/file44464/no_strict_proto.patch ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue5755> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue5322] Python 2.6 object.__new__ argument calling autodetection faulty
Jeroen Demeyer added the comment: @serhiy.storchaka: yes, changing the order of the base classes fixes the issue with __new__. Also manually assigning __new__ works, like class C(A, B): __new__ = B.__new__ What is broken by this patch is only the auto-detection of which __new__ (really, which tp_new) should be called. @doko: not "another regression", it's exactly the one that we are talking about. -- ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue5322> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue5322] Python 2.6 object.__new__ argument calling autodetection faulty
Jeroen Demeyer added the comment: Wouldn't it be possible to fix assignment of __new__ without breaking backwards compatibility (and then apply the same patch for all Python versions)? I have a feeling that breaking the auto-detection of tp_new is a new bug introduced by this patch and not a fundamental feature needed to fix assignment of __new__. -- ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue5322> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue5322] Python 2.6 object.__new__ argument calling autodetection faulty
Jeroen Demeyer added the comment: Here is more minimal breaking example. This clearly shows that this patch breaks backwards compatibility. ``` $ cat obj.pyx cdef class OBJ(object): pass $ ipython Python 2.7.13rc1 (default, Dec 11 2016, 14:21:24) Type "copyright", "credits" or "license" for more information. IPython 5.1.0 -- An enhanced Interactive Python. ? -> Introduction and overview of IPython's features. %quickref -> Quick reference. help -> Python's own help system. object? -> Details about 'object', use 'object??' for extra details. In [1]: import pyximport; pyximport.install() Out[1]: (None, ) In [2]: import obj In [3]: class X(obj.OBJ, dict): ...: pass ...: In [4]: X() --- TypeError Traceback (most recent call last) in () > 1 X() TypeError: obj.OBJ.__new__(X) is not safe, use dict.__new__() ``` -- nosy: +jdemeyer ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue5322> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue25750] tp_descr_get(self, obj, type) is called without owning a reference to "self"
Jeroen Demeyer added the comment: If you are on POSIX, you could also use cysignals to get a traceback (simply import cysignals, which will install a handler for fatal signals like SIGSEGV). -- ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue25750> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue5322] Python 2.6 object.__new__ argument calling autodetection faulty
Jeroen Demeyer added the comment: It worries me that nothing in the Python docs nor in any PEP describes how tp_new is inherited. In my opinion, this patch makes a significant change which should be subject to a PEP. However, neither the old nor new behaviour is described anywhere. This also makes it harder to argue which behaviour is correct. -- ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue5322> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13285] signal module ignores external signal changes
Jeroen Demeyer added the comment: Ping? I'll try to implement this in cysignals (which is more difficult than doing it in CPython because I cannot access all internals of the Python signal module). -- ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue13285> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13285] signal module ignores external signal changes
Jeroen Demeyer added the comment: I have a preliminary implementation (in the cysignals package) at https://github.com/sagemath/cysignals/pull/53 -- ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue13285> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue30057] signal.signal should check tripped signals
New submission from Jeroen Demeyer: There is a race condition in calling signal.signal() if the signal arrives while (or right before) signal.signal() is being executed: the function signal.signal(sig, action) marks the signal "sig" as not tripped. Because of this, signals can get lost. Instead, it would be better to call PyErr_CheckSignals() to check for pending signals. -- components: Interpreter Core messages: 291561 nosy: jdemeyer priority: normal severity: normal status: open title: signal.signal should check tripped signals versions: Python 2.7, Python 3.5 ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue30057> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue30057] signal.signal should check tripped signals
Changes by Jeroen Demeyer <jdeme...@cage.ugent.be>: Added file: http://bugs.python.org/file46802/fix30057-py3.patch ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue30057> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue30057] signal.signal should check tripped signals
Changes by Jeroen Demeyer <jdeme...@cage.ugent.be>: -- keywords: +patch Added file: http://bugs.python.org/file46801/fix30057-py2.patch ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue30057> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue30071] Duck-typing inspect.isfunction()
Jeroen Demeyer added the comment: > As indicated above, perfect emulation seems impossible for Cython or any > other external compiler that does not use the same bytecode. True, Cython functions are not implemented using Python bytecode, so perfect emulation is impossible. The use case I care most about is getargspec(), which is fully supported by Cython functions. > If it were possible for Cython to makes its CythonFunction class a subclass > of FunctionType, the issue would be 'solved', though the incompatibilities > would remain. That's an interesting idea. Currently, that is simply impossible because >>> from types import FunctionType >>> class X(FunctionType): pass Traceback (most recent call last): File "", line 1, in TypeError: type 'function' is not an acceptable base type Still, one could argue to change the implementation of FunctionType. If you do that, it would be best to define a BaseFunctionType and then have Cython functions and Python functions inherit from that. Personally, I think that's an even better but much more involved solution (I guess it would require a PEP). -- ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue30071> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue30071] Duck-typing inspect.isfunction()
New submission from Jeroen Demeyer: Python is supposed to encourage duck-typing, but the "inspect" module doesn't follow this advice. A particular problem is that Cython functions are not recognized by the inspect module to be functions: http://cython.readthedocs.io/en/latest/src/userguide/limitations.html#inspect-support -- components: Library (Lib) messages: 291647 nosy: jdemeyer, scoder priority: normal severity: normal status: open title: Duck-typing inspect.isfunction() versions: Python 2.7, Python 3.3, Python 3.4, Python 3.5, Python 3.6, Python 3.7 ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue30071> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue30071] Duck-typing inspect.isfunction()
Changes by Jeroen Demeyer <jdeme...@cage.ugent.be>: -- keywords: +patch Added file: http://bugs.python.org/file46803/isfunction.patch ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue30071> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue30071] Duck-typing inspect.isfunction()
Jeroen Demeyer added the comment: > If inspect reports something is a duck, it should be an actual duck, not just > something that quacks. The problem is that some Python packages (Sphinx and IPython for example) really need to know whether it quacks. And the only tool they have is inspect.isfunction(), so they use that. It's silly that every single package using inspect.isfunction() should be fixed. Better just fix inspect.isfunction(). >>> from types import SimpleNamespace >>> x = SimpleNamespace(__code__=1, spam=2) >>> '__code__' in dir(x) Of course, you can always break stuff. User code is not supposed to invent new __dunder__ special names. -- ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue30071> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue30071] Duck-typing inspect.isfunction()
Jeroen Demeyer added the comment: For the record: the __code__ attribute of a Cython function is a real "code" object (the same type as the __code__ attribute of a Python function). Of course not all fields are relevant, for example co_code is empty. So I think it's clear that Cython tries really hard to be compatible with Python functions. -- ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue30071> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue30071] Duck-typing inspect.isfunction()
Jeroen Demeyer added the comment: At the very least, the inspect module should use more duck-typing internally. For example, consider this code from "getfile": if ismethod(object): object = object.__func__ if isfunction(object): object = object.__code__ if istraceback(object): object = object.tb_frame if isframe(object): object = object.f_code if iscode(object): return object.co_filename -- ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue30071> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue30071] Duck-typing inspect.isfunction()
Jeroen Demeyer added the comment: > So I expect that the case you 'care most about' already works. Yes, it works. That's the most ironic part of this issue: getfullargspec(func) works but packages like Sphinx will not call getfullargspec(func) because they do not detect that "func" is actually a function. -- ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue30071> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue29988] (async) with blocks and try/finally are not as KeyboardInterrupt-safe as one might like
Changes by Jeroen Demeyer <jdeme...@cage.ugent.be>: -- nosy: +jdemeyer ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue29988> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue29988] (async) with blocks and try/finally are not as KeyboardInterrupt-safe as one might like
Jeroen Demeyer added the comment: Nice analysis. I always assumed that `with` was safe from such race conditions, but it isn't. -- ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue29988> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue29988] (async) with blocks and try/finally are not as KeyboardInterrupt-safe as one might like
Jeroen Demeyer added the comment: > Or we could steal a bit in the opcode encoding or something. That seems like a very reasonable and easy-to-implement solution. It would generalize this check: https://github.com/python/cpython/blob/e82cf8675bacd7a03de508ed11865fc2701dcef5/Python/ceval.c#L1067-L1071 (@Nathaniel Smith: nice blog post!) -- ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue29988> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue29988] (async) with blocks and try/finally are not as KeyboardInterrupt-safe as one might like
Jeroen Demeyer added the comment: > Actually, I think it's between the end of the `try` and the beginning of the > `finally` (which is precisely the same place that *breaks* for a with > statement). Sorry, this is wrong and Erik was right. But the special case doesn't work anyway, so it doesn't really matter. -- ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue29988> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue29988] (async) with blocks and try/finally are not as KeyboardInterrupt-safe as one might like
Jeroen Demeyer added the comment: > It seems like that does at least try to guarantee that a signal can't > interrupt between: > > lock.acquire() > try: > ... Actually, I think it's between the end of the `try` and the beginning of the `finally` (which is precisely the same place that *breaks* for a with statement). -- ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue29988> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue31388] Provide a way to defer SIGINT handling in the current thread
Jeroen Demeyer <jdeme...@cage.ugent.be> added the comment: It's not only about ensuring that cleanup code gets run, but also about ensuring that the interrupt is actually seen. Currently, if you press CTRL-C at the "wrong" moment (during __del__), it will just get ignored. -- nosy: +jdemeyer ___ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue31388> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue5755] "-Wstrict-prototypes" is valid for Ada/C/ObjC but not for C++"
Change by Jeroen Demeyer <j.deme...@ugent.be>: -- nosy: +jdemeyer ___ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue5755> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue5755] "-Wstrict-prototypes" is valid for Ada/C/ObjC but not for C++"
Change by Jeroen Demeyer <j.deme...@ugent.be>: -- pull_requests: +6476 stage: -> patch review ___ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue5755> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue5755] "-Wstrict-prototypes" is valid for Ada/C/ObjC but not for C++"
Jeroen Demeyer <j.deme...@ugent.be> added the comment: > Or just remove it I updated the PR to do that. I didn't want to propose that initially because that patch was proposed here almost 2 years ago but not accepted. -- ___ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue5755> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue33445] test_cprofile should fail instead of displaying a message
Change by Jeroen Demeyer <j.deme...@ugent.be>: -- keywords: +patch pull_requests: +6420 stage: -> patch review ___ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue33445> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue33445] test_cprofile should fail instead of displaying a message
New submission from Jeroen Demeyer <j.deme...@ugent.be>:
When this test from Lib/test/test_profile.py fail, it just prints a message and
doesn't fail the testsuite:
def test_cprofile(self):
results = self.do_profiling()
expected = self.get_expected_output()
self.assertEqual(results[0], 1000)
for i, method in enumerate(self.methodnames):
if results[i+1] != expected[method]:
print("Stats.%s output for %s doesn't fit expectation!" %
(method, self.profilerclass.__name__))
print('\n'.join(unified_diff(
results[i+1].split('\n'),
expected[method].split('\n'
--
components: Tests
messages: 316287
nosy: jdemeyer
priority: normal
severity: normal
status: open
title: test_cprofile should fail instead of displaying a message
___
Python tracker <rep...@bugs.python.org>
<https://bugs.python.org/issue33445>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue5755] "-Wstrict-prototypes" is valid for Ada/C/ObjC but not for C++"
Jeroen Demeyer added the comment: > 2.7 doesn't have CFLAGS_NODIST I meant backporting this patch as-is to 2.7 without adding -Wstrict-prototypes to CFLAGS_NODIST -- ___ Python tracker <https://bugs.python.org/issue5755> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue5755] "-Wstrict-prototypes" is valid for Ada/C/ObjC but not for C++"
Jeroen Demeyer added the comment: > Can we backport this to 3.7 and 3.6? I think it's safe and helpful. And 2.7 for the same reasons. -- ___ Python tracker <https://bugs.python.org/issue5755> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue5755] "-Wstrict-prototypes" is valid for Ada/C/ObjC but not for C++"
Change by Jeroen Demeyer : -- pull_requests: +7099 ___ Python tracker <https://bugs.python.org/issue5755> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue33418] Memory leaks in functions
Jeroen Demeyer added the comment: > While this is a obvious bug, f.__module__ = f seems very unnatural. Sure. -- ___ Python tracker <https://bugs.python.org/issue33418> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue32797] Tracebacks from Cython modules no longer work
Jeroen Demeyer <j.deme...@ugent.be> added the comment: > How does CPython display the source for tracebacks in Cython modules? Do you mean the "python" command-line program? That uses a different algorithm: to find a file FOO, it searches [os.path.join(p, os.path.basename(FOO)) for p in sys.path] This is completely broken because it ignores all leading path components of FOO. So it will only work if your file is in the root of your package, not in a subdirectory. -- ___ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue32797> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue32797] Tracebacks from Cython modules no longer work
Jeroen Demeyer <j.deme...@ugent.be> added the comment: Since you are asking various "meta" questions, let me explain the wider context first. This bug report is coming from SageMath. Currently, SageMath only supports Python 2.7 but we are slowly and steadily porting it to Python 3. This bug is one of the many issues that we found while working on this port. It could very well be that SageMath is the only Cython project which *installs* the source code (although it would make sense to do that for all Cython projects once this bug is fixed). So the fact that nobody has complained before is simply because the only project that could hit this bug is running on Python 2 only. Also, people may be so used to not seeing Cython code in tracebacks that they don't question it. They may think that it's just a fact of life that it doesn't work. Concerning backporting to 3.y.z, that is not my decision to make. Of course, I would like to see this backported (it would be trivial to do that), but that should be decided by whoever accepts the pull request. In any case, I don't see why that should influence whether the patch should be accepted for 3.8. That seems to be putting things in the wrong order: first, the patch is applied to 3.8 and then we decide whether to backport it. -- ___ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue32797> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue32797] Tracebacks from Cython modules no longer work
Jeroen Demeyer <j.deme...@ugent.be> added the comment: > But the standard library has no need to ever find source for extension modules > So there's no need for the stdlib to be involved The standard library is not a closed system. It's not meant to support only itself, it's supposed to be an API. If linecache.getlines() is the Python API to get source code, then Cython code should use that API. Having a different competing API for getting source code (for other projects like Cython) is really the worst possible solution: some tools will only use linecache, other tools will use the new API and this will be a mess. > Note that I haven't said it shouldn't be fixed, merely that I'm not as > convinced, having read this discussion, that having linecache do a path search > if the loader returns None is *necessarily* the best solution here. Do you have other proposals? Like I said, the only thing that I want is one officially supported way to have the loader answer to linecache "I don't know where the sources are but continue looking for them". > Ideally, of course, there would be a CythonExtensionLoader that handled this > in get_source. That would be ideal solution indeed and it's the first thing that we tried to fix this. Unfortunately for Cython, PEP 302 (and in particular the get_source signature) was written with the assumption that a *single* module only has a *single* source file. This assumption doesn't hold for Cython code: like C, it supports include/declaration files which can contain code. So my conclusion is that loader.get_source() simply cannot work for Cython. -- ___ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue32797> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue32797] Tracebacks from Cython modules no longer work
Change by Jeroen Demeyer <j.deme...@ugent.be>: -- keywords: +patch pull_requests: +6349 stage: -> patch review ___ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue32797> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue32797] Tracebacks from Cython modules no longer work
Jeroen Demeyer <j.deme...@ugent.be> added the comment: > IMO, debating whether a None return means there's absolutely no chance of > there being source is silly - the best the loader can say is that it can't > provide source. I don't think it is silly: if "None" means that the loader cannot provide the source, then it makes sense to continue looking for the source. If "None" means that there is certainly no source, then it does not make sense to continue looking. > On the other hand, what is Cython source code even doing on sys.path? It's specifically installed for tracebacks (and other debugging). In a way, it's no different from installing both .py and .pyc files. Nobody questions that, even though the .pyc files are sufficient. > I sort of understand the benefit, but it does seem to be a practice peculiar > to one scenario Sure, it's particular but it's a real existing scenario. > and I'm not sure the standard library should deal with it. Depends what you mean with "deal with it". Basically, all that I'm asking for is at least one officially supported way to enable finding sources for extension modules. There are many possible ways to fix this, that's why I made this post to python-ideas. > I'm struggling to see how a Python programmer would benefit from access to > the source code of a compiled extension anyway. Cython code looks very much like Python. Very likely, a Python programmer would understand the Cython code. Anyway, this is besides the point: even if it just benefits the author of the Cython code, it's already useful. > it's not exactly an urgent issue. I never proposed to make it a release blocker :-) It's not urgent but it should still be fixed. > Cython still needs to work around the issue for users of older Pythons. No. Older versions already work because there is no ExtensionFileLoader. The changes in Python 3.x(?) actually broke this. Certainly in Python 2.7, those tracebacks work fine. -- ___ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue32797> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue33418] Memory leaks in functions
Change by Jeroen Demeyer <j.deme...@ugent.be>: -- components: +Interpreter Core type: -> resource usage ___ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue33418> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue33418] Memory leaks in functions
New submission from Jeroen Demeyer <j.deme...@ugent.be>: This is a memory leak: >>> while True: ...def f(): pass ...f.__doc__ = f This also: >>> while True: ... f = [].append ... f.__module__ = f This is because the classes "function" and "builtin_function_or_method" do not implement tp_clear. -- messages: 316125 nosy: jdemeyer priority: normal severity: normal status: open title: Memory leaks in functions ___ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue33418> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue32773] distutils should NOT preserve timestamps
New submission from Jeroen Demeyer <jdeme...@cage.ugent.be>: When a Python project is installed, distutils copies the files from the build to install directory using copy_file(). In this copy operation, timestamps are preserved. In other words, the timestamp of the installed file equals the timestamp of the source file. By contrast, autotools does not preserve timestamps: the timestamp of the installed files equals the time of installation. This makes more sense because of dependency checking: if you reinstall a package, you typically want to rebuild everything depending on that package. This issue is mostly relevant for installing .h files: most build systems (including distutils itself) provide a way to recompile C/C++ source files if they depend on a changed header file. But that only works if the timestamp of the header is updated when it is installed. Note that ./command/build_py.py contains a comment # XXX copy_file by default preserves atime and mtime. IMHO this is # the right thing to do, but perhaps it should be an option -- in # particular, a site administrator might want installed files to # reflect the time of installation rather than the last # modification time before the installed release. but without justification. -- components: Distutils messages: 311673 nosy: dstufft, eric.araujo, erik.bray, jdemeyer priority: normal severity: normal status: open title: distutils should NOT preserve timestamps versions: Python 2.7, Python 3.4, Python 3.5, Python 3.6, Python 3.7, Python 3.8 ___ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue32773> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue32773] distutils should NOT preserve timestamps
Jeroen Demeyer <jdeme...@cage.ugent.be> added the comment: This is a bug report and not a feature request. I don't think that there should be an option. It should just do the right thing, which is NOT preserving timestamps. -- ___ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue32773> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue32773] distutils should NOT preserve timestamps
Jeroen Demeyer <jdeme...@cage.ugent.be> added the comment: I am genuinely curious to hear a good reason why timestamps should be preserved by distutils. I cannot really imagine what could possibly break. As I said, this is the standard for many non-Python projects and it seems to work just fine. I can see one potential backwards-compatibility issue for projects abusing distutils to do things unrelated to installing Python packages. So I understand that you don't want to change the default in the copy_file() function, but only in the methods calling that function. -- ___ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue32773> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue32773] distutils should NOT preserve timestamps
Jeroen Demeyer <jdeme...@cage.ugent.be> added the comment: > if so wouldn't that still require an internal option? No, you just need to change the calls to the copy_file() function to add the keyword argument preserve_times=False If you agree, then I could easily provide a patch. -- ___ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue32773> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue32797] Tracebacks from Cython modules no longer work
Jeroen Demeyer <jdeme...@cage.ugent.be> added the comment: > Why? What would that help with? PEP 302 says get_source() can return None > [if] no sources are found. Returning None implies that it's absolutely impossible that there are sources to be found. But in certain cases (in the case of Cython), extension modules do have sources. So ExtensionFileLoader should assume that there may or may not be sources to be found. That is signalled by not implementing "get_source()". -- ___ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue32797> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue32797] Tracebacks from Cython modules no longer work
Jeroen Demeyer <jdeme...@cage.ugent.be> added the comment: > I don't think there's a bug in Python here, and that this is a problem that > needs to be solved on the Cython end. I'm not necessarily disagreeing here. It all depends on how ExtensionFileLoader is meant to be used. Should it try to support extension modules in the narrow sense (hand-written .c files) or in the broad sense (any kind of extension module, possibly auto-generated). Doing that properly in Cython would almost certainly need PEP 489 support though (Cython is in the process of implementing that, but apparently it's not easy) -- ___ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue32797> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue32797] Tracebacks from Cython modules no longer work
New submission from Jeroen Demeyer <jdeme...@cage.ugent.be>: Displaying the source code in tracebacks for Cython-compiled extension modules in IPython no longer works due to PEP 302. Various fixes are possible, the two most obvious ones are: 1. linecache should continue searching for the source file even if loader.get_source() returns None. 2. the method ExtensionFileLoader.get_source() should be removed (instead of being implemented and returning None). Now why was this broken and how do the above fix that? When IPython needs to display a traceback, it uses linecache.getlines() to get the source code to display. For Cython extensions, the filename is a correct *relative* filename (it must be a relative filename since Cython does not know where the sources will be after installation). Since the filename is relative, linecache does not immediately find it, so it looks for a PEP 302 loader. For extension modules (Cython or not), it finds an instance of ExtensionFileLoader. If the loader has a get_source() method, then it uses that to get the sources. Since ExtensionFileLoader.get_source() returns None, linecache stops looking further for sources. Instead, what should happen is that linecache continues looking for the sources in sys.path where it has a chance of finding them (if they are installed somewhere in sys.path). -- components: Library (Lib) messages: 311829 nosy: erik.bray, jdemeyer priority: normal severity: normal status: open title: Tracebacks from Cython modules no longer work ___ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue32797> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1617161] Instance methods compare equal when their self's are equal
Jeroen Demeyer added the comment: I just posted to python-dev about this issue: https://mail.python.org/pipermail/python-dev/2018-June/153959.html However, I think that comparing using "==" is the right thing to do. So I think that >>> [].append == [].append False should really return True. -- nosy: +jdemeyer ___ Python tracker <https://bugs.python.org/issue1617161> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue33925] builtin_function_or_method compares __self__ by identity instead of equality
Jeroen Demeyer added the comment: > This is a duplicate of issue1617161. Well, it's really the opposite. That issue seems to be arguing that __self__ should be compared using "is" while I think it should be compared using "==". -- ___ Python tracker <https://bugs.python.org/issue33925> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue33925] builtin_function_or_method compares __self__ by identity instead of equality
New submission from Jeroen Demeyer : Methods of Python functions compare equal if the functions are equal and if __self__ is equal: >>> class X: ... def __eq__(self, other): return True ... def meth(self): pass >>> X().meth == X().meth True This is because X() == X() even though X() is not X(). For extension types, we get instead: >>> [].append == [].append False This is because comparison is done with "is" instead of "==". This is a needless difference. -- messages: 320148 nosy: jdemeyer priority: normal severity: normal status: open title: builtin_function_or_method compares __self__ by identity instead of equality ___ Python tracker <https://bugs.python.org/issue33925> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue34280] METH_NOARGS: no longer require that second arg is NULL
Change by Jeroen Demeyer : -- keywords: +patch pull_requests: +8077 stage: -> patch review ___ Python tracker <https://bugs.python.org/issue34280> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue34280] METH_NOARGS: no longer require that second arg is NULL
New submission from Jeroen Demeyer : A C function with signature METH_NOARGS takes two arguments where the first is "self" and the second is guaranteed to be NULL. Given that this second argument really should never be used, I would like to drop the guarantee that the argument is NULL. Concretely, I propose to change: 1. the documentation for METH_NOARGS 2. some functions in Modules/_io/bufferedio.c which actually do use the second argument of a METH_NOARGS function. For the moment, the second argument is still NULL, but one is not supposed to rely on that. The reason for this patch is that this second argument can be re-purposed in PEP 580 (and possibly PEP 573) to pass the function object. -- components: Interpreter Core messages: 322670 nosy: jdemeyer priority: normal severity: normal status: open title: METH_NOARGS: no longer require that second arg is NULL type: enhancement versions: Python 3.8 ___ Python tracker <https://bugs.python.org/issue34280> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue34245] Python library should be installed writable
New submission from Jeroen Demeyer :
In Makefile.pre.in, there is this:
# Shared libraries must be installed with executable mode on some systems;
# rather than figuring out exactly which, we always give them executable mode.
# Also, making them read-only seems to be a good idea...
INSTALL_SHARED= ${INSTALL} -m 555
Installing libraries read-only is very non-standard (I'm not aware of any other
build system which does that). Python should just use the more standard 755
install mode.
--
components: Build
messages: 322469
nosy: jdemeyer
priority: normal
severity: normal
status: open
title: Python library should be installed writable
versions: Python 2.7, Python 3.4, Python 3.5, Python 3.6, Python 3.7, Python 3.8
___
Python tracker
<https://bugs.python.org/issue34245>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue34245] Python library should be installed writable
Change by Jeroen Demeyer : -- keywords: +patch pull_requests: +8012 stage: -> patch review ___ Python tracker <https://bugs.python.org/issue34245> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue34245] Python library should be installed writable
Jeroen Demeyer added the comment: Also, some tools may want to edit the library after installation. Rebasing on Cygwin is an example of that. -- ___ Python tracker <https://bugs.python.org/issue34245> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue34245] Python library should be installed writable
Jeroen Demeyer added the comment: > Isn't it useful to avoid accidental change while open files with editor for > just reading? Why would that argument apply to a binary file (and only to binary files)? > Is there any real world problem about read-only library? It makes it slightly harder to remove a Python installation. Depending on the OS, you'll get a failure or require some additional confirmation. Furthermore, it's very non-standard. Even if that's not a problem by itself, Python should just install things in the standard way. -- ___ Python tracker <https://bugs.python.org/issue34245> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue29502] Should PyObject_Call() call the profiler on C functions, use C_TRACE() macro?
Jeroen Demeyer added the comment: I always assumed that enabling profiling only from the Python bytecode interpreter was a deliberate choice. -- nosy: +jdemeyer ___ Python tracker <https://bugs.python.org/issue29502> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue34211] Cygwin build broken due to use of _Type in static declaration in _abc module
Jeroen Demeyer added the comment: For those who are not very aware of Cygwin issues: what is wrong with PyVarObject_HEAD_INIT(_Type, 0); -- nosy: +jdemeyer ___ Python tracker <https://bugs.python.org/issue34211> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue34280] METH_NOARGS: no longer require that second arg is NULL
Jeroen Demeyer added the comment: OK, I closed this without applying the change. It means one extra special case in PEP 580, but it's not a big deal. -- ___ Python tracker <https://bugs.python.org/issue34280> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue34287] bufferedio.c uses unused argument of METH_NOARGS functions
Change by Jeroen Demeyer : -- keywords: +patch pull_requests: +8091 stage: -> patch review ___ Python tracker <https://bugs.python.org/issue34287> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue34287] bufferedio.c uses unused argument of METH_NOARGS functions
New submission from Jeroen Demeyer : A METH_NOARGS function has a second unused argument which is always NULL (this is guaranteed by the documentation). However, some functions in Modules/_io/bufferedio.c actually that second NULL argument. This is technically not a bug, but it looks more clear to explicitly mark that second argument as unused. -- components: Extension Modules messages: 322736 nosy: jdemeyer, rhettinger, scoder priority: normal severity: normal status: open title: bufferedio.c uses unused argument of METH_NOARGS functions versions: Python 3.8 ___ Python tracker <https://bugs.python.org/issue34287> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue34280] METH_NOARGS: no longer require that second arg is NULL
Change by Jeroen Demeyer : -- stage: patch review -> resolved status: open -> closed ___ Python tracker <https://bugs.python.org/issue34280> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue34211] Cygwin build broken due to use of _Type in static declaration in _abc module
Jeroen Demeyer added the comment:
Linker issues are always tricky...
I understand that there is no problem within libpython, so the questions below
refer to extension modules. I am asking them from the point of view of somebody
writing Python extension modules who is clueless about Cygwin.
So you're saying that it's not allowed to refer to _Type in a static
struct? But it is OK to refer to _Type in code?
I assume that there is nothing special about PyType_Type and that this apply
for all variables. Are functions OK? For example, in functools.c I see
static PyGetSetDef partial_getsetlist[] = {
{"__dict__", PyObject_GenericGetDict, PyObject_GenericSetDict},
{NULL} /* Sentinel */
};
What makes functions different from variables? Aren't they essentially just
pointers?
--
___
Python tracker
<https://bugs.python.org/issue34211>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue32773] distutils should NOT preserve timestamps
Jeroen Demeyer added the comment: I started a discussion at https://mail.python.org/mm3/archives/list/distutils-...@python.org/thread/4FHEGHZYWCDRWVPGYLAU5VUS5BAX73MO/ -- ___ Python tracker <https://bugs.python.org/issue32773> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue34126] Profiling certain invalid calls crashes Python
Change by Jeroen Demeyer : -- resolution: -> fixed status: open -> closed ___ Python tracker <https://bugs.python.org/issue34126> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue32797] Tracebacks from Cython modules no longer work
Jeroen Demeyer added the comment:
> Then instead of adding the source directory to sys.path
What's wrong with that? Installing the .pyx sources together with the .so
compiled modules makes a lot of sense to me: it is very analogous to installing
the .py sources together with the .pyc byte-compiled files. In
https://bugs.python.org/issue32797#msg315965 Paul Moore disagreed with that
analogy, but I don't quite understand why.
And if ${prefix}/lib/pythonX.Y/site-packages/PKGNAME is not a good place to
store the installed sources, where would you want to install them otherwise?
> (which was only working because the legacy import system never implemented
> PEP 302 properly)
Not sure what you mean here...
--
___
Python tracker
<https://bugs.python.org/issue32797>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue32797] Tracebacks from Cython modules no longer work
Jeroen Demeyer added the comment: > In my view (and that of the documentation for sys.path), sys.path is where > you put things that the Python interpreter can load - .so files, .pyc files > and .py files. It's quite typical for packages to install stuff in site-packages which the interpreter cannot load. In fact, that's the exactly the point of the package_data argument to setup(), see https://packaging.python.org/guides/distributing-packages-using-setuptools/#package-data Just as an example, Numpy installs tons of stuff inside site-packages/numpy/ (header files, configuration files, data files for the testsuite) -- ___ Python tracker <https://bugs.python.org/issue32797> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue32797] Tracebacks from Cython modules no longer work
Jeroen Demeyer added the comment: To everybody who mentioned that Cython sources don't belong on sys.path: where *do* they belong then? One issue which hasn't been mentioned before is packaging. By installing Cython sources along with the generated .so files, we can re-use all the existing tooling from distutils/setuptools/wheel to install those source files. If we want to install them in a different way, ideally it should be done in a way sanctioned by the PyPA and the tools should support it. We should then also change linecache to search for source files in that directory. Unless somebody can come up with a simple suggestion, this seems to require basically a PEP. I don't plan to write that PEP and fight for it, since this can easily be fixed with essentially a 1-line patch to linecache, as I proposed in https://github.com/python/cpython/pull/6653 -- ___ Python tracker <https://bugs.python.org/issue32797> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue32797] Tracebacks from Cython modules no longer work
Jeroen Demeyer added the comment: > In a subdirectory similar to __pycache__. I thought about that, but I don't like the idea because then the directory structure of the actual sources would be different from the directory structure of the installed sources. So for example, how should "pip install -e" install the sources? -- ___ Python tracker <https://bugs.python.org/issue32797> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue32797] Tracebacks from Cython modules no longer work
Jeroen Demeyer added the comment: Nick: do you agree that this "source-only metapath" should by default contain an entry to look in sys.path for source files? -- ___ Python tracker <https://bugs.python.org/issue32797> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue32797] Tracebacks from Cython modules no longer work
Jeroen Demeyer added the comment: > Keeping two identical package structures in different places, one for .py > files and generated .so files, and one for Cython source files (.pyx, .pxd, > .pxi), is not desirable from a user perspective, and would require namespace > packages for the lookup, where otherwise a simple single Python package > structure would suffice. That would complicate Cython's internal compile time > import lookup system quite a bit. This is an important point. You shouldn't consider these Cython files as "extra stuff", they really should be considered as part of the package. -- ___ Python tracker <https://bugs.python.org/issue32797> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
