[Tutor] Volunteer teacher

avi.e.gross at gmail.com avi.e.gross at gmail.com
Mon Jul 25 15:58:26 EDT 2022


Alan,

I can't say the FIRST thing I look at in a language is OOP. LOL!

I stopped counting languages long ago and many did not have anything like
OOP then, albeit some may have aspects of it now, if they are still being
used.

What I look at depends on my needs and how it is being learned. I consider
life to be the accumulation of lots of little tricks and techniques that
often allow you to use them to solve many kinds of problems, often in
association with others. In my UNIX days back at Bell labs, (and still in
many places like LINUX distributions) there actually were sets of tools
ranging from echo and cat to cut and sed and grep and awk that could be
combined in pipelines to do all kinds of rapid prototyping and, if it became
commonly used and important, might be rewritten in more  than one-liners in
C or awk or PERL or whatever.

There are many levels of mental tools you can use including some that try to
guess which of many tools may be best suited (in combination with others) to
get a task done. Smart people are often not so much more gifted overall than
those who strive to learn and master some simple tools and find ways to
combine them in a semi-optimal way to get jobs done. They do not always have
to re-invent the wheel!

So when I start a new language, I start by getting a feel for the language
so I can compare and contrast it with others and see if there are some
purposes it is designed for and some it is very much NOT designed for and a
royal pain. If so, I look to see if add-ons help.

If you look at Python, it has some glaring gaps as they considered
heterogeneous lists to be the most abstract and neglected to make something
basic in other languages like an array/vector. Hence, many people just load
numpy and perhaps pandas and go on from there and suddenly python is
friendly for doing things with objects like dataframes that depend on
columns having a uniform nature. Perhaps amusingly is how a language like R
where a data.frame was a strictly-enforced list of vectors, now allows list
columns as well since allowing varied content can sometimes be useful.
Languages start with certain premises but some evolve.

I do not know why people say python is simple. Compared to what? It may well
be that the core has some simplicity but nothing that supports so many ways
of programming as well as many ways of doing similar things, can be simple.
Not even debatable. It may be that the deliberate use of indentation rather
than braces, for grouping, makes it look simpler. I think the opposite and
my own code in other languages has lots of such indentation deliberately
along with braces and other such structures. Not because it is required, but
because I like to see trends at a glance. Copying code from one place to
another is trivial and will work without reformatting, albeit tools in
editors easily can reformat it. On the other hand, copying python code can
be a mess and a source of error if you copy it to a region of different
indentation and things dangle.

So back to first appearances, I look for themes and differences. Does the
language require something special such as a semicolon to terminate an
instruction, or a colon to denote the beginning of a body of text. What are
the meanings of symbols I use elsewhere and are they different. Think of how
many differences there are in how some languages use single and double
quotes (Python uses them interchangeably and in triples) or what characters
may need to be escaped when used differently. I look at issues of scope
which vary widely. And I look for idioms, often highly compressed notation
like x //= 10 and so on.

But overall, there is a kernel in which most languages seem almost identical
except for pesky details. Or are they? Yes, everything has an IF statement,
often followed by an ELSE (upper case just for emphasis) but some use an
ELIF and others an ELSE IF and some provide alternatives like some kind of
CASE or SWITCH statement with variations  or ternary operations like ?:  or
operations designed to apply vectorized like ifelse(condition, this, that)
and so on. Lots of creative minds have come up with so many variations. You
can get looked at strangely if you end up programming in very basic tiny
steps using literal translations from your days writing in BASIC until you
get stuck with how to translate GOSUB, LOL!

In my opinion, to teach OOP using Python in a single class is an exercise in
what NOT to teach. Yes, inside an object you create there may lurk recursive
method calls or functional programming constructs or who knows what cute
method. All you care about is the damn object sorts the contents when asked
to or when it feels like it.

Do hey need to know why or how the following works?

a_sorted = [a.pop(a.index(min(a))) for _ in range(len(a))]

Or this quicksort one liner:

q = lambda l: q([x for x in l[1:] if x <= l[0]]) + [l[0]] + q([x for x in l
if x > l[0]]) if l else []

Since the above can easily be done like this more understandable way:

def quicksort(my_list):
    # recursion base case - empty list
    if not my_list:
        return []
    # first element is pivot
    pivot = my_list[0]
    # break up problem
    smaller = [x for x in my_list[1:] if x < pivot]
    greater = [x for x in my_list[1:] if x >= pivot]
    # recursively solve problem and recombine solutions
    return quicksort(smaller) + [pivot] + quicksort(greater)

The goal is to let them study more python on their own when they feel like
it but focus in on OOP in general, unless that is not the full purpose of
the course.

I actually enjoy courses at times that are heterogeneous and show dozens of
ways to solve a particular problem using lots of sides of a language. This
forum often gets a question answered many different ways. But a focused
course is best not pushed off the track. After all, a major focus on OOP is
to hide how it is done and to allow existing objects to change how they do
it as long as the outside view is the same. As an example, an object could
re-sort every time an item is added or perhaps changed or deleted, but it
could also NOT do that but mark the fact that the data is not currently
sorted, and any attempt to use the data would notice that and sort it before
handing back anything. In some cases, the latter approach may be more
efficient. But the user rarely knows or cares what happens as long as it
happens as expected from the outside of a black box.


-----Original Message-----
From: Tutor <tutor-bounces+avi.e.gross=gmail.com at python.org> On Behalf Of
Alan Gauld via Tutor
Sent: Sunday, July 24, 2022 9:15 AM
To: tutor at python.org
Subject: Re: [Tutor] Volunteer teacher

On 24/07/2022 02:23, avi.e.gross at gmail.com wrote:
> Dumb Question.
> 
> Every damn language I have done so-called object-oriented programming 
> in DOES IT DIFFERENT.

Of course, because OOP is not a language feature. Languages implement tools
to facilitate OOP. And each language designer will have different ideas
about which features of OOP need support and how best to provide that. In
some it will be by classes, in others actors, in others prototyping. Some
will try to make OOP look like existing procedural code where others will
create a special syntax specifically for objects.

> If you had a book on generic object-oriented techniques and then saw 
> Python or R or JAVA and others, what would their experience be?

That's what happens every time I meet a new language. I look to see how that
language implements the concepts of OOP.

> And I thing things do not always exist in a vacuum. Even when writing 
> a program that uses OO I also use functional methods, recursion and 
> anything else I feel like. Just learning OO may leave them stranded in
Python!

OOP doesn't preclude these other programming techniques.
OOP is a design idiom that allows for any style of lower level coding. (What
is more difficult is taking a high level functional design and introducing
OOP into that - those two things don't blend well at all!)

I've also never succeeded in doing OOP in Prolog.
Maybe somebody has done it, but it beats me! I've also never felt quite
comfortable shoe-horning objects into SQL despite the alleged support for
the OOP concepts of some database systems/vendors...

--
Alan G
Author of the Learn to Program web site
http://www.alan-g.me.uk/
http://www.amazon.com/author/alan_gauld
Follow my photo-blog on Flickr at:
http://www.flickr.com/photos/alangauldphotos


_______________________________________________
Tutor maillist  -  Tutor at python.org
To unsubscribe or change subscription options:
https://mail.python.org/mailman/listinfo/tutor



More information about the Tutor mailing list