Re: Why assert is not a function?

[Grant Edwards]

On 2021-03-02, Chris Angelico  wrote:
> On Wed, Mar 3, 2021 at 10:22 AM Mirko via 
> Python-list> wrote:
>
>> In production code you don't want any asserts, but logging. Having
>> "assert" being a function would make it much harder to get rid of
>> it in production code.
>
> Really?
>
> if PRODUCTION:
> def assert(*a, **kw): pass
>
> would work if it were a function :)

Wouldn't that still evaluate all of the arguments? You get rid of the
value of the assert, but retain almost all of the cost.

I thought the entire point of asser being a keyword was so that if you
disable asserts then they go away completely: the arguments aren't
even evaluated.

--
Grant



-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Why assert is not a function?

[Terry Reedy]

On 3/1/2021 5:51 PM, Marco Sulla wrote:

I have a curiosity. Python, as many languages, has assert as a
keyword. Can't it be implemented as a function? Is there an advantage
to have it as a keyword?


One does not need to turn the test expression into a function.  One does 
not need to wrap the message expression to delay evaluation.



--
Terry Jan Reedy

--
https://mail.python.org/mailman/listinfo/python-list

Re: editor recommendations?

[Lele Gaifax]

Cameron Simpson  writes:

> My fingers know vim. Some others' fingers know emacs.

Emacs has also an Evil[1] mode, that mimics some vi/vim features.

I suggest taking a look at Doom Emacs[2], a popular so-called "Emacs
distribution", that provides an out-of-the-box great experience with a modular
configuration.

ciao, lele.
[1] https://www.emacswiki.org/emacs/Evil
[2] https://github.com/hlissner/doom-emacs
-- 
Emacs outshines all other editing software in approximately the same
way that the noonday sun does the stars. It is not just bigger and
brighter; it simply makes everything else vanish.  — Neal Stephenson

-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Why assert is not a function?

[Chris Angelico]

On Thu, Mar 4, 2021 at 1:40 AM Grant Edwards  wrote:
>
> On 2021-03-02, Chris Angelico  wrote:
> > On Wed, Mar 3, 2021 at 10:22 AM Mirko via 
> > Python-list> wrote:
> >
> >> In production code you don't want any asserts, but logging. Having
> >> "assert" being a function would make it much harder to get rid of
> >> it in production code.
> >
> > Really?
> >
> > if PRODUCTION:
> > def assert(*a, **kw): pass
> >
> > would work if it were a function :)
>
> Wouldn't that still evaluate all of the arguments? You get rid of the
> value of the assert, but retain almost all of the cost.
>
> I thought the entire point of asser being a keyword was so that if you
> disable asserts then they go away completely: the arguments aren't
> even evaluated.
>

It depends on what the point of "removing the assertions" is, but yes,
that will indeed still evaluate the arguments. IMO the cost of running
assertions isn't that high compared to the value of keeping them
(which is why I never run -O), and the performance argument is a weak
one compared to the much stronger value of having the actual failing
expression available in the exception report.

ChrisA
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Why assert is not a function?

[David Lowry-Duda]

> assert condition, expression
> 
> Only is condition is false with expression be evaluated.
> So you can safely do expensive things I the expression with incuring 
> and cost if the condition is True.

I think I've only every used a string as the expression. Have you found 
it useful to use complicated, expensive expressions? Could you give an 
example?

- DLD
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Why assert is not a function?

[Barry Scott]

> On 3 Mar 2021, at 17:35, David Lowry-Duda  wrote:
> 
>> assert condition, expression
>> 
>> Only is condition is false with expression be evaluated.
>> So you can safely do expensive things I the expression with incuring 
>> and cost if the condition is True.
> 
> I think I've only every used a string as the expression. Have you found 
> it useful to use complicated, expensive expressions? Could you give an 
> example?

In the test suite of the product I work on its common to put a lot of 
information into the expression.
For example if a HTTP request returns unexpected content we will include all 
the headers and
body of the that the request returners.

assert http_status == '200', 'Request failed status %r Body:\n%s' % 
(http_status, http_header_and_body)

Barry


> 
> - DLD
> -- 
> https://mail.python.org/mailman/listinfo/python-list
> 

-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Why assert is not a function?

[Chris Angelico]

On Thu, Mar 4, 2021 at 5:25 AM Barry Scott  wrote:
>
>
>
> > On 3 Mar 2021, at 17:35, David Lowry-Duda  wrote:
> >
> >> assert condition, expression
> >>
> >> Only is condition is false with expression be evaluated.
> >> So you can safely do expensive things I the expression with incuring
> >> and cost if the condition is True.
> >
> > I think I've only every used a string as the expression. Have you found
> > it useful to use complicated, expensive expressions? Could you give an
> > example?
>
> In the test suite of the product I work on its common to put a lot of 
> information into the expression.
> For example if a HTTP request returns unexpected content we will include all 
> the headers and
> body of the that the request returners.
>
> assert http_status == '200', 'Request failed status %r Body:\n%s' % 
> (http_status, http_header_and_body)
>

