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
On 6/30/2021 5:30 PM, Pablo Galindo Salgado wrote:
Also, notice we are extending the traceback module (in Python) to
support this, so you probably can also leverage those changes so you
don't need to mess with code objects yourself :)
IDLE currently uses traceback.extract_tb and
> Then how will modules that customizes traceback presentation, such as
idlelib, be able to get the 4-tuple for a particular traceback entry?
From the exception, you can get the code object and from the code
object the extra information using
the Python API:
Example:
>>> try:
... 1/0
Also, notice we are extending the traceback module (in Python) to support
this, so you probably can also leverage those changes so you don't need to
mess with code objects yourself :)
On Wed, 30 Jun 2021 at 22:29, Pablo Galindo Salgado
wrote:
> Hi Terry,
>
> Thanks for your message!
>
> > Then
Hi Terry,
Thanks for your message!
> Then how will modules that customizes traceback presentation, such as
idlelib, be able to get the 4-tuple for a particular traceback entry?
>From the exception, you can get the code object and from the code object
the extra information using
the Python API:
On 6/30/2021 12:30 PM, Ammar Askar wrote:
I don't think we're making strong claims that the full `(line,
end_line, column, end_column)` should be the canonical representation
for exception locations. The only concrete place we suggest their
usage is in the printing of tracebacks.
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
Hello Mark,
Thanks for writing this email. I do appreciate your effort and your passion
for trying to improve Python and this work, but I
have to say that I am a bit frustrated with how are you dealing with this
and that unfortunately, I have to admit that this is
absorbing too much emotional
> Hopefully if we add more pseudokeywords in the future it won't break
the ability to parse traceback spans.
It won't because soft keywords are now handled natively with the peg
parser (as "match" and "case" now) instead of hacked into the tokenizer :)
On Fri, 21 May 2021 at 01:55, Nathaniel
On Wed, May 19, 2021 at 7:28 PM Pablo Galindo Salgado
wrote:
>>
>> Excellent point! Do you know how reliable this is in practice, i.e.
>> what proportion of bytecode source spans are something you can
>> successfully pass to ast.parse? If it works it's obviously nicer, but
>> I can't tell how
>
> Excellent point! Do you know how reliable this is in practice, i.e.
> what proportion of bytecode source spans are something you can
> successfully pass to ast.parse? If it works it's obviously nicer, but
> I can't tell how often it works. E.g. anything including
>
On Tue, May 18, 2021 at 2:49 PM Pablo Galindo Salgado
wrote:
> * It actually doesn't have more advantages. The current solution in the PEP
> can do exactly the same as this solution if you allow reparsing when
> displaying tracebacks. This is because with the start line, end line, start
>
Ok, we have implemented a rough prototype and we have decided not to go
with this for the following reasons:
* Is almost the same storage cost as the solution we already have. Since
storing the node id cost 4 bytes (an integer) per instruction
and our solution needs 2+ bytes per instruction for
On 5/18/21 5:25 AM, Pablo Galindo Salgado wrote:
Yet another problem that I found:
One integer is actually not enough to assign IDs. One unsigned integer
can cover 4,294,967,295 AST nodes, but is technically possibleto have
more than that in a single file.
Surely you could use a 64-bit int
> One integer is actually not enough to assign IDs.
Actually, disregard this particular problem. I think that we could
perfectly stop assigning IDs if we reach the overflow limit and call it a
day
since you need to have a truly horrendous file to reach 4,294,967,295 AST nodes
(I did some tests to
Yet another problem that I found:
One integer is actually not enough to assign IDs. One unsigned integer can
cover 4,294,967,295 AST nodes, but is technically possible
to have more than that in a single file. While in PEP 657 we are tracking
offsets that are normally very low < 100 typically or
Hu, actually another problem of this approach:
Nodes are created and modified after the optimization pass, so the AST
produced by the parser is not enough to reconstruct the actual
information, we need to also run the optimization passes, but
unfortunately, this is (by design) not don't in
Hi Nathaniel,
Thanks a lot for your suggestion! I like the idea although I still think is
more complex than our current proposal, but on the other hand it allows for
a much richer results so I'm quite excited to try it out. We are going to
give it a go to explore it with a prototype and if we are
On Mon, May 17, 2021 at 6:18 AM Mark Shannon wrote:
> 2. Repeated binary operations on the same line.
>
> A single location can also be clearer when all the code is on one line.
>
> i1 + i2 + s1
>
> PEP 657:
>
> i1 + i2 + s1
>
>
> Using a single location:
>
> i1 + i2 + s1
>
Ethan Furman wrote:
> On 5/17/2021 6:13 AM, Mark Shannon wrote:
> > Where i1, i2 are integers and s1 is a string.
> > > i1 + i2 + s1
> >
> Wouldn't the carets just be under the i2 + s1 portion?
I don't think so, since this is executed as `((i1 + i2) + s1)`.
Mark's carets look
On 5/17/2021 6:13 AM, Mark Shannon wrote:
> Where i1, i2 are integers and s1 is a string.
> i1 + i2 + s1
>
Wouldn't the carets just be under the i2 + s1 portion?
--
~Ethan~
___
Python-Dev mailing list -- python-dev@python.org
To
> > 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.
Python does have an Optimized mode (-O). Granted, it’s not used very often,
but this would be a good
> 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
Hi,
On 17/05/2021 5:22 pm, Ammar Askar wrote:
>> 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
> 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
P.S. We will add "using a single caret" to the "rejected ideas section"
with some rationale.
On Mon, 17 May 2021, 14:28 Pablo Galindo Salgado,
wrote:
> Hi Mark,
>
> Thanks for your useful feedback. Some comments:
>
> > 1. Errors spanning multiple lines.
>
> That is addressed. Check the latest
Hi Mark,
Thanks for your useful feedback. Some comments:
> 1. Errors spanning multiple lines.
That is addressed. Check the latest version of the PEP: we are propising
storing the end lines as well:
https://www.python.org/dev/peps/pep-0657/#specification
> 2. Repeated binary operations on
27 matches
Mail list logo
