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. 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]
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.
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 ;-)
- Jan
Roman