Supply condition in function call

[Steven D'Aprano]

By the way, you're not alone in recognising that Python 3 may be a little
harder to teach to beginners than Python 2. Raymond Hettinger, one of the
most respected Pythonistas around, has pointed out the same thing.

More below.


On Sat, 28 Mar 2015 12:48 am, Rustom Mody wrote:

> On Friday, March 27, 2015 at 10:05:21 AM UTC+5:30, Steven D'Aprano wrote:
>> On Fri, 27 Mar 2015 01:21 pm, Rustom Mody wrote:
>> 
>> > Anyway my point is that in python (after 2.2??) saying something is an
>> > object is a bit of a tautology -- ie verbiage without information.
>> 
>> 
>> Er, it's *always* been a tautology. Every value in Python is an object,
>> including classes, and that has been always the case.
>> 
>> However, just because it's a tautology doesn't mean it isn't useful to
>> know. (Tautologies are also known as *facts* and knowing facts is usually
>> a good thing.) For the majority of programming languages, it is not the
>> case that all values are objects, and not all people reading the
>> documentation should be expected to know that this applies to Python.
> 
> I am making a point of pedagogy not semantics.

I'm also making a point of pedagogy. You cannot possibly understand Python
without understanding the words Python programmers use to discuss Python
code, and that includes "object", a word with multiple meanings.

How can you talk about teaching people to use filter without discussing the
semantics of filter? What are you teaching them then, the way the word
looks when written down using calligraphy?

Any meaningful discussion about pedagogy cannot avoid semantics. You cannot
teach people about filter without expressing what filter is and does and
what sort of thing it returns. This is all semantics. In my opinion, once
somebody is reduced to dismissing an argument as "that's just semantics",
they've already lost, they just don't know it.


> This is help(filter) for python 2 and 3.
> 
> Python2:
> Help on built-in function filter in module __builtin__:
> 
> filter(...)
>     filter(function or None, sequence) -> list, tuple, or string
>     
>     Return those items of sequence for which function(item) is true.  If
>     function is None, return the items that are true.  If sequence is a
>     tuple or string, return the same type, else return a list.


Right. filter is Python 2 is a function, and it returns a list, tuple or
string.


> Python 3
> Help on class filter in module builtins:
> 
> class filter(object)
>  |  filter(function or None, iterable) --> filter object
>  |  
>  |  Return an iterator yielding those items of iterable for which
>  |  function(item) is true. If function is None, return the items that are
>  |  true.

Right. filter in Python 3 is a class (a.k.a. a type). Calling a type
normally returns an instance of that type, in this case a "filter object"
in the same way that calling str(x) returns a str object or list(x) returns
a list object.

Are we learning yet? :-)

filter is *more powerful* in Python 3, because it is no longer eager. It is
lazy, and returns an iterator. What sort of iterator? A *filter instance*.
We have to call it something, and Python wouldn't be improved if filter was
a function which returned a "pimwit instance". That helps neither beginners
nor experts.



>  |  Methods defined here:

This is the usual guff that help() prints when you pass it a class or type.
Occasionally it is useful. Often it is not, especially the dunder methods.

Unfortunately help's UI is rather primitive. It would be nice if it provided
a menu of commands whereby you could hide/show dunders (hidden by default,
perhaps), but that's an order of magnitude more complexity. It might make a
nice third-party tool though.



> Try and put yourself in the place of a noob:
> 
> Knows some C, not much else.

Why C? Why not somebody who knows Java and not much else, or PHP, or Ruby,
or no other programming language at all? People can come to Python from all
sorts of backgrounds. C is not and never has been a prerequisite for
learning Python. Not every programmer, or programming beginner, knows C.

Coming to Python from C is possibly the worst place to start from. Coming
from another OOP language like Ruby or Java is better, since the basic
concepts will be more familiar, although you will have to unlearn many of
the idioms and details. Having no preconceptions is even better.

Instead of a C programmer, how about a Scheme or Lisp programmer reading
help(filter) in Python 2:

"I know what Python lists, tuples and strings are, this sounds just like the
filter I know from Scheme. Easy! By the way, why is there no car and cdr
function for processing lists?"

The point being that preconceptions often need to be unlearned. If the C
programmer needs to learn what an object is, the Scheme programmer needs to
unlearn what a list is. Should we therefore decide that Python's use of the
word "list" is harmful?

(I'm hoping that you will agree that it is not, but if you wish to debate
it, I'm game.)

It's 2015, not 1990, and our imaginary student would have to have been
especially isolated to have experience in programming and yet not have any
idea of what "object" means. OOP has been the dominant programming paradigm
for a quarter of a century, anyone with even a modicum of exposure to
programming should have some concept of objects. Even C programmers will
have heard of the term, even if they think of it as a fancy word for a
struct with some fields being pointers-to-functions.



> Starts studying python.
> Good until a point.
> Then suddenly hit... map, filter, and the worst of all lambda.
> More he reads less he understands.
> Tries help... Gets the above.
> 
> So which do you think helps him more python 2 or 3?

That depends. 

You're glossing over an awful lot. Where precisely is this "point" they
reach? Have they learned what lists and tuples are yet? If not, then the
Python 2 docs will give them no insight. "What's a list?"

Have they learned what an object is, and understand about iterators and lazy
processing? If so, then the Python 3 docs will give them no pause. "Ah,
filter is a type, and its instances are iterators. Simple."

Obviously there are degrees of knowledge between those two points on the
learning curve[1], and for *some* of those degrees a beginner will find the
Python 2 version of filter easier to understand than the Python 3 version.
Oh well. That's the usual trade-off between power and simplicity.

It seems to me that your complaint about the filter docs in Python 3 is
based on the supposition that filter should be learned *early* in the
process, presumably after list but before iterators and the idea of lazy
processing. But why should filter (and map) be necessarily more fundamental
than lazy processing? Why not teach them the other way around?

Although Python is intended to be easy to learn, it is not intended to be a
purely pedagogical language. It is meant to be a practical language, and
that may mean including features which are hard to teach but useful, like
first-class functions, iterators, coroutines, asynchronous processing,
exceptions, and so forth. Trading off some simplicity for power is a good
thing.




[1] "The" learning curve would imply that there is one and only one order in
which people can learn Python concepts, which is nonsense of course. But we
can fairly assume that *most* people will learn about lists and strings
before they learn about iterators.


-- 
Steven