25.09.21 17:46, Guido van Rossum пише:
> - I was envisioning something that provides an API that would allow a
> test framework to do what pytest does; not a behavior chance to the
> assert statement by default.
>
> - Please, please collaborate with the pytest developers on the design.
+++
Getting OT here -- a full discussion of unitest is a while other topic.
One I do want to have one of these days, but not now. But for closure:
> This would make assertions more useful to everyone, whatever test
> framework (or no test framework at all) they use.
>
> > 1) Many major (and
Thank you
On Sat, Sep 25, 2021, at 18:53, Guido van Rossum wrote:
> First you need to fond a core dev to sponsor you (Steven D’A?). That person
> will guide you through the process.
>
> On Sat, Sep 25, 2021 at 08:30 Noam Tenne wrote:
>> __
>> So should I just scratch this and rewrite a PEP
First you need to fond a core dev to sponsor you (Steven D’A?). That person
will guide you through the process.
On Sat, Sep 25, 2021 at 08:30 Noam Tenne wrote:
> So should I just scratch this and rewrite a PEP for an extensible
> assertion mechanism?
>
> On Fri, Sep 24, 2021, at 14:04, Noam
So should I just scratch this and rewrite a PEP for an extensible assertion
mechanism?
On Fri, Sep 24, 2021, at 14:04, Noam Tenne wrote:
> Hi All,
>
> Following the discussions on "Power Assertions: Is it PEP-able?", I've
> drafted this PEP.
> Your comments are most welcome.
>
> PEP:
>
On Sat, Sep 25, 2021 at 00:56 Steven D'Aprano wrote:
> On Fri, Sep 24, 2021 at 11:23:00PM -0700, Guido van Rossum wrote:
>
> > > Is there no room for making it easier to do this with less invasive
> > > changes to the stdlib, or are Steven d'A's "heroic measures in an
> > > import hook" the
My first thought was: it would be very nice, when doing quick and dirty
scratch code, to not have to resort to a full fledged test framework to get
readable assertions. You could just throw an assert statement in a if
__name__ == '__main__' block at the bottom, click the run arrow next to it
in
On Sat, 25 Sept 2021 at 06:09, Stephen J. Turnbull
wrote:
>
> Guido van Rossum writes:
>
> > I think this is by far the best option. Pytest can evolve much faster than
> > the stdlib.
>
> Is there no room for making it easier to do this with less invasive
> changes to the stdlib, or are Steven
On Fri, Sep 24, 2021 at 11:23:00PM -0700, Guido van Rossum wrote:
> > Is there no room for making it easier to do this with less invasive
> > changes to the stdlib, or are Steven d'A's "heroic measures in an
> > import hook" the right way to go?
> >
> > Other Steve
>
>
> There’s room for that,
On Fri, Sep 24, 2021 at 10:39:32PM -0700, Christopher Barker wrote:
> Now that's a PEP I could get behind.
You mean, like this PEP? *wink*
> Adding one feature to unittest doesn't seem worth it to me
I don't think this PEP directly proposes any new features to unittest.
If it is accepted,
>Is there no room for making it easier to do this with less invasive
changes to the stdlib, or are Steven d'A's "heroic measures in an
import hook" the right way to go?
I'm not familiar with this, can you please elaborate?
>From what I understand we can change stdlib to the point of manipulating
>So maybe what we should do now, rather than add one feature, is propose a new
>test framework/test runner for the stdlib, inspired by pytest.
I'd actually avoid reinventing a test framework as I think this has proven to
be futile. I'm of the opinion that the language should provide a lean
Will do!
On Fri, Sep 24, 2021, at 14:10, Paul Moore wrote:
> On Fri, 24 Sept 2021 at 12:05, Noam Tenne wrote:
>
> > Caveats
> > ---
> >
> > It is important to note that expressions with side effects are affected by
> > this feature. This is because in order to display this information, we
On Fri, Sep 24, 2021 at 22:07 Stephen J. Turnbull <
stephenjturnb...@gmail.com> wrote:
> Guido van Rossum writes:
>
> > I think this is by far the best option. Pytest can evolve much faster
> than
> > the stdlib.
>
> Is there no room for making it easier to do this with less invasive
> changes
On Fri, Sep 24, 2021 at 8:51 PM Steven D'Aprano wrote:
>
> Pytest needs to take heroic measures in an import hook to re-write your
> assertions to do what it does:
>
> Maybe a language change, with a public API for assertions, would make it
> much easier and less hacky for test frameworks to
Guido van Rossum writes:
> I think this is by far the best option. Pytest can evolve much faster than
> the stdlib.
Is there no room for making it easier to do this with less invasive
changes to the stdlib, or are Steven d'A's "heroic measures in an
import hook" the right way to go?
Other
This proposal sounds very promising. Some observations/questions follow.
On Fri, Sep 24, 2021 at 02:04:21PM +0300, Noam Tenne wrote:
> Assertion failed:
>
> sc.val['d'] == f
> | ||
> | eFalse
> |
> {'d': 'e'}
Can we see what the output would look like
On Fri, Sep 24, 2021 at 07:45:41PM -0700, Christopher Barker wrote:
> 1) this should be part of a test framework, not something built in to
> exceptions. Pytest has shown that it can be done without any language
> changes.
Pytest needs to take heroic measures in an import hook to re-write your
On Fri, Sep 24, 2021 at 19:49 Christopher Barker
wrote:
> Alternatively, take the approach taken with distutils and setuptools—
> officially accept that a full featured test framework will be left to third
> parties.
>
I think this is by far the best option. Pytest can evolve much faster than
My first thought when reading this (and the recent discussion on Python
ideas) was that pytest already does this.
Then I see in the PEP: "What pytest does is awesome“
So what?
Well, two points:
1) this should be part of a test framework, not something built in to
exceptions. Pytest has
On Fri, 24 Sept 2021 at 12:05, Noam Tenne wrote:
> Caveats
> ---
>
> It is important to note that expressions with side effects are affected by
> this feature. This is because in order to display this information, we must
> store references to the instances and not just the values.
One
21 matches
Mail list logo
