On Thu, Sep 09, 2021 at 09:16:23AM -0700, Guido van Rossum wrote:
> assert cond, raise=ExcType(args)
How about this?
if not cond: raise ExcType(args)
This is 100% backwards compatible, doesn't not abuse `assert`, will not
be removed when running under -O, and takes exactly the same numbe
On Thu, Sep 09, 2021 at 12:53:34PM -0400, Ricky Teachey wrote:
> I have never heard of DBC and don't have a clue what is stands for. I am
> not a pro software developer.
DBC stands for "Design By Contract", it is a methodology for developing
software.
https://en.wikipedia.org/wiki/Design_by_con
On Thu, Sep 09, 2021 at 12:02:13PM -0400, Juancarlo Añez wrote:
> Steven,
>
> The purpose is to make it easier to make software more resilient.
Thank you but I understand the purpose of DBC and how it can be helpful
for writing resilient software. If you search the archives, you will see
that n
On 2021-09-09 22:31, Juancarlo Añez wrote:
Well, if the idea makes sense, then I'm certain that we'll have a very
long and productive discussion about the best syntax here (re: *:=*).
;-)
For backwards compatibility and no surprises:
*assert: *ExType, cond, args
It doesn't break anythi
Hello,
This to thread has gotten no responses at all, so:
Ping!
On Sun, Aug 22, 2021, 3:16 PM Finn Mason wrote:
> Sorry, the formatting was terrible. I copy and pasted it from the original
> issue without really thinking about it.
> Here's the same thing, but actually readable:
>
> In _collecti
Well, if the idea makes sense, then I'm certain that we'll have a very long
and productive discussion about the best syntax here (re: *:=*).
;-)
For backwards compatibility and no surprises:
*assert: *ExType, cond, args
It doesn't break anything, ExtType defaults to AssertionError, and linter
On Thu, Sep 9, 2021 at 12:38 PM Christopher Barker
wrote:
> Take a look at the archives of this list -- there was a large
> conversation about DBC a while back (a year, two years ??? )
>
> I think if you really want to support DBC, there will need to be more
> changes than this -- though there ar
Take a look at the archives of this list -- there was a large
conversation about DBC a while back (a year, two years ??? )
I think if you really want to support DBC, there will need to be more
changes than this -- though there are libraries that support it with
current Python.
Also, let's be clea
Ooh, that’s a nice idea. If the message is an exception instance, raise it
instead of AssertionError. Unfortunately it’s not 100% backwards
compatible. We could address that with the syntax
assert cond, raise=ExcType(args)
Maybe we could deprecate the case
assert cond, ExcType(args)
So that
Let me re-*assert* ;-)
External tests will not be invoked at runtime, yet failures *_will_* occur
at runtime because of a variety of environmental factors (including cosmic
rays).
Software should assert at least some of its preconditions, postconditions,
and invariants.
How can we make that easy
Steven,
The purpose is to make it easier to make software more resilient.
The inspiration was this article that reminded me that software *_will
always fail_*, and also reminded me about all the discussions around DBC
and Eiffel:
https://www.youtube.com/watch?v=AaZ_RSt0KP8
IOW, my premise is t
Hey Chris,
thanks for the response. Right, the metaclass approach should work because then
type(ANY) returns AnyMeta. Still, I find it a bit unintuitive that
`classmethod` does not work and that one needs to either write two classes to
achieve this behaviour, or to create an instance of a class
09.09.21 17:19, Randolf Scholz пише:
> As a sidenote, I think it would actually be kinda cool to have the
> `typing.Any` behave this way, i.e. always comparing to True.
> One example where this would be useful is that it would allow comparisons like
>
> ```python
> assert mytuple == (Any, "abc")
On Fri, Sep 10, 2021 at 12:28 AM Randolf Scholz
wrote:
>
> Hey,
>
> I noticed that writing a class with a classmethod `__eq__`, it does not work
> as expected:
>
> ```python
> class ANY:
> @classmethod
> def __eq__(cls, other):
> return True
>
> assert ANY == 2 # succeeds
> asse
Hey,
I noticed that writing a class with a classmethod `__eq__`, it does not work as
expected:
```python
class ANY:
@classmethod
def __eq__(cls, other):
return True
assert ANY == 2 # succeeds
assert ANY == 2 # fails
```
This is, to my understanding, because `ANY == 2` tra
A typo, it should be:
```
assert ANY() == 2 # succeeds
assert ANY == 2 # fails
```
___
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-ide
Hi Takuo Matsuoka.
Thank you for your interest in the idea of applying keyword unpack
argument assignments at the time of assignment.
Great magic code, you could implement this at the software level.
But again it's not useful unless it's syntactically supported.
Currently in Python even this sy
17 matches
Mail list logo
