[Python-ideas] Re: Power Assertions: Is it PEP-able?
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 compile-time cost). > Then, when the exception is about to be printed to the console, > re-evaluate it and do the display. Yes, it would simplify, but we cannot guarantee this (especially in tests). If we could, we would not need an assert. ___ Python-ideas mailing list -- python-ideas@python.org To unsubscribe send an email to python-ideas-le...@python.org https://mail.python.org/mailman3/lists/python-ideas.python.org/ Message archived at https://mail.python.org/archives/list/python-ideas@python.org/message/R65D3VPFF5354ENFUWSXL2GQWUKZFVSH/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Power Assertions: Is it PEP-able?
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. ___ Python-ideas mailing list -- python-ideas@python.org To unsubscribe send an email to python-ideas-le...@python.org https://mail.python.org/mailman3/lists/python-ideas.python.org/ Message archived at https://mail.python.org/archives/list/python-ideas@python.org/message/CUYVV3XXAGJ2QEUGXJDTVEDCVQF5ZY2U/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Power Assertions: Is it PEP-able?
> 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/mailman3/lists/python-ideas.python.org/ Message archived at https://mail.python.org/archives/list/python-ideas@python.org/message/IEXGEPLU5SAINPV3RQIFBZYNYRUIVNWP/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Different exceptions for assert
Steve, I've seen *unless* discussed and rejected before, but it is a good enough syntax for the purpose of asserting invariants, and it should be useful for other purposes (because it has been proposed before). The semantics are clear, and the implementation is simple with the new Python parser shortcutting to an "*if not"*. I do really like this option. On Sun, Sep 12, 2021 at 1:46 AM Steven D'Aprano wrote: > On Sat, Sep 11, 2021 at 02:30:10PM -0400, Juancarlo Añez wrote: > > > *invariant* cond: etc > > A software invariant is still an assertion. > > In another post, I semi-suggested a new (soft) keyword: > > unless condition: > # block > raise Exception > > But really, it's just an "if not". > > if not condition: > unless condition: > assert condition: > > are all exactly the same amount of typing. It's not clear that learning > a new keyword `unless` is more readable than just using `if not`. > > I think it might work better in languages that attempt to follow natural > language (e.g. XTalk languages) than one like Python with a relatively > minimal amount of syntax. But it is clear to me that using `assert` for > non-assertions is misleading. > > -- > Steve > ___ > Python-ideas mailing list -- python-ideas@python.org > To unsubscribe send an email to python-ideas-le...@python.org > https://mail.python.org/mailman3/lists/python-ideas.python.org/ > Message archived at > https://mail.python.org/archives/list/python-ideas@python.org/message/ERBJUTXNAVALGUGDPC7EHQT3LUP3NQHB/ > Code of Conduct: http://python.org/psf/codeofconduct/ > -- Juancarlo *Añez* ___ Python-ideas mailing list -- python-ideas@python.org To unsubscribe send an email to python-ideas-le...@python.org https://mail.python.org/mailman3/lists/python-ideas.python.org/ Message archived at https://mail.python.org/archives/list/python-ideas@python.org/message/3GOYGFSNKEGVB2NFC6MT5C2U7KNS3UEG/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Power Assertions: Is it PEP-able?
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 seen it the first time. > > > What is your argument for making this part of the language? Why not a > > 3rd party library? > > It needs a support in the compiler. The condition expression should be > compiled to keep all immediate results of subexpressions on the stack. > If the final result is true, immediate results are dropped. If it is > false, the second argument of assert is evaluated and its value together > with all immediate results of the first expression, together with > references to corresponding subexpressions (as strings, ranges or AST > nodes) are passed to the special handler. That handler can be > implemented in a third-party library, because formatting and outputting > a report is a complex task. The default handler can just raise an > AttributeError. > 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 compile-time cost). Then, when the exception is about to be printed to the console, re-evaluate it and do the display. ChrisA ___ Python-ideas mailing list -- python-ideas@python.org To unsubscribe send an email to python-ideas-le...@python.org https://mail.python.org/mailman3/lists/python-ideas.python.org/ Message archived at https://mail.python.org/archives/list/python-ideas@python.org/message/IXPY4BRCZ3MPSSVBKWFYJGMR6ZHFGCJF/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Power Assertions: Is it PEP-able?
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 awesome. I though about implementing it in the > standard compiler since seen it the first time. > > > What is your argument for making this part of the language? Why not a > > 3rd party library? > > It needs a support in the compiler. The condition expression should be > compiled to keep all immediate results of subexpressions on the stack. > If the final result is true, immediate results are dropped. If it is > false, the second argument of assert is evaluated and its value together > with all immediate results of the first expression, together with > references to corresponding subexpressions (as strings, ranges or AST > nodes) are passed to the special handler. That handler can be > implemented in a third-party library, because formatting and outputting > a report is a complex task. The default handler can just raise an > AttributeError. > > > 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. > > The only extra cost is that immediate results are temporary save on > stack instead of just be dropped. It increases the size of bytecode and > stack, but I don't think it will be significant. > > ___ > Python-ideas mailing list -- python-ideas@python.org > To unsubscribe send an email to python-ideas-le...@python.org > https://mail.python.org/mailman3/lists/python-ideas.python.org/ > Message archived at > https://mail.python.org/archives/list/python-ideas@python.org/message/S673FXNSAWR3UWKNLIYTBVDAWONDPWWJ/ > Code of Conduct: http://python.org/psf/codeofconduct/ > -- --Guido (mobile) ___ Python-ideas mailing list -- python-ideas@python.org To unsubscribe send an email to python-ideas-le...@python.org https://mail.python.org/mailman3/lists/python-ideas.python.org/ Message archived at https://mail.python.org/archives/list/python-ideas@python.org/message/E67KVRNCGWB5CULMKOSQSOBS36RLYLFA/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Should for loops run in their own scope?
In the example at the top of the discuss thread >>> larr = [lambda: i for i in range(10)] >>> iarr = [l() for l in larr] >>> iarr [9, 9, 9, 9, 9, 9, 9, 9, 9, 9] a comprehension is used, which already (kinda) creates it's own scope. So that is really about lambda, not loops. Or at least, that post was about lambda. And lambda works just like other functions, which is should -- are folks suggesting lambda should be different? (side note: I think there is a contsant struggle because folks *want* lambda to be more than it is in python. And since lambda only supports a single expression, and we now have comprehensions, its use is pretty darn limited anyway.) As for for loops: I personally have used the fact that for loops "leak" their scope more often than I get bitten them not having their own scope. -CHB On Sun, Sep 12, 2021 at 8:38 AM Steven D'Aprano wrote: > Over on Discuss, there's a small discussion about the "lambdas in for > loop" problem described in the FAQs. > > https://discuss.python.org/t/make-lambdas-proper-closures/10553 > > > https://docs.python.org/3/faq/programming.html#why-do-lambdas-defined-in-a-loop-with-different-values-all-return-the-same-result > > I've created a poll on Discuss. If you have an account, you may like to > vote on whether for loops should run in their own scope: > > https://discuss.python.org/t/should-loops-be-in-their-own-scope-poll/10593 > > > * No change, leave loops as they are. > > * Change loops to use their own scope. > > * No change for loops by default, but add an option to run them in a new > scope. > > > Just throwing out some random syntax to be shot down, how does this read > to folks? > > for item in sequence in scope: > # block here has its own scope > ... > > > I have no idea what the implementation difficulties might be, but with > lots of hand-waving and in full knowledge that it won't be *me* having > to do the implementation, I imagine it could be easy enough if the for > loop is compliled into a nested function that is then immediately > executed. Sort of like a comprehension? > > Personally, I'm happy with Python not using block scopes (only functions > and classes create a new scope, other blocks do not). But for loop scope > does seem to be frequently requested, so while I don't see the benefit > myself, maybe others do. > > > -- > Steve > ___ > Python-ideas mailing list -- python-ideas@python.org > To unsubscribe send an email to python-ideas-le...@python.org > https://mail.python.org/mailman3/lists/python-ideas.python.org/ > Message archived at > https://mail.python.org/archives/list/python-ideas@python.org/message/YCTRSKPVDE43LAYNVDMXI7OJJ73FZDGN/ > Code of Conduct: http://python.org/psf/codeofconduct/ > -- Christopher Barker, PhD (Chris) Python Language Consulting - Teaching - Scientific Software Development - Desktop GUI and Web Development - wxPython, numpy, scipy, Cython ___ Python-ideas mailing list -- python-ideas@python.org To unsubscribe send an email to python-ideas-le...@python.org https://mail.python.org/mailman3/lists/python-ideas.python.org/ Message archived at https://mail.python.org/archives/list/python-ideas@python.org/message/EUIVWCVZNDYY7UPHEEHXEDYD7GYBFA3W/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Should for loops run in their own scope?
Honestly, the construct of `lambda x=x: stuff(x)` in a loop or comprehension isn't that hard to learn. Yes, I've also forgotten it and tripped over that. But then, I've also banged my head on the wall when I use a language with block scope and forget that variables won't be available after the block ends. Learning Python scope rules is just part of learning the language. Simplicity and consistency is much more important to me than "yet another way to do it." On Sun, Sep 12, 2021, 11:38 AM Steven D'Aprano wrote: > Over on Discuss, there's a small discussion about the "lambdas in for > loop" problem described in the FAQs. > > https://discuss.python.org/t/make-lambdas-proper-closures/10553 > > > https://docs.python.org/3/faq/programming.html#why-do-lambdas-defined-in-a-loop-with-different-values-all-return-the-same-result > > I've created a poll on Discuss. If you have an account, you may like to > vote on whether for loops should run in their own scope: > > https://discuss.python.org/t/should-loops-be-in-their-own-scope-poll/10593 > > > * No change, leave loops as they are. > > * Change loops to use their own scope. > > * No change for loops by default, but add an option to run them in a new > scope. > > > Just throwing out some random syntax to be shot down, how does this read > to folks? > > for item in sequence in scope: > # block here has its own scope > ... > > > I have no idea what the implementation difficulties might be, but with > lots of hand-waving and in full knowledge that it won't be *me* having > to do the implementation, I imagine it could be easy enough if the for > loop is compliled into a nested function that is then immediately > executed. Sort of like a comprehension? > > Personally, I'm happy with Python not using block scopes (only functions > and classes create a new scope, other blocks do not). But for loop scope > does seem to be frequently requested, so while I don't see the benefit > myself, maybe others do. > > > -- > Steve > ___ > Python-ideas mailing list -- python-ideas@python.org > To unsubscribe send an email to python-ideas-le...@python.org > https://mail.python.org/mailman3/lists/python-ideas.python.org/ > Message archived at > https://mail.python.org/archives/list/python-ideas@python.org/message/YCTRSKPVDE43LAYNVDMXI7OJJ73FZDGN/ > Code of Conduct: http://python.org/psf/codeofconduct/ > ___ Python-ideas mailing list -- python-ideas@python.org To unsubscribe send an email to python-ideas-le...@python.org https://mail.python.org/mailman3/lists/python-ideas.python.org/ Message archived at https://mail.python.org/archives/list/python-ideas@python.org/message/JVAI5OSACTGML2UR6BUOUZ7KUZUTYCTM/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Power Assertions: Is it PEP-able?
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 of the language? Why not a > 3rd party library? It needs a support in the compiler. The condition expression should be compiled to keep all immediate results of subexpressions on the stack. If the final result is true, immediate results are dropped. If it is false, the second argument of assert is evaluated and its value together with all immediate results of the first expression, together with references to corresponding subexpressions (as strings, ranges or AST nodes) are passed to the special handler. That handler can be implemented in a third-party library, because formatting and outputting a report is a complex task. The default handler can just raise an AttributeError. > 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. The only extra cost is that immediate results are temporary save on stack instead of just be dropped. It increases the size of bytecode and stack, but I don't think it will be significant. ___ Python-ideas mailing list -- python-ideas@python.org To unsubscribe send an email to python-ideas-le...@python.org https://mail.python.org/mailman3/lists/python-ideas.python.org/ Message archived at https://mail.python.org/archives/list/python-ideas@python.org/message/S673FXNSAWR3UWKNLIYTBVDAWONDPWWJ/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Should for loops run in their own scope?
Over on Discuss, there's a small discussion about the "lambdas in for loop" problem described in the FAQs. https://discuss.python.org/t/make-lambdas-proper-closures/10553 https://docs.python.org/3/faq/programming.html#why-do-lambdas-defined-in-a-loop-with-different-values-all-return-the-same-result I've created a poll on Discuss. If you have an account, you may like to vote on whether for loops should run in their own scope: https://discuss.python.org/t/should-loops-be-in-their-own-scope-poll/10593 * No change, leave loops as they are. * Change loops to use their own scope. * No change for loops by default, but add an option to run them in a new scope. Just throwing out some random syntax to be shot down, how does this read to folks? for item in sequence in scope: # block here has its own scope ... I have no idea what the implementation difficulties might be, but with lots of hand-waving and in full knowledge that it won't be *me* having to do the implementation, I imagine it could be easy enough if the for loop is compliled into a nested function that is then immediately executed. Sort of like a comprehension? Personally, I'm happy with Python not using block scopes (only functions and classes create a new scope, other blocks do not). But for loop scope does seem to be frequently requested, so while I don't see the benefit myself, maybe others do. -- Steve ___ Python-ideas mailing list -- python-ideas@python.org To unsubscribe send an email to python-ideas-le...@python.org https://mail.python.org/mailman3/lists/python-ideas.python.org/ Message archived at https://mail.python.org/archives/list/python-ideas@python.org/message/YCTRSKPVDE43LAYNVDMXI7OJJ73FZDGN/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Power Assertions: Is it PEP-able?
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 actually thinking exactly the opposite: this would more useful in > production than in testing. > When I'm testing, tests build on each other. I should know that the > inner parts work, and I should be testing specific aspects of the outer > parts. If I don't have confidence in those inner parts, then I need to > write more tests against them. If I don't "know" where the data comes > from in my assertions, then my tests are trying to test too much at > once. > On the other hand, weird things happen in production, and my first > reaction to "this shouldn't happen unless there's a bug" are is to start > looking in the logs at how we got there. These power assertions are > like a retroactive or JIT logging mechanism (in the sense that I may not > have logged enough detail), or a sort of first order run-time debugger > that shows me what's relevant at the point of the failure. > As far as the extra cost goes, how does that cost compare to the full > stack trace I already get from the exception being raised? That's an interesting observation. I haven't thought of that. Regarding cost - I haven't profiled my implementation, so I'll have to get back to you on that one. ___ Python-ideas mailing list -- python-ideas@python.org To unsubscribe send an email to python-ideas-le...@python.org https://mail.python.org/mailman3/lists/python-ideas.python.org/ Message archived at https://mail.python.org/archives/list/python-ideas@python.org/message/6F7MAI5TI6CIESDPOJTGCAYVIZARK23A/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Power Assertions: Is it PEP-able?
> 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 sub-expression, the thread-style breakdown is unreadable. I believe my chart-style implementation offers better readability. > What is your argument for making this part of the language? Why not a 3rd > party library? The first argument is that asserts are fundamental, which is why they are a core part of the language in the first place. If they're already part of the core, we can improve them to provide more constructive feedback, without having to pull in mammoth testing frameworks, which brings me to my second argument. My understanding of the compiler is that a 3rd party library can't simply rewrite AST during the standard compilation. If one wants to intervene with the AST phase, one must rewrite and execute the python files. This is a very intrusive and impractical process for a scope of a 3rd party library. It's definitely more fitting for frameworks that act as executers such as pytest and my framework Nimoy. Please correct me if I'm mistaken. > 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. Correct. I believe that the proper way to handle this is a switch much like `-O`. The feature will be opt-in, and one can opt-in using that switch. ___ Python-ideas mailing list -- python-ideas@python.org To unsubscribe send an email to python-ideas-le...@python.org https://mail.python.org/mailman3/lists/python-ideas.python.org/ Message archived at https://mail.python.org/archives/list/python-ideas@python.org/message/SPUISYVZWRAHJMY5IP5AZ42SDQKW6E6D/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Add a special TypeError subclass for implementation errors
03.09.21 10:34, Thomas Grainger пише: > I think that it would be good to make TypeError more fine-grained. > Another example is: > sum(1, 2, 3) > Traceback (most recent call last): > File "", line 1, in > TypeError: sum() takes at most 2 arguments (3 given) I agree that TypeErrors raised for incorrect number or names of arguments is a separate class of TypeErrors. But it is not related to my proposition. It includes also two kinds of errors: 1. Programming error. The author of the calling code uses a known function improperly or the author of the function break compatibility. 2. User input error. If a user provides an incompatible callable. ___ Python-ideas mailing list -- python-ideas@python.org To unsubscribe send an email to python-ideas-le...@python.org https://mail.python.org/mailman3/lists/python-ideas.python.org/ Message archived at https://mail.python.org/archives/list/python-ideas@python.org/message/ZX2YFXHRI6BNWABCFRJ4GWRNW2RMAA7J/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Power Assertions: Is it PEP-able?
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 production than in testing. When I'm testing, tests build on each other. I should know that the inner parts work, and I should be testing specific aspects of the outer parts. If I don't have confidence in those inner parts, then I need to write more tests against them. If I don't "know" where the data comes from in my assertions, then my tests are trying to test too much at once. On the other hand, weird things happen in production, and my first reaction to "this shouldn't happen unless there's a bug" are is to start looking in the logs at how we got there. These power assertions are like a retroactive or JIT logging mechanism (in the sense that I may not have logged enough detail), or a sort of first order run-time debugger that shows me what's relevant at the point of the failure. As far as the extra cost goes, how does that cost compare to the full stack trace I already get from the exception being raised? ___ Python-ideas mailing list -- python-ideas@python.org To unsubscribe send an email to python-ideas-le...@python.org https://mail.python.org/mailman3/lists/python-ideas.python.org/ Message archived at https://mail.python.org/archives/list/python-ideas@python.org/message/RC373JSGZE2O6FOYJSPNZMOZU4DPNPKS/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Add a special TypeError subclass for implementation errors
03.09.21 10:34, Thomas Grainger пише: > what's the reason for this not to raise AttributeError? At least backward compatibility. Currently a TypeError is raised in such cases, and AttributeError is not a subtype of TypeError. Also, not always any attribute is involved. For example, float() raises a TypeError if __float__() returns not float. And even if some dunder name is involved, rules for resolving special methods and common attributes are different. > I assume you asked this question in relation to the 3.11 changes to `with x:` > raising TypeError vs AttributeError ? No, it is not related. It was a bug to raise AttributeError, now it is fixed, but the fix is not backported for compatibility reasons. > How about `AttributeNotFoundError` or `AttributeRequiredError` ? It would be confused with completely unrelated AttributeError. ___ Python-ideas mailing list -- python-ideas@python.org To unsubscribe send an email to python-ideas-le...@python.org https://mail.python.org/mailman3/lists/python-ideas.python.org/ Message archived at https://mail.python.org/archives/list/python-ideas@python.org/message/DE45KOKRPMUV7X2IYHKN26YQGNBJJ2OB/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Add a special TypeError subclass for implementation errors
12.09.21 07:48, Ram Krishna пише:
> I guess having subclass for implementation errors to distinguish will be very
> helpful, Typeerror has become very generic and finding solution is like
> searching a needle in haystack for the new developers.
>
> Eg- TypeError: ‘int’ object is not iterable
>
> students=int(input('Please enter the number of students in the class: '))
>
> for number in students:
> math_grade=(input("Enter student's Maths grade: "))
> science_grade=(input("Enter student's Science grade: "))
> social_grade=(input("Enter student's Scoial grade: "))
>
> Common homeworks/tutorial for beginners who find difficult to understand why
> this error occurred. So a fine grained exception would be lot easier to
> understand and resolve quickly.
My proposition does not change the type of exception here. It is a
vanilla TypeError: you use a value of improper type in operation.
A new implementation error would be raised if you implement your own
iterable class and return int in __iter__(). Most beginners will never
see such errors because it is an advanced topic.
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at
https://mail.python.org/archives/list/python-ideas@python.org/message/3BUU5NQNGJKO4V2JROS3XVCCMTZ7EIMZ/
Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Power Assertions: Is it PEP-able?
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 not want to incur the extra
cost.
—Guido
On Sun, Sep 12, 2021 at 07:09 wrote:
> Hi all,
>
> I’d like your comments and feedback on an enhancement that introduces
> power assertions to the Python language.
>
> Proposal
>
> This feature is inspired by a similar feature of the Groovy language[1],
> and is effectively a variant of the `assert` keyword.
> When an assertion expression evaluates to `False`, the output shows not
> only the failure, but also a breakdown of the evaluated expression from the
> inner part to the outer part.
>
> For example, a procedure like:
> ```python
> class SomeClass:
> def __init__(self):
> self.val = {'d': 'e'}
>
> def __str__(self):
> return str(self.val)
>
> sc = SomeClass()
>
> assert sc.val['d'] == 'f'
> ```
>
> Will result in the output:
>
> ```python
> Assertion failed:
>
> sc.val['d'] == f
> | ||
> | eFalse
> |
> {'d': 'e'}
> ```
> See link [2] if the formatting above is screwed up.
>
> In the output above we can see the value of every part of the expression
> from left to right, mapped to their expression fragment with the pipe (`|`).
> The number of rows that are printed depend on the value of each fragment
> of the expression.
> If the value of a fragment is longer than the actual fragment (`{'d':
> 'e'}` is longer than `sc`), then the next value (`e`) will be printed on a
> new line which will appear above.
> Values are appended to the same line until it overflows in length to
> horizontal position of the next fragment.
>
> The information that’s displayed is dictated by the type.
> If the type is a constant value, it will be displayed as is.
> If the type implements `__str__`, then the return value of that will be
> displayed.
>
> 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.
>
> Rational
>
> Every test boils down to the binary statement "Is this true or false?",
> whether you use the built-in assert keyword or a more advanced assertion
> method provided by a testing framework.
> When an assertion fails, the output is binary too — "Expected x, but got
> y".
>
> There are helpful libraries like Hamcrest which give you a more verbose
> breakdown of the difference and answer the question "What exactly is the
> difference between x and y?".
> This is extremely helpful, but it still focuses on the difference between
> the values.
>
> We need to keep in mind that a given state is normally an outcome of a
> series of states, that is, one outcome is a result of multiple conditions
> and causes.
> This is where power assertion comes in. It allows us to better understand
> what led to the failure.
>
> Implementation
>
> I’ve already built a fully functional implementation[2] of this feature as
> part of my Python testing framework - Nimoy[3].
> The current implementation uses AST manipulation to remap the expression
> to a data structure[4] at compile time, so that it can then be evaluated
> and printed[5] at runtime.
>
>
> [1]
> http://docs.groovy-lang.org/next/html/documentation/core-testing-guide.html#_power_assertions
> [2]
> https://browncoat-ninjas.github.io/nimoy/examples/#power-assertions-beta
> [3] https://github.com/browncoat-ninjas/nimoy/
> [4]
> https://github.com/browncoat-ninjas/nimoy/blob/develop/nimoy/ast_tools/expression_transformer.py#L77
> [5]
> https://github.com/browncoat-ninjas/nimoy/blob/develop/nimoy/assertions/power.py
> ___
> Python-ideas mailing list -- python-ideas@python.org
> To unsubscribe send an email to python-ideas-le...@python.org
> https://mail.python.org/mailman3/lists/python-ideas.python.org/
> Message archived at
> https://mail.python.org/archives/list/python-ideas@python.org/message/T26DR4BMPG5EOB3A2ELVEWQPYRENRXHM/
> Code of Conduct: http://python.org/psf/codeofconduct/
>
--
--Guido (mobile)
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at
https://mail.python.org/archives/list/python-ideas@python.org/message/EEVHXKWUMVSEPAR73WOBQM3BO7NESPBZ/
Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Power Assertions: Is it PEP-able?
Hi all,
I’d like your comments and feedback on an enhancement that introduces power
assertions to the Python language.
Proposal
This feature is inspired by a similar feature of the Groovy language[1], and is
effectively a variant of the `assert` keyword.
When an assertion expression evaluates to `False`, the output shows not only
the failure, but also a breakdown of the evaluated expression from the inner
part to the outer part.
For example, a procedure like:
```python
class SomeClass:
def __init__(self):
self.val = {'d': 'e'}
def __str__(self):
return str(self.val)
sc = SomeClass()
assert sc.val['d'] == 'f'
```
Will result in the output:
```python
Assertion failed:
sc.val['d'] == f
| ||
| eFalse
|
{'d': 'e'}
```
See link [2] if the formatting above is screwed up.
In the output above we can see the value of every part of the expression from
left to right, mapped to their expression fragment with the pipe (`|`).
The number of rows that are printed depend on the value of each fragment of the
expression.
If the value of a fragment is longer than the actual fragment (`{'d': 'e'}` is
longer than `sc`), then the next value (`e`) will be printed on a new line
which will appear above.
Values are appended to the same line until it overflows in length to horizontal
position of the next fragment.
The information that’s displayed is dictated by the type.
If the type is a constant value, it will be displayed as is.
If the type implements `__str__`, then the return value of that will be
displayed.
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.
Rational
Every test boils down to the binary statement "Is this true or false?", whether
you use the built-in assert keyword or a more advanced assertion method
provided by a testing framework.
When an assertion fails, the output is binary too — "Expected x, but got y".
There are helpful libraries like Hamcrest which give you a more verbose
breakdown of the difference and answer the question "What exactly is the
difference between x and y?".
This is extremely helpful, but it still focuses on the difference between the
values.
We need to keep in mind that a given state is normally an outcome of a series
of states, that is, one outcome is a result of multiple conditions and causes.
This is where power assertion comes in. It allows us to better understand what
led to the failure.
Implementation
I’ve already built a fully functional implementation[2] of this feature as part
of my Python testing framework - Nimoy[3].
The current implementation uses AST manipulation to remap the expression to a
data structure[4] at compile time, so that it can then be evaluated and
printed[5] at runtime.
[1]
http://docs.groovy-lang.org/next/html/documentation/core-testing-guide.html#_power_assertions
[2] https://browncoat-ninjas.github.io/nimoy/examples/#power-assertions-beta
[3] https://github.com/browncoat-ninjas/nimoy/
[4]
https://github.com/browncoat-ninjas/nimoy/blob/develop/nimoy/ast_tools/expression_transformer.py#L77
[5]
https://github.com/browncoat-ninjas/nimoy/blob/develop/nimoy/assertions/power.py
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at
https://mail.python.org/archives/list/python-ideas@python.org/message/T26DR4BMPG5EOB3A2ELVEWQPYRENRXHM/
Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Add a special TypeError subclass for implementation errors
On Sun, Sep 12, 2021 at 10:49 PM Ram Krishna wrote:
>
> I guess having subclass for implementation errors to distinguish will be very
> helpful, Typeerror has become very generic and finding solution is like
> searching a needle in haystack for the new developers.
>
> Eg- TypeError: ‘int’ object is not iterable
>
> students=int(input('Please enter the number of students in the class: '))
>
> for number in students:
> math_grade=(input("Enter student's Maths grade: "))
> science_grade=(input("Enter student's Science grade: "))
> social_grade=(input("Enter student's Scoial grade: "))
>
> Common homeworks/tutorial for beginners who find difficult to understand why
> this error occurred. So a fine grained exception would be lot easier to
> understand and resolve quickly.
Learning how to debug is part of learning to write software. (Maybe
the biggest part.) Changing the type of that TypeError won't help; the
key is figuring out why you're trying to iterate over an integer. The
exception text is, to new developers, far more important than the
actual type; I'd say that the type only really becomes significant
when you're trying to catch the exception - that is to say, when
exceptions DON'T mean errors.
Also, novice programmers often forget (or fail to notice) that Python
exceptions point you to the exact place where the error happened
(especially in 3.10+); IME pointing someone to the right line of code
is far more valuable than identifying the cause of the error, unless
all of your students are creating the exact same bugs. (And sometimes
even then. Maybe you have an exercise that is specifically designed to
guide someone towards a wrong piece of code, experience a particular
bug, and learn from it.) Most novices that I've taught have gone
straight for the exception message, ignored the type name at the
start, and ignored the line of code. And if I'm completely honest,
I've made that same mistake myself, too - ended up looking in
completely the wrong place...
(The one thing that often trips people up is that, if an exception
points to line X, the bug might be on line X-1, especially if it's a
missed close parenthesis or something. I don't think there's an easy
technical solution to that, but it's something I do have to point out
to people fairly often.)
ChrisA
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at
https://mail.python.org/archives/list/python-ideas@python.org/message/EL7TAOXEGQ2AILGKW5SXY3UR3J4O6EVD/
Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Add a special TypeError subclass for implementation errors
I guess having subclass for implementation errors to distinguish will be very
helpful, Typeerror has become very generic and finding solution is like
searching a needle in haystack for the new developers.
Eg- TypeError: ‘int’ object is not iterable
students=int(input('Please enter the number of students in the class: '))
for number in students:
math_grade=(input("Enter student's Maths grade: "))
science_grade=(input("Enter student's Science grade: "))
social_grade=(input("Enter student's Scoial grade: "))
Common homeworks/tutorial for beginners who find difficult to understand why
this error occurred. So a fine grained exception would be lot easier to
understand and resolve quickly.
*List of TypeErrors* - https://itsmycode.com/tag/typeerror/
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at
https://mail.python.org/archives/list/python-ideas@python.org/message/45JVNSKTEN5HHWAUTWRWZMPF4FWJEFFH/
Code of Conduct: http://python.org/psf/codeofconduct/
