PEP 663 is presented below for your viewing pleasure.
Comments, questions, and concerns are welcome.
PEP: 663
Title: Improving and Standardizing Enum str(), repr(), and format() behaviors
Version: $Revision$
Last-M
Juancarlo A$(D+P(Bez writes:
> assert cond:
> # Write some debugging info to a log.
> ...
> raise ExtType(args)
>
> I like the idea of preparing the arguments for the assertion message in a
> context that gets executed only when the assertion fails.
The mor
On 10/09/2021 23:38, Juancarlo Añez wrote:
Following with the ideas on this thread, it would be possible for -OO
to turn off only assertions with exceptions that descend from
AssertionError.
I think this would be confusing, as contrasted with the simple rule that
-OO turns off assertion
assert cond:
# Write some debugging info to a log.
...
raise ExtType(args)
I like the idea of preparing the arguments for the assertion message in a
context that gets executed only when the assertion fails.
On Thu, Sep 9, 2021 at 7:16 PM MRAB wrote:
> On 2021-09-0
Christopher,
The *if* version has the condition inverted, and it's structure makes it
look as part of the algorithm, instead of an assertion over an invariant.
Following with the ideas on this thread, it would be possible for -OO to
turn off only assertions with exceptions that descend from Asser
On 9/10/21 4:19 AM, matt...@matthewstocks.co.uk wrote:
> My proposal is that iterating through a member of a Flag enum will return all
the constituent members.
It's a good proposal, and is already in 3.11. If you want the functionality
now you can use the aenum [0] library.
--
~Ethan~
[0]
My proposal is that iterating through a member of a Flag enum will return all
the constituent members.
Demonstration Setup:
class FlagEnum(enum.Flag):
A = enum.auto()
B = enum.auto()
C = enum.auto()
FlagCombo = FlagEnum.A | FlagEnum.B
My proposed change would cause the following to
On 10.09.2021 05:49, Steven D'Aprano wrote:
> What I question is that allowing assert to raise non-assertions will
> lead to *more* resilient software rather than less.
>
> I know far too many people who insist on abusing assertions as a lazy
> way to validate caller- or user-supplied data, whic
And 4) DBC constraints also become more useful than standard assertions
when used in the context of a class hierarchy.
I.e. preconditions, postconditions and invariants should be stronger (or
sometimes weaker, IIRC, there are subtle rules related to variance and
contravariance) for subclasses than
On Fri, Sep 10, 2021 at 7:30 AM Steven D'Aprano wrote:
>
> [...] If we are seriously considering DBC for Python, [...]
As I think I wrote in the previous thread about DBC in Python, there are
already several DBC libraries on PyPI and we should precisely evaluate both
their design and impact (e.
10 matches
Mail list logo
