On 07/11/2015 11:35, Ben Finney wrote:
Bartc <b...@freeuk.com> writes:
On 07/11/2015 03:43, Ben Finney wrote:
Bartc <b...@freeuk.com> writes:
Is there no way then in Python to declare:
pi = 3.141519 # etc
and make it impossible to override?
No, and it would be a bad thing if that were something a library author
could forbid.
Python assumes the programmers using it are consenting adults. Doing
harmful things is difficult but not forbidden.
But surely it can't hurt to ensure certain values can't be changed
accidentally or maliciously?
The value ‘3.141519’ (in your example above) can't be changed. That
value will always be exactly the same, as long as the program is
running.
What I think you mean is “surely it can't hurt to ensure certain names
can never be bound to any value but their initial binding”.
On that I strongly disagree, for the reasons already discussed in this
thread: it arrogates to the library author the power to forbid patching
the library, which cripples extending, debugging, introspection, and a
host of other useful activities.
Why would it stop introspection?
If the source is available, why would it stop anyone extending a library?
To my mind, Python allows far too much freedom in being able to change
anything at any time. Imagine if the interfaces to Win32 API or to the
Linux kernel could be turned upside down from one microsecond to the
next, while programs are still running.
Take a simple function like thousands of others:
def dull(x,y,z);
.....
.....
99.9999% of the time, the name 'dull' is not going to be bound to
anything else, and it would just be called like this:
dull(10,20,30)
Yet Python has to assume 100% of the time that it could have been
changed. Think of the opportunities for optimising if the probability
was 0%.
Perhaps if library authors want people tinkering with their code at
runtime, they should mark it as such ('var', 'volatile' etc). Because
most of us are quite happy with a boring, static library that is not
likely to morph into something else!
--
Bartc
--
https://mail.python.org/mailman/listinfo/python-list
