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
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
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
> versi
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
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 messag
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 i
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&#x
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
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
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
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
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 p
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
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 i
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
<ht
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. Ther
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/issu
Change by Jeroen Demeyer :
--
pull_requests: +15018
pull_request: https://github.com/python/cpython/pull/15295
___
Python tracker
<https://bugs.python.org/issue37
Change by Jeroen Demeyer :
--
resolution: -> fixed
stage: patch review -> resolved
status: open -> closed
___
Python tracker
<https://bugs.python.or
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
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
>&g
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/issu
Change by Jeroen Demeyer :
--
pull_requests: +15046
pull_request: https://github.com/python/cpython/pull/15328
___
Python tracker
<https://bugs.python.org/issue37
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
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
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: M
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 A
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 av
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 fract
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 libr
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
compo
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/issu
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 acc
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
Change by Jeroen Demeyer :
--
nosy: +jdemeyer
___
Python tracker
<https://bugs.python.org/issue37934>
___
___
Python-bugs-list mailing list
Unsubscribe:
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/issue37
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_o
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
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.pytho
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/issu
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/issue40
Change by Jeroen Demeyer :
--
pull_requests: +13292
___
Python tracker
<https://bugs.python.org/issue36907>
___
___
Python-bugs-list mailing list
Unsubscribe:
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:
Change by Jeroen Demeyer :
--
keywords: +patch
pull_requests: +13347
stage: -> patch review
___
Python tracker
<https://bugs.python.org/issue36970>
___
___
Py
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_FastCal
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,
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 al
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-d
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
Change by Jeroen Demeyer :
--
keywords: +patch
pull_requests: +13354
stage: -> patch review
___
Python tracker
<https://bugs.python.org/issue36971>
___
___
Py
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
<ht
Change by Jeroen Demeyer :
--
keywords: +patch
pull_requests: +13359
stage: -> patch review
___
Python tracker
<https://bugs.python.org/issue36974>
___
___
Py
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
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/is
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.or
Change by Jeroen Demeyer :
--
pull_requests: +13367
___
Python tracker
<https://bugs.python.org/issue36974>
___
___
Python-bugs-list mailing list
Unsubscribe:
Change by Jeroen Demeyer :
--
pull_requests: +13370
___
Python tracker
<https://bugs.python.org/issue36974>
___
___
Python-bugs-list mailing list
Unsubscribe:
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.
--
___
Pyt
Change by Jeroen Demeyer :
--
title: Rename _PyObject_FastCall functions -> Rename _PyObject_FastCallKeywords
___
Python tracker
<https://bugs.python.org/issu
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
Change by Jeroen Demeyer :
--
keywords: +patch
pull_requests: +13371
stage: -> patch review
___
Python tracker
<https://bugs.python.org/issue36994>
___
___
Py
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: n
Change by Jeroen Demeyer :
--
resolution: -> duplicate
stage: patch review -> resolved
status: open -> closed
___
Python tracker
<https://bugs.python.or
Change by Jeroen Demeyer :
--
keywords: +patch
pull_requests: +13375
stage: -> patch review
___
Python tracker
<https://bugs.python.org/issue36995>
___
___
Py
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: -> duplica
Change by Jeroen Demeyer :
--
pull_requests: +13397
___
Python tracker
<https://bugs.python.org/issue36974>
___
___
Python-bugs-list mailing list
Unsubscribe:
Jeroen Demeyer added the comment:
This is missing a testcase: PR 13461
--
___
Python tracker
<https://bugs.python.org/issue34125>
___
___
Python-bugs-list mailin
Change by Jeroen Demeyer :
--
resolution: -> fixed
stage: patch review -> resolved
status: open -> closed
___
Python tracker
<https://bugs.python.or
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
Jeroen Demeyer added the comment:
Using __int__ instead of __index__ works. PR coming right away.
--
___
Python tracker
<https://bugs.python.org/issue36
Change by Jeroen Demeyer :
--
pull_requests: +13408
___
Python tracker
<https://bugs.python.org/issue36907>
___
___
Python-bugs-list mailing list
Unsubscribe:
Change by Jeroen Demeyer :
--
pull_requests: +13414
___
Python tracker
<https://bugs.python.org/issue36974>
___
___
Python-bugs-list mailing list
Unsubscribe:
Change by Jeroen Demeyer :
--
pull_requests: +13547
pull_request: https://github.com/python/cpython/pull/13653
___
Python tracker
<https://bugs.python.org/issue36
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://githu
Jeroen Demeyer added the comment:
Petr claims to have a fix, https://github.com/python/cpython/pull/13665
--
___
Python tracker
<https://bugs.python.org/issue22
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 '&#x
Jeroen Demeyer added the comment:
Testsuite breakage: https://bugs.python.org/issue37098
--
nosy: +jdemeyer
___
Python tracker
<https://bugs.python.org/issue26
New submission from Jeroen Demeyer :
On an older Linux system:
==
ERROR: test_memfd_create (test.test_os.MemfdCreateTests)
--
Traceback (most recent call last
Change by Jeroen Demeyer :
--
pull_requests: +13569
pull_request: https://github.com/python/cpython/pull/13682
___
Python tracker
<https://bugs.python.org/issue36
Change by Jeroen Demeyer :
--
pull_requests: +13666
pull_request: https://github.com/python/cpython/pull/13781
___
Python tracker
<https://bugs.python.org/issue36
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
Jeroen Demeyer added the comment:
I opened a more general issue #37151
--
___
Python tracker
<https://bugs.python.org/issue36924>
___
___
Python-bugs-list mailin
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/issu
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 iss
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
Change by Jeroen Demeyer :
--
pull_requests: +13721
pull_request: https://github.com/python/cpython/pull/13844
___
Python tracker
<https://bugs.python.org/issue36
Change by Jeroen Demeyer :
--
pull_requests: +13733
pull_request: https://github.com/python/cpython/pull/13858
___
Python tracker
<https://bugs.python.org/issue36
Change by Jeroen Demeyer :
--
pull_requests: +13740
pull_request: https://github.com/python/cpython/pull/13864
___
Python tracker
<https://bugs.python.org/issue37
Change by Jeroen Demeyer :
--
pull_requests: +13741
pull_request: https://github.com/python/cpython/pull/13865
___
Python tracker
<https://bugs.python.org/issue36
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: +jde
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/issu
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 giv
Jeroen Demeyer added the comment:
I opened another doc issue about super(): #37176
--
nosy: +jdemeyer
___
Python tracker
<https://bugs.python.org/issue18
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 use
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 *wh
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 f
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.
--
n
Jeroen Demeyer added the comment:
Should we revert these inline functions back to macros?
--
nosy: +jdemeyer
___
Python tracker
<https://bugs.python.org/issue37
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
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) (*).
1 - 100 of 691 matches
Mail list logo
