Well I'm sorry Cesare but this is unacceptable. As Skip points out there is plenty of code that relies on this. Also, consider what "problem" you are trying to solve here. What is the benefit to the user of moving this error to compile time? I cannot see any. --Guido On Tue, Apr 7, 2009 at 8:19 AM, Cesare Di Mauro <cesare.dimauro@a-tono.com> wrote:
In data 07 aprile 2009 alle ore 17:19:25, <skip@pobox.com> ha scritto:
Cesare> The only difference at this time is regards invalid operations, Cesare> which will raise exceptions at compile time, not at running Cesare> time.
Cesare> So if you write:
Cesare> a = 1 / 0
Cesare> an exception will be raised at compile time.
I think I have to call *bzzzzt* here. This is a common technique used during debugging. Insert a 1/0 to force an exception (possibly causing the running program to drop into pdb). I think you have to leave that in.
Skip
Many tests rely on this, and I have changed them from something like:
try: 1 / 0 except: ....
to
try: a = 1; a / 0 except: ....
But I know that it's a major source of incompatibilities, and in the final code I'll enabled it only if user demanded it (through a flag).
Cesare _______________________________________________ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/guido%40python.org
-- --Guido van Rossum (home page: http://www.python.org/~guido/)