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:
--
nosy: +jdemeyer
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue1222585
___
___
Python-bugs
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
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
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:
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
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
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
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
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
Changes by Jeroen Demeyer <jdeme...@cage.ugent.be>:
--
type: -> crash
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/issue25750>
___
__
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
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:
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:
Follow-up: #26476
--
nosy: +jdemeyer
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/issue4949>
___
___
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:
> 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&
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:
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:
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
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
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:
@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:
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:
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
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:
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:
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.
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
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
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
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
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>:
--
keywords: +patch
Added file: http://bugs.python.org/file46803/isfunction.patch
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python
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
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:
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:
> 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
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:
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
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:
> 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 <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.
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>:
--
pull_requests: +6476
stage: -> patch review
___
Python tracker <rep...@bugs.python.org>
<https://bugs.py
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 tra
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_
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/iss
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/iss
Change by Jeroen Demeyer :
--
pull_requests: +7099
___
Python tracker
<https://bugs.python.org/issue5755>
___
___
Python-bugs-list mailing list
Unsubscribe:
Jeroen Demeyer added the comment:
> While this is a obvious bug, f.__module__ = f seems very unnatural.
Sure.
--
___
Python tracker
<https://bugs.python.org/issu
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:
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:
> 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
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:
> 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>:
--
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
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:
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
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:
> 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:
> 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
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
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 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
s
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 "==".
--
___
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() ==
Change by Jeroen Demeyer :
--
keywords: +patch
pull_requests: +8077
stage: -> patch review
___
Python tracker
<https://bugs.python.org/issue34280>
___
___
Py
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
argume
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
Change by Jeroen Demeyer :
--
keywords: +patch
pull_requests: +8012
stage: -> patch review
___
Python tracker
<https://bugs.python.org/issue34245>
___
___
Py
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/issue34
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 slight
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/issue29
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/issue34
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/issue34
Change by Jeroen Demeyer :
--
keywords: +patch
pull_requests: +8091
stage: -> patch review
___
Python tracker
<https://bugs.python.org/issue34287>
___
___
Py
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
Change by Jeroen Demeyer :
--
stage: patch review -> resolved
status: open -> closed
___
Python tracker
<https://bugs.python.org/issue34280>
___
___
Pyth
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
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/issue32
Change by Jeroen Demeyer :
--
resolution: -> fixed
status: open -> closed
___
Python tracker
<https://bugs.python.org/issue34126>
___
___
Python-bugs-list
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 b
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-packa
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
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 &
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.o
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
&
1 - 100 of 586 matches
Mail list logo