That doesn't look like the sort of thing that should be an assertion.
Assertions should be for things that, if your code were bug-free,
could never happen.

ChrisA
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Why assert is not a function?

[Barry Scott]

> On 3 Mar 2021, at 18:41, Chris Angelico  wrote:
> 
> On Thu, Mar 4, 2021 at 5:25 AM Barry Scott  > wrote:
>> 
>> 
>> 
>>> On 3 Mar 2021, at 17:35, David Lowry-Duda  wrote:
>>> 
 assert condition, expression
 
 Only is condition is false with expression be evaluated.
 So you can safely do expensive things I the expression with incuring
 and cost if the condition is True.
>>> 
>>> I think I've only every used a string as the expression. Have you found
>>> it useful to use complicated, expensive expressions? Could you give an
>>> example?
>> 
>> In the test suite of the product I work on its common to put a lot of 
>> information into the expression.
>> For example if a HTTP request returns unexpected content we will include all 
>> the headers and
>> body of the that the request returners.
>> 
>>assert http_status == '200', 'Request failed status %r Body:\n%s' % 
>> (http_status, http_header_and_body)
>> 
> 
> That doesn't look like the sort of thing that should be an assertion.
> Assertions should be for things that, if your code were bug-free,
> could never happen.

If the code works the status will be 200 and the test will pass.

Now you can argue that the test suite should use something better then assert,
but assert is what the code that I inherited uses. Its origins go back many many
years. Its would be a lot of work to modernise as there are 1,000s of test 
suites
affect.

Barry


> 
> ChrisA
> -- 
> https://mail.python.org/mailman/listinfo/python-list 
> 
-- 
https://mail.python.org/mailman/listinfo/python-list

a + not b

[Rob Cliffe via Python-list]

I can't work out why
    1 + - 1
    1 + (not 1)
are legal syntax, but
    1 + not 1
isn't.
Is there a good reason for this?
Thanks
Rob Cliffe

--
https://mail.python.org/mailman/listinfo/python-list

RE: a + not b

[Avi Gross via Python-list]

As a guess, Rob, precedence rules for not may not bind as strongly as you think.

1 + (not 1)

With parentheses, "not 1" is a subexpression that should be performed first and 
might return the value "False"

1 + False

treats False in a numeric context as a zero so evaluates to 1.

But

1 + not 1 

Looks a bit ambiguous as "+ " expects something it considers a number or that 
can be converted to a number. Without parentheses, it may try to do 

1 + not

Which gets the same Syntax error.

I looked and operator "not" is evaluated much later than "+" and just before 
"and" and "or" so you need parentheses to force the interpretation you may 
intend. Similarly, some used of "and" require parentheses as do other operators.

-Original Message-
From: Python-list  On 
Behalf Of Rob Cliffe via Python-list
Sent: Wednesday, March 3, 2021 10:19 PM
To: Python 
Subject: a + not b

I can't work out why
 1 + - 1
 1 + (not 1)
are legal syntax, but
 1 + not 1
isn't.
Is there a good reason for this?
Thanks
Rob Cliffe

-- 
https://mail.python.org/mailman/listinfo/python-list

-- 
https://mail.python.org/mailman/listinfo/python-list

Re: a + not b

[MRAB]

On 2021-03-04 03:39, Avi Gross via Python-list wrote:

As a guess, Rob, precedence rules for not may not bind as strongly as you think.

1 + (not 1)

With parentheses, "not 1" is a subexpression that should be performed first and might 
return the value "False"

1 + False

treats False in a numeric context as a zero so evaluates to 1.

But

1 + not 1

Looks a bit ambiguous as "+ " expects something it considers a number or that 
can be converted to a number. Without parentheses, it may try to do

1 + not

Which gets the same Syntax error.

I looked and operator "not" is evaluated much later than "+" and just before "and" and 
"or" so you need parentheses to force the interpretation you may intend. Similarly, some used of "and" 
require parentheses as do other operators.
If you look through the grammar, the relevant bits are:


sum: sum '+' term
term: factor
factor: power
power: await_primary
await_primary: primary
primary: atom

and an 'atom' can be a number, etc, but can never start with "not".

A 'primary' can be an 'atom' and can have a subscript.


-Original Message-
From: Python-list  On 
Behalf Of Rob Cliffe via Python-list
Sent: Wednesday, March 3, 2021 10:19 PM
To: Python 
Subject: a + not b

I can't work out why
  1 + - 1
  1 + (not 1)
are legal syntax, but
  1 + not 1
isn't.
Is there a good reason for this?
Thanks
Rob Cliffe


--
https://mail.python.org/mailman/listinfo/python-list