Change by Jeroen Demeyer <j.deme...@ugent.be>:
--
nosy: +jdemeyer
___
Python tracker <rep...@bugs.python.org>
<https://bugs.python.org/issue5755>
___
__
Change by Jeroen Demeyer <j.deme...@ugent.be>:
--
keywords: +patch
pull_requests: +6420
stage: -> patch review
___
Python tracker <rep...@bugs.python.org>
<https://bugs.pyt
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_
Change by Jeroen Demeyer <j.deme...@ugent.be>:
--
components: +Interpreter Core
type: -> resource usage
___
Python tracker <rep...@bugs.python.org>
<https://bugs.pyt
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 Tru
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.b
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, i
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 Py
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" mea
Change by Jeroen Demeyer <j.deme...@ugent.be>:
--
keywords: +patch
pull_requests: +6349
stage: -> patch review
___
Python tracker <rep...@bugs.python.org>
<https://bugs.pyt
Jeroen Demeyer <j.deme...@ugent.be> added the comment:
Alternatively, instead of not implementing `loader.get_source()`, we could
define a new semantic: if it returns `NotImplemented`, assume that the loader
doesn't know how to get the sources. In that case, linecache would fal
Jeroen Demeyer <j.deme...@ugent.be> added the comment:
Can we please go back to the original issue? If you think that __code__ should
be an alias for __call__.__code__, that is a different issue.
On https://github.com/python/cpython/pull/6448#issuecomment-381507329 I posted
an alter
Jeroen Demeyer <j.deme...@ugent.be> added the comment:
> I would like python_coded_callable.__code__ to be the code object executed
> when python_coded_callable is called
First of all, that doesn't answer the question of what to do with non-Python
coded callables where there is
Jeroen Demeyer <j.deme...@ugent.be> added the comment:
The only attributes that a method is guaranteed to have are __func__ and
__self__ (which are the arguments passed to the MethodType constructor).
All other attributes are looked up through __func__ by the C version of the
following
Jeroen Demeyer <j.deme...@ugent.be> added the comment:
> I am wondering if, instead, the bug is in m, the object returned by
> MethodType, or in attribute lookup thereupon.
What would you expect m.__code__ to return then? Methods support arbitrary
callables and certainly not a
Change by Jeroen Demeyer <j.deme...@ugent.be>:
--
keywords: +patch
pull_requests: +6151
stage: -> patch review
___
Python tracker <rep...@bugs.python.org>
<https://bugs.pyt
Jeroen Demeyer <j.deme...@ugent.be> added the comment:
Follow-up: https://bugs.python.org/issue33265
--
___
Python tracker <rep...@bugs.python.org>
<https://bugs.python
New submission from Jeroen Demeyer <j.deme...@ugent.be>:
In contextlib, there is code which roughly looks like
def _exit_wrapper(exc_type, exc, tb):
return cm_exit(cm, exc_type, exc, tb)
_exit_wrapper.__self__ = cm
This creates a new function _exit_wrappe
Jeroen Demeyer <j.deme...@ugent.be> added the comment:
Why this?
_exit_wrapper.__self__ = cm
It seems that you are trying to create something which is exactly like a method
except that it's not a method. Is there any reason to not use an actual method?
It would actually simplify the co
Change by Jeroen Demeyer <j.deme...@ugent.be>:
--
keywords: +patch
pull_requests: +6144
stage: -> patch review
___
Python tracker <rep...@bugs.python.org>
<https://bugs.pyt
New submission from Jeroen Demeyer <j.deme...@ugent.be>:
The inspect functions isgeneratorfunction, iscoroutinefunction,
isasyncgenfunction can fail on methods that do not have a __code__ attribute:
>>> from types import MethodType
>>> class Callable:
...
New submission from Jeroen Demeyer <j.deme...@ugent.be>:
Setting PYTHONUSERBASE=/tmp/x/.. causes the Python test suite to fail:
==
FAIL: test_user_similar (test.test_sysconfig.TestSys
Jeroen Demeyer <j.deme...@ugent.be> added the comment:
Superseded by https://www.python.org/dev/peps/pep-0575/
--
stage: test needed -> resolved
status: open -> closed
___
Python tracker <rep...@bugs.python.org>
<https://bugs.
Jeroen Demeyer <j.deme...@ugent.be> added the comment:
See https://mail.python.org/pipermail/python-ideas/2018-March/049398.html
--
___
Python tracker <rep...@bugs.python.org>
<https://bugs.python
Change by Jeroen Demeyer <j.deme...@ugent.be>:
--
nosy: +jdemeyer
___
Python tracker <rep...@bugs.python.org>
<https://bugs.python.org/issue11566>
___
_
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. S
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
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 sea
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 provid
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 wor
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 t
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
Jeroen Demeyer <jdeme...@cage.ugent.be> added the comment:
Just to note that this bug affects SageMath too:
https://trac.sagemath.org/ticket/24528
Thanks for fixing!
--
nosy: +jdemeyer
___
Python tracker <rep...@bugs.python.or
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.
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
a
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 precis
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/ceva
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/i
Changes by Jeroen Demeyer <jdeme...@cage.ugent.be>:
--
nosy: +jdemeyer
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/issue29988>
___
_
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 &q
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 Cy
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
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 = objec
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 the
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
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
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
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
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 ca
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/i
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.
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
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
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
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
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>
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
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
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", "credi
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.pytho
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/i
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
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'
>>>
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,
> beca
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&
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. Mo
Jeroen Demeyer added the comment:
Follow-up: #26476
--
nosy: +jdemeyer
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/issue4949>
___
___
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/i
Changes by Jeroen Demeyer <jdeme...@cage.ugent.be>:
--
type: -> crash
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/issue25750>
___
__
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
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
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
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
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
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
Changes by Jeroen Demeyer jdeme...@cage.ugent.be:
--
nosy: +jdemeyer
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue1222585
___
___
Python-bugs
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
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
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
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
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
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
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
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
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
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
501 - 586 of 586 matches
Mail list logo
