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 -- https://mail.python.org/mailman/listinfo/python-list