[Python-Dev] Re: Drop Solaris, OpenSolaris, Illumos and OpenIndiana support in Python

[Gregory P. Smith]

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:
>
>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 if we still wanted to maintain the Solaris support in
> Python, because Solaris buildbots were failing for longer than 6
> months and nobody was able to fix them. It was requested to find a
> core developer volunteer to fix Solaris issues and to set up a Solaris
> buildbot.
>
>
> https://mail.python.org/archives/list/python-dev@python.org/thread/NOT2RORSNX72ZLUHK2UUGBD4GTPNKBUS/#NOT2RORSNX72ZLUHK2UUGBD4GTPNKBUS
>
> Four years later, nothing has happened. Moreover, in 2018, Oracle laid
> off the Solaris development engineering staff. There are around 25
> open Python bugs specific to Solaris.
>
> I see 3 options:
>
> * Current best effort support (no change): changes only happen if a
> core dev volunteers to review and merge a change written by a
> contributor.
>
> * Schedule the removal in 2 Python releases (Python 3.12) and start to
> announce that Solaris support is going to be removed
>
> * Remove the Solaris code right now (my proposition): Solaris code
> will have to be maintained outside the official Python code base, as
> "downstream patches"
>
>
> Solaris has a few specific features visible at the Python level:
> select.devpoll, os.stat().st_fstype and stat.S_ISDOOR().
>
> While it's unclear to me if Oracle still actively maintains Solaris
> (latest release in 2018, no major update since 2018), Illumos and
> OpenSolaris (variants or "forks") still seem to be active.
>
> In 2019, a Solaris blog post explains that Solaris 11.4 still uses
> Python 2.7 but plans to migrate to Python 3, and Python 3.4 is also
> available. These two Python versions are no longer supported.
>
> https://blogs.oracle.com/solaris/future-of-python-on-solaris
>
> The question is if the Python project has to maintain the Solaris
> specific code or if this code should now be maintained outside Python.
>
> What do you think? Should we wait 5 more years? Should we expect a
> company will offer to maintain the Solaris support? Is there a
> motivated core developer to fix Solaris issue? As I wrote, nothing has
> happened in the last 4 years...
>
> Victor
> --
> Night gathers, and now my watch begins. It shall not end until my death.
> ___
> Python-Dev mailing list -- python-dev@python.org
> To unsubscribe send an email to python-dev-le...@python.org
> https://mail.python.org/mailman3/lists/python-dev.python.org/
> Message archived at
> https://mail.python.org/archives/list/python-dev@python.org/message/VDD7NMEDFXMOP4S74GEYJUHJRJPK2UR3/
> Code of Conduct: http://python.org/psf/codeofconduct/
>
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/HHP6DVPMDNUHEZZPKJDLZTMOI7O7LWPO/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Drop Solaris, OpenSolaris, Illumos and OpenIndiana support in Python

[Victor Stinner]

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 if we still wanted to maintain the Solaris support in
Python, because Solaris buildbots were failing for longer than 6
months and nobody was able to fix them. It was requested to find a
core developer volunteer to fix Solaris issues and to set up a Solaris
buildbot.

https://mail.python.org/archives/list/python-dev@python.org/thread/NOT2RORSNX72ZLUHK2UUGBD4GTPNKBUS/#NOT2RORSNX72ZLUHK2UUGBD4GTPNKBUS

Four years later, nothing has happened. Moreover, in 2018, Oracle laid
off the Solaris development engineering staff. There are around 25
open Python bugs specific to Solaris.

I see 3 options:

* Current best effort support (no change): changes only happen if a
core dev volunteers to review and merge a change written by a
contributor.

* Schedule the removal in 2 Python releases (Python 3.12) and start to
announce that Solaris support is going to be removed

* Remove the Solaris code right now (my proposition): Solaris code
will have to be maintained outside the official Python code base, as
"downstream patches"


Solaris has a few specific features visible at the Python level:
select.devpoll, os.stat().st_fstype and stat.S_ISDOOR().

While it's unclear to me if Oracle still actively maintains Solaris
(latest release in 2018, no major update since 2018), Illumos and
OpenSolaris (variants or "forks") still seem to be active.

