If you want X, you know where to find it (was Re: do...until wisdom needed...)

[Alex Martelli]

"Andrew Dalke" <dalke at acm.org> wrote in message
news: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/potential
paraphrasing 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_ towards
that.  How would one forbid, say,
    x = y + y
as the alternative to
    x = y * 2
or
    x = 2 * y
without a LOT of complex rules that force a programmer to put
everything 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 (and
might 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 the
text-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 a
family of functions, classes, methods -- NOT a new syntax
form of a general kind.  For example, there is no way in
C++ that a template could be used to make a new 'unless'
macro that acts "like 'if', but logically negating the
condition".  The semantics of any (e.g.) function that is
defined via a C++ template is still that of a function as
is typical of C++: all arguments are evaluated before the
function code starts, etc.  You COULD define 'unless' in
the C preprocessor, a la
# define unless(condition) if(!(condition))
which is a big part of why today's language designers
such as Stroustrup and Koenig detest the C preprocessor
and dream about making it obsolete someday.

Python's existing functions, classes &c are not all that
dissimilar from C++'s templates, despite acting at
runtime rather than compile-time -- certain traits,
such as signature-based polymorphism, are common, and
in practice some people with high experience of C++
template authoring appear to find the translation to
Python very smooth and painless because of that
commonality.


> 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 distinction
than 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 x
as a synonym of
    if not x > y:
        print x

It would have to be deeper, richer and more complex to allow
full power, of course, i.e., the definition of all kinds of
statements 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.  (I

My POV is very different -- I see many languages presenting
constructs that are preferable to Python's current ones in
certain 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's
beautiful quote about perfection being reached, not when
there is nothing more left to add, but when there is nothing
more 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 list
comprehensions 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 with

The main reason for doing something at compile-time is
indeed performance, but there may be others -- you might
get somewhat-earlier diagnostics of errors (although the
templates experience tells us that the errors that DO
come may be utterly confusing, at least in the first few
years as implementers hone their skills on them), and,
with macros in particular, you might be able to alter the
syntax sugar a lot.  Suppose for example that in your
application area you have a lot of need for loops that
run exactly three times.  Instead of writing:
    for i in range(3):
        whatever(i)
over and over again, with a suitable macro you might
have the ability to write:
    thrice:
        whatever(index)
with a variable 'index' appearing inside the loop body
as if by black magic, etc.  Perhaps instead of waiting
until runtime for an error message if you misspelled
range as ragne, you might be able to get a compile-time
message if you misspelled thrice as trice.  Performance
might 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 to
pay, again in the context of a language whose simplicity
is 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 surely
would -- it's not a features-rich language, its problems
lie 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 developing
his or her own version of Stackless, Alice, etc - there is, in
Python as in most languages, a separation between the system
programmer and the application programmer, though you might
choose to frame it otherwise.  One of Lisp's traditional strengths
is in erasing this distinction, first of all by targeting the
syntax to ease of processing by machine as opposed to ease of
reading or writing by humans; suitable macros clearly _play to
this 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++ .. and

I think that such a multi-language mentality is atypical in
most programming communities, although I see it a lot in
Python (and share it).


Alex