Throwing in another +1 for `except group`.
It's explicit, doesn't introduce new punctuation and avoids confusion with
unpacking.
Regards,
Ammar
On Mon, Oct 4, 2021, 3:31 AM Antoine Pitrou wrote:
> On Sun, 3 Oct 2021 19:42:29 +0200
> Łukasz Langa wrote:
> >
> > -1
> >
> > If I could read the
Hey everyone,
As part of PEP 588, migrating bugs.python.org issues to Github, there
are two current mailing list related items that need a replacement or
need to be turned down.
1. Weekly summary emails with bug counts and issues from the week,
example:
Hi Terry,
> IDLE currently uses traceback.extract_tb and traceback.print_list
Awesome, that should work out perfectly then. Our current
proof-of-concept implementation augments the traceback.FrameSummary
class to include `end_lineno`, `colno` and `end_colno` attributes. We
will make sure to add
Hi Mark,
Thank you for the feedback. Let me address/elaborate some of the
points that Pablo touched on.
> PEP 657 proposes that locations for exceptions be treated as ranges,
> whereas tracing, profiling and debugging currently treat locations as
> points.
I don't think we're making strong
This section on wikipedia
https://en.wikipedia.org/wiki/Freenode#Ownership_change_and_conflict
and this article have a good summary:
https://hackaday.com/2021/05/20/freenode-debacle-prompts-staff-exodus-new-network/
Essentially what happened is that freenode was bought out a while ago
by a
> The cost I'm concerned about is the runtime cost of worse code, because
> the compiler can't perform some optimizations due the constraints of
> providing the extended debug information.
Aah thanks for clarifying, I see what you mean now. In cases like this
where the compiler is making
> While nicer locations for errors is great, it won't be popular if it has
> a negative impact on performance.
> Locations need to tracked through the compiler.
In performance sensitive contexts won't most code be pre-compiled into
pyc files anyway? I feel like the performance cost of accurate
> I wasn’t able to find examples - is this what is up and running on
> docs.python.org, or is that a future plan?
I believe currently only the pre-release (3.10) documentation
https://docs.python.org/3.10/
and in-development (3.11) documentation https://docs.python.org/3.11/
is using the theme.
I really like this idea Nathaniel.
We already have a section considering lazy-loading column information in the
draft PEP but obviously it has a pretty high implementation complexity since it
necessitates a change in the pyc format and the importlib machinery.
Long term this might be the way to
Filed https://github.com/pypa/setuptools/issues/2362 against
setuptools, not sure what we should do locally to fix this in the
meantime.
On Mon, Aug 31, 2020 at 1:11 PM Ammar Askar wrote:
>
> Karthik, your analysis is correct. You just have to import importlib
> first to get
Karthik, your analysis is correct. You just have to import importlib
first to get the error:
>>> import importlib
>>> import importlib.util
>>> importlib.util.abc.Loader
Traceback (most recent call last):
File "", line 1, in
AttributeError: module 'importlib.util' has no attribute 'abc'
On
Python
> specific APIs like PyMem_Malloc
> then the reflect code should catch that.
>
> On Wed, 13 May 2020 at 12:29, Giampaolo Rodola'
> wrote:
>
>> On Wed, May 13, 2020 at 9:17 AM Ammar Askar wrote:
>>
>>> > Py_DECREF calls in the C code
>>>
&g
> Py_DECREF calls in the C code
I think this part specifically is already covered through refleak
checks:
https://github.com/python/cpython/blob/master/Lib/test/libregrtest/refleak.py
Since it can involve the repetition of tests many times, these aren't
run on the CI though, they do get run on
This is the discussion where it was named:
https://discuss.python.org/t/poll-what-is-your-favorite-name-for-the-new-include-subdirectory/477?u=ammaraskar
and the bug explaining the motivation: https://bugs.python.org/issue35134
>(and why the additional "pycore_XXX.h" naming convention for some
to:tjre...@udel.edu>> wrote:
>
> [question about our coverage bot]
>
>> Everything is either covered by the Travis or codecov configuration files
>> which are both checked into the cpython repo. (I'm on vacation or else I
>> would provide links to the files themsel
> Is it possible, given that we are not paying for those reports, to
> customize the 'exclude_lines' definitions?
Do you want to exclude python code or C code?
For C code you can mark sections that exclude coverage in lcov
with comments like "LCOV_EXCL_START"
16 matches
Mail list logo
