Movatterモバイル変換
[0]ホーム
If you want X, you know where to find it (was Re: do...until wisdom needed...)
Alex Martellialeaxit at yahoo.com
Wed Apr 18 09:33:57 EDT 2001
"Andrew Dalke" <dalke at acm.org> wrote in messagenews:9bir7a$5vo$1 at slb3.atl.mindspring.net...> Alex Martelli wrote:> >> "There should be ONE 'obviously correct' way to do it" is one of the> >> Python mantras>> Douglas Alan responded:> >This is a BAD mantra. Not as bad as the Perl mantra, "There should be> >3294369 ways to do it", but extremes are rarely ideal. "The truth lies> >somewhere in the middle.">> Huh? His mantra isn't an extreme.Not mine -- I think Tim Peters authored it (emphasis/quoting/potentialparaphrasing mine, as I was quoting from memory).> "There must be only one way> to do it" is an extreme. That is, pure orthogonality is an extreme.Yep. I do not believe any programming language even _aims_ towardsthat. How would one forbid, say, x = y + yas the alternative to x = y * 2or x = 2 * ywithout a LOT of complex rules that force a programmer to puteverything into some kind of 'normal form'?Whence the "should" rather than "must", etc.> Saying there "should be one 'obviously correct' way" means there> could be other obviously correct ways as well as non-obvious ways,> but those designs aren't Pythonic.In practice, even with 'should' etc, it remains a _design ideal_,as I went on to say.> >Besides, there are many uses for procedural macros other than for> >providing trivial syntactic sugars that are best done by using the> >sugar already provided.>> You all are going to have to explain things to me. My physics> degree never told me what "procedural macros", "hygenic macros",The "hygienic" part has to do with namespace separation (andmight in fact be redundant in a powerful-enough base language,or so a Common Lisp expert tells me in private correspondence).It's sometimes informally used to distinguish them from thetext-transformation kinds of macros that the C preprocessor has.> etc. mean. My best guess is they are transformations which act> on parse trees before finalizing the parsing, vaguely like what> templates do for C++ (which my physics degree did tell me about).Sort of, but more. A C++ template only lets you define afamily of functions, classes, methods -- NOT a new syntaxform of a general kind. For example, there is no way inC++ that a template could be used to make a new 'unless'macro that acts "like 'if', but logically negating thecondition". The semantics of any (e.g.) function that isdefined via a C++ template is still that of a function asis typical of C++: all arguments are evaluated before thefunction code starts, etc. You COULD define 'unless' inthe C preprocessor, a la# define unless(condition) if(!(condition))which is a big part of why today's language designerssuch as Stroustrup and Koenig detest the C preprocessorand dream about making it obsolete someday.Python's existing functions, classes &c are not all thatdissimilar from C++'s templates, despite acting atruntime rather than compile-time -- certain traits,such as signature-based polymorphism, are common, andin practice some people with high experience of C++template authoring appear to find the translation toPython very smooth and painless because of thatcommonality.> If that's the case then I can see how they would be useful,> because one nice thing about templates is to allow A = B + n * C> to be implemented element-wise for matricies without producing> intermediates.That's more about the compile-time vs run-time distinctionthan it is about templates.> But every time I look to see how templates work I sigh in> relief that someone else has done the hard work. C++ aside,> could you present an example of how these might be used in> Python?Very hypothetically and superficially, for example:macrodef unless(condition): expand_to: if not condition:and then you could use unless x > y: print xas a synonym of if not x > y: print xIt would have to be deeper, richer and more complex to allowfull power, of course, i.e., the definition of all kinds ofstatements with multiple clauses including optional ones, &c.> I'm finding it hard to conceive of significantly> better ways to write code than what Python has already. (IMy POV is very different -- I see many languages presentingconstructs that are preferable to Python's current ones incertain cases. If all the constructs were Pythonized, though,the simplicity of the language would be utterly destroyed.So, it seems to me to be a case (once again) of St. Exupery'sbeautiful quote about perfection being reached, not whenthere is nothing more left to add, but when there is nothingmore left to take away.> don't see list comprehensions or string method as all that> significant.)I disagree with you on this -- i.e., I see both listcomprehensions and string methods as great things.> By example I mean how it might look written in Python, not> how it is done in Lisp, Scheme, Dylan or other language not> used by computational physicists/chemists/biologists.I thought Lisp did have a significant user base in biology?http://www.franz.com/products/allegrocl/acl-bioinformatics/and all that?> Mind you also that justifications based on performance (as> with my element-wise addition) don't have much weight withThe main reason for doing something at compile-time isindeed performance, but there may be others -- you mightget somewhat-earlier diagnostics of errors (although thetemplates experience tells us that the errors that DOcome may be utterly confusing, at least in the first fewyears as implementers hone their skills on them), and,with macros in particular, you might be able to alter thesyntax sugar a lot. Suppose for example that in yourapplication area you have a lot of need for loops thatrun exactly three times. Instead of writing: for i in range(3): whatever(i)over and over again, with a suitable macro you mighthave the ability to write: thrice: whatever(index)with a variable 'index' appearing inside the loop bodyas if by black magic, etc. Perhaps instead of waitinguntil runtime for an error message if you misspelledrange as ragne, you might be able to get a compile-timemessage if you misspelled thrice as trice. Performancemight not be a very significant factor here, maybe.I consider the advantages scarce in a Python context,and the complexity increase far too high a price topay, again in the context of a language whose simplicityis an important point.> me. For that I rewrite in C. My main, number one concern> is to have a programming language where both software> developers and life scientists (medicinal chemists,> biophysicists, structual biologists, etc.) can use it and> enjoy using it. I would need to be convinced that someone> whose programming training is a semester of FORTRAN and> a couple of years of shell scripting can learn how 90% of> the features in a language works without having to get any> special training beyond help from coworkers and books.I doubt many languages would meet this specification.Python surely does. Maybe Sather, Tcl, Rexx. C surelywould -- it's not a features-rich language, its problemslie elsewhere (very low-level: makes for fast code, *BUT*hampers programmer productivity, maintainability, ...).> >See Guy Steele, "Growing a Language":> >> >>http://cm.bell-labs.com/cm/cs/who/wadler/gj/Documents/steele-oopsla98.pdf> >> >"We need to put tools for language growth in the hands of the users">> That tools is the C (or Java) implementation, no? Otherwise growth> into forms like Stackless and Alice never would have taken place.I think the point is that not _every_ Python user is developinghis or her own version of Stackless, Alice, etc - there is, inPython as in most languages, a separation between the systemprogrammer and the application programmer, though you mightchoose to frame it otherwise. One of Lisp's traditional strengthsis in erasing this distinction, first of all by targeting thesyntax to ease of processing by machine as opposed to ease ofreading or writing by humans; suitable macros clearly _play tothis strength_. Python's slant, of course, is different.> I use Python because I don't think one language provides everything.> So really I don't use Python, I use Python and C/C++ .. andI think that such a multi-language mentality is atypical inmost programming communities, although I see it a lot inPython (and share it).Alex
More information about the Python-listmailing list
[8]ページ先頭