"no variable or argument declarations are necessary."

[Ron Adam]

Antoon Pardon wrote:
> Op 2005-10-03, Steven D'Aprano schreef <steve at REMOVETHIScyber.com.au>:
> 
>>On Mon, 03 Oct 2005 06:59:04 +0000, Antoon Pardon wrote:
>>
>>
>>>Well I'm a bit getting sick of those references to standard idioms.
>>>There are moments those standard idioms don't work, while the
>>>gist of the OP's remark still stands like:
>>>
>>>  egold = 0:
>>>  while egold < 10:
>>>    if test():
>>>      ego1d = egold + 1
>>
>>for item in [x for x in xrange(10) if test()]:
>>
>>But it isn't about the idioms. It is about the trade-offs. Python allows
>>you to do things that you can't do in other languages because you
>>have much more flexibility than is possible with languages that
>>require you to declare variables before using them. The cost is, some
>>tiny subset of possible errors will not be caught by the compiler. But
>>since the compiler can't catch all errors anyway, you need to test for
>>errors and not rely on the compiler. No compiler will catch this error:
>>
>>x = 12.0 # feet
>># three pages of code
>>y = 15.0 # metres
>># three more pages of code
>>distance = x + y
>>if distance < 27:
>>    fire_retro_rockets()
>>
>>And lo, one multi-billion dollar Mars lander starts braking either too
>>early or too late. Result: a new crater on Mars, named after the NASA
>>employee who thought the compiler would catch errors.
> 
> 
> Using (unit)tests will not guarantee that your programs is error free.
> 
> So if sooner or later a (unit)tested program causes a problem, will you
> then argue that we should abondon tests, because tests won't catch
> all errors.

Maybe you need to specify what kind of errors you want to catch. 
Different types of errors require different approaches.

    * Errors that interrupt program execution.

These are Type errors and/or illegal instruction errors such as divide 
by zero.  Try-excepts and checking attributes where these are possible 
to handle them should be used.

    * Human 'user' input errors.

Value testing is what is needed for these.

    * Programming errors...

Nothing will replace testing here.


I think what you want is optional name and object locking in order to 
prevent certain types of errors and increase reliability and dependability.

    Name locking - This will allow you to be able to depend that a 
specific name refers to a specific object.  But that object can still be 
modified if it's mutable.

    Object locking - This would make a non mutable object from a mutable 
object.  A function could work here for lists. This probably isn't 
possible with many complex objects.  Names need to be rebound in many 
objects for them to work.  I think this may be much harder to do than it 
seems.

An example, (but probably not possible to do).

     Const = {}
     Const['pi'] = 3.1415926535897931

         ... add more keys/value pairs ...

     lockobject Const   # prevent object from being changed
     lockname Const     # prevent name 'Const' from being rebound

         ... many pages of code ...

     print Const['pi']      # dependable result?


Is this the type of control you want?
Would it make your programs more dependable or reliable?

Name locking might be implemented with additional name spaces, but they 
would need to be checked prior to other name spaces, so it could slow 
everything down.

And there would probably be ways to unlock objects.  But maybe that's 
not a problem as I think what you want to prevent is erroneous results 
due to unintentional name changes or object changes.

I think both of these would have unexpected side effects in many cases, 
so their use would be limited.

Cheers,
Ron