[issue37493] Use _PyObject_CallNoArg() in a few more places

2019-07-04 Thread Jeroen Demeyer
Change by Jeroen Demeyer : -- resolution: -> fixed stage: patch review -> resolved status: open -> closed ___ Python tracker <https://bugs.python.or

[issue22117] Rewrite pytime.h to work on nanoseconds

2019-07-04 Thread Jeroen Demeyer
Change by Jeroen Demeyer : -- pull_requests: +14405 pull_request: https://github.com/python/cpython/pull/11636 ___ Python tracker <https://bugs.python.org/issue22

[issue29312] Use FASTCALL in dict.update()

2019-07-04 Thread Jeroen Demeyer
Jeroen Demeyer added the comment: > How can we avoid unpacking dict in case of d1.update(**d2)? We cannot. However, how common is that call? One could argue that we should optimize for the more common case of d1.update(d2). -- ___ Python trac

[issue29312] Use FASTCALL in dict.update()

2019-07-04 Thread Jeroen Demeyer
Jeroen Demeyer added the comment: Above, I meant #37207 or PR 13930. -- ___ Python tracker <https://bugs.python.org/issue29312> ___ ___ Python-bugs-list mailin

[issue29312] Use FASTCALL in dict.update()

2019-07-04 Thread Jeroen Demeyer
Jeroen Demeyer added the comment: > How can we avoid unpacking dict in case of d1.update(**d2)? The unpacking is only a problem if you insist on using PyDict_Merge(). It would be perfectly possible to implement dict merging from a tuple+vector instead of from a dict. In that case, th

[issue29312] Use FASTCALL in dict.update()

2019-07-04 Thread Jeroen Demeyer
Jeroen Demeyer added the comment: You are correct that PyDict_Merge() does not need to recompute the hashes of the keys. However, your example doesn't work because you need string keys for **kwargs. The "str" class caches its hash, so you would need a dict with a "str&

[issue37207] Use PEP 590 vectorcall to speed up calls to range(), list() and dict()

2019-07-04 Thread Jeroen Demeyer
Change by Jeroen Demeyer : -- pull_requests: +14406 pull_request: https://github.com/python/cpython/pull/14588 ___ Python tracker <https://bugs.python.org/issue37

[issue29312] Use FASTCALL in dict.update()

2019-07-04 Thread Jeroen Demeyer
Change by Jeroen Demeyer : -- pull_requests: +14407 stage: -> patch review pull_request: https://github.com/python/cpython/pull/14589 ___ Python tracker <https://bugs.python.org/issu

[issue37483] Add PyObject_CallOneArg()

2019-07-05 Thread Jeroen Demeyer
Change by Jeroen Demeyer : -- pull_requests: +14415 pull_request: https://github.com/python/cpython/pull/14600 ___ Python tracker <https://bugs.python.org/issue37

[issue37483] Add PyObject_CallOneArg()

2019-07-05 Thread Jeroen Demeyer
Jeroen Demeyer added the comment: > Jeroen: hum, you both proposed a similar fix :-) It seems that I lost the race ;-) But seriously: if we both independently came up with the same solution, that's a good sign that the solution is

[issue37207] Use PEP 590 vectorcall to speed up calls to range(), list() and dict()

2019-07-05 Thread Jeroen Demeyer
Jeroen Demeyer added the comment: One thing that keeps bothering me when using vectorcall for type.__call__ is that we would have two completely independent code paths for constructing an object: the new one using vectorcall and the old one using tp_call, which in turn calls tp_new and

[issue36974] Implement PEP 590

2019-07-05 Thread Jeroen Demeyer
Jeroen Demeyer added the comment: Any objections to closing this? -- ___ Python tracker <https://bugs.python.org/issue36974> ___ ___ Python-bugs-list mailin

[issue37151] Calling code cleanup after PEP 590

2019-07-05 Thread Jeroen Demeyer
Change by Jeroen Demeyer : -- pull_requests: +14418 pull_request: https://github.com/python/cpython/pull/14603 ___ Python tracker <https://bugs.python.org/issue37

