Brett Cannon writes:
>> Ah. I don't know if CIs like GitHub Actions and Azure Pipelines
>> provide Python debug builds. If if it's not the case, it would be nice
>> to have the choice :-)
>>
>
> They do not:
>
On Tue, 8 Feb 2022 00:39:12 -0800
"Gregory P. Smith" wrote:
> What does pyperformance say about --enable-optimizations builds with all of
> those compiled out vs today?
>
> I like the runtime safety checking for purposes of making the lives of
> Python C API users easier. But without the use of
On Tue, Feb 8, 2022 at 9:49 AM Serhiy Storchaka wrote:
>
> 07.02.22 17:55, Victor Stinner пише:
> > I'm asking to replace runtime checks with assertions when the C API is
> > "obviously" misused: replace PyErr_BadInternalCall(),
> > _Py_CheckFunctionResult() and _Py_CheckSlotResult() with
07.02.22 17:55, Victor Stinner пише:
> I'm asking to replace runtime checks with assertions when the C API is
> "obviously" misused: replace PyErr_BadInternalCall(),
> _Py_CheckFunctionResult() and _Py_CheckSlotResult() with assertions.
> The exact scope should be defined.
Would not be better to
What does pyperformance say about --enable-optimizations builds with all of
those compiled out vs today?
I like the runtime safety checking for purposes of making the lives of
Python C API users easier. But without the use of assertion enabled CPython
builds being the norm during development (we
On Mon, Feb 7, 2022 at 8:59 AM Victor Stinner wrote:
> On Mon, Feb 7, 2022 at 5:48 PM Guido van Rossum wrote:
> > So you're proposing to completely get rid of those three?
>
> I don't propose to remove them, but only call them if Python is built
> in debug mode. Or remove them from the release
On 2/7/2022 11:48 AM, Guido van Rossum wrote:
(I still haven't gotten into the habit of building in debug mode by
default, in part because it *isn't* the default when you invoke
./configure or PCbuild/build.bat.)
On Windows, I have build.bat in the directory containing the repository
and
On Mon, Feb 7, 2022 at 5:48 PM Guido van Rossum wrote:
> So you're proposing to completely get rid of those three?
I don't propose to remove them, but only call them if Python is built
in debug mode. Or remove them from the release build, unless
./configure --with-assertions is used.
> And
So you're proposing to completely get rid of those three? And you're sure
that each and every single call to any of those is better off being an
assert()?
(I still haven't gotten into the habit of building in debug mode by
default, in part because it *isn't* the default when you invoke
On Mon, Feb 7, 2022 at 5:38 PM Guido van Rossum wrote:
> ISTM this is better discussed on a case-by-case basis than as a blanket
> policy change. (The latter could end up causing a flood of trivial PRs from
> wannabe-contributors who found and fix yet another violation of the policy,
> which
ISTM this is better discussed on a case-by-case basis than as a blanket
policy change. (The latter could end up causing a flood of trivial PRs from
wannabe-contributors who found and fix yet another violation of the policy,
which is both a nuisance for reviewers and a risk of introducing bugs due
11 matches
Mail list logo
