On Tue, Apr 7, 2009 06:25PM, Guido van Rossum wrote:
Well I'm sorry Cesare but this is unacceptable. As Skip points out there is plenty of code that relies on this.
Guido, as I already said, in the final code the normal Python behaviour will be kept, and the stricter one will be enabled solely due to a flag set by the user.
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
In my experience it's better to discover a bug at compile time rather than at running time. Cesare
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/)