[issue1423] wave sunau aifc 16bit errors
New submission from jeroen: When you write sound files wav sunau of aifc and you are using 16 bits samples. The number of frames in the files is incorrect. close function which updates the headers makes a mistake I assume. For the sunau type I had to double the number of frames in the close function to make it correct. If you do not correctg number of frames a 10 second file will play 5 seconds -- components: Library (Lib) messages: 57377 nosy: jeroen severity: normal status: open title: wave sunau aifc 16bit errors versions: Python 2.5 __ Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue1423> __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1423] wave sunau aifc 16bit errors
jeroen added the comment: I played using winsound.PlaySound function for the wav. I used VLC and windows media player for wav,au and aiff after that All had the same problem. It was solved for sunau by doubling the nframes number written by the close function in the sunau module. I assume something similar should be done for the wav and aiff modules. This is what I changed in sunau I am not sure if adding *self._sampwidth breaks something else. It works for me now when I create 16bit stereo files. def _patchheader(self): self._file.seek(8) # jjk added * sampwidth otherwise for 16 bit you get wrong nframes _write_u32(self._file, self._datawritten*self._sampwidth) self._datalength = self._datawritten self._file.seek(0, 2) Hope this helps. greetings __ Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue1423> __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1423] wave sunau aifc 16bit errors
jeroen added the comment: as far as I know. But i have not use or tested it since a long time On Sat, Sep 18, 2010 at 4:34 PM, Mark Lawrence wrote: > > Mark Lawrence added the comment: > > Is this still valid? > > -- > nosy: +BreamoreBoy -gvanrossum > versions: +Python 2.7, Python 3.1, Python 3.2 -Python 2.6, Python 3.0 > > ___ > Python tracker > <http://bugs.python.org/issue1423> > ___ > -- Added file: http://bugs.python.org/file18919/unnamed ___ Python tracker <http://bugs.python.org/issue1423> ___as far as I know. But i have not use or tested it since a long timeOn Sat, Sep 18, 2010 at 4:34 PM, Mark Lawrence <mailto:rep...@bugs.python.org";>rep...@bugs.python.org> wrote: Mark Lawrence <mailto:breamore...@yahoo.co.uk";>breamore...@yahoo.co.uk> added the comment: Is this still valid? -- nosy: +BreamoreBoy -gvanrossum versions: +Python 2.7, Python 3.1, Python 3.2 -Python 2.6, Python 3.0 ___ Python tracker <mailto:rep...@bugs.python.org";>rep...@bugs.python.org> <http://bugs.python.org/issue1423"; target="_blank">http://bugs.python.org/issue1423> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13926] IDLE closes when requesting a list of available modules in the online help utility
Changes by Jeroen : -- components: IDLE nosy: Jeroen priority: normal severity: normal status: open title: IDLE closes when requesting a list of available modules in the online help utility type: behavior versions: Python 2.7 ___ Python tracker <http://bugs.python.org/issue13926> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13926] IDLE closes when requesting a list of available modules in the online help utility
New submission from Jeroen : When using IDLE (2.7.2) in Ubuntu 11.10 the following error occurs: When the online help utility in IDLE is started (by entering the help() commando), it should be possible to get a list of all available modules by typing "modules". When I do so a message is shown that the list will be created, but after a few seconds the list isn't shown but IDLE is closed instead. Python version: Python 2.7.2+ (default, Oct 4 2011, 20:06:09) [GCC 4.6.1] on linux2 Tk version: 8.5 IDLE version: 2.7.2 2012/2/2 Jeroen > > Changes by Jeroen : > > > -- > components: IDLE > nosy: Jeroen > priority: normal > severity: normal > status: open > title: IDLE closes when requesting a list of available modules in the > online help utility > type: behavior > versions: Python 2.7 > > ___ > Python tracker > <http://bugs.python.org/issue13926> > ___ > -- ___ Python tracker <http://bugs.python.org/issue13926> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13926] pydoc - stall when requesting a list of available modules in the online help utility
Jeroen added the comment: Ned, I've run the "help()" from the command-line as requested and the result was: Python 2.7.2+ (default, Oct 4 2011, 20:06:09) [GCC 4.6.1] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> help() Welcome to Python 2.7! This is the online help utility. If this is your first time using Python, you should definitely check out the tutorial on the Internet at http://docs.python.org/tutorial/. Enter the name of any module, keyword, or topic to get help on writing Python programs and using Python modules. To quit this help utility and return to the interpreter, just type "quit". To get a list of available modules, keywords, or topics, type "modules", "keywords", or "topics". Each module also comes with a one-line summary of what it does; to list the modules whose summaries contain a given word such as "spam", type "modules spam". help> modules Please wait a moment while I gather a list of all available modules... /usr/lib/python2.7/dist-packages/gobject/constants.py:24: Warning: g_boxed_type_register_static: assertion `g_type_from_name (name) == 0' failed import gobject._gobject /usr/lib/python2.7/dist-packages/gtk-2.0/gtk/__init__.py:40: Warning: g_boxed_type_register_static: assertion `g_type_from_name (name) == 0' failed from gtk import _gtk ** (python:2050): CRITICAL **: pyg_register_boxed: assertion `boxed_type != 0' failed /usr/lib/python2.7/dist-packages/gtk-2.0/gtk/__init__.py:40: Warning: cannot register existing type `GdkDevice' from gtk import _gtk /usr/lib/python2.7/dist-packages/gtk-2.0/gtk/__init__.py:40: Warning: g_type_get_qdata: assertion `node != NULL' failed from gtk import _gtk Segmentation fault 2012/2/4 Ned Deily > > Ned Deily added the comment: > > Jeroen, if you try running "help()" from a command-line python2.7, rather > than in IDLE, what results do you get? Most likely, Python will crash > there and there should be an exception and traceback printed, in which case > the problem has nothing to do with IDLE directly. Note that there have > been some improvements to pydoc's robustness since 2.7.2 was released (for > instance, the changes for issue7425 and issue7367). > > (Terry, are you sure you meant Issue12092?) > > -- > nosy: +ned.deily > > ___ > Python tracker > <http://bugs.python.org/issue13926> > ___ > -- ___ Python tracker <http://bugs.python.org/issue13926> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10888] os.stat(filepath).st_mode gives wrong 'executable permission' result
Jeroen Dobbelaere added the comment: Some more background: The actual issue was initially detected when observing that the 'tarfile' package produced a tar containing different permissions, depending on the script being executed by 'cygwin python' or 'native python'. When using native python to do the 'untar', I did not observe any issue (as it seems to automatically add 'read and execute' for all files). But, when I used 'cygwin tar', the .dll did not get its 'read and execute' permission (as it was not specified in the tar file), which then resulted in program that crashed (with a very unhelpful message). Allowing 'read and execute' manually resolved the crash. So, although this permission should not mean anything, it does seem to have some influence :( -- ___ Python tracker <http://bugs.python.org/issue10888> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue5100] ElementTree.iterparse and Element.tail confusion
New submission from Jeroen Dirks : I am using cElementTree.iterparse in order to parse through a huge XML document and filter out sections of interest. The usage pattern is that I wait for an "end" event for a element of interest and then if it matches a some criterium I write it out using cElementTree.tostring(). My code had bug in it because the cElementTree.tostring methods prints the element including its tail. The element retreived from the iterparse iterator sometimes contains the tail by the time it emits the end event but sometimes it does not. In my document the tail just consisted of the newline '\n' character and about 98% of the time it was attached to the element during its end event. This is rather confusing behavior. Could ElementTree/cElementTree.iterparse be changed so that if you respond to the end event for an element its tail is never set? -- components: XML messages: 80783 nosy: jeroen.dirks severity: normal status: open title: ElementTree.iterparse and Element.tail confusion type: behavior versions: Python 2.6 ___ Python tracker <http://bugs.python.org/issue5100> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue37774] Micro-optimize vectorcall using PY_LIKELY
Jeroen Demeyer added the comment: > IHMO PGO compilation already defeats the purpose of these macros. That's certainly true. The question is whether we want to optimize also non-PGO builds. -- ___ Python tracker <https://bugs.python.org/issue37774> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue37836] Support .as_integer_ratio() in fractions.Fraction
New submission from Jeroen Demeyer : Currently, the fractions.Fraction constructor accepts an .as_integer_ratio() method only for the specific types "float" and "Decimal". It would be good to support this for arbitrary classes. This is part of what was proposed in #37822, but without adding the math.operator() function. -- components: Library (Lib) messages: 349536 nosy: jdemeyer, mark.dickinson, rhettinger, serhiy.storchaka, stutzbach priority: normal severity: normal status: open title: Support .as_integer_ratio() in fractions.Fraction versions: Python 3.9 ___ Python tracker <https://bugs.python.org/issue37836> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue37837] add internal _PyLong_FromUnsignedChar() function
Jeroen Demeyer added the comment: Maybe an even better idea would be to partially inline PyLong_FromLong(). If the check for small ints in PyLong_FromLong() would be inlined, then the compiler could optimize those checks. This would benefit all users of PyLong_FromLong() without code changes. -- nosy: +jdemeyer ___ Python tracker <https://bugs.python.org/issue37837> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue37774] Micro-optimize vectorcall using PY_LIKELY
Jeroen Demeyer added the comment: > If it's an optimization, can you show a benchmark to validate that it's > really faster as expected? Yes, I did test it. I didn't save the results, but I can redo them if you want. If you plan to reject the issue anyway, there is no point. > not building with PGO lead to random performances I would expect that Py_LIKELY/Py_UNLIKELY helps with this. If the compiler doesn't have probability information, it guesses. This can cause unrelated changes to change the heuristics used by the compiler, impacting the performance of some piece of code. With Py_LIKELY/Py_UNLIKELY, the code generated by the compiler should be more stable. -- ___ Python tracker <https://bugs.python.org/issue37774> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue37774] Micro-optimize vectorcall using PY_LIKELY
Jeroen Demeyer added the comment: We're not talking about prefetching here. The Py_LIKELY/Py_UNLIKELY macros only affect which of the two code paths in a branch is the "default" one, i.e. the one not involving a jmp. -- ___ Python tracker <https://bugs.python.org/issue37774> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue20861] datetime argument handling inconsistent; should accept logical integers, not coercible values
Jeroen Demeyer added the comment:
This is essentially a duplicate of #36048. The example is now deprecated:
>>> from decimal import Decimal
>>> from datetime import datetime
>>> datetime(Decimal("2000.5"), 1, 2)
:1: DeprecationWarning: an integer is required (got type
decimal.Decimal). Implicit conversion to integers using __int__ is deprecated,
and may be removed in a future version of Python.
datetime.datetime(2000, 1, 2, 0, 0)
So I think that this can be closed.
--
nosy: +jdemeyer
___
Python tracker
<https://bugs.python.org/issue20861>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue37774] Micro-optimize vectorcall using PY_LIKELY
Jeroen Demeyer added the comment: I claim that adding Py_LIKELY/Py_UNLIKELY will reduce the performance randomness of non-PGO builds. So it would be strange to use that randomness as an argument *against* this patch. -- ___ Python tracker <https://bugs.python.org/issue37774> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue37774] Micro-optimize vectorcall using PY_LIKELY
Jeroen Demeyer added the comment: > My question is if it is safe to let developers "abuse" it. If these macros > are misused, they can lead to a performance regression. I expect people using these macros and PR reviewers to use good judgement when to use these macros. There are many cases where the use of such macros should be uncontroversial, for example when checking for errors. > For example, if you mark the error path as unlikely: this path will become > slower. If the error path is taken "frequently" enough, the slowdown can > become significant overall. The speedup/slowdown that Py_LIKELY/Py_UNLIKELY gives is quite small, just a few clock cycles. This means that we shouldn't worry about performance regressions if the rest of the code takes much longer anyway. An example of this is raising exceptions, which typically involves PyErr_Format(). So I wouldn't worry too much about error paths getting slower. > About the macros, I would prefer to make it private to not promote it. I don't think it matters whether we call it Py_LIKELY or _Py_LIKELY. People that want to use it will use it anyway. And there is no issue with "provisional API" since this API is well-established in many existing projects. -- ___ Python tracker <https://bugs.python.org/issue37774> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue37645] Replace PyEval_GetFuncName/PyEval_GetFuncDesc
Jeroen Demeyer added the comment: > Maybe repr(func) should be left unchanged, but str(func) can be enhanced? Yes, that is what I meant. -- ___ Python tracker <https://bugs.python.org/issue37645> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue37645] Replace PyEval_GetFuncName/PyEval_GetFuncDesc
Change by Jeroen Demeyer : -- pull_requests: +15018 pull_request: https://github.com/python/cpython/pull/15295 ___ Python tracker <https://bugs.python.org/issue37645> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue37540] vectorcall: keyword names must be strings
Change by Jeroen Demeyer : -- resolution: -> fixed stage: patch review -> resolved status: open -> closed ___ Python tracker <https://bugs.python.org/issue37540> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue37645] Replace PyEval_GetFuncName/PyEval_GetFuncDesc
Jeroen Demeyer added the comment: > I'm wary of making error messages depend on the str representation of a > function; that would prevent us from changing it later. Why wouldn't we be able to change anything? Typically, the exact string of an error message is NOT part of the API (the exception *type* is, but we're not talking about that). > I'm wary of "%S" used in error messages. Those are for the programmer, not > the user I'm not following here. Given that Python is a programming language, the user *is* the programmer. Anyway, you don't have to be convinced. I'm trying to solve a problem here and I have two approaches (PR 14890 and PR 15295). I'm more inclined towards PR 15295, but if you like the idea of PR 14890 better, we can go with that instead. -- ___ Python tracker <https://bugs.python.org/issue37645> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue37645] Replace PyEval_GetFuncName/PyEval_GetFuncDesc
Jeroen Demeyer added the comment: > I'm wary of "%S" used in error messages. Maybe you're misunderstanding something. The goal is not really to change error messages, only the way how they are produced. For example, we currently have >>> def f(): pass >>> f(**1) Traceback (most recent call last): File "", line 1, in TypeError: f() argument after ** must be a mapping, not int This is about how the "f()" in the error message is produced. Currently, this uses PyEval_GetFuncName() and PyEval_GetFuncDesc(). For the reasons explained in this issue, I want to replace that. I see two ways of doing this: 1. (PR 14890) Write a new function _PyObject_FunctionStr(func) which returns func.__qualname__ + "()" with a suitable fallback if there is no __qualname__ attribute. At some point, we could also introduce a %F format character for this. 2. (PR 15295) Use str(func) in the error message and change various __str__ methods (really tp_str functions) to give a more readable output. -- ___ Python tracker <https://bugs.python.org/issue37645> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue37836] Support .as_integer_ratio() in fractions.Fraction
Change by Jeroen Demeyer : -- keywords: +patch pull_requests: +15045 stage: -> patch review pull_request: https://github.com/python/cpython/pull/15327 ___ Python tracker <https://bugs.python.org/issue37836> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue37836] Support .as_integer_ratio() in fractions.Fraction
Change by Jeroen Demeyer : -- pull_requests: +15046 pull_request: https://github.com/python/cpython/pull/15328 ___ Python tracker <https://bugs.python.org/issue37836> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue37836] Support .as_integer_ratio() in fractions.Fraction
Jeroen Demeyer added the comment: > See issue37884 which uses a C accelerator. Note that that doesn't replace this issue, because I need to support as_integer_ratio both in the *numerator* and *denominator*. -- ___ Python tracker <https://bugs.python.org/issue37836> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue37884] Optimize Fraction() and statistics.mean()
Jeroen Demeyer added the comment: > There is a 14% regression in creating a Fraction from an integer Isn't that the main use case? I suggest to keep the special case for 'int' as fast path to avoid this regression. -- nosy: +jdemeyer ___ Python tracker <https://bugs.python.org/issue37884> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue37836] Support .as_integer_ratio() in fractions.Fraction
Jeroen Demeyer added the comment: > I afraid this can slow down the Fraction constructor. No, it doesn't! It even speeds up the constructor in some cases: ./python -m perf timeit --duplicate 200 -s 'from fractions import Fraction; x = 1' 'Fraction(x)' BEFORE: Mean +- std dev: 826 ns +- 20 ns AFTER: Mean +- std dev: 814 ns +- 17 ns ./python -m perf timeit --duplicate 200 -s 'from fractions import Fraction; x = 1' 'Fraction(x, x)' BEFORE: Mean +- std dev: 1.44 us +- 0.03 us AFTER: Mean +- std dev: 1.46 us +- 0.02 us ./python -m perf timeit --duplicate 200 -s 'from fractions import Fraction; x = Fraction(1)' 'Fraction(x)' BEFORE: Mean +- std dev: 1.64 us +- 0.03 us AFTER: Mean +- std dev: 1.30 us +- 0.04 us ./python -m perf timeit --duplicate 200 -s 'from fractions import Fraction; x = Fraction(1)' 'Fraction(x, x)' BEFORE: Mean +- std dev: 3.03 us +- 0.05 us AFTER: Mean +- std dev: 2.34 us +- 0.06 us ./python -m perf timeit --duplicate 200 -s 'from fractions import Fraction; x = 1.0' 'Fraction(x)' BEFORE: Mean +- std dev: 1.82 us +- 0.02 us AFTER: Mean +- std dev: 1.29 us +- 0.04 us -- ___ Python tracker <https://bugs.python.org/issue37836> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue37819] as_integer_ratio() missing from fractions.Fraction()
Jeroen Demeyer added the comment: > Sorry, but I do not understand why adding Fraction.as_integer_ratio() > prevents adding math.as_integer_ratio(). I also support a public function for that. It seems that we're planning this "as_integer_ratio" thing to become public API, so why not have a function as Serhiy proposes? I consider the situation with as_integer_ratio() very analogous to __index__ where we have operator.index(), so I would actually suggest operator.as_integer_ratio() but that's bikeshedding territory. -- nosy: +jdemeyer ___ Python tracker <https://bugs.python.org/issue37819> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue37884] Optimize Fraction() and statistics.mean()
Jeroen Demeyer added the comment: > ISTM that small and probably unimportant opimizations shouldn't spill-over > into API feature creep. The way I see it, the optimization is besides the point here. Regardless of performance, the added function is a useful feature to have to avoid forcing people to reinvent the wheel. For example, would you want the exact same code duplicated for fractions.Fraction() and for statictics.mean()? See also #37836 in case you didn't know about that issue. -- ___ Python tracker <https://bugs.python.org/issue37884> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue37884] Optimize Fraction() and statistics.mean()
Jeroen Demeyer added the comment: > AFAICT, no end-user has ever requested this ever. What do you mean with "this"? (A) A public function like math.as_integer_ratio() (B) Using as_integer_ratio() in the fractions.Fraction() constructor (C) The optimization of the fractions.Fraction() constructor For SageMath, (B) would be very useful. See https://discuss.python.org/t/pep-3141-ratio-instead-of-numerator-denominator/2037/24?u=jdemeyer (replace __ratio__ by as_integer_ratio) -- ___ Python tracker <https://bugs.python.org/issue37884> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue37884] Optimize Fraction() and statistics.mean()
Jeroen Demeyer added the comment: > our needs tend to be much different from end-users This issue is about fractions and statistics, which are closer to typical user libraries than CPython libraries. In fact, both could easily be packages on PyPI instead of part of the standard library. > no end-user has ever requested this ever. If math.as_integer_ratio() existed, probably SageMath would use it. On the other hand, the code for math.as_integer_ratio() is simple enough that SageMath could easily implement it if needed. -- ___ Python tracker <https://bugs.python.org/issue37884> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue37913] Document that __length_hint__ may return NotImplemented
New submission from Jeroen Demeyer : The special method __length_hint__ can return NotImplemented. In this case, the result is as if the __length_hint__ method didn't exist at all. This behaviour is implemented and tested but not documented. -- assignee: docs@python components: Documentation messages: 350180 nosy: docs@python, jdemeyer priority: normal severity: normal status: open title: Document that __length_hint__ may return NotImplemented type: enhancement versions: Python 3.7, Python 3.8, Python 3.9 ___ Python tracker <https://bugs.python.org/issue37913> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue37913] Document that __length_hint__ may return NotImplemented
Change by Jeroen Demeyer : -- keywords: +patch pull_requests: +15093 stage: -> patch review pull_request: https://github.com/python/cpython/pull/15383 ___ Python tracker <https://bugs.python.org/issue37913> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue37884] Optimize Fraction() and statistics.mean()
Jeroen Demeyer added the comment: May I propose PR 15327 as alternative? It solves some of the same issues as the PR on this issue, in particular supporting arbitrary objects with as_integer_ratio(). It also improves performance somewhat for certain inputs, but that's more by accident. -- ___ Python tracker <https://bugs.python.org/issue37884> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue37884] Optimize Fraction() and statistics.mean()
Jeroen Demeyer added the comment: > FWIW, the entire point of us having recently added as_integer_ratio() methods > to so many concrete classes is to avoid the need for helper functions in > favor of a simple try/except around a single call. But what about PEP 3141? The fractions.Fraction constructor accepts numbers.Rational instances, which do not necessarily have an as_integer_ratio() method. We can't just drop support for that (*). So in practice you do need to check both as_integer_ratio() and the PEP 3141 numerator/denominator properties. It seems useful to have a helper function for this. (*) Unless you want to deprecate PEP 3141. This may be less crazy than it sounds, especially given Guido van Rossum's reaction on https://discuss.python.org/t/pep-3141-ratio-instead-of-numerator-denominator/2037/25?u=jdemeyer -- ___ Python tracker <https://bugs.python.org/issue37884> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue37934] Docs: Clarify NotImplemented use cases
Change by Jeroen Demeyer : -- nosy: +jdemeyer ___ Python tracker <https://bugs.python.org/issue37934> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue37884] Optimize Fraction() and statistics.mean()
Jeroen Demeyer added the comment: For the record: making a public math.as_integer_ratio() function was rejected at #37822. -- ___ Python tracker <https://bugs.python.org/issue37884> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue37934] Docs: Clarify NotImplemented use cases
Jeroen Demeyer added the comment: > As you say, we currently have only one usage of NotImplemented outside its > intended purpose. I know at least 3 in CPython, so it's not so rare to use NotImplemented for something else than binary operators: 1. __subclasshook__ 2. reducer_override (in pickling) 3. __length_hint__ > Of course, you might argue that _once Python has NotImplemented_, it can be > used elsewhere - but as I said, I don't think it should be encouraged. I'm not saying that it should be actively encouraged, but the documentation shouldn't be limited to just one use case. Given that NotImplemented exists, why shouldn't it be used in more cases to indicate that an operation is not implemented? -- ___ Python tracker <https://bugs.python.org/issue37934> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue33418] Memory leaks in functions
Jeroen Demeyer added the comment: > It looks like a bug triggered on purpose. Absolutely. It's one of the many small issues that I found while working on PEP 590 and related things. -- ___ Python tracker <https://bugs.python.org/issue33418> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue37645] Replace PyEval_GetFuncName/PyEval_GetFuncDesc
Jeroen Demeyer added the comment: > I left some comments on the PR. I don't see anything. Either I'm doing something wrong or GitHub is messed up. -- ___ Python tracker <https://bugs.python.org/issue37645> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue44874] Deprecate Py_TRASHCAN_SAFE_BEGIN/END
Change by Jeroen Demeyer : -- nosy: +jdemeyer nosy_count: 4.0 -> 5.0 pull_requests: +26438 pull_request: https://github.com/python/cpython/pull/12607 ___ Python tracker <https://bugs.python.org/issue44874> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue40608] PY3.8 GC segfault (Py_TRASHCAN_SAFE_BEGIN/END are not backwards compatible)
Jeroen Demeyer added the comment: I need to check, but I think this is a duplicate of bpo-35983, which still has PR 12607 open. -- ___ Python tracker <https://bugs.python.org/issue40608> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue36907] Crash due to borrowed references in _PyStack_UnpackDict()
Change by Jeroen Demeyer : -- pull_requests: +13292 ___ Python tracker <https://bugs.python.org/issue36907> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue36970] Rename _PyObject_FastCall functions
New submission from Jeroen Demeyer : As preparation for PEP 590, rename _PyObject_FastCallKeywords -> _PyObject_Vectorcall _PyObject_FastCallDict -> _PyObject_VectorcallDict -- components: Interpreter Core messages: 342892 nosy: Mark.Shannon, jdemeyer, petr.viktorin priority: normal severity: normal status: open title: Rename _PyObject_FastCall functions type: enhancement versions: Python 3.8 ___ Python tracker <https://bugs.python.org/issue36970> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue36970] Rename _PyObject_FastCall functions
Change by Jeroen Demeyer : -- keywords: +patch pull_requests: +13347 stage: -> patch review ___ Python tracker <https://bugs.python.org/issue36970> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue36970] Rename _PyObject_FastCall functions
Jeroen Demeyer added the comment: > Is it possible to rename Vectorcall, which looks good on its own but not > inside _PyObject_VectorcallDict()? I don't understand what you mean here? > _PyObject_FastCallDict is much easier to read. You think that "_PyObject_FastCallDict" is easier to read than "_PyObject_VectorcallDict"? I don't think that there is much difference. > Has the PEP been accepted? It still says "Draft". It's very close to being accepted, just some details to work out. -- ___ Python tracker <https://bugs.python.org/issue36970> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue36970] Rename _PyObject_FastCall functions
Jeroen Demeyer added the comment: Now to justify the naming: the plan is to keep the name "fast call" for the PyMethodDef flag METH_FASTCALL but to use the name "vectorcall" in the more general API. I think that's a good idea regardless of PEP 590, as it makes it clear that _PyObject_Vectorcall is useful for more than just METH_FASTCALL functions. -- ___ Python tracker <https://bugs.python.org/issue36970> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue36970] Rename _PyObject_FastCall functions
Jeroen Demeyer added the comment: > I would prefer to wait until the PEP is accepted before starting to push > changes ;-) I don't think it's wrong to propose and discuss changes already now. With the first beta of Python 3.8 getting close, it's better to be prepared already for the moment that PEP 590 is accepted. > Cython uses the FASTCALL calling convention. Please check with Stefan Behnel > to see fix it's ok to "remove" _PyObject_FastCallKeywords and > _PyObject_FastCallDict. It would be bad to suddently break all extensions > compiled with Cython. I checked, Cython does not use those *generic* _PyObject_FastCall functions. It does use more specialized functions like _PyFunction_FastCallDict and _PyMethodDef_RawFastCallKeywords. -- ___ Python tracker <https://bugs.python.org/issue36970> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue36970] Rename _PyObject_FastCall functions
Jeroen Demeyer added the comment: > From the perspective of reading, it is one of the most obnoxious names I've > seen in the Python code base. PyObject_Vectorcall() is the name in PEP 590, so if you want to change it, better write to python-dev about it. -- ___ Python tracker <https://bugs.python.org/issue36970> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue36971] Add subsections in C API "Common Object Structures" page
New submission from Jeroen Demeyer : The page https://docs.python.org/3/c-api/structures.html could be better structured by arranging the content in sub-sections. -- assignee: docs@python components: Documentation messages: 342911 nosy: docs@python, jdemeyer priority: normal severity: normal status: open title: Add subsections in C API "Common Object Structures" page versions: Python 3.8 ___ Python tracker <https://bugs.python.org/issue36971> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue36971] Add subsections in C API "Common Object Structures" page
Change by Jeroen Demeyer : -- keywords: +patch pull_requests: +13354 stage: -> patch review ___ Python tracker <https://bugs.python.org/issue36971> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue36974] Implement PEP 590
Change by Jeroen Demeyer : -- components: Interpreter Core nosy: Mark.Shannon, jdemeyer, petr.viktorin priority: normal severity: normal status: open title: Implement PEP 590 type: enhancement versions: Python 3.8 ___ Python tracker <https://bugs.python.org/issue36974> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue36974] Implement PEP 590
Change by Jeroen Demeyer : -- keywords: +patch pull_requests: +13359 stage: -> patch review ___ Python tracker <https://bugs.python.org/issue36974> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue36970] Rename _PyObject_FastCall functions
Jeroen Demeyer added the comment: The consensus on PEP 590 now seems to be to keep the name `_PyObject_FastCallDict` and rename only `_PyObject_FastCallKeywords` -> `_PyObject_Vectorcall`. For the record: I don't agree with this decision but I'll implement it. -- ___ Python tracker <https://bugs.python.org/issue36970> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue36937] New _PyObject_MakeTpCall() function
Jeroen Demeyer added the comment: So what are you trying to say? That it *should* be a static function? It most likely won't be a static function after PEP 590 is fully implemented. -- ___ Python tracker <https://bugs.python.org/issue36937> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue36937] New _PyObject_MakeTpCall() function
Jeroen Demeyer added the comment: In that case, there is no point a making a separate issue or PR. -- resolution: -> duplicate stage: patch review -> resolved status: open -> closed ___ Python tracker <https://bugs.python.org/issue36937> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue36974] Implement PEP 590
Change by Jeroen Demeyer : -- pull_requests: +13367 ___ Python tracker <https://bugs.python.org/issue36974> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue36974] Implement PEP 590
Change by Jeroen Demeyer : -- pull_requests: +13370 ___ Python tracker <https://bugs.python.org/issue36974> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue36970] Rename _PyObject_FastCallKeywords
Jeroen Demeyer added the comment: What's your opinion on renaming also _PyCFunction_FastCallKeywords -> _PyCFunction_Vectorcall _PyFunction_FastCallKeywords -> _PyFunction_Vectorcall If you agree, I will add it to the PR. -- ___ Python tracker <https://bugs.python.org/issue36970> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue36970] Rename _PyObject_FastCallKeywords
Change by Jeroen Demeyer : -- title: Rename _PyObject_FastCall functions -> Rename _PyObject_FastCallKeywords ___ Python tracker <https://bugs.python.org/issue36970> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue36994] Missing tests for CALL_FUNCTION_EX opcode profiling method_descriptor
New submission from Jeroen Demeyer : The branch for profiling a method_descriptor inside do_call_core is not tested by the test suite. -- components: Tests messages: 343044 nosy: jdemeyer priority: normal severity: normal status: open title: Missing tests for CALL_FUNCTION_EX opcode profiling method_descriptor versions: Python 3.8 ___ Python tracker <https://bugs.python.org/issue36994> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue36994] Missing tests for CALL_FUNCTION_EX opcode profiling method_descriptor
Change by Jeroen Demeyer : -- keywords: +patch pull_requests: +13371 stage: -> patch review ___ Python tracker <https://bugs.python.org/issue36994> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue36995] tp_print -> tp_vectorcall_offset
New submission from Jeroen Demeyer : If PEP 590 is accepted: in code comments, replace tp_print by tp_vectorcall_offset and (while we're at it) tp_reserved by tp_as_async. -- components: Interpreter Core messages: 343061 nosy: Mark.Shannon, jdemeyer, petr.viktorin priority: normal severity: normal status: open title: tp_print -> tp_vectorcall_offset versions: Python 3.8 ___ Python tracker <https://bugs.python.org/issue36995> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue36970] Rename _PyObject_FastCallKeywords
Change by Jeroen Demeyer : -- resolution: -> duplicate stage: patch review -> resolved status: open -> closed ___ Python tracker <https://bugs.python.org/issue36970> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue36995] tp_print -> tp_vectorcall_offset
Change by Jeroen Demeyer : -- keywords: +patch pull_requests: +13375 stage: -> patch review ___ Python tracker <https://bugs.python.org/issue36995> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue36995] tp_print -> tp_vectorcall_offset
Jeroen Demeyer added the comment: I see what you mean now. One bpo issue with many pull requests. I was following the CPython policy that every pull request needed an issue, but it didn't occur to me to put multiple independent PRs on one issue. -- resolution: -> duplicate stage: patch review -> resolved status: open -> closed ___ Python tracker <https://bugs.python.org/issue36995> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue36974] Implement PEP 590
Change by Jeroen Demeyer : -- pull_requests: +13397 ___ Python tracker <https://bugs.python.org/issue36974> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue34125] Profiling depends on whether **kwargs is given
Jeroen Demeyer added the comment: This is missing a testcase: PR 13461 -- ___ Python tracker <https://bugs.python.org/issue34125> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue36994] Missing tests for CALL_FUNCTION_EX opcode profiling method_descriptor
Change by Jeroen Demeyer : -- resolution: -> fixed stage: patch review -> resolved status: open -> closed ___ Python tracker <https://bugs.python.org/issue36994> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue36907] Crash due to borrowed references in _PyStack_UnpackDict()
Jeroen Demeyer added the comment: > Jeroen, do you want to also do a backport for 3.7? Don't we have a bot for that? -- ___ Python tracker <https://bugs.python.org/issue36907> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue36907] Crash due to borrowed references in _PyStack_UnpackDict()
Jeroen Demeyer added the comment: Using __int__ instead of __index__ works. PR coming right away. -- ___ Python tracker <https://bugs.python.org/issue36907> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue36907] Crash due to borrowed references in _PyStack_UnpackDict()
Change by Jeroen Demeyer : -- pull_requests: +13408 ___ Python tracker <https://bugs.python.org/issue36907> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue36974] Implement PEP 590
Change by Jeroen Demeyer : -- pull_requests: +13414 ___ Python tracker <https://bugs.python.org/issue36974> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue36974] Implement PEP 590
Change by Jeroen Demeyer : -- pull_requests: +13547 pull_request: https://github.com/python/cpython/pull/13653 ___ Python tracker <https://bugs.python.org/issue36974> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22117] Rewrite pytime.h to work on nanoseconds
Jeroen Demeyer added the comment: Can somebody here explain the meaning of the comment in test_gdb.py # Tested function must not be defined with METH_NOARGS or METH_O, # otherwise call_function() doesn't call PyCFunction_Call() This test is breaking with PEP 590, see https://github.com/python/cpython/pull/13185 -- nosy: +jdemeyer ___ Python tracker <https://bugs.python.org/issue22117> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22117] Rewrite pytime.h to work on nanoseconds
Jeroen Demeyer added the comment: Petr claims to have a fix, https://github.com/python/cpython/pull/13665 -- ___ Python tracker <https://bugs.python.org/issue22117> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue37097] python_is_optimized() false negatives
New submission from Jeroen Demeyer :
The function python_is_optimized() in Lib/test/support.py:
def python_is_optimized():
"""Find if Python was built with optimizations."""
cflags = sysconfig.get_config_var('PY_CFLAGS') or ''
final_opt = ""
for opt in cflags.split():
if opt.startswith('-O'):
final_opt = opt
return final_opt not in ('', '-O0', '-Og')
However, it seems that the *default* (when no special CFLAGS are configured) is
-O3. My Python build is done with this default -O3 but python_is_optimized()
returns False. This is the reason why I didn't catch the buildbot failure at
https://github.com/python/cpython/pull/13185#issuecomment-497062965
(this test is only run when python_is_optimized() is True)
--
components: Tests
messages: 343952
nosy: benjamin.peterson, jdemeyer, petr.viktorin, pitrou
priority: normal
severity: normal
status: open
title: python_is_optimized() false negatives
type: behavior
versions: Python 3.8, Python 3.9
___
Python tracker
<https://bugs.python.org/issue37097>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue26836] Add memfd_create to os module
Jeroen Demeyer added the comment: Testsuite breakage: https://bugs.python.org/issue37098 -- nosy: +jdemeyer ___ Python tracker <https://bugs.python.org/issue26836> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue37098] test_memfd_create() test failure
New submission from Jeroen Demeyer :
On an older Linux system:
==
ERROR: test_memfd_create (test.test_os.MemfdCreateTests)
--
Traceback (most recent call last):
File "/usr/local/src/sage-config/local/src/cpython/Lib/test/test_os.py", line
3128, in test_memfd_create
fd = os.memfd_create("Hi", os.MFD_CLOEXEC)
OSError: [Errno 38] Function not implemented
--
components: Tests
messages: 343953
nosy: ZackerySpytz, christian.heimes, jdemeyer
priority: normal
severity: normal
status: open
title: test_memfd_create() test failure
type: behavior
versions: Python 3.8, Python 3.9
___
Python tracker
<https://bugs.python.org/issue37098>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue36974] Implement PEP 590
Change by Jeroen Demeyer : -- pull_requests: +13569 pull_request: https://github.com/python/cpython/pull/13682 ___ Python tracker <https://bugs.python.org/issue36974> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue36974] Implement PEP 590
Change by Jeroen Demeyer : -- pull_requests: +13666 pull_request: https://github.com/python/cpython/pull/13781 ___ Python tracker <https://bugs.python.org/issue36974> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue37151] Calling code cleanup after PEP 590
New submission from Jeroen Demeyer : Now that PEP 590 has been implemented, a lot of old code can be cleaned up. In particular: - get rid of _PyMethodDef_RawFastCallXXX() functions and replace them by vectorcall functions for each calling convention - get rid of FastCallDict() implementations for specific types, but keep the generic _PyObject_FastCallDict() - get rid of some specific tp_call implementations: try to use tp_call=PyVectorcall_Call in more places -- components: Interpreter Core messages: 344577 nosy: Mark.Shannon, jdemeyer, petr.viktorin priority: normal severity: normal status: open title: Calling code cleanup after PEP 590 type: enhancement versions: Python 3.9 ___ Python tracker <https://bugs.python.org/issue37151> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue36924] Simplify implementation of classmethod_descriptor.__call__
Jeroen Demeyer added the comment: I opened a more general issue #37151 -- ___ Python tracker <https://bugs.python.org/issue36924> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue37151] Calling code cleanup after PEP 590
Change by Jeroen Demeyer : -- keywords: +patch pull_requests: +13694 stage: -> patch review pull_request: https://github.com/python/cpython/pull/13340 ___ Python tracker <https://bugs.python.org/issue37151> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22117] Rewrite pytime.h to work on nanoseconds
Jeroen Demeyer added the comment: > Commenting closed issues is not the most efficient way to get an answer ;-) Serious question: why is that? I got an email from bugs.python.org with your comment, so why should commenting on closed issues be any worse than commenting on open issues? Especially if the people on the issue are still active core developers. -- ___ Python tracker <https://bugs.python.org/issue22117> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22117] Rewrite pytime.h to work on nanoseconds
Jeroen Demeyer added the comment: Right, but my question was very specifically about a test added for this issue. So asking it here first made sense to me. If nobody would reply, I could still ask somewhere else. In the end, Petr solved the problem anyway, so the question is irrelevant now. -- ___ Python tracker <https://bugs.python.org/issue22117> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue36974] Implement PEP 590
Change by Jeroen Demeyer : -- pull_requests: +13721 pull_request: https://github.com/python/cpython/pull/13844 ___ Python tracker <https://bugs.python.org/issue36974> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue36974] Implement PEP 590
Change by Jeroen Demeyer : -- pull_requests: +13733 pull_request: https://github.com/python/cpython/pull/13858 ___ Python tracker <https://bugs.python.org/issue36974> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue37151] Calling code cleanup after PEP 590
Change by Jeroen Demeyer : -- pull_requests: +13740 pull_request: https://github.com/python/cpython/pull/13864 ___ Python tracker <https://bugs.python.org/issue37151> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue36922] Implement Py_TPFLAGS_METHOD_DESCRIPTOR
Change by Jeroen Demeyer : -- pull_requests: +13741 pull_request: https://github.com/python/cpython/pull/13865 ___ Python tracker <https://bugs.python.org/issue36922> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue37138] PEP 590 method_vectorcall calls memcpy with NULL src
Jeroen Demeyer added the comment: That's entirely my fault. I was not aware of the fact that calling memcpy() with src=NULL and length 0 was undefined behaviour. I disagree that it should be undefined, but there is not much point in arguing against the C standard. -- nosy: +jdemeyer ___ Python tracker <https://bugs.python.org/issue37138> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue37138] PEP 590 method_vectorcall calls memcpy with NULL src
Change by Jeroen Demeyer : -- keywords: +patch pull_requests: +13743 stage: needs patch -> patch review pull_request: https://github.com/python/cpython/pull/13867 ___ Python tracker <https://bugs.python.org/issue37138> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue37176] super() docs don't say what super() does
New submission from Jeroen Demeyer : The documentation for super() at https://docs.python.org/3.8/library/functions.html#super does not actually say what super() does. It only says "Return a proxy object that delegates method calls to a parent or sibling class of type" and then gives a bunch of use cases and examples. If there is one place where we should define exactly what super() does (as opposed to give guidance on how to use it), the stdlib reference should be it. -- assignee: docs@python components: Documentation messages: 344827 nosy: docs@python, jdemeyer priority: normal severity: normal status: open title: super() docs don't say what super() does type: enhancement versions: Python 2.7, Python 3.5, Python 3.6, Python 3.7, Python 3.8, Python 3.9 ___ Python tracker <https://bugs.python.org/issue37176> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue18355] Merge super() guide into documentation
Jeroen Demeyer added the comment: I opened another doc issue about super(): #37176 -- nosy: +jdemeyer ___ Python tracker <https://bugs.python.org/issue18355> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue37176] super() docs don't say what super() does
Jeroen Demeyer added the comment: > What more do you want? Mainly: it says "a parent or sibling class of *type*" but it doesn't explain which class it actually uses. And the sentence "The __mro__ attribute of the type lists the method resolution search order used by both getattr() and super()" is even wrong or at least confusing: what matters is not the MRO of the type (the first argument to super()) but the MRO of the object (the second argument to super()). The zero-argument form super() is not explained at all. > Perhaps there ought to be a "gentle guide to super" somewhere, and the docs > could link to that? There are plenty of guides like that and in fact that docs already link to https://rhettinger.wordpress.com/2011/05/26/super-considered-super/ -- ___ Python tracker <https://bugs.python.org/issue37176> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue37176] super() docs don't say what super() does
Jeroen Demeyer added the comment: > Only one of the two arguments is called "type". The other is called "object-or-type". I'm having problems with the first word of "a parent or sibling class of type". The most important part of super() is to *which* class that attribute lookups are delegated to and this is not explained. > The __mro__ attribute is on the type, not the instance: Sorry for that. I meant to say: And the sentence "The __mro__ attribute of the type lists the method resolution search order used by both getattr() and super()" is even wrong or at least confusing: what matters is not the MRO of the type (the first argument to super()) but the MRO of ***the type of*** the object (the second argument to super()). > Yes it is. Look at the example given: An example is not an explanation. But it's true, this is the least of my problems with this doc. -- ___ Python tracker <https://bugs.python.org/issue37176> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue37176] super() docs don't say what super() does
Jeroen Demeyer added the comment: > The sentence doesn't talk about the MRO of *type* (the first argument), it talks about the __mro__ attribute. If you have to explain in a bpo issue how the doc should be read, that proves exactly my point that it's confusing. The fact that it's technically correct if you read it the right way is irrelevant. -- ___ Python tracker <https://bugs.python.org/issue37176> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue37194] Move new vector private declarations to the internal C API
Jeroen Demeyer added the comment: > I propose to move the new *private* declarations to the internal C API. Some of those functions (in particular _PyObject_Vectorcall) are expected to become public in 3.9. They are only private for now since the API is provisional. -- nosy: +jdemeyer ___ Python tracker <https://bugs.python.org/issue37194> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue37191] Python.h contains intermingled declarations
Jeroen Demeyer added the comment: Should we revert these inline functions back to macros? -- nosy: +jdemeyer ___ Python tracker <https://bugs.python.org/issue37191> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue37191] Python.h contains intermingled declarations
Jeroen Demeyer added the comment: > It's well within our rights to ignore this: since 3.6 we require intermingled > declarations. It's not clear from PEP 7 if we require intermingled declarations only when compiling CPython itself, or also for external packages that include CPython headers. It would be prudent to stay C89-compatible for non-internal header files. -- ___ Python tracker <https://bugs.python.org/issue37191> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue37176] super() docs don't say what super() does
Jeroen Demeyer added the comment: > What matters is the __mro__ attribute of the first argument. It matters because that is how the MRO actually is searched. I'm sorry to say that you're wrong here. super() looks at the MRO of the type of the object (the second argument) (*). It has to do that in order to support diamonds. Consider a diamond like D / \ B C \ / A (with A as common base class). Now super(B, D()).attr will look in the MRO of D (which is D, B, C, A) and therefore delegate to C.attr. In this case, C does not even appear in the MRO of B. (*) To be pedantic: in the special case that the second argument is a type itself, it looks at the MRO of the second argument. -- ___ Python tracker <https://bugs.python.org/issue37176> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
