I agree, remove Solaris support. Nobody willing to contribute seems
interested.
-gps
--
blame half the typos on my phone.
On Thu, Oct 29, 2020, 2:50 PM Victor Stinner wrote:
> Hi,
>
> I propose to drop the Solaris support in Python to reduce the Python
> maintenance burden:
>
>
Hi,
I propose to drop the Solaris support in Python to reduce the Python
maintenance burden:
https://bugs.python.org/issue42173
I wrote a draft PR to show how much code could be removed (around 700
lines in 65 files):
https://github.com/python/cpython/pull/23002/files
In 2016, I asked
On Thu, Oct 29, 2020 at 9:45 AM Victor Stinner wrote:
> Le jeu. 29 oct. 2020 à 13:02, Fabio Zadrozny a écrit :
> > Debuggers can call `PyFrame_LocalsToFast` when needed -- otherwise
> mutating non-current frames doesn't work anyways. As a note, pydevd already
> has such a call:
>
> Except that we can't measure the performance of a specification.
> We can only measure the performance of entire implementations.
> I can make an implementation that conforms to PEP 626 that is slower
> than master, or I can make one that's faster :)
> It doesn't change the value of the PEP
Hi Pablo,
On 29/10/2020 11:08 am, Pablo Galindo Salgado wrote:
> The new semantics may well result in some slowdowns. That's stated in
the PEP.I don't think I can reliably isolate the effects of the (very
slight)
change in the behavior of f_lineno.
Ok, then let's make at least we measure
Le jeu. 29 oct. 2020 à 13:02, Fabio Zadrozny a écrit :
> Debuggers can call `PyFrame_LocalsToFast` when needed -- otherwise mutating
> non-current frames doesn't work anyways. As a note, pydevd already has such a
> call:
>
Hi all,
Right now, when a debugger is active, the number of local variables can
affect the tracing speed quite a lot.
For instance, having tracing setup in a program such as the one below takes
4.64 seconds to run, yet, changing all the variables to have the same name
-- i.e.: change all
> The new semantics may well result in some slowdowns. That's stated in
the PEP. I don't think I can reliably isolate the effects of the (very
slight)
change in the behavior of f_lineno.
Ok, then let's make at least we measure the general slowdowns.
> When you say updating "field", are you
Hi Pablo,
On 29/10/2020 9:56 am, Pablo Galindo Salgado wrote:
> Performance compared to what?
Compared before the patch. The comparison that I mentioned is before and
after the PR with the PEP implementation.
PEP 626 changes the line number table and the compiler.
Such a comparison would
> Performance compared to what?
Compared before the patch. The comparison that I mentioned is before and
after the PR with the PEP implementation.
> The current behavior of `f_lineno` is ill-defined, so mimicking it would
be tricky
Maybe I failed to express myself: that's fine, we don't need to
Hi,
That's great. Thanks Pablo.
On 29/10/2020 1:32 am, Pablo Galindo Salgado wrote:
On behalf of the steering council, I am happy to announce that as
BDFL-Delegate I am
accepting PEP 626 -- Precise line numbers for debugging and other tools.
I am confident this PEP will result in a better
11 matches
Mail list logo