In 2019, a Solaris blog post explains that Solaris 11.4 still uses
Python 2.7 but plans to migrate to Python 3, and Python 3.4 is also
available. These two Python versions are no longer supported.

https://blogs.oracle.com/solaris/future-of-python-on-solaris

The question is if the Python project has to maintain the Solaris
specific code or if this code should now be maintained outside Python.

What do you think? Should we wait 5 more years? Should we expect a
company will offer to maintain the Solaris support? Is there a
motivated core developer to fix Solaris issue? As I wrote, nothing has
happened in the last 4 years...

Victor
-- 
Night gathers, and now my watch begins. It shall not end until my death.
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/VDD7NMEDFXMOP4S74GEYJUHJRJPK2UR3/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Improve CPython tracing performance

[Fabio Zadrozny]

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:
> https://github.com/fabioz/PyDev.Debugger/blob/0d4d210f01a1c0a8647178b2e665b53ab113509d/_pydevd_bundle/pydevd_save_locals.py#L57
> and PyPy also has a counterpart.
>
> Hum, if a trace or profile function is written in Python, reading
> frame.f_locals does call PyFrame_FastToLocalsWithError(). So a Python
> debugger/profiler would be ok with your code.
>
> For a debugger/profiler written in C, it would be a backward
> incompatible change. I agree that it would be reasonable to require it
> to call PyFrame_FastToLocalsWithError().
>
> > If it's non controversial, is a PEP needed or just an issue to track it
> would be enough to remove those 2 lines?
>
> Incompatible changes should be well documented in What's New in Python
> 3.10. In this case, I don't think that a deprecation period is needed.
>
> Just open an issue. Please post the URL to your issue in reply to your
> email. It's even better if you can write a PR to implement your idea
> ;-)
>


Ok, I've created https://bugs.python.org/issue42197 to track it.

--
Fabio
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/IIH5J5MGGF4JALBIGVDNEMPVVGCORHLF/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Accepting PEP 626

[Pablo Galindo Salgado]

> 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 itself.

Oh, I see now where the confusion is. Regarding the benchmarks, unless
is catastrophically worse and there is no way to make it competitive, the
PEP acceptance is not conditional to the specific result of the benchmarks:
my request is just to *have* a benchmark on the implementation :)

On Thu, 29 Oct 2020 at 13:29, Mark Shannon  wrote:

> 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 the general slowdowns.
>
> 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 itself.
>
> Let me give you a toy example.
>
> def f():
>  while 1:
>  body()
>
> 3.9 compiles this to:
>
> (The trailing, implicit return has been stripped for clarity)
>
>3 >>0 LOAD_GLOBAL  0 (body)
>2 CALL_FUNCTION0
>4 POP_TOP
>6 JUMP_ABSOLUTE0
>
> A naive implementation that conforms to PEP 626 would this compile to:
>
>2 >>0 NOP
>3   2 LOAD_GLOBAL  0 (body)
>4 CALL_FUNCTION0
>6 POP_TOP
>8 JUMP_ABSOLUTE0
>
> But a better implementation could produce this:
>
>2   0 NOP
>3 >>2 LOAD_GLOBAL  0 (body)
>4 CALL_FUNCTION0
>6 POP_TOP
>2   8 JUMP_ABSOLUTE2
>
> Which has the same bytecodes as 3.9 in the loop, and has the correct
> line numbers.
>
> Cheers,
> Mark.
>
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/JCW4JZH6LNWDYXGPXWQ4MPWDZ27KROEK/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Accepting PEP 626

[Mark Shannon]

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 the general slowdowns.


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 itself.

Let me give you a toy example.

def f():
while 1:
body()

3.9 compiles this to:

(The trailing, implicit return has been stripped for clarity)

  3 >>0 LOAD_GLOBAL  0 (body)
  2 CALL_FUNCTION0
  4 POP_TOP
  6 JUMP_ABSOLUTE0

A naive implementation that conforms to PEP 626 would this compile to:

  2 >>0 NOP
  3   2 LOAD_GLOBAL  0 (body)
  4 CALL_FUNCTION0
  6 POP_TOP
  8 JUMP_ABSOLUTE0

But a better implementation could produce this:

  2   0 NOP
  3 >>2 LOAD_GLOBAL  0 (body)
  4 CALL_FUNCTION0
  6 POP_TOP
  2   8 JUMP_ABSOLUTE2

Which has the same bytecodes as 3.9 in the loop, and has the correct 
line numbers.


Cheers,
Mark.
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/A6RRMIGXVHV7I7QMG42BCD6K4AJBKVST/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Improve CPython tracing performance

[Victor Stinner]

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: 
> https://github.com/fabioz/PyDev.Debugger/blob/0d4d210f01a1c0a8647178b2e665b53ab113509d/_pydevd_bundle/pydevd_save_locals.py#L57
>  and PyPy also has a counterpart.

Hum, if a trace or profile function is written in Python, reading
frame.f_locals does call PyFrame_FastToLocalsWithError(). So a Python
debugger/profiler would be ok with your code.

For a debugger/profiler written in C, it would be a backward
incompatible change. I agree that it would be reasonable to require it
to call PyFrame_FastToLocalsWithError().

> If it's non controversial, is a PEP needed or just an issue to track it would 
> be enough to remove those 2 lines?

Incompatible changes should be well documented in What's New in Python
3.10. In this case, I don't think that a deprecation period is needed.

Just open an issue. Please post the URL to your issue in reply to your
email. It's even better if you can write a PR to implement your idea
;-)

Victor
-- 
Night gathers, and now my watch begins. It shall not end until my death.
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/YRHHR6BWIQK3BBIEPOM47XSMXWUODYF7/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Improve CPython tracing performance

[Fabio Zadrozny]

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 assignments to `a = 1` (such that there's only a single
variable in the namespace), it takes 1.47 seconds (in my machine)... the
higher the number of variables, the slower the tracing becomes.

```
import time
t = time.time()

def call():
a = 1
b = 1
c = 1
d = 1
e = 1
f = 1

def noop(frame, event, arg):
return noop

import sys
sys.settrace(noop)

for i in range(1_000_000):
call()

print('%.2fs' % (time.time() - t,))
```

This happens because `PyFrame_FastToLocalsWithError` and
`PyFrame_LocalsToFast` are called inside the `call_trampoline` (
https://github.com/python/cpython/blob/master/Python/sysmodule.c#L946).

So, I'd like to simply remove those calls.

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:
https://github.com/fabioz/PyDev.Debugger/blob/0d4d210f01a1c0a8647178b2e665b53ab113509d/_pydevd_bundle/pydevd_save_locals.py#L57
and PyPy also has a counterpart.

As for `PyFrame_FastToLocalsWithError`, I don't really see any reason to
call it at all.

i.e.: something as the code below prints the `a` variable from the `main()`
frame regardless of that and I checked all pydevd tests and nothing seems
to be affected (it seems that accessing f_locals already does this:
https://github.com/python/cpython/blob/cb9879b948a19c9434316f8ab6aba9c4601a8173/Objects/frameobject.c#L35,
so, I don't see much reason to call it at all).

```
def call():
import sys
frame = sys._getframe()
print(frame.f_back.f_locals)

def main():
a = 1
call()

if __name__ == '__main__':
main()
```

Does anyone see any issue with this?

If it's non controversial, is a PEP needed or just an issue to track it
would be enough to remove those 2 lines?

Thanks,

Fabio
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/62WK3THUDNWZCDOMXXDZFG3O4LIOIP4W/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Accepting PEP 626

[Pablo Galindo Salgado]

> 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 thinking of a C struct?
That's an implementation detail.
The PEP states that the f_lineno *attribute* of the code object will be
updated.

Any of them, but as you mentioned isolating the effect of that it may be
not worth
it. Let's measure the impact of the whole change as a whole then.

Cheers,
Pablo


On Thu, 29 Oct 2020 at 10:55, Mark Shannon  wrote:

> 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 not test the performance impact of the change to
> `f_lineno`, as it will likely be swamped by the other changes.
>
> >
> >  > 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 mimick
> > the current behaviour of f_lineno or change anything in the PEP
> > regarding that. I just want to check that the new semantics do not slow
> > down anything in a subtle way.
>
> 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.
>
> >
> >  > What's the reason for supposing that it will be slower?
> >
> > There is no real concern, but as there were some conversations about
> > performance and the pep mentions that "the "f_lineno" attribute of the
> > code object will be updated to point the current line being executed" I
> > just want to make sure that updating that field on every bytecode line
> > change does not affect anything. Again, I am pretty sure it will be
> > negligible impact and the performance check should be just a routine
> > confirmation.
>
> When you say updating "field", are you thinking of a C struct?
> That's an implementation detail.
> The PEP states that the f_lineno *attribute* of the code object will be
> updated.
>
> Note that the behavior of 3.9 is weird in some cases:
>
> test.py:
>  import sys
>
>  def print_line():
>  print(sys._getframe(1).f_lineno)
>
>  def test():
>  print_line()
>  sys._getframe(0).f_trace = True
>  print_line()
>  print_line()
>
>  test()
>
>
> $ python3.9 ~/test/test.py
> 7
> 8
> 8
>
> With PEP 626 this is required to print:
> 7
> 9
> 10
>
>
> Cheers,
> Mark.
>
> >
> > Cheers,
> > Pablo
> >
> > On Thu, 29 Oct 2020, 09:47 Mark Shannon,  > > wrote:
> >
> > 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 experience for
> >  > debuggers, profilers and tools
> >  > that rely on tracing functions. All the existing concerns
> regarding
> >  > out-of-process debuggers
> >  > and profilers have been addressed by Mark in the latest version
> > of the
> >  > PEP. The acceptance of
> >  > the PEP comes with the following requests:
> >  >
> >  > * The PEP must be updated to explicitly state that the
> API functions
> >  > described in the
> >  > "Out of process debuggers and profilers" must remain
> > self-contained
> >  > in any potential
> >  >  future modifications or enhancements.
> >  > * The PEP states that the "f_lineno" attribute of the code object
> > will
> >  > be updated to point to
> >  > the current line being executed even if tracing is off. Also,
> > there
> >  > were some folks concerned with
> >  > possible performance implications. Although in my view there
> > is no
> >  > reason to think this will impact
> >  > performance negatively, I would like us to confirm that
> > indeed this
> >  > is the case before merging the
> >  > implementation (with the pyperformance test suite, for
> example).
> >
> > Performance compared to what?
> > The current behavior of `f_lineno` is ill-defined, so mimicking it
> > would
> > be tricky.
> >
> > What's the reason for supposing that it will be slower?
> >
> > Cheers,
> > Mark.
> >
> >  >
> >  > Congratulations Mark Shannon!
> >  >
> >  > Thanks also toeveryone else who provided feedback on this PEP!
> >  >
> >  > Regards from rainy London,
> >  > Pablo 

[Python-Dev] Re: Accepting PEP 626

[Mark Shannon]

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 not test the performance impact of the change to 
`f_lineno`, as it will likely be swamped by the other changes.




 > 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 mimick 
the current behaviour of f_lineno or change anything in the PEP 
regarding that. I just want to check that the new semantics do not slow 
down anything in a subtle way.


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.




 > What's the reason for supposing that it will be slower?

There is no real concern, but as there were some conversations about 
performance and the pep mentions that "the "f_lineno" attribute of the 
code object will be updated to point the current line being executed" I 
just want to make sure that updating that field on every bytecode line 
change does not affect anything. Again, I am pretty sure it will be 
negligible impact and the performance check should be just a routine 
confirmation.


When you say updating "field", are you thinking of a C struct?
That's an implementation detail.
The PEP states that the f_lineno *attribute* of the code object will be 
updated.


Note that the behavior of 3.9 is weird in some cases:

test.py:
import sys

def print_line():
print(sys._getframe(1).f_lineno)

def test():
print_line()
sys._getframe(0).f_trace = True
print_line()
print_line()

test()


$ python3.9 ~/test/test.py
7
8
8

With PEP 626 this is required to print:
7
9
10


Cheers,
Mark.



Cheers,
Pablo

On Thu, 29 Oct 2020, 09:47 Mark Shannon, > wrote:


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 experience for
 > debuggers, profilers and tools
 > that rely on tracing functions. All the existing concerns regarding
 > out-of-process debuggers
 > and profilers have been addressed by Mark in the latest version
of the
 > PEP. The acceptance of
 > the PEP comes with the following requests:
 >
 > * The PEP must be updated to explicitly state that the API functions
 > described in the
 >     "Out of process debuggers and profilers" must remain
self-contained
 > in any potential
 >      future modifications or enhancements.
 > * The PEP states that the "f_lineno" attribute of the code object
will
 > be updated to point to
 >     the current line being executed even if tracing is off. Also,
there
 > were some folks concerned with
 >     possible performance implications. Although in my view there
is no
 > reason to think this will impact
 >     performance negatively, I would like us to confirm that
indeed this
 > is the case before merging the
 >     implementation (with the pyperformance test suite, for example).

Performance compared to what?
The current behavior of `f_lineno` is ill-defined, so mimicking it
would
be tricky.

What's the reason for supposing that it will be slower?

Cheers,
Mark.

 >
 > Congratulations Mark Shannon!
 >
 > Thanks also toeveryone else who provided feedback on this PEP!
 >
 > Regards from rainy London,
 > Pablo Galindo Salgado


___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/WHBHMT5DD3AR3PKO6IQ6XDZBWTCWF3O7/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Accepting PEP 626

[Pablo Galindo Salgado]

> 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 mimick the
current behaviour of f_lineno or change anything in the PEP regarding that.
I just want to check that the new semantics do not slow down anything in a
subtle way.

> What's the reason for supposing that it will be slower?

There is no real concern, but as there were some conversations about
performance and the pep mentions that "the "f_lineno" attribute of the code
object will be updated to point the current line being executed" I just
want to make sure that updating that field on every bytecode line change
does not affect anything. Again, I am pretty sure it will be negligible
impact and the performance check should be just a routine confirmation.

Cheers,
Pablo

On Thu, 29 Oct 2020, 09:47 Mark Shannon,  wrote:

> 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 experience for
> > debuggers, profilers and tools
> > that rely on tracing functions. All the existing concerns regarding
> > out-of-process debuggers
> > and profilers have been addressed by Mark in the latest version of the
> > PEP. The acceptance of
> > the PEP comes with the following requests:
> >
> > * The PEP must be updated to explicitly state that the API functions
> > described in the
> > "Out of process debuggers and profilers" must remain self-contained
> > in any potential
> >  future modifications or enhancements.
> > * The PEP states that the "f_lineno" attribute of the code object will
> > be updated to point to
> > the current line being executed even if tracing is off. Also, there
> > were some folks concerned with
> > possible performance implications. Although in my view there is no
> > reason to think this will impact
> > performance negatively, I would like us to confirm that indeed this
> > is the case before merging the
> > implementation (with the pyperformance test suite, for example).
>
> Performance compared to what?
> The current behavior of `f_lineno` is ill-defined, so mimicking it would
> be tricky.
>
> What's the reason for supposing that it will be slower?
>
> Cheers,
> Mark.
>
> >
> > Congratulations Mark Shannon!
> >
> > Thanks also toeveryone else who provided feedback on this PEP!
> >
> > Regards from rainy London,
> > Pablo Galindo Salgado
>
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/BIUZGR4YSCTV5FFNSN2RSCGB6MC3U2RB/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Accepting PEP 626

[Mark Shannon]

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 experience for 
debuggers, profilers and tools
that rely on tracing functions. All the existing concerns regarding 
out-of-process debuggers
and profilers have been addressed by Mark in the latest version of the 
PEP. The acceptance of

the PEP comes with the following requests:

* The PEP must be updated to explicitly state that the API functions 
described in the
    "Out of process debuggers and profilers" must remain self-contained 
in any potential

     future modifications or enhancements.
* The PEP states that the "f_lineno" attribute of the code object will 
be updated to point to
    the current line being executed even if tracing is off. Also, there 
were some folks concerned with
    possible performance implications. Although in my view there is no 
reason to think this will impact
    performance negatively, I would like us to confirm that indeed this 
is the case before merging the

    implementation (with the pyperformance test suite, for example).


Performance compared to what?
The current behavior of `f_lineno` is ill-defined, so mimicking it would 
be tricky.


What's the reason for supposing that it will be slower?

Cheers,
Mark.



Congratulations Mark Shannon!

Thanks also toeveryone else who provided feedback on this PEP!

Regards from rainy London,
Pablo Galindo Salgado

___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/R3DGNMJ7WIJWBEVNK5274FXPYEMPZFJE/
Code of Conduct: http://python.org/psf/codeofconduct/