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 h
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.__cod
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:
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 th
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 det
Jeroen Demeyer added the comment:
> I tried using compiler.compiler.remove('-Wstrict-prototypes') to no avail.
The -Wstrict-prototypes issue is a separate bug. It is fixed in Python >= 3.6
and there is an open backport PR for 2.7:
https://github.com/python/c
Jeroen Demeyer added the comment:
See also PEP 579 (issue 11) and the thread
https://mail.python.org/pipermail/python-ideas/2018-June/051572.html
--
nosy: +jdemeyer
___
Python tracker
<https://bugs.python.org/issue20
Jeroen Demeyer added the comment:
The consensus is clearly to return NotImplemented in this case, also because
that's what most builtins do, like the object() example that you mentioned.
However, I would rather keep that note and change it to say return
NotImplemented. It's an
Jeroen Demeyer added the comment:
I am curious, how did you find out about this bug? Do you have a concrete use
case for directly calling an instance of classmethod_descriptor? Typically, one
would write dict.fromkeys(...) instead of dict.__dict__['fromkeys'](dict, ...).
-
New submission from Jeroen Demeyer :
On Windows builds, one may get the message
C:\projects\cpython\PCbuild\_freeze_importlib.vcxproj(130,5): error :
importlib.h, importlib_external.h, importlib_zipimport.h updated. You will need
to rebuild pythoncore to see the changes.
See for example
Change by Jeroen Demeyer :
--
keywords: +patch
pull_requests: +12527
stage: -> patch review
___
Python tracker
<https://bugs.python.org/issue36448>
___
___
Py
Jeroen Demeyer added the comment:
Yes of course. When not using the trashcan, stuff crashes. I don't get your
point...
--
___
Python tracker
<https://bugs.python.org/is
Jeroen Demeyer added the comment:
To clarify: the purpose of MyList is specifically to check that no double
deallocations occur. For this test to make sense, MyList should not use the
trashcan itself.
--
___
Python tracker
<ht
Jeroen Demeyer added the comment:
> As an aside, I thought we had a merge hook to check this on Travis?
For some reason, the Travis CI build on
https://github.com/python/cpython/pull/12582 isn't actually starting. It says
"Waiting for status to be reported" but I p
Jeroen Demeyer added the comment:
Changing types like that looks like an ugly hack and a recipe for breakage. For
example, in list_dealloc(), the following needs the type to be correct:
if (numfree < PyList_MAXFREELIST && PyList_CheckExact(op))
free_list[numfree++] = o
Jeroen Demeyer added the comment:
> It disables the trashcan mechanism
Yes, it disables the trashcan in some cases. But only when using the trashcan
mechanism would probably crash CPython anyway due to a double deallocation. So
at the very least, PR 11841 improves things from "
Change by Jeroen Demeyer :
--
pull_requests: +12546
___
Python tracker
<https://bugs.python.org/issue35983>
___
___
Python-bugs-list mailing list
Unsubscribe:
Jeroen Demeyer added the comment:
I created an additional PR 12607 with some more changes to the, in particular
to make the old backwards-compatibility trashcan macros safer. This should be
seen as part of the same bugfix but I decided to make a new PR because PR 11841
had several positive
Jeroen Demeyer added the comment:
> I'd propose adding "%0D%0A%0D%0AIf you are developing on another platform,
> try make regen-all and commit the updated files"
I updated the PR with wording similar to that. I don't want to bikeshed too
much about the precise wor
Jeroen Demeyer added the comment:
Is anybody willing to review PR 11636?
--
___
Python tracker
<https://bugs.python.org/issue35707>
___
___
Python-bugs-list m
Jeroen Demeyer added the comment:
See also PEP 590, which has very similar ideas. Also PEP 580 is related to this.
--
___
Python tracker
<https://bugs.python.org/issue29
Change by Jeroen Demeyer :
--
pull_requests: +12612
___
Python tracker
<https://bugs.python.org/issue36347>
___
___
Python-bugs-list mailing list
Unsubscribe:
New submission from Jeroen Demeyer :
The "instance method" class is not used anywhere and there are no obvious use
cases. We should just deprecate it to simplify Python.
See discussion at
https://mail.python.org/pipermail/python-dev/2019-April/156975.html
--
messages: 3
Jeroen Demeyer added the comment:
> I'm tempted to call YAGNI on this.
Indeed. See https://bugs.python.org/issue36525
--
nosy: +jdemeyer
___
Python tracker
<https://bugs.python.or
Change by Jeroen Demeyer :
--
title: Deprecate instance method -> Deprecate instancemethod
___
Python tracker
<https://bugs.python.org/issue36525>
___
___
Py
Change by Jeroen Demeyer :
--
keywords: +patch
pull_requests: +12613
stage: -> patch review
___
Python tracker
<https://bugs.python.org/issue36525>
___
___
Py
Jeroen Demeyer added the comment:
> Amusingly, this is because of an old hack to make directly calling
> somedict.__getitem__ fast:
> https://github.com/python/cpython/commit/8f5cdaa784f555149adf5e94fd2e989f99d6b1db
But what's the use case of making somedict.__getitem__(x) fa
Jeroen Demeyer added the comment:
OK, makes sense. Also super() calls I guess: you can write
super().__getitem__(x) but not super()[x] (although the latter *could* be
implemented if we wanted to).
I see two ways of fixing this:
1. Make wrapper descriptors faster, removing the need for the
Jeroen Demeyer added the comment:
This should be closed.
--
nosy: +jdemeyer
___
Python tracker
<https://bugs.python.org/issue29209>
___
___
Python-bugs-list m
Jeroen Demeyer added the comment:
This might be solvable using PEP 580 by using METH_VARARGS instead of
METH_FASTCALL for such functions. This would still require a temporary tuple
for the positional args but no additional dict would need to be allocated.
--
nosy: +jdemeyer
Change by Jeroen Demeyer :
--
pull_requests: +12624
___
Python tracker
<https://bugs.python.org/issue35983>
___
___
Python-bugs-list mailing list
Unsubscribe:
Jeroen Demeyer added the comment:
I realized that there is a nasty interaction between the trashcan and __del__:
if you're very close to the trashcan limit and you're calling __del__, then
objects that should have been deallocated in __del__ (in particular, an object
involving s
Jeroen Demeyer added the comment:
In Python 3, the resurrection issue probably appears too. But it's not so much
a problem since __del__ (mapped to tp_finalize) is only called once anyway. So
there are no bad consequences if the object is resurrected incorr
New submission from Jeroen Demeyer :
NOTE: because of PEP 442, this issue is specific to Python 2. This bug was
discovered while adding testcases for bpo-35983 to the Python 2.7 backport.
There is a nasty interaction between the trashcan and __del__: if you're very
close to the tra
Change by Jeroen Demeyer :
--
keywords: +patch
pull_requests: +12648
stage: -> patch review
___
Python tracker
<https://bugs.python.org/issue36556>
___
___
Py
Change by Jeroen Demeyer :
--
pull_requests: +12653
___
Python tracker
<https://bugs.python.org/issue35983>
___
___
Python-bugs-list mailing list
Unsubscribe:
Jeroen Demeyer added the comment:
Why is this using type "sig_atomic_t" for a file descriptor instead of "int"
(which is the type of file descriptors)? See
https://github.com/python/cpython/pull/12670
--
nosy: +jdemeyer
___
Py
Jeroen Demeyer added the comment:
Just curious... how is PEP 384 relevant to modules insides CPython itself? I
thought that this only mattered for external packages. Do you expect people to
use a 3.7-compiled posixmodule.c on Python 3.8?
--
nosy: +jdemeyer
Jeroen Demeyer added the comment:
> Back in 2007 the only POSIX-compliant type allowed for that was sig_atomic_t,
> anything else was undefined.
Fair enough, but having a non-atomic type is still much better than a
completely wrong type. In other words, the requirement of fitting
Jeroen Demeyer added the comment:
I'm not sure with what you disagree. At least, you have to admit that using
sig_atomic_t is buggy for different reasons than signal safety, namely that
there is no guarantee that one can safely convert back and forth to an
Jeroen Demeyer added the comment:
> unpack the int into an array of sig_atomic_t.
What do you mean with this? You can't write a complete array atomically, so I
don't see how this would help.
--
___
Python tracker
<https:/
Jeroen Demeyer added the comment:
> Unpacking the int would mean having one sig_atomic_t for 'invalid', using
> that instead of INVALID_FD, plus an array of sig_atomic_t for the fd itself.
> Every time you want to change the fd you first set the 'invalid' flag,
New submission from Jeroen Demeyer :
On Linux with an old kernel:
0:03:59 load avg: 5.97 [300/420/1] test_posix failed -- running: test_tools (1
min 11 sec), test_concurrent_futures (2 min 42 sec)
test test_posix failed -- Traceback (most recent call last):
File "/usr/local/src/sage-c
Jeroen Demeyer added the comment:
> signal-safe is different from thread-safe
I know, but I think that other threads can receive signals too. So in that
case, it needs to be signal-safe as well as thread-safe.
--
___
Python tracker
<
New submission from Jeroen Demeyer :
Because of some discussion that is happening on #1583 I noticed this bit of
code in the OS-level signal handler (set by the C function sigaction() or
signal()):
static void
signal_handler(int sig_num)
{
/* See NOTES section above */
if (getpid
Change by Jeroen Demeyer :
--
keywords: +patch
pull_requests: +12711
stage: -> patch review
___
Python tracker
<https://bugs.python.org/issue36601>
___
___
Py
Jeroen Demeyer added the comment:
Also note that the documentation of the signal module already has the correct
wording:
Python signal handlers are always executed in the main Python thread, even if
the signal was received in another thread
Jeroen Demeyer added the comment:
> signalmodule.c has a hack to limit it to the main thread.
The Python signal handler always runs in the main thread, but the signal can be
caught by any thread. In other words, trip_signal() can be run by any thr
Change by Jeroen Demeyer :
--
type: -> performance
___
Python tracker
<https://bugs.python.org/issue36616>
___
___
Python-bugs-list mailing list
Unsubscrib
New submission from Jeroen Demeyer :
The bytecode interpreter uses an inline function call_function() to handle most
function calls. To check for profiling, call_function() needs to call to
PyThreadState_GET().
In the reference implementation of PEP 590, I saw that we can remove these
Jeroen Demeyer added the comment:
Mark, Petr, do you agree? I like the way how the reference implementation of
PEP 590 improves the handling of profiling. However, that change really has
little to do with PEP 590, it's something that we can do independ
Change by Jeroen Demeyer :
--
keywords: +patch
pull_requests: +12764
stage: -> patch review
___
Python tracker
<https://bugs.python.org/issue36616>
___
___
Py
Jeroen Demeyer added the comment:
The gain is small, but it's there.
I made some further changes:
- replacing code of the form
sp = stack_pointer;
call_function(..., &sp, ...)
stack_pointer = sp;
by
call_function(..., &stack_pointer, ...)
- fold the in
Jeroen Demeyer added the comment:
I don't really understand the rationale for these changes. What's wrong with
the global variable _PyRuntime?
What's the long-term goal for _PyRuntime? If you can't get rid of all
occurrences of _PyRuntime, how does it help to get rid
Jeroen Demeyer added the comment:
> The long term goal is to support multiple interpreter instances per process:
> Eric Snow's PEP 554 "Multiple Interpreters in the Stdlib"
> https://www.python.org/dev/peps/pep-0554/
Sorry, but I don't see the relation between thi
Jeroen Demeyer added the comment:
So what's the relation between _PyRuntime and PyInterpreterState? If the latter
is a structure per interpreter, what's the point of also making the former per
interpreter? It would be better to move data from _PyRuntime to
PyInterp
Jeroen Demeyer added the comment:
> It's wrong to share a single gc state between two interpreters
And what's your solution for that? I'm not asking for a complete
ready-to-implement answer, but at least a basic idea. Otherwise it's impossible
for me to judge whet
Jeroen Demeyer added the comment:
Changing *every* C API function to include a state parameter looks very
cumbersome. Another alternative would be to store the interpreter state in
every Python object (or every class, that would be sufficient). That way, you
would only need to pass context
Jeroen Demeyer added the comment:
Personally, I have always found "instance" and "owner" very confusing names for
these arguments. If you want to change the documentation, I would recommend
changing those names too. Better names would be "obj" and
Jeroen Demeyer added the comment:
> Perhaps the datamodel docs can be clarified to note that callers are allowed
> to omit the third argument
That's not true in general, only when __get__ is a slot wrapper (i.e. for
classes implemented in C). When __get__ is a Python functi
Jeroen Demeyer added the comment:
FYI: this one-liner installs the crashing versions:
pip3 install git+https://github.com/nickdrozd/astroid.git@crash
git+https://github.com/nickdrozd/pylint.git@crash
--
nosy: +jdemeyer
___
Python tracker
<ht
Jeroen Demeyer added the comment:
What seems to be happening is a recursion error while handling a recursion
error. Essentially
>>> def f():
... try:
... f()
... except:
... f()
...
>>> f()
Fatal Python error: Cannot recover from stack overfl
New submission from Jeroen Demeyer :
_PyStack_UnpackDict() is used to convert from the FastCallDict calling
convention to FastCallKeywords. It currently needs two allocations: one for the
tuple of keyword names and one for the array of arguments (positional and
keyword).
This can be
Change by Jeroen Demeyer :
--
nosy: +vstinner
___
Python tracker
<https://bugs.python.org/issue36904>
___
___
Python-bugs-list mailing list
Unsubscribe:
New submission from Jeroen Demeyer :
class IntWithDict:
def __init__(self, **kwargs):
self.kwargs = kwargs
def __index__(self):
self.kwargs.clear()
L = [2**i for i in range(1)]
return 0
x = IntWithDict(dont_inherit=float())
compile("",
Change by Jeroen Demeyer :
--
type: -> crash
___
Python tracker
<https://bugs.python.org/issue36907>
___
___
Python-bugs-list mailing list
Unsubscrib
Change by Jeroen Demeyer :
--
components: +Interpreter Core -Library (Lib)
___
Python tracker
<https://bugs.python.org/issue36904>
___
___
Python-bugs-list mailin
Jeroen Demeyer added the comment:
Ideally, this would be fixed together with #36907.
--
___
Python tracker
<https://bugs.python.org/issue36904>
___
___
Pytho
Jeroen Demeyer added the comment:
Ideally, this would be fixed together with #36904.
--
___
Python tracker
<https://bugs.python.org/issue36907>
___
___
Pytho
Jeroen Demeyer added the comment:
The idea of #36904 could be used here: define a special kind of tuple, which is
like an ordinary tuple followed by a C array of PyObject* entries (all
refcounted), terminated by a NULL to know where it ends. A special deallocation
function would decref all
Change by Jeroen Demeyer :
--
keywords: +patch
pull_requests: +13217
stage: -> patch review
___
Python tracker
<https://bugs.python.org/issue36907>
___
___
Py
Change by Jeroen Demeyer :
--
keywords: +patch
pull_requests: +13218
stage: -> patch review
___
Python tracker
<https://bugs.python.org/issue36904>
___
___
Py
Jeroen Demeyer added the comment:
Breakage due to the usage of borrowed references in _PyStack_UnpackDict():
#36907
--
nosy: +jdemeyer
___
Python tracker
<https://bugs.python.org/issue27
New submission from Jeroen Demeyer :
The new flag Py_TPFLAGS_METHOD_DESCRIPTOR proposed in PEP 590 is meant for
classes whose instances behave like unbound methods. In other words, it's meant
for objects supporting the LOAD_METHOD optimization. There are two such classes
in CPython: fun
Change by Jeroen Demeyer :
--
keywords: +patch
pull_requests: +13250
stage: -> patch review
___
Python tracker
<https://bugs.python.org/issue36922>
___
___
Py
New submission from Jeroen Demeyer :
The class classmethod_descriptor implements classmethods for builtin functions.
Unlike the plain classmethod class (which is used for Python classmethods),
instances of classmethod_descriptor are callable. However, calling them is
unlikely to happen in
Change by Jeroen Demeyer :
--
keywords: +patch
pull_requests: +13252
stage: -> patch review
___
Python tracker
<https://bugs.python.org/issue36924>
___
___
Py
New submission from Jeroen Demeyer :
Once PEP 590 is implemented, it makes sense to focus on using the new
"vectorcall" calling convention, which is essentially what is currently
FastCallKeywords. To simplify things, it would also be good to use FastCallDict
in as few places as po
Change by Jeroen Demeyer :
--
keywords: +patch
pull_requests: +13254
stage: -> patch review
___
Python tracker
<https://bugs.python.org/issue36926>
___
___
Py
New submission from Jeroen Demeyer :
Document and add an assertion that the "keyword names" tuple of the
CALL_FUNCTION_KW opcode must be non-empty. This is already the case with the
current compiler: if there are no keyword arguments in a call, then the
CALL_FUNCTION_KW opcode i
Change by Jeroen Demeyer :
--
keywords: +patch
pull_requests: +13266
stage: -> patch review
___
Python tracker
<https://bugs.python.org/issue36936>
___
___
Py
New submission from Jeroen Demeyer :
Add a new private function
PyObject *_PyObject_MakeTpCall(PyObject *callable, PyObject *const *args,
Py_ssize_t nargs, PyObject *keywords)
to call "callable" using tp_call, but with arguments given using the
FastCallKeywords or FastCallDict
Jeroen Demeyer added the comment:
> What happens when pass an empty tuple?
The way how bytecode is compiled, that doesn't actually happen so it's an
entirely hypothetical question.
The various XXX_FastCallKeywords functions seem to allow passing an empty tuple
to mean "no
Change by Jeroen Demeyer :
--
keywords: +patch
pull_requests: +13267
stage: -> patch review
___
Python tracker
<https://bugs.python.org/issue36937>
___
___
Py
Jeroen Demeyer added the comment:
I forgot to mention that the idea and first implementation comes from Mark
Shannon.
--
___
Python tracker
<https://bugs.python.org/issue36
Jeroen Demeyer added the comment:
Adding that assertion allows future optimizations and simplifications: with the
assertion, "keyword arguments are passed" becomes equivalent to
kwnames != NULL
instead of
kwnames != NULL && PyTuple_GET_SIZE(kwnames) > 0
This ma
Jeroen Demeyer added the comment:
Isn't it a *feature* that those doctest directives are not shown? Those
directives are meant for the doctest module only, not for the reader of the
rendered documentation.
--
nosy: +jdemeyer
___
Python tr
Jeroen Demeyer added the comment:
> Doctest directives in code examples should be suppressed everywhere *except*
> in the doctest.html examples showing how to use directives.
Thanks for clarifying. I missed that.
--
___
Python tracker
Jeroen Demeyer 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
<https://bugs.python.org/issue30
New submission from Jeroen Demeyer :
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
Jeroen Demeyer 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
<https://bugs.py
Jeroen Demeyer 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
Jeroen Demeyer 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
New submission from Jeroen Demeyer :
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
Jeroen Demeyer 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)
Jeroen Demeyer 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
Change by Jeroen Demeyer :
--
nosy: +jdemeyer
___
Python tracker
<https://bugs.python.org/issue11566>
___
___
Python-bugs-list mailing list
Unsubscribe:
Jeroen Demeyer added the comment:
See https://mail.python.org/pipermail/python-ideas/2018-March/049398.html
--
___
Python tracker
<https://bugs.python.org/issue30
Jeroen Demeyer added the comment:
Superseded by https://www.python.org/dev/peps/pep-0575/
--
stage: test needed -> resolved
status: open -> closed
___
Python tracker
<https://bugs.python.org/i
New submission from Jeroen Demeyer :
Setting PYTHONUSERBASE=/tmp/x/.. causes the Python test suite to fail:
==
FAIL: test_user_similar (test.test_sysconfig.TestSysConfig
301 - 400 of 588 matches
Mail list logo
