why cannot assign to function call
daniel.a.esch at gmail.com
Thu Jan 8 15:57:16 CET 2009
Trivially and at a high level,
teaching python to kids who are learning programming as introductory
teaching python to motivated college graduate students
teaching python to adult non-professional programmers with a need to learn
python (like for instance, frustrated accountants who have HAD IT with
The difference between the last 2 is important. I am not now nor will I
ever be a professional programmer; there's a depth of knowledge to the
subject that I will not ever systematically study (mostly due to time
constraints). On the other hand, the problems I want and need to solve, I
want to get right and will put in the effort to learn what I need to get it
right. Contrast the college student. He's getting a broad and hopefully
deep grounding in more CS theory than I have. How much does he care? Well,
the beer bash Friday at 4 probably has a higher priority in his life right
now, not unreasonably.
So you can explain things to me fairly technically (I've done lots of VBA
programming, hated it, and am motivated in self-study in python), but not
too abstractly, because I don't have a deep ground in the theory behind CS
and programming. (What I know of grammar parsing comes via some linguistics
work I did in college, not Backus-Naur Form, although Noam chomsky was
important in both fields)
In contrast, the CS student should get a generalized explanation because he
needs to grow the skills to work it out on his own, and because the
generalized and theoretically grounded explanation is more useful for him in
extrapolating to other areas. If he can't do more with it than i can, he
needs to change majors.
On 1/8/09, Steve Holden <steve at holdenweb.com> wrote:
> Aaron Brady wrote:
> > On Jan 8, 1:45 am, Steven D'Aprano
> > <ste... at REMOVE.THIS.cybersource.com.au> wrote:
> >> On Wed, 07 Jan 2009 10:17:55 +0000, Mark Wooding wrote:
> > snip
> >>> The `they're just objects' model is very simple, but gets tied up in
> >>> knots explaining things. The `it's all references' model is only a
> >>> little more complicated, but explains everything.
> >> But it *over* explains, because it implies things that "everybody knows"
> >> about references in other languages that aren't true for Python.
> >> Of course it's not literally true that "everybody knows" that you can
> >> references to implement a swap(x, y) procedure. But people coming from a
> >> C or Pascal background tend to assume that everything is like C/Pascal,
> >> and there are a lot of them. If C was a rare, unfamiliar language, my
> >> opposition to using the term "reference" would be a lot milder. Maybe in
> >> another five years?
> >>> No, indeed. Python is a language for talking about paperweights. And
> >>> it's because of the paperweights that the duck-typing works: all the
> >>> paperweights are the same shape and size, so they're physically
> >>> interchangeable.
> >> Okay, the abstraction has leaked again... are the paperweights
> >> to the objects, or the names we've bound objects to? I'm confused...
> >> How do we deal with anonymous objects in your model?
> >> --
> >> Steven
> > Mark, hi, Steven, pleasure as always.
> > Neither side is perfect or wild; (Do admit it); How do we decide what
> > is best for newcomers to Python, depending on background?
> The crux of this mistake is assuming that all beginners are alike, and
> that there is therefore a single "best" way to explain things to them.
> Teaching should be a dialog, in which the teacher makes use of knowledge
> revealed by the student about their existing knowledge and ways of
> thinking to present ideas in an easily assimilable form.
> In other words, don't treat all students the same.
> Steve Holden +1 571 484 6266 +1 800 494 3119
> Holden Web LLC http://www.holdenweb.com/
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Python-list