On Tue, 30 Jan 2007 20:29:34 +0100, Roman Susi <rnd@onego.ru> wrote:
Jan Kanis wrote:
On Mon, 29 Jan 2007 08:38:39 +0100, Roman Susi <rnd@onego.ru> wrote:
This is what incremental dynamic semantics is about. So, the suggestion is good only as separated feature, but is IMHO wrong if considered in the language design as a whole.
wtf is incremental dynamic semantics, in this context? I did some googling but all I found referred to techniques related to programming environments. This proposal is just about a change in the language.
Oh, I thought this is very fundamental and well-known as it is the second line of Guido's definition of Python:
"Python is an interpreted, object-oriented, high-level programming language with dynamic semantics. ..."
As I understand it, it means that statements are read sequencially and the semantics of names depends on the flow control.
I never made a link with this description of python and the term 'incremental dynamic semantics'. Guess I learned something new today.
The proposal (as it seems to me) wants to make change to the language inconsistent with nature dynamic semantics. Its like put implicit:
if RUN_FIRST_TIME: do this else: do that
for the same line of code (def statement's first line).
[snip]
I'm certainly no proponent of doing something like this. Do note that the discussion is between evaluating default expressions at definition time or at call time, and the pep entails evaluating default expressions on /every/ function call, just like the body of the function is evaluated on every call. There's already other code being evaluated at both def time and call time, so the proposal does not introduce anything new to pythons evaluation model. IMO having the default exprs evaluate at call time is in no way against pythons language design.
Well, it's good to be clear on where the disagreements lie. However I'm not yet ready to let it rest at that without some more arguments.
As Chris pointed out in his first mail, this 'wart' is mentioned on several lists of python misfeatures: [0][1][2]. I'd like to add to this that even the python documentation finds this issue severe enough to issue an "Important warning"[4].
It seems clear that this behaviour is a gotcha, at least for newbies. This could be excused if there is a good reason to spend the additional time learning this behaviour, but some of the links state, and my
But as somebody already said the alternative is even worse... Its quite easier to mention 3-5 Python warts up front to newbies than to introduce subtle exception for semantics and noise words such as "new" which do not have any other use elsewhere.
But it's much better to just eliminate the warts without introducing subtle exceptions. The pep proposes evaluating default exprs on every function call, just like the function body is. No new exceptions are introduced. The fact that newbies often expect default values to be fresh on every call seems to entail that they won't be surprised a lot when the idiom of using default values as caches won't work, if the pep gets accepted. Old time pythoneers who know what's new in 3.0 won't be surprised either. I'm not in favour of introducing new noise words or other new syntax, I just want to 'fix' pythons current semantics.
assumption is, that there are very few situations where re-evaluating causes a problem and which isn't easily fixable. The semantics which I'd like to have are even easier than the current semantics: everything in a function, be it before or after the colon, is executed when the function is called. Of course, as Collin Winters pointed out, the burden of proof of showing that these semantics aren't going to be a problem is still on the pep proponents.
So, are there any _other_ arguments in favour of the current semantics??
Repeat the mantra:
Python's dynamic semantics will not change Python's dynamic semantics will not change Python's dynamic semantics will not change
;-)
If anything, the proposal is going to _improve_ pythons dynamicness and late-bindingness. Oh, and it's nice to know repeating mantras now count as 'arguments' <wink> - Jan