Sorry to bring up the old assert syntax issue; I wanted to clarify it
before explaining to someone.
For: assert expr, message_expr
It seems to be left at:
1. The assert statement is left unchanged in 3.0.
2. Asserting a tuple now creates a _compile time_ warning to try to
prevent assert(expr,message_expr).
3. "assert expr, message_expr" is roughly equivalent to "if (expr):
raise AssertionError(message_expr)"
4. The "as" keyword ("assert expr as message") was decided against
because it did not appear as the
message renamed the expression. Counter argument was that it did
rename expr to message_expr as
original expr was lost.
5. assert cannot be a function call, because message_expr is not
evaluated unless expr is false.
6. There was some wish for assert to have a function call for ease of
debuggers, that is, "if (expr): raise_assert(message_expr)". No one
was too interested.
Did I miss anything? I like problems to have accurate final solutions.
Thanks for the time,
Charles
On Thu, Apr 24, 2008 at 9:13 PM, Nick Coghlan <[EMAIL PROTECTED]> wrote:
> Charles Merriam wrote:
>>
>> On Thu, Apr 24, 2008 at 2:01 PM, Guido van Rossum <[EMAIL PROTECTED]>
>> wrote:
>>>
>>> On Thu, Apr 24, 2008 at 1:51 PM, Mikhail Glushenkov
>>>>
>>>> Why not make ``assert`` a built-in function then?
>>>
>>> Because then it can't be disabled by the compiler in -O mode.
>>
>> A reasonable conclusion, but needs better reasoning. One could
>> certainly do an:
>> assert_stmt ::= "assert" (expression ["," expression])
>> and implement it, when there isn't a -O, as:
>> __assert__(expression, message=None) # built-in
>
> Hmm, having an __assert__ builtin might be nice regardless - easier to have
> assertions in test suites that are executed regardless of -0, instead of
> every different Python test suite having to include its own function to wrap
> 'raise AssertionError(message)'.
>
> Independently of that, changing assert to allow surrounding parentheses
> (similar to the name list in a from module import name-list style import
> statement) would also be convenient for longer expressions or error
> messages.
>
> Cheers,
> Nick.
>
> --
> Nick Coghlan | [EMAIL PROTECTED] | Brisbane, Australia
> ---------------------------------------------------------------
> http://www.boredomandlaziness.org
>
_______________________________________________
Python-3000 mailing list
Python-3000@python.org
http://mail.python.org/mailman/listinfo/python-3000
Unsubscribe:
http://mail.python.org/mailman/options/python-3000/archive%40mail-archive.com
