On 22/11/2015 03:43, Steven D'Aprano wrote:
On Fri, 20 Nov 2015 10:59 pm, BartC wrote:
On 20/11/2015 01:05, Steven D'Aprano wrote:
Here's another use for function defaults, as static storage:
[...]
This is a quick and easy way to memoise a function which would otherwise
be horribly slow. And it only works because _memo is bound to a mutable
object once, and once only.
We're arguing at cross-purposes then since you are obviously interested
in these esoteric aspects,
Memoisation isn't "esoteric", it is a simple, basic and widely-used
technique used to improve performance of otherwise expensive functions.
Ackermann is esoteric and so is memoisation, or at least the term is.
(I use the Ackermann function frequently, but usually as a benchmark
measuring how good a language implementation is at function calls,
especially recursive ones. And how well it copes with large recursion
depth. Adding memoisation would defeat the purpose!)
But if it's used for static storage, then why not just use static
storage? That's a simpler and more general concept than memoisation.
If Python's 'default values' are just a device for obtaining local
static storage which are otherwise not possible, then why not use
terminology to say so? As I guess it's too late to do anything about the
syntax.
(Of course it won't be quite the same, as the caller can overwrite the
local and /private/ 'static' variables at any time, but I suppose that
would be yet another feature!)
Quite frankly, to call it such demonstrates a considerable level of
ignorance about basic programming idioms. Not just Python, but general
purpose programming.
I've come to learn that basic idioms are best. Especially trying to
understand someone else's code (or to translate into another language
with a different set of advanced features). Some people delight in
pulling out all the stops and using all the advanced features of a
language to the hilt. With the result being very concise and clever
code, but completely unreadable.
(Here, however, the language doesn't like you doing in-place
modification of a parameter unless the '&' is used,
It sounds to me like you have implemented something like Pascal's "var"
parameters, is that right? I believe some languages (VB perhaps?) call
them "output parameters".
(Something like that. Python seems to exclusively to push around
references to objects. I use a mix of value objects and part-references.
The & is an indication to use full references. I can also use actual
pointers, but I'm trying to get away from that.)
OK, so the "=" is misleading if not a lie.
No. Why would you conclude that? If I called the function like so:
test( [1, 2, 3, 4, 5] )
and got the result 6, would I conclude that the "=" is misleading if not a
lie? After all, the function declaration clearly shows arg being assigned
the value [], so why am I getting 6 as the result instead of 1?
That's being silly. We all know this is default value syntax. The lie is
the [] not necessarily being the default value on every call.
The whole point of parameter default arguments is that they are bound to the
parameter *only* if the parameter otherwise isn't given a value. That's a
separate issue from *when* the default expression is evaluated.
No, that is at the heart of matter. And it's not just a question of
'when' the 'binding' is done, but the fact that, even if we accept that
the default value is evaluated when the function is defined, that value
can then subsequently change.
We all know now /why/ it can do so, which is an unfortunate consequence
of how it's implemented. But you seem very keen to show it in a positive
light. It's a feature, not a bug!
In my language, a construct such as [10,20,30] is evaluated just once at
start-up.
I don't understand that explanation. How does that work? Given:
x = [10, 20, 30]
y = [10, 20, 30]
how does your language know what value y has if it doesn't evaluate the
second construct?
(It generates some start-up code which assigns [10,20,30] to a variable.
Then that variable is used in place of that particular [10,20,30]. (It
doesn't combine multiple instances of the same constant list, as that is
not common. So y would be dealt with separately.)
I think Python already does something along these lines for tuples,
which cannot change. It means you're executing a simple LOAD instead of
BUILT_LIST on N values.)
--
Bartc
--
https://mail.python.org/mailman/listinfo/python-list
