On Tue, Oct 5, 2021 at 9:50 AM Caleb Donovick wrote:
>
> > 2) Some OTHER exception occurs on the reevaluation. It's a chained
> > exception like any other.
>
> Except it's not a chained exception and displaying as such would be VERY
> confusing IMO.
> Granted we could easily strip the chained
> 2) Some OTHER exception occurs on the reevaluation. It's a chained
> exception like any other.
Except it's not a chained exception and displaying as such would be VERY
confusing IMO.
Granted we could easily strip the chained exception and just return the
original one. So after
reconsideration
> I wonder, could this be simplified a bit, on the assumption that a
> well-written assertion shouldn't have a problem with being executed
> twice?
While I agree as an engineering principle an assert should not have side
effects
and hence re-evaluation should be fine in most cases, it is not
On Tue, Oct 5, 2021 at 9:02 AM Caleb Donovick wrote:
>
> > I wonder, could this be simplified a bit, on the assumption that a
> > well-written assertion shouldn't have a problem with being executed
> > twice?
>
> While I agree as an engineering principle an assert should not have side
> effects
If assertions have an associated block, then `pdb` can be invoked within. I
almost never use debuggers, so I don't remember, but I think a recent
Python version introduced the likes of `debug()` to step into the
pre-configured debugger.
About the "power assertions" proposal in this thread, once
I think that this is a great idea. However, pipes only point to one
character, which can be confusing. (Citation: many tracebacks before 3.10.)
I'm wondering: Could failed assertions step you into `pdb`, if they are
used for testing purposes? Could there be a way to specify different levels
of
>
> What about asserts that are not used for testing, but as classic “unless
> there’s a bug, this should hold”?
To me this relates to the thread about having a structured *assert* that
doesn't go away with *-O*.
My purpose when addressing *assert* was precisely the *“unless there’s a
bug, this
12.09.21 21:36, Chris Angelico пише:
> I wonder, could this be simplified a bit, on the assumption that a
> well-written assertion shouldn't have a problem with being executed
> twice? Instead of keeping all the subexpressions around (a run-time
> cost), keep the AST of the expression itself (a
12.09.21 21:20, Guido van Rossum пише:
> Maybe you all could collaborate on a PEP? This sounds a worthy topic.
I can write an implementation if we decide on the interface. I am
currently have higher priorities of other tasks than to make a research
on this feature.
> Maybe you all could collaborate on a PEP? This sounds a worthy topic.
.
Yes, I would love that please.
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
On Mon, Sep 13, 2021 at 1:37 AM Serhiy Storchaka wrote:
>
> 12.09.21 17:28, Guido van Rossum пише:
> > This is cool.
> >
> > AFAIK pytest does something like this. How does your implementation differ?
>
> What pytest does is awesome. I though about implementing it in the
> standard compiler since
Maybe you all could collaborate on a PEP? This sounds a worthy topic.
On Sun, Sep 12, 2021 at 08:37 Serhiy Storchaka wrote:
> 12.09.21 17:28, Guido van Rossum пише:
> > This is cool.
> >
> > AFAIK pytest does something like this. How does your implementation
> differ?
>
> What pytest does is
12.09.21 17:28, Guido van Rossum пише:
> This is cool.
>
> AFAIK pytest does something like this. How does your implementation differ?
What pytest does is awesome. I though about implementing it in the
standard compiler since seen it the first time.
> What is your argument for making this part
2QdxY4RzWzUUiLuE＠potatochowder.com wrote:
> On 2021-09-12 at 07:28:53 -0700,
> Guido van Rossum gu...@python.org wrote:
> > What about asserts that are not used for testing, but as classic
> > “unless there’s a bug, this should hold”? Those may not want to incur
> > the extra cost.
> > I was
> This is cool.
Thank you. Much appreciated.
> AFAIK pytest does something like this. How does your implementation differ?
The pytest implementation is very powerful in the way of hints and suggestions
that point to the difference and source, but when the asserted expression has
more than one
On 2021-09-12 at 07:28:53 -0700,
Guido van Rossum wrote:
> What about asserts that are not used for testing, but as classic
> “unless there’s a bug, this should hold”? Those may not want to incur
> the extra cost.
I was actually thinking exactly the opposite: this would more useful in
This is cool.
AFAIK pytest does something like this. How does your implementation differ?
What is your argument for making this part of the language? Why not a 3rd
party library?
What about asserts that are not used for testing, but as classic “unless
there’s a bug, this should hold”? Those may
17 matches
Mail list logo