[issue29312] Use FASTCALL in dict.update()

2019-07-08 Thread Jeroen Demeyer
Jeroen Demeyer added the comment: > d2 must be converted to 2 lists (kwnames and args) and then a new dict should > be created. The last part is not necessarily true. You could do the update directly, without having that intermediat

[issue29312] Use FASTCALL in dict.update()

2019-07-09 Thread Jeroen Demeyer
Jeroen Demeyer added the comment: > but it will make d1.update(**d2) slower with a complexity of O(n): d2 must be > converted to 2 lists This part is still true and it causes a slow-down of about 23% for dict.update(**d), see benchmarks at https://github.com/python/cpython/pull

[issue37540] vectorcall: keyword names must be strings

2019-07-10 Thread Jeroen Demeyer
New submission from Jeroen Demeyer : Keyword names in calls are expected to be strings, however it's currently not clear who should enforce/check this. I suggest to fix this for vectorcall/METH_FASTCALL and specify that it's the caller's job to make sure that keyword names a

[issue37540] vectorcall: keyword names must be strings

2019-07-10 Thread Jeroen Demeyer
Change by Jeroen Demeyer : -- keywords: +patch pull_requests: +14487 stage: -> patch review pull_request: https://github.com/python/cpython/pull/14682 ___ Python tracker <https://bugs.python.org/issu

[issue37483] Add PyObject_CallOneArg()

2019-07-10 Thread Jeroen Demeyer
Change by Jeroen Demeyer : -- resolution: -> fixed stage: patch review -> resolved status: open -> closed ___ Python tracker <https://bugs.python.or

[issue37484] Use PY_VECTORCALL_ARGUMENTS_OFFSET for __exit__

2019-07-10 Thread Jeroen Demeyer
Change by Jeroen Demeyer : -- resolution: -> fixed stage: patch review -> resolved status: open -> closed ___ Python tracker <https://bugs.python.or

[issue29548] Recommend PyObject_Call* APIs over PyEval_Call*() APIs

2019-07-10 Thread Jeroen Demeyer
Change by Jeroen Demeyer : -- pull_requests: +14488 pull_request: https://github.com/python/cpython/pull/14683 ___ Python tracker <https://bugs.python.org/issue29

[issue37151] Calling code cleanup after PEP 590

2019-07-10 Thread Jeroen Demeyer
Change by Jeroen Demeyer : -- pull_requests: +14490 pull_request: https://github.com/python/cpython/pull/14684 ___ Python tracker <https://bugs.python.org/issue37

[issue37547] Add _PyObject_CallMethodOneArg()

2019-07-10 Thread Jeroen Demeyer
New submission from Jeroen Demeyer : We already have _PyObject_CallNoArg() _PyObject_CallOneArg() _PyObject_CallMethodNoArgs() so it makes sense to also add _PyObject_CallMethodOneArg() -- components: Interpreter Core messages: 347619 nosy: inada.naoki, jdemeyer, vstinner priority

[issue37547] Add _PyObject_CallMethodOneArg()

2019-07-10 Thread Jeroen Demeyer
Change by Jeroen Demeyer : -- keywords: +patch pull_requests: +14492 stage: -> patch review pull_request: https://github.com/python/cpython/pull/14685 ___ Python tracker <https://bugs.python.org/issu

[issue37547] Add _PyObject_CallMethodOneArg()

2019-07-11 Thread Jeroen Demeyer
Change by Jeroen Demeyer : -- resolution: -> fixed stage: patch review -> resolved status: open -> closed ___ Python tracker <https://bugs.python.or

[issue29548] Recommend PyObject_Call* APIs over PyEval_Call*() APIs

2019-07-11 Thread Jeroen Demeyer
Jeroen Demeyer added the comment: I understand the arguments for not removing these functions. However, I still think that we should deprecate them but without planning in advance when they should be removed. Victor said that we should document these functions as "please don'

[issue37562] PEP 590 implementation introduced a performance regression

2019-07-11 Thread Jeroen Demeyer
Jeroen Demeyer added the comment: Could you please specify: - which commits are you comparing exactly? From your explanation, I guess aacc77fbd and its parent, but that's not completely fair since PEP 590 consists of many commits (see #36974). A better comparison would be master ag

[issue37562] PEP 590 implementation may have introduced a performance regression

2019-07-12 Thread Jeroen Demeyer
Jeroen Demeyer added the comment: I will certainly have a look and try a few things, but it will probably be next week. -- ___ Python tracker <https://bugs.python.org/issue37

[issue37588] Py_DEPRECATED and unavoidable warnings

2019-07-15 Thread Jeroen Demeyer
Jeroen Demeyer added the comment: See also https://github.com/python/cpython/pull/14193#pullrequestreview-251630953 -- nosy: +jdemeyer ___ Python tracker <https://bugs.python.org/issue37

[issue37562] PEP 590 implementation may have introduced a performance regression

2019-07-15 Thread Jeroen Demeyer
Jeroen Demeyer added the comment: I did some benchmarks WITHOUT PGO (simply because it's much faster to compile and therefore easier to test things out). The command I used for testing is ./python -m perf timeit --duplicate 200 -s 'f = len; x

[issue36974] Implement PEP 590

2019-07-15 Thread Jeroen Demeyer
Change by Jeroen Demeyer : -- pull_requests: +14578 pull_request: https://github.com/python/cpython/pull/14782 ___ Python tracker <https://bugs.python.org/issue36

[issue37562] PEP 590 implementation may have introduced a performance regression

2019-07-15 Thread Jeroen Demeyer
Change by Jeroen Demeyer : -- pull_requests: +14579 pull_request: https://github.com/python/cpython/pull/14782 ___ Python tracker <https://bugs.python.org/issue37

[issue37562] PEP 590 implementation may have introduced a performance regression

2019-07-15 Thread Jeroen Demeyer
Change by Jeroen Demeyer : -- versions: -Python 3.9 ___ Python tracker <https://bugs.python.org/issue37562> ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue37562] PEP 590 implementation may have introduced a performance regression

2019-07-15 Thread Jeroen Demeyer
Jeroen Demeyer added the comment: PR 14782 (backport of PR 13781) fixes the regression for me. -- ___ Python tracker <https://bugs.python.org/issue37

[issue37499] test_gdb.test_pycfunction should use dedicated test functions

2019-07-16 Thread Jeroen Demeyer
Change by Jeroen Demeyer : -- keywords: +patch pull_requests: +14589 stage: needs patch -> patch review pull_request: https://github.com/python/cpython/pull/14795 ___ Python tracker <https://bugs.python.org/issu

[issue29548] Recommend PyObject_Call* APIs over PyEval_Call*() APIs

2019-07-17 Thread Jeroen Demeyer
Change by Jeroen Demeyer : -- pull_requests: +14600 pull_request: https://github.com/python/cpython/pull/14804 ___ Python tracker <https://bugs.python.org/issue29

[issue37588] Py_DEPRECATED and unavoidable warnings

2019-07-17 Thread Jeroen Demeyer
Jeroen Demeyer added the comment: One possible solution would be to have a macro to suppress the tp_print field in the first place. Something like #ifndef PY_NO_TP_PRINT /* bpo-37250: kept for backwards compatibility in CPython 3.8 only */ Py_DEPRECATED(3.8) int (*tp_print)(PyObject

[issue37619] update_one_slot() should not ignore wrapper descriptors for wrong type

2019-07-18 Thread Jeroen Demeyer
New submission from Jeroen Demeyer : >>> class S(str): ... __eq__ = int.__eq__ >>> S() == S() True The expectation is that this raises an exception because int.__eq__() is called on S instances. -- components: Interpreter Core messages: 348108 nosy: jdemeye

[issue37619] update_one_slot() should not ignore wrapper descriptors for wrong type

2019-07-18 Thread Jeroen Demeyer
Change by Jeroen Demeyer : -- keywords: +patch pull_requests: +14627 stage: -> patch review pull_request: https://github.com/python/cpython/pull/14836 ___ Python tracker <https://bugs.python.org/issu

[issue37588] Py_DEPRECATED and unavoidable warnings

2019-07-19 Thread Jeroen Demeyer
Jeroen Demeyer added the comment: > We have some reserved/deprecated/unused fields. Setting 0 to them makes > forward incompatible code. Good point. tp_print is removed in 3.9 -- ___ Python tracker <https://bugs.python.org/i

[issue37588] Py_DEPRECATED and unavoidable warnings

2019-07-19 Thread Jeroen Demeyer
Jeroen Demeyer added the comment: I support the patch proposed in https://bugs.python.org/file48478/pyport.h.diff but it's not up to me to make that decision. -- ___ Python tracker <https://bugs.python.org/is

[issue34396] Certain methods that heap allocated subtypes inherit suffer a 50-80% performance penalty

2019-07-19 Thread Jeroen Demeyer
Change by Jeroen Demeyer : -- keywords: +patch pull_requests: +14652 stage: -> patch review pull_request: https://github.com/python/cpython/pull/14863 ___ Python tracker <https://bugs.python.org/issu

[issue37645] Replace PyEval_GetFuncName/PyEval_GetFuncDesc

2019-07-21 Thread Jeroen Demeyer
New submission from Jeroen Demeyer : PyEval_GetFuncName is bad API because 1. It hardcodes a limited number of function classes (which doesn't even include all function classes in the core interpreter) instead of supporting duck-typing. 2. In case of a "function" object,

[issue37645] Replace PyEval_GetFuncName/PyEval_GetFuncDesc

2019-07-21 Thread Jeroen Demeyer
Jeroen Demeyer added the comment: 4. It uses the __name__ instead of the __qualname__ -- ___ Python tracker <https://bugs.python.org/issue37645> ___ ___ Pytho

[issue37645] Replace PyEval_GetFuncName/PyEval_GetFuncDesc

2019-07-21 Thread Jeroen Demeyer
Change by Jeroen Demeyer : -- keywords: +patch pull_requests: +14673 stage: -> patch review pull_request: https://github.com/python/cpython/pull/14890 ___ Python tracker <https://bugs.python.org/issu

[issue35707] time.sleep() should support objects with __float__

2019-08-04 Thread Jeroen Demeyer
Jeroen Demeyer added the comment: > If we want to support other numerical types with loss in double rounding, the > most reliable way is to represent them as fractions (x.as_integer_ratio() or > (x.numerator, x.denominator)) See https://discuss.python.org/t/pep-3141-ratio-i

[issue37645] Replace PyEval_GetFuncName/PyEval_GetFuncDesc

2019-08-04 Thread Jeroen Demeyer
Jeroen Demeyer added the comment: Another solution would be to change the __str__ of various function objects to a prettier output. For example, we currently have >>> def f(): pass >>> print(f) We could change this to >>> def f(): pass >>> print(f) f

[issue28716] Fractions instantiation revisited

2019-08-05 Thread Jeroen Demeyer
Jeroen Demeyer added the comment: See https://discuss.python.org/t/pep-3141-ratio-instead-of-numerator-denominator/2037/24?u=jdemeyer for a proposal to define a new dunder __ratio__ (instead of as_integer_ratio) for this. -- nosy: +jdemeyer

[issue37562] PEP 590 implementation may have introduced a performance regression

2019-08-05 Thread Jeroen Demeyer
Jeroen Demeyer added the comment: Please close -- ___ Python tracker <https://bugs.python.org/issue37562> ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue36974] Implement PEP 590

2019-08-05 Thread Jeroen Demeyer
Jeroen Demeyer added the comment: > Should we add a note like "if you get a 'SystemError: bad call flags' on > import, check the descriptor flags of your functions" in What's New in Python > 3.8? A better solution would be to change the error message. We

[issue33829] C API: provide new object protocol helper

2019-08-05 Thread Jeroen Demeyer
Jeroen Demeyer added the comment: I agree with rejecting and closing this issue. -- nosy: +jdemeyer ___ Python tracker <https://bugs.python.org/issue33

[issue37774] Micro-optimize vectorcall using PY_LIKELY

2019-08-06 Thread Jeroen Demeyer
New submission from Jeroen Demeyer : Take the LIKELY/UNLIKELY macros out of Objects/obmalloc.c (renaming them of course). Use them in a few places to micro-optimize vectorcall. -- components: Interpreter Core messages: 349108 nosy: Mark.Shannon, inada.naoki, jdemeyer priority: normal

[issue37774] Micro-optimize vectorcall using PY_LIKELY

2019-08-06 Thread Jeroen Demeyer
Change by Jeroen Demeyer : -- keywords: +patch pull_requests: +14881 stage: -> patch review pull_request: https://github.com/python/cpython/pull/15144 ___ Python tracker <https://bugs.python.org/issu

[issue31388] Provide a way to defer SIGINT handling in the current thread

2019-08-07 Thread Jeroen Demeyer
Jeroen Demeyer added the comment: Another idea I had is to somehow deal with this in PyErr_WriteUnraisable: whenever PyErr_WriteUnraisable is called for a KeyboardInterrupt, defer that exception to a later time, for example when _PyEval_EvalFrameDefault() is called

[issue11165] Document PyEval_Call* functions

2019-08-07 Thread Jeroen Demeyer
Jeroen Demeyer added the comment: These functions are now officially deprecated, see PR 14804. So I think that this issue can be closed. -- nosy: +jdemeyer ___ Python tracker <https://bugs.python.org/issue11

[issue37822] Add math.as_integer_ratio()

2019-08-12 Thread Jeroen Demeyer
Jeroen Demeyer added the comment: Aren't you worried about using the non-special non-reserved attributes like "as_integer_ratio"? That's the reason why I proposed a dunder name "__ratio__" instead of "as_integer_ratio". In my opinion, it was a mista

[issue29988] (async) with blocks and try/finally are not as KeyboardInterrupt-safe as one might like

2017-06-28 Thread Jeroen Demeyer
Changes by Jeroen Demeyer : -- nosy: +jdemeyer ___ Python tracker <http://bugs.python.org/issue29988> ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue29988] (async) with blocks and try/finally are not as KeyboardInterrupt-safe as one might like

2017-06-28 Thread Jeroen Demeyer
Jeroen Demeyer added the comment: Nice analysis. I always assumed that `with` was safe from such race conditions, but it isn't. -- ___ Python tracker <http://bugs.python.org/is

[issue29988] (async) with blocks and try/finally are not as KeyboardInterrupt-safe as one might like

2017-06-28 Thread Jeroen Demeyer
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

[issue29988] (async) with blocks and try/finally are not as KeyboardInterrupt-safe as one might like

2017-06-28 Thread Jeroen Demeyer
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 p

[issue29988] (async) with blocks and try/finally are not as KeyboardInterrupt-safe as one might like

2017-06-28 Thread Jeroen Demeyer
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

[issue35707] time.sleep() should support objects with __float__

2019-01-10 Thread Jeroen Demeyer
New submission from Jeroen Demeyer : This used to work correctly in Python 2: class Half(object): def __float__(self): return 0.5 import time time.sleep(Half()) With Python 3.6, one gets instead Traceback (most recent call last): File "test.py", line 6, in time.

[issue35707] time.sleep() should support objects with __float__

2019-01-10 Thread Jeroen Demeyer
Jeroen Demeyer added the comment: > I'm not sure in which order the conversion should be tried to avoid/reduce > precision loss during the conversion. I would suggest the order 1. __index__ to ensure exact conversion of exact integers 2. __float__ to ensure correct conversion

[issue35707] time.sleep() should support objects with __float__

2019-01-13 Thread Jeroen Demeyer
Jeroen Demeyer added the comment: > the most reliable way is to represent them as fractions (x.as_integer_ratio() > or (x.numerator, x.denominator)) I don't think that we can rely on non-dunder names like that. They are not reserved names, so classes can give them any semantic

[issue35707] time.sleep() should support objects with __float__

2019-01-13 Thread Jeroen Demeyer
Jeroen Demeyer added the comment: > The correct code works for float and int (and maybe decimal.Decimal, I don't > recall!) Not for Decimal! In fact sleep(Decimal("0.99")) is interpreted as sleep(0) because __int

[issue13285] signal module ignores external signal changes

2019-01-16 Thread Jeroen Demeyer
Jeroen Demeyer added the comment: > In Jeroen's API, I can see what the Python-level signal handler is, but > there's no way to find out whether that signal handler is actually in use or > not. I added support for that in the latest cysignals release. Now you can do

[issue13285] signal module ignores external signal changes

2019-01-16 Thread Jeroen Demeyer
Jeroen Demeyer added the comment: For reference, the sources for my implementation: https://github.com/sagemath/cysignals/blob/master/src/cysignals/pysignals.pyx -- ___ Python tracker <https://bugs.python.org/issue13

[issue35707] time.sleep() should support objects with __float__

2019-01-18 Thread Jeroen Demeyer
Jeroen Demeyer added the comment: My proposal vastly improves the situation for Decimal. I will write a PR for this and I hope that it won't be rejected just because it's not perfect. -- ___ Python tracker <https://bugs.python.o

[issue35707] time.sleep() should support objects with __float__

2019-01-18 Thread Jeroen Demeyer
Jeroen Demeyer added the comment: I guess I should wait until PR 11507 is merged, to avoid merge conflicts. -- ___ Python tracker <https://bugs.python.org/issue35

[issue35707] time.sleep() should support objects with __float__

2019-01-21 Thread Jeroen Demeyer
Jeroen Demeyer added the comment: To avoid code duplication, it's tempting to merge _PyTime_FromObject and _PyTime_ObjectToDenominator These two functions almost do the same, but not quite. -- ___ Python tracker <https://bugs.py

[issue35707] time.sleep() should support objects with __float__

2019-01-21 Thread Jeroen Demeyer
Jeroen Demeyer added the comment: The motivation for PEP 357 was certainly using an object as the index for a sequence, but that's not the only use case. In fact PEP 357 states "For example, the slot can be used any time Python requires an integer internally" So despite the

[issue35794] test_posix.py test failure

2019-01-21 Thread Jeroen Demeyer
New submission from Jeroen Demeyer : This test was recently added (PR 6332): def test_no_such_executable(self): no_such_executable = 'no_such_executable' try: pid = posix.posix_spawn(no_such_executable, [no_such_

[issue35794] test_posix.py test failure

2019-01-21 Thread Jeroen Demeyer
Jeroen Demeyer added the comment: It's a relatively old Gentoo GNU/Linux system: Linux tamiyo 3.17.7-gentoo #2 SMP PREEMPT Fri Dec 23 18:13:49 CET 2016 x86_64 Intel(R) Core(TM) i7-2640M CPU @ 2.80GHz GenuineIntel GNU/Linux The problem occurs when there are directories on $PATH which ar

[issue35707] time.sleep() should support objects with __float__

2019-01-21 Thread Jeroen Demeyer
Jeroen Demeyer added the comment: If __index__ doesn't "feel" right, what do you propose then to fix this issue, keeping in mind the concerns of https://bugs.python.org/issue35707#msg333401 -- ___ Python tracker <https

[issue35707] time.sleep() should support objects with __float__

2019-01-21 Thread Jeroen Demeyer
Jeroen Demeyer added the comment: In other words: if we can only use __float__ and __int__, how do we know which one to use? -- ___ Python tracker <https://bugs.python.org/issue35

[issue35707] time.sleep() should support objects with __float__

2019-01-21 Thread Jeroen Demeyer
Jeroen Demeyer added the comment: > If we want to support other numerical types with loss in double rounding Looking at the existing code, I can already see several double-rounding "bugs" in the code, so I wouldn't be too m

[issue35707] time.sleep() should support objects with __float__

2019-01-21 Thread Jeroen Demeyer
Change by Jeroen Demeyer : -- pull_requests: +11407 ___ Python tracker <https://bugs.python.org/issue35707> ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue35707] time.sleep() should support objects with __float__

2019-01-21 Thread Jeroen Demeyer
Change by Jeroen Demeyer : -- pull_requests: +11407, 11408 ___ Python tracker <https://bugs.python.org/issue35707> ___ ___ Python-bugs-list mailing list Unsub

[issue35707] time.sleep() should support objects with __float__

2019-01-21 Thread Jeroen Demeyer
Change by Jeroen Demeyer : -- pull_requests: +11407, 11408, 11409 ___ Python tracker <https://bugs.python.org/issue35707> ___ ___ Python-bugs-list mailin

[issue35794] test_posix.py test failure

2019-01-21 Thread Jeroen Demeyer
Jeroen Demeyer added the comment: > Test with os.posix_spawn() is fine: Indeed, the difference between posix_spawn() and posix_spawnp() is that only the latter uses $PATH to look up the executable. -- ___ Python tracker <https://bugs.pyth

[issue19660] decorator syntax: allow testlist instead of just dotted_name

2019-01-21 Thread Jeroen Demeyer
Jeroen Demeyer added the comment: There is again some discussion about this at https://discuss.python.org/t/why-are-some-expressions-syntax-errors/420 -- ___ Python tracker <https://bugs.python.org/issue19

[issue35707] time.sleep() should support objects with __float__

2019-01-25 Thread Jeroen Demeyer
Change by Jeroen Demeyer : -- components: +Interpreter Core ___ Python tracker <https://bugs.python.org/issue35707> ___ ___ Python-bugs-list mailing list Unsub

[issue35707] time.sleep() should support objects with __float__

2019-01-28 Thread Jeroen Demeyer
Jeroen Demeyer added the comment: > I'm also mildly concerned by how duplicative the code becomes post-patch. I know, that's why I added that comment on GitHub. > perhaps just implement _PyTime_ObjectToTime_t as a wrapper for > _PyTime_ObjectToDenominator Sure, but wil

[issue35707] time.sleep() should support objects with __float__

2019-01-29 Thread Jeroen Demeyer
Jeroen Demeyer added the comment: > You've got a reference leak in your __index__ based paths. Thanks for pointing that out. I fixed that now. -- ___ Python tracker <https://bugs.python.org

[issue25592] distutils docs: data_files always uses sys.prefix

2019-01-29 Thread Jeroen Demeyer
Jeroen Demeyer added the comment: > it seems that Jeroen's analysis is right. So would you be willing to merge the PR then? -- ___ Python tracker <https://bugs.python.org

[issue25592] distutils docs: data_files always uses sys.prefix

2019-01-30 Thread Jeroen Demeyer
Jeroen Demeyer added the comment: > Fixing this on 2.7 would require additional investigation (distutils might > have diverged) Let's be honest, we are talking about distutils here. So it's way more likely that it didn't diverge and that the behavior is exactly the sam

[issue25592] distutils docs: data_files always uses sys.prefix

2019-02-01 Thread Jeroen Demeyer
Jeroen Demeyer added the comment: > Could you still give it a quick check? I did just that. For reference, these are the steps: - Checkout the "2.7" branch of the cpython git repo - ./configure --prefix=/tmp/prefix --exec-prefix=/tmp/eprefix && make && make

[issue25592] distutils docs: data_files always uses sys.prefix

2019-02-01 Thread Jeroen Demeyer
Jeroen Demeyer added the comment: (note typo in the above: /tmp/prefix/pip should be /tmp/prefix/bin/pip) -- ___ Python tracker <https://bugs.python.org/issue25

[issue35983] tp_dealloc trashcan shouldn't be called for subclasses

2019-02-13 Thread Jeroen Demeyer
New submission from Jeroen Demeyer : When designing an extension type subclassing an existing type, it makes sense to call the tp_dealloc of the base class from the tp_dealloc of the subclass. Now suppose that I'm subclassing "list" which uses the trashcan mechanism. Then it

[issue35983] tp_dealloc trashcan shouldn't be called for subclasses

2019-02-13 Thread Jeroen Demeyer
Jeroen Demeyer added the comment: The problem is easily reproduced with Cython: cdef class List(list): cdef int deallocated def __dealloc__(self): if self.deallocated: print("Deallocated twice!") self.deallocated = 1 L = None for i i

[issue35983] tp_dealloc trashcan shouldn't be called for subclasses

2019-02-13 Thread Jeroen Demeyer
Change by Jeroen Demeyer : -- keywords: +patch pull_requests: +11871 stage: test needed -> patch review ___ Python tracker <https://bugs.python.org/issu

[issue35983] tp_dealloc trashcan shouldn't be called for subclasses

2019-02-13 Thread Jeroen Demeyer
Jeroen Demeyer added the comment: NOTE: also OrderedDict currently uses trashcan hacking to work around this problem: /* Call the base tp_dealloc(). Since it too uses the trashcan mechanism, * temporarily decrement trash_delete_nesting to prevent triggering it * and putting

[issue17703] Trashcan mechanism segfault during interpreter finalization in Python 2.7.4

2019-02-13 Thread Jeroen Demeyer
Jeroen Demeyer added the comment: See also https://bugs.python.org/issue35983 for another trashcan-related issue. -- nosy: +jdemeyer ___ Python tracker <https://bugs.python.org/issue17

[issue35983] tp_dealloc trashcan shouldn't be called for subclasses

2019-02-14 Thread Jeroen Demeyer
Jeroen Demeyer added the comment: > Jeroen, could you share your example? I am learning the C-API of Python and > this example could be interesting. Either use the Cython code I posted above or run the testcase I added in PR 11841. -- ___

[issue13285] signal module ignores external signal changes

2017-04-12 Thread Jeroen Demeyer
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 <http://bugs.py

[issue13285] signal module ignores external signal changes

2017-04-12 Thread Jeroen Demeyer
Jeroen Demeyer added the comment: I have a preliminary implementation (in the cysignals package) at https://github.com/sagemath/cysignals/pull/53 -- ___ Python tracker <http://bugs.python.org/issue13

[issue30057] signal.signal should check tripped signals

2017-04-12 Thread Jeroen Demeyer
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

[issue30057] signal.signal should check tripped signals

2017-04-12 Thread Jeroen Demeyer
Changes by Jeroen Demeyer : -- keywords: +patch Added file: http://bugs.python.org/file46801/fix30057-py2.patch ___ Python tracker <http://bugs.python.org/issue30

[issue30057] signal.signal should check tripped signals

2017-04-12 Thread Jeroen Demeyer
Changes by Jeroen Demeyer : Added file: http://bugs.python.org/file46802/fix30057-py3.patch ___ Python tracker <http://bugs.python.org/issue30057> ___ ___ Python-bug

[issue30071] Duck-typing inspect.isfunction()

2017-04-14 Thread Jeroen Demeyer
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/lates

[issue30071] Duck-typing inspect.isfunction()

2017-04-14 Thread Jeroen Demeyer
Changes by Jeroen Demeyer : -- keywords: +patch Added file: http://bugs.python.org/file46803/isfunction.patch ___ Python tracker <http://bugs.python.org/issue30

<    1   2   3   4   5   6   >