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
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
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 ev
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
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
>
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
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
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
> 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
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
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-res
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
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 blo
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 pos
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
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
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 s
> 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
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.
___
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
20 matches
Mail list logo
