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 ex
> 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 unive
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 ev
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 ass
>
> 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 com
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
https://mail.python.org/mailman
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 awe
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 o
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 actual
> 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 su
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
productio
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