[Edu-sig] Does any such tutorial exist?

[Kirby Urner]

At 10:05 AM 2/9/2003 -0500, Arthur wrote:
> >Of course the more Pythonic way to express this would be:
>
> > >>> reduce(add, [sqr(i) for i in range(5)])
> >30
>
>Not in my book.
>
>The essence of the function passing code could, I thought, be understood -
>at least in outline - on a reading by a non-programmer.
>
>The reduce(add...) business with a list comprehension thrown in - is to me
>obscure, in precisely the way code often seems obscure to the non-coder.

Yes.  You and Tim Peters both wisely counsel against over-use/abuse of these
particular sugars.  Sometimes I find them compact and expressive, but it
should be perfectly ok to write:

    def sum (f, x):
      sum = 0
      for i in range(x):
         sum += f(i)
      return sum

instead of:

    def sum (f, x):
       return reduce(add, [f(i) for i in range(x)] )


>Its would be a pity if "more Pythonic" evolved to mean "the way someone
>versed in Python's obscurities might do it to save some keystokes".

Some just find it more expressive.  The "reduce" concept is found in
other languages, e.g. Mathematica and J, albiet in variant forms.  If
you're coming from one of these backgrounds, then you're happy to find
the grammar you're used to available in Python.  And of course the
list comprehension idea is very familiar to Haskell people.

Japanese is obscure if you don't speak Japanese -- people don't all
approach Python from the same background.  Many come to it from another
programming language.

List comprehensions certainly cut down on the need to use lambda, which
I regard as more unfamiliar to a beginner, although again a useful intro
to languages which make lambda a core concept.

>And precisely why some might feel that list comprehensions, for example, are
>themselves unPythonic - or at least unnecessary.

I agree that they're unnecessary in principle.  But then so is range() --
you could just increment, the way it's done in C.

>reduce(add..) syntax, for whatever reason, never.  Even in Numeric - where
>the reduce(add..) is core - it is generally wrapped into a function with a
>more generically identifiable mathematical meaning.

I think a beginning Python programmer should at least know about the operator
module, and the ability to import add, sub, mul etc. to use in such 
situations.
For example, if you're doing a lot with 3-tuples, as when adding 3d vectors,
it's useful to be able to go:

  >>> a = (1,2,3)
  >>> b = (3,2,1)

  >>> def addtuple(x,y):
          return tuple(map(add,x,y))

  >>> addtuple(a,b)
  (4, 4, 4)

>But it's probably the combination that seems to me to put the one-liner over
>the edge into something too something or other.
>
>But of course reduce(add..) pre-dated list comprehensions.  So my comment is
>not as to the evolution of the language.  Although I would argue that more
>possibilities for obscurities have evolved over time.

The thing about reduce, map and apply is that they take functions as
arguments.  This is characteristic of functional programming.

The thread was "intro to basic Python" and I was suggesting that both the
OOP paradigm, and the functional paradigm, as well as the more classic
procedural paradigm, all intersect in Python, and it's worthwhile to not
just seize on the procedural alone.

One should "get in on the ground floor" with OOP and functional concepts as
well.  Primitives which take functions as arguments, like map, reduce and 
apply,
are good examples of functional concepts.

I think there's a danger in having people most comfortable with procedural
programming inadvertently depriving newbies from accessing alternative
philosophies that are just as basic in their own way.

>The importance of readibility of code is accepted, I think, as a Pythonic
>principle.  Perhaps I define it too broadly by hoping it to mean readable,
>in some sense - and to the extent reasonable and realistic - as text to the
>eyes of the non-coder.
>
>But even if unrealistically broad, it is probably one way to think of
>achieving readability even when coding Python in a real world situation.
>A worthy but unattainable goal - that at least keeps one moving in the right
>direction.
>
>I do go on, don't I.
>
>Art

I think an intro course that focuses on basics might do well to actually
spend some time on these broad brush stroke concepts:  procedural, functional
and object oriented, using Python examples to illustrate what's meant.

At least for me, it helps to have this higher level heuristics floating
around -- gives me more of a frame of reference for the new material.
I like historical context.

Kirby