[this is bytes of an oversized put-all-into-it intervention. A possibly expanded version will be submitted on clp with local followup before a couple days]
Josiah Carlson wrote: [BB] >> I'd say a first step in convincing me I am wrong would be to show me examples of >> object methods of the standard library that are recursive, and cut out for >> recursion. [JC] > Actually, I don't believe that is necessary. I've shown that you would > get better performance with a non-recursive function and passing two > arguments, than you would passing one argument with scoping tricks to > get the second. Assuming my aim was purely performance clearly stretches the hints I gave that I wasn't unconcerned by it. Taking ground on this to unwarrantedly suppose that my methodology was deficient, rectify it, and then dictate the "necessary" conclusions I find... er, preposterous seems balanced, "thought police" not totally unwarranted. What I am doing. After a long while of relaxed ties with the latest Python, and upon observing at http://pythonsudoku.sourceforge.net/, an imo hugely bloated code-base concerned with sudoku, I found it a convenient means to refamiliarize myself with some leading edge Python, to explore the manifold of equivalent programs defined a priori by the invariant constraint : "universal sudoku solver in +-pure python, ~10ms/problem, and ~60 LOCS total". At present I must have examined about 50 versions, some unfinished, some differing only by details you would call "trivial", others massively differing by choice of key data types and modules. And algorithmic details, readability, ease of debugging, obviousness, speed, concision... in brief, differing in beauty as I see it. A minute example that this approach works (given my aims) is that has signification to me, such a leading edge detail as the news that unicode.translate() had been accelerated during the latest 2.5 sprint. While I've not excluded code profiling as a tool to use at some point, I don't think it is adapted at this stage; timeit does what I need, whenever I want to compare speed of versions differing by one factor that usually implies many local changes. As made clear (I hope) speed isn't the primary or unique concern anyway. [...] This said... This said, first : I deny you have or ever had real ground to refuse legitimacy, motivation, efficiency or methodological soundness to my approach. Second : I tell you with good ground that under these (admittedly peculiar, but quite intense) "lighting conditions" the compiler "feature" that's the cause of the present debate stands out like a sore thumb. [JC] >>> Given [...] >>> you are not likely to find me agreeing with you about >>> augmented assignment and/or lexically nested scopes. [BB] >> I see. Thanks for the background. Background for backround, let me just say that >> python hadn't yet grown a lambda when I first played with it. May I read >> your >> last statement as acknowledging that I am not so much asking for a door to >> be >> created, than asking for a naturally builtin door, not to be locked by >> special >> efforts ? [JC] > No, you may not. There are two options for the Python compiler/runtime > behavior when faced with an augmented assignment for a name not yet > known in this particular lexical scope but known in a parent scope: "Special efforts" I maintain. Here they hide in the choice of hypothesis and tensing to artificially exclude from the "use case", what is in fact the most likely situation whenever the compiler/runtime follows to its end the codepath you advocate. Indeed, that situation is almost bound to be the case *if* the resulting error message acurately describes the user's real error *and* the latter is not prey to foolish coding habits (further than the in-your-opinion fatally foolish habit that's assumed by hypothesis : and I guess this explains your bias here, crediting *presumed* fools with more than their share of foolishness - circular thinking). As relates to this "background use case", what I advocate amounts to substituting "reference to unknown global variable" for "local variable referenced before initialization". An error message for another, both bringing attention to the right problem. [JC] > to expect whenever the "compiler/runtime" system > assume you meant the name in the parent scope, or assume you made a > mistake. The current state of affairs (for all released Pythons with > augmented assignment) is to assume that you meant the local scope. Why? > Because while allowing the augmented assignment would make your life > easier in this case, the error would "pass silently" Yeah, this all quite fits what I had anticipated when I spoke of my "deeply felt aversion for whatever resembles a constraining curriculum of errors to make (or else I would program in Java)". But its true I hadn't anticipated the concurrent case of errors one is required to make simultaneously ;) [JC] > when it was an > actual error (a not uncommon case), I guess your insistence on the rightful methodology entitles me to enquire in turn on your choice of tool to establish the relative frequency of said case ? Given that I've shown that it *is* the exceptional case, structurally speaking ! [JC] > which is a bit of a no-no, What I would have believed a /bit/ of a no-no for Python, is to turn away from the "consenting adults" spirit to go the way of so many other programming languages. Picture of the latter way : - As a matter of course, to place the virtue of catching errors early, before the virtue of following programmers' legitimate intentions. - Designing for assumed chronic lusers in need of being protected by the compiler from shooting themselves in the foot. (Ok, this relates to a single marginal "feature", whose closest peer in characteristic is maybe the strange quirks of sum() - a quite distant peer). [JC] > and the > case when you meant the parent scope is easily worked around. Did I ever deny this ? I actually started by showing how the runtime (friendly as opposed to the compiler) taught me a workaround I did not yet know (to the contrary of the flurry of workarounds you've cited since, who knows why) To pythondevers, my concluding message will go thus, in mixed metaphors : beware of not throwing away with the "bathwater" - the cultural intrusion of hordes of Scheme immigrants who take closures for the first word of Creation, the "baby" : an *original* space in Python, well moderated but roomy enough for Python-natives to evolve a python-inspired style in closures with some flesh to it. Which means freedom from the nuisance barkings of an obnoxious javanese watchdog named "Sin". Regards, Boris Borcic -- "On naît tous les mètres du même monde" _______________________________________________ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
