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. On Sat, 27 Jan 2007 06:30:00 +0100, Josiah Carlson <jcarlson@uci.edu> wrote:
"Jan Kanis" <jan.kanis@phil.uu.nl> wrote:
I hope we agree that the problem we're trying to solve is that while [snip] I'm going to have to disagree on the 'non-intuitive and ugly' claim. We are just going to have to agree to disagree.
On Mon, 29 Jan 2007 08:38:39 +0100, Roman Susi <rnd@onego.ru> wrote:
Hello!
I'd liked to say outright that this bad idea which complicates matters more than provides solutions. Right now it is enough to know that the part from def to ":" is executed at definition time.
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 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. On the other hand, are there really any good reasons to choose the current semantics of evaluation at definition time? What I've heard basically boils down to two arguments: - "let's not change anything", i.e. resist change because it is change, which I don't think is a very pythonic argument. - Arguments based on the assumption that people actually do make lots of use of the fact that default arguments are shared between function invocations, many of which will result in (much) more code if it has to be transformed to using one of the alternative idioms. If this is true, it is a valid argument. I guess there's still some stdlib grepping to do to decide this. So, are there any _other_ arguments in favour of the current semantics?? - Jan [0] 10 Python pitfalls (http://zephyrfalcon.org/labs/python_pitfalls.html) [1] Python Gotchas (http://www.ferg.org/projects/python_gotchas.html#contents_item_6) [2] When Pythons Attack (http://www.onlamp.com/pub/a/python/2004/02/05/learn_python.html?page=2) [4] Python manual - 4. More control flow tools (http://docs.python.org/tut/node6.html#SECTION006710000000000000000)