I'm looking for questions to put on a test for students who never had
any experience with programming, but have learned to use Python's
procedures, default arguments, if-else, strings, tuples, lists and
dictionaries. (There's no OOP at all in this course. Students don't
even write ls.append(...). They write list.append(ls, ...)).

I'd like to put questions that they would have to write procedures that
would would be real-world type of stuff, without error checking,
exceptions and such. So if you think of something more or less cool
that uses loops, we can sometimes simplify it by assuming the input has
a certain fixed size.

I came up with the following question. Using strings of length 5
(always), write a procedure histogram(s) that consumes a string and
produces a dictionary whose keys are each substrings (of the string) of
length 1 and their corresponding values are the number of times each
such substrings appear. For example, histogram("aaaaa") = {"a": 5}.
Students can "loop through" the string by writing out s[0], s[1], s[2],
s[3], s[4].

I'd like even better questions. I'd like questions that would tell them
to write procedures that would also have inverses, so that one could
check the other of the other. (A second question would ask for the
inverse, but hopefully real world stuff. One such question could be
parsing a line separate by fields such as "root:0:0:mypass:Super User"
and another that gives them ["root", 0, 0, ...] and asks them to write
"root:0:0:mypass:..." You get the idea.)

Students know how to use str(). But they don't know how to use type(),
so they can't really check for the type of the input. I probably
couldn't ask them to write a prototype of a tiny subset of pickle, say.

I think you get the idea. I hope you can provide me with creativity. I
have been looking at books, but every one I look at they introduce loops
very quickly and off they go. Thank you!

On Tue, Aug 10, 2021 at 7:25 AM Hope Rouselle <hrouselle@jevedi.xotimo> wrote:
> I came up with the following question. Using strings of length 5
> (always), write a procedure histogram(s) that consumes a string and
> produces a dictionary whose keys are each substrings (of the string) of
> length 1 and their corresponding values are the number of times each
> such substrings appear. For example, histogram("aaaaa") = {"a": 5}.
> Students can "loop through" the string by writing out s[0], s[1], s[2],
> s[3], s[4].

In other words, recreate collections.Counter? Seems decent, but you'll
need to decide whether you want them to use defaultdict, use
__missing__, or do it all manually.

> I think you get the idea. I hope you can provide me with creativity. I
> have been looking at books, but every one I look at they introduce loops
> very quickly and off they go. Thank you!

Probably because loops are kinda important? :)

ChrisA

On 8/9/21 3:07 PM, Hope Rouselle wrote:
> I'm looking for questions to put on a test for students who never had
> any experience with programming, but have learned to use Python's
> procedures, default arguments, if-else, strings, tuples, lists and
> dictionaries. (There's no OOP at all in this course. Students don't
> even write ls.append(...). They write list.append(ls, ...)).

Nitpickery... there *is* OOP in the course, they just don't know it.

Long long ago (over 20 yrs now) I developed a Python course for a
commercial training provider, and in it I claimed one of the great
things about Python was it supported all kinds of object oriented
programming techniques, but you could also use it without doing anything
object oriented. If I wrote a course now, I'd never make that claim,
because everything you do in Python is pretty much object oriented.

>>> x = list()
>>> type(x)
<class 'list'>
>>> dir(x)
['__add__', '__class__', '__class_getitem__', '__contains__',
'__delattr__', '__delitem__', '__dir__', '__doc__', '__eq__',
'__format__', '__ge__', '__getattribute__', '__getitem__', '__gt__',
'__hash__', '__iadd__', '__imul__', '__init__', '__init_subclass__',
'__iter__', '__le__', '__len__', '
__lt__', '__mul__', '__ne__', '__new__', '__reduce__', '__reduce_ex__',
'__repr__', '__reversed__', '__rmul__', '__setattr__', '__setitem__',
'__sizeof__', '__str__', '__subclasshook__', 'append', 'clear', 'copy',
'count', 'extend', 'index', 'insert', 'pop', 'remove', 'reverse', 'sort']

list is a class and it has methods... it's "object-oriented"!

Even if you do

x = 2 + 3

you're actually creating an integer object with a value of 2, and
calling its add method to add the integer object with the value of 3 to
it. The syntax hides it, but in a way it's just convenience that it does
so...

>>> 2 + 3
5 >>> x = 2
>>> x.__add__(3)
5

sorry for nitpicking :) But... don't be afraid of letting them know
it's OOP, and it''s not huge and complex and scary!

On Tue, Aug 10, 2021 at 8:19 AM Mats Wichmann <mats@wichmann.us> wrote:
> Even if you do
>
> x = 2 + 3
>
> you're actually creating an integer object with a value of 2, and
> calling its add method to add the integer object with the value of 3 to
> it. The syntax hides it, but in a way it's just convenience that it does
> so...
>
> >>> 2 + 3
> 5
> >>> x = 2
> >>> x.__add__(3)
> 5
>
>
> sorry for nitpicking :) But... don't be afraid of letting them know
> it's OOP, and it''s not huge and complex and scary!
>

Since we're nitpicking already, "2 + 3" isn't the same as
"(2).__add__(3)"; among other things, it's able to call
(3).__radd__(2) instead. Plus there's technicalities about type slots
and such.

If you want to highlight the OOP nature of Python, rather than looking
at magic methods, I'd first look at polymorphism. You can add a pair
of integers; you can add a pair of tuples; you can add a pair of
strings. Each one logically adds two things together and gives a
result, and they're all spelled the exact same way. Dunder methods are
a way for custom classes to slot into that same polymorphism, but the
polymorphism exists first and the dunders come later.

ChrisA

On 8/9/21 6:34 PM, Chris Angelico wrote:

> If you want to highlight the OOP nature of Python, rather than looking
> at magic methods, I'd first look at polymorphism. You can add a pair
> of integers; you can add a pair of tuples; you can add a pair of
> strings. Each one logically adds two things together and gives a
> result, and they're all spelled the exact same way. Dunder methods are
> a way for custom classes to slot into that same polymorphism, but the
> polymorphism exists first and the dunders come later.
>
> ChrisA
>

not disagreeing... and yeah I could have thought deeper about the
answer, but I still think "notthing has been OOP" -> "yes it has, they
just didn't realize it" was worth mentioning

On Tue, Aug 10, 2021 at 1:41 PM Mats Wichmann <mats@wichmann.us> wrote:
>
>
> On 8/9/21 6:34 PM, Chris Angelico wrote:
>
> > If you want to highlight the OOP nature of Python, rather than looking
> > at magic methods, I'd first look at polymorphism. You can add a pair
> > of integers; you can add a pair of tuples; you can add a pair of
> > strings. Each one logically adds two things together and gives a
> > result, and they're all spelled the exact same way. Dunder methods are
> > a way for custom classes to slot into that same polymorphism, but the
> > polymorphism exists first and the dunders come later.
> >
> > ChrisA
> >
>
> not disagreeing... and yeah I could have thought deeper about the
> answer, but I still think "notthing has been OOP" -> "yes it has, they
> just didn't realize it" was worth mentioning

Oh yes, absolutely agree.

ChrisA

Chris Angelico <rosuav@gmail.com> writes:

> On Tue, Aug 10, 2021 at 7:25 AM Hope Rouselle <hrouselle@jevedi.xotimo> wrote:
>> I came up with the following question. Using strings of length 5
>> (always), write a procedure histogram(s) that consumes a string and
>> produces a dictionary whose keys are each substrings (of the string) of
>> length 1 and their corresponding values are the number of times each
>> such substrings appear. For example, histogram("aaaaa") = {"a": 5}.
>> Students can "loop through" the string by writing out s[0], s[1], s[2],
>> s[3], s[4].
>
> In other words, recreate collections.Counter? Seems decent, but you'll
> need to decide whether you want them to use defaultdict, use
> __missing__, or do it all manually.

Yes, the course introduces very little so there is a lot of recreation
going on. Hm, I don't know defaultdict and I don't know how to use
__missing__. The course does introduce dict.get(), though. If students
use dict.get(), then the procedure could essentially be:

def histogram(s):
d = {}
d[s[0]] = d.get(s[0], 0) + 1
d[s[1]] = d.get(s[1], 0) + 1
d[s[2]] = d.get(s[2], 0) + 1
d[s[3]] = d.get(s[3], 0) + 1
d[s[4]] = d.get(s[4], 0) + 1
return d

>> I think you get the idea. I hope you can provide me with creativity. I
>> have been looking at books, but every one I look at they introduce loops
>> very quickly and off they go. Thank you!
>
> Probably because loops are kinda important? :)

Totally important. But each course author thinks they know better.
Sometimes a college professor can do very little to help her students.
I am actually fond of functional programming as a first course using a
language with as little syntax as possible. Python is very nice but
it's not a small language. It's easy to see courses spending an entire
semester on introducing syntax and this one is no different. I think
it's more interesting to see all the syntax in a few minutes and spend
the semester on strategies.

Mats Wichmann <mats@wichmann.us> writes:

> On 8/9/21 3:07 PM, Hope Rouselle wrote:
>> I'm looking for questions to put on a test for students who never had
>> any experience with programming, but have learned to use Python's
>> procedures, default arguments, if-else, strings, tuples, lists and
>> dictionaries. (There's no OOP at all in this course. Students don't
>> even write ls.append(...). They write list.append(ls, ...)).
>
> Nitpickery... there *is* OOP in the course, they just don't know it.
>
> Long long ago (over 20 yrs now) I developed a Python course for a
> commercial training provider, and in it I claimed one of the great
> things about Python was it supported all kinds of object oriented
> programming techniques, but you could also use it without doing
> anything object oriented. If I wrote a course now, I'd never make that
> claim, because everything you do in Python is pretty much object
> oriented.
>
>>>> x = list()
>>>> type(x)
> <class 'list'>
>>>> dir(x)
> ['__add__', '__class__', '__class_getitem__', '__contains__',
> '__delattr__', '__delitem__', '__dir__', '__doc__', '__eq__',
> '__format__', '__ge__', '__getattribute__', '__getitem__', '__gt__',
> '__hash__', '__iadd__', '__imul__', '__init__', '__init_subclass__',
> '__iter__', '__le__', '__len__', '
> __lt__', '__mul__', '__ne__', '__new__', '__reduce__',
> '__reduce_ex__', '__repr__', '__reversed__', '__rmul__',
> '__setattr__', '__setitem__', '__sizeof__', '__str__',
> '__subclasshook__', 'append', 'clear', 'copy', 'count', 'extend',
> 'index', 'insert', 'pop', 'remove', 'reverse', 'sort']
>
> list is a class and it has methods... it's "object-oriented"!
>
>
> Even if you do
>
> x = 2 + 3
>
> you're actually creating an integer object with a value of 2, and
> calling its add method to add the integer object with the value of 3
> to it. The syntax hides it, but in a way it's just convenience that it
> does so...
>
>>>> 2 + 3
> 5
>>>> x = 2
>>>> x.__add__(3)
> 5
>
>
> sorry for nitpicking :) But... don't be afraid of letting them know
> it's OOP, and it''s not huge and complex and scary!

I totally agree with you but I didn't know that even numbers were like
that in Python. In fact, I still don't quite believe it...

>>> 2.__add__(3)
SyntaxError: invalid syntax

But then I tried:

>>> (2).__add__(3)
5

Now I do believe it! :-) Awesome. I had no idea.

(*) More opinions

So, yeah, the idea of a course like that is to try to simplify the world
to students, but it totally backfires in my opinion. There is so much
syntax to learn, so many little details... We spend the entire semester
discussing these little details.

I posted here recently a study of the semantics of slices. When I
finally got it, I concluded it's not very simple. The course introduces
a few examples and expects students to get it all from these examples.
I would rather not introduce slices but teach students enough to write
procedures that give them the slices. The slices are the fish; learning
to write the procedures is the know-how. (I'm fine with even teaching
them how to write procedures to add or subtract numbers [and the rest of
arithmetic], although none of them would find mysterious what is the
meaning of arithmetic expressions such as 3 + 6 - 9, even taking
precedence of operators into account. That's syntax they already know.
If we teach them the syntax of procedures, we could be essentially done
with syntax.)

Chris Angelico <rosuav@gmail.com> writes:

[...]

>> not disagreeing... and yeah I could have thought deeper about the
>> answer, but I still think "notthing has been OOP" -> "yes it has, they
>> just didn't realize it" was worth mentioning
>
> Oh yes, absolutely agree.

At the same time, inside the machine nothing is OOP --- so all the OOP
is no OOP at all and they just didn't realize it? This seems to show
that OOP is about perspective. An essential thing for OOP is the
keeping of states. Closures can keep state, so having procedures as
first-class values allows us to say we are doing OOP too. (Arguments of
procedures are messages and function application is message passing,
with closures keeping a state --- and all the rest of OOP can be
implemented with enough such functional technology.) In summary, OOP
should not be defined as some special syntax, otherwise there is no OOP
in ``2 + 2''.

Having said that, I totally agree with all the nitpicking.

Hope Rouselle <hrouselle@jevedi.xotimo> writes:
>I posted here recently a study of the semantics of slices. When I
>finally got it, I concluded it's not very simple.

On December 10, 2017 I posted a procedure "sl" here that
yields (I hope) the same slice values from a sequence
"sequence" as the inbuilt slices.

def wrap( x, length ):
if x < 0: x += length
return x

def clip( x, length, is_negative ):
if x > length - is_negative: x = length - is_negative
if x < 0: x = -is_negative
return x

def clipandwrap( x, length, is_negative ):
x = wrap( x, length )
x = clip( x, length, is_negative )
return x

def sl( sequence, start, top, step ):
is_negative = +( step <= 0 )
clipwrap = lambda var: clipandwrap( var, len( sequence ), is_negative )
start = clipwrap( start )
top = clipwrap( top )
i = start
while i > top if is_negative else i < top:
yield sequence[ i ]
i += step

On Wed, Aug 11, 2021 at 4:14 AM Hope Rouselle <hrouselle@jevedi.xotimo> wrote:
>
> Chris Angelico <rosuav@gmail.com> writes:
>
> > On Tue, Aug 10, 2021 at 7:25 AM Hope Rouselle <hrouselle@jevedi.xotimo> wrote:
> >> I came up with the following question. Using strings of length 5
> >> (always), write a procedure histogram(s) that consumes a string and
> >> produces a dictionary whose keys are each substrings (of the string) of
> >> length 1 and their corresponding values are the number of times each
> >> such substrings appear. For example, histogram("aaaaa") = {"a": 5}.
> >> Students can "loop through" the string by writing out s[0], s[1], s[2],
> >> s[3], s[4].
> >
> > In other words, recreate collections.Counter? Seems decent, but you'll
> > need to decide whether you want them to use defaultdict, use
> > __missing__, or do it all manually.
>
> Yes, the course introduces very little so there is a lot of recreation
> going on. Hm, I don't know defaultdict and I don't know how to use
> __missing__. The course does introduce dict.get(), though. If students
> use dict.get(), then the procedure could essentially be:
>
> def histogram(s):
> d = {}
> d[s[0]] = d.get(s[0], 0) + 1
> d[s[1]] = d.get(s[1], 0) + 1
> d[s[2]] = d.get(s[2], 0) + 1
> d[s[3]] = d.get(s[3], 0) + 1
> d[s[4]] = d.get(s[4], 0) + 1
> return d

There's nothing wrong with getting students to recreate things, but
there are so many different levels on which you could do this, which
will leave your more advanced students wondering what's legal. :) Here
are several ways to do the same thing:

>>> s = "hello world"

>>> from collections import Counter; Counter(s)
Counter({'l': 3, 'o': 2, 'h': 1, 'e': 1, ' ': 1, 'w': 1, 'r': 1, 'd': 1})

>>> from collections import defaultdict
>>> hist = defaultdict(int)
>>> for ltr in s: hist[ltr] += 1
....
>>> hist
defaultdict(<class 'int'>, {'h': 1, 'e': 1, 'l': 3, 'o': 2, ' ': 1,
'w': 1, 'r': 1, 'd': 1})

>>> class Incrementer(dict):
.... def __missing__(self, key): return 0
....
>>> hist = Incrementer()
>>> for ltr in s: hist[ltr] += 1
....
>>> hist
{'h': 1, 'e': 1, 'l': 3, 'o': 2, ' ': 1, 'w': 1, 'r': 1, 'd': 1}

>>> hist = {}
>>> for ltr in s: hist[ltr] = hist.get(ltr, 0) + 1
....
>>> hist
{'h': 1, 'e': 1, 'l': 3, 'o': 2, ' ': 1, 'w': 1, 'r': 1, 'd': 1}

>>> hist = {}
>>> for ltr in s:
.... if ltr in hist: hist[ltr] += 1
.... else: hist[ltr] = 1
....
>>> hist
{'h': 1, 'e': 1, 'l': 3, 'o': 2, ' ': 1, 'w': 1, 'r': 1, 'd': 1}

>>> hist = {}
>>> for ltr in s:
.... try: hist[ltr] += 1
.... except KeyError: hist[ltr] = 1
....
>>> hist
{'h': 1, 'e': 1, 'l': 3, 'o': 2, ' ': 1, 'w': 1, 'r': 1, 'd': 1}

A Counter shows the values ranked, all the others retain insertion
order, but they all get to the same result.

It seems *very* strange to have an exercise like this without looping.
That seems counterproductive. But if you're expecting them to not use
loops, you'll want to also be very clear about what other features
they're allowed to use - or alternatively, stipulate what they ARE
allowed to use, eg "Use only indexing and the get() method".

ChrisA

On Wed, Aug 11, 2021 at 4:18 AM Hope Rouselle <hrouselle@jevedi.xotimo> wrote:
>
> I totally agree with you but I didn't know that even numbers were like
> that in Python. In fact, I still don't quite believe it...
>
> >>> 2.__add__(3)
> SyntaxError: invalid syntax

Yeah, that's because "2." looks like the beginning of a float.

> But then I tried:
>
> >>> (2).__add__(3)
> 5
>
> Now I do believe it! :-) Awesome. I had no idea.

You can also do it this way:

>>> x = 2
>>> x.__add__(3)
5

But don't teach this; it ignores several problems. Notably, a subclass
should be able to (re)define operators:

>>> class FancyNumber(int):
.... def __repr__(self): return "FancyNumber(%d)" % self
.... def __add__(self, other): return type(self)(int(self) + other)
.... def __radd__(self, other): return type(self)(other + int(self))
....
>>> FancyNumber(2) + 3
FancyNumber(5)
>>> 2 + FancyNumber(3)
FancyNumber(5)
>>> FancyNumber(2).__add__(3)
FancyNumber(5)
>>> (2).__add__(FancyNumber(3))
5

With the + operator, you always get a FancyNumber back. Explicitly
calling the dunder method fails. (General principle: Dunder methods
are for defining, not for calling, unless you're in the process of
defining a dunder.)

> (*) More opinions
>
> So, yeah, the idea of a course like that is to try to simplify the world
> to students, but it totally backfires in my opinion. There is so much
> syntax to learn, so many little details... We spend the entire semester
> discussing these little details.

Agreed, and if you try to teach all the syntax, you're inevitably
going to get bogged down like that.

> I posted here recently a study of the semantics of slices. When I
> finally got it, I concluded it's not very simple. The course introduces
> a few examples and expects students to get it all from these examples.
> I would rather not introduce slices but teach students enough to write
> procedures that give them the slices. The slices are the fish; learning
> to write the procedures is the know-how. (I'm fine with even teaching
> them how to write procedures to add or subtract numbers [and the rest of
> arithmetic], although none of them would find mysterious what is the
> meaning of arithmetic expressions such as 3 + 6 - 9, even taking
> precedence of operators into account. That's syntax they already know.
> If we teach them the syntax of procedures, we could be essentially done
> with syntax.)

A language like Python is useful, not because every tiny part of it is
easy to explain, but because the language *as a whole* does what is
expected of it. Toy languages are a lot easier to explain on a
concrete level (look up Brainf*ck - it has very few operations and
each one can be very simply defined), and that might be tempting in
terms of "hey, we can teach the entire language in ten minutes", but
they're utterly useless for students.

Instead, my recommendation would be: Entice students with power.
Pretend you're teaching some aspect of magic at a wizards' school and
make sure your students feel massively OP. Sure, they might not
understand what makes those cantrips work, but they know that they DO
work. You can have students casting print calls left and right, doing
complex incantations with list comprehensions, and even defining their
own classes, all without ever worrying about the details of how it all
works. Then once the "wow" is achieved, you can delve into the details
of how things actually function, transforming progressively from
"wizardry" to "science".

And to be quite frank, a lot of code IS magic to most programmers.
Which isn't a problem. Do you REALLY need to understand how your CPU
does register renaming in order to benefit from it? Or do you need to
know every detail of the TCP packet header before using the internet?
Not likely. Those details hide away under the covers, and we make
happy use of them. There's infinite knowledge out there, and you - and
your students - are free to dip into exactly as much as you're
comfortable with.

ChrisA

On Wed, Aug 11, 2021 at 4:18 AM Hope Rouselle <hrouselle@jevedi.xotimo> wrote:
>
> Chris Angelico <rosuav@gmail.com> writes:
>
> [...]
>
> >> not disagreeing... and yeah I could have thought deeper about the
> >> answer, but I still think "notthing has been OOP" -> "yes it has, they
> >> just didn't realize it" was worth mentioning
> >
> > Oh yes, absolutely agree.
>
> At the same time, inside the machine nothing is OOP --- so all the OOP
> is no OOP at all and they just didn't realize it? This seems to show
> that OOP is about perspective. An essential thing for OOP is the
> keeping of states. Closures can keep state, so having procedures as
> first-class values allows us to say we are doing OOP too. (Arguments of
> procedures are messages and function application is message passing,
> with closures keeping a state --- and all the rest of OOP can be
> implemented with enough such functional technology.) In summary, OOP
> should not be defined as some special syntax, otherwise there is no OOP
> in ``2 + 2''.
>
> Having said that, I totally agree with all the nitpicking.

Object orientation is a particular abstraction concept. It's not a
feature of the machine, it's a feature of the language that you write
your source code in. I've done OOP using IDL and CORBA, writing my
code in C and able to subclass someone else's code that might have
been written in some other language. [1] Central tenets of OOP
(polymorphism, inheritance, etc) can be implemented at a lower level
using whatever makes sense, but *at the level that you're writing*,
they exist, and are useful.

Data types, variables, control flow, these are all abstractions. But
they're such useful abstractions that we prefer to think that way in
our code. So, *to us*, those are features of our code. To the
computer, of course, they're just text that gets processed into
actually-executable code, but that's not a problem.

So I would say that (in Python) there IS object orientation in "2 +
2", and even in the Python C API, there is object orientation, despite
C not normally being considered an object-oriented language.

ChrisA

[1] And boy oh boy was that good fun. The OS/2 Presentation Manager
had a wealth of power available. Good times, sad that's history now.

On 8/10/2021 9:15 AM, Hope Rouselle wrote:
>>>> 2.__add__(3)
> SyntaxError: invalid syntax
>
> But then I tried:
>
>>>> (2).__add__(3)
> 5

Add a space is easier.
>>> 2 .__add__(3)
5 >>>

--
Terry Jan Reedy

Chris Angelico <rosuav@gmail.com> writes:

> On Wed, Aug 11, 2021 at 4:14 AM Hope Rouselle <hrouselle@jevedi.xotimo> wrote:
>>
>> Chris Angelico <rosuav@gmail.com> writes:
>>
>> > On Tue, Aug 10, 2021 at 7:25 AM Hope Rouselle
>> > <hrouselle@jevedi.xotimo> wrote:
>> >> I came up with the following question. Using strings of length 5
>> >> (always), write a procedure histogram(s) that consumes a string and
>> >> produces a dictionary whose keys are each substrings (of the string) of
>> >> length 1 and their corresponding values are the number of times each
>> >> such substrings appear. For example, histogram("aaaaa") = {"a": 5}.
>> >> Students can "loop through" the string by writing out s[0], s[1], s[2],
>> >> s[3], s[4].
>> >
>> > In other words, recreate collections.Counter? Seems decent, but you'll
>> > need to decide whether you want them to use defaultdict, use
>> > __missing__, or do it all manually.
>>
>> Yes, the course introduces very little so there is a lot of recreation
>> going on. Hm, I don't know defaultdict and I don't know how to use
>> __missing__. The course does introduce dict.get(), though. If students
>> use dict.get(), then the procedure could essentially be:
>>
>> def histogram(s):
>> d = {}
>> d[s[0]] = d.get(s[0], 0) + 1
>> d[s[1]] = d.get(s[1], 0) + 1
>> d[s[2]] = d.get(s[2], 0) + 1
>> d[s[3]] = d.get(s[3], 0) + 1
>> d[s[4]] = d.get(s[4], 0) + 1
>> return d
>
> There's nothing wrong with getting students to recreate things, but
> there are so many different levels on which you could do this, which
> will leave your more advanced students wondering what's legal. :) Here
> are several ways to do the same thing:

[... very impressive set of solutions...]

> It seems *very* strange to have an exercise like this without looping.

It is. I agree.

> That seems counterproductive.

It is.

> But if you're expecting them to not use loops, you'll want to also be
> very clear about what other features they're allowed to use - or
> alternatively, stipulate what they ARE allowed to use, eg "Use only
> indexing and the get() method".

Yes, I will do that. I mean the course does that all the time. They
cannot use anything that has not been introduced. That's another
problem because the course introduces various things and students can't
quite keep everything in mind. The suggestion to make up a list of
things is mostly ignored by nearly all of them. :-)

Terry Reedy <tjreedy@udel.edu> writes:

> On 8/10/2021 9:15 AM, Hope Rouselle wrote:
>>>>> 2.__add__(3)
>> SyntaxError: invalid syntax
>> But then I tried:
>>
>>>>> (2).__add__(3)
>> 5
>
> Add a space is easier.
>>>> 2 .__add__(3)
> 5
>>>>

Hah. That's brilliant! So cool.

On 8/10/2021 5:27 PM, Hope Rouselle wrote:
> Terry Reedy <tjreedy@udel.edu> writes:
>
>> On 8/10/2021 9:15 AM, Hope Rouselle wrote:
>>>>>> 2.__add__(3)
>>> SyntaxError: invalid syntax
>>> But then I tried:
>>>
>>>>>> (2).__add__(3)
>>> 5
>>
>> Add a space is easier.
>>>>> 2 .__add__(3)
>> 5
>>>>>
>
> Hah. That's brilliant! So cool.

Python is a little looser about whitespace than one might expect from
reading 'normal' code when the result is unambiguous in that it cannot
really mean anything other than what it does. Two other examples:

>>> if3: print('yes!')
yes!
>>> [0] [0]
0

--
Terry Jan Reedy

On 11/08/21 3:22 pm, Terry Reedy wrote:
> Python is a little looser about whitespace than one might expect from
> reading 'normal' code when the result is unambiguous in that it cannot
> really mean anything other than what it does.
>
> >>> if3: print('yes!')
> yes!

That may not be doing what you think it's doing. Consider also

>>> if0: print('yes!')
yes!

--
Greg

Terry Reedy <tjreedy@udel.edu> writes:

> On 8/10/2021 5:27 PM, Hope Rouselle wrote:
>> Terry Reedy <tjreedy@udel.edu> writes:
>>
>>> On 8/10/2021 9:15 AM, Hope Rouselle wrote:
>>>>>>> 2.__add__(3)
>>>> SyntaxError: invalid syntax
>>>> But then I tried:
>>>>
>>>>>>> (2).__add__(3)
>>>> 5
>>>
>>> Add a space is easier.
>>>>>> 2 .__add__(3)
>>> 5
>>>>>>
>> Hah. That's brilliant! So cool.
>
> Python is a little looser about whitespace than one might expect from
> reading 'normal' code when the result is unambiguous in that it cannot
> really mean anything other than what it does. Two other examples:
>
>>>> if3: print('yes!')
> yes!

That's cool to know too, but I would have expected that. Programming
languages tend to ignore whitespace as much as possible. (But someone
followed-up with more details... I'll get there.) But the next one...

>>>> [0] [0]
> 0

Oh! This almost fooled me. It's just a list containing the integer
zero followed by the index-operator (or however the brackets are called
in this case.)

At first I thought maybe there was an implicit operator between lists
just like it happens with strings.

>>> "a" "," "b"
'a,b'

But which operator would it be? It wasn't concatenation, of course. So
I looked at what type() thought of it. Then I tried changing numbers:

>>> [1] [1]
Traceback (most recent call last):
File "<pyshell#13>", line 1, in <module>
[1] [1]
IndexError: list index out of range

And that's when it hit me. :-) Thanks!

Greg Ewing <greg.ewing@canterbury.ac.nz> writes:

> On 11/08/21 3:22 pm, Terry Reedy wrote:
>> Python is a little looser about whitespace than one might expect
>> from reading 'normal' code when the result is unambiguous in that it
>> cannot really mean anything other than what it does.
>> >>> if3: print('yes!')
>> yes!
>
> That may not be doing what you think it's doing. Consider also
>
>>>> if0: print('yes!')
> yes!

So, yes, that's puzzling.

>>> 0 == False
True
>>> if0: print("yes")
yes
>>> if(0): print("yes")

>>>

What's going on there?

Chris Angelico <rosuav@gmail.com> writes:

> On Wed, Aug 11, 2021 at 4:18 AM Hope Rouselle <hrouselle@jevedi.xotimo> wrote:
>>
>> I totally agree with you but I didn't know that even numbers were like
>> that in Python. In fact, I still don't quite believe it...
>>
>> >>> 2.__add__(3)
>> SyntaxError: invalid syntax
>
> Yeah, that's because "2." looks like the beginning of a float.
>
>> But then I tried:
>>
>> >>> (2).__add__(3)
>> 5
>>
>> Now I do believe it! :-) Awesome. I had no idea.
>
> You can also do it this way:
>
>>>> x = 2
>>>> x.__add__(3)
> 5
>
> But don't teach this; it ignores several problems.

I wouldn't. This is all Python-stuff. The course chooses a language
like Python, but it is not trying to teach Python --- it is trying to
teach computer programming, that is, strategies in high-precision.

[...]

>> (*) More opinions
>>
>> So, yeah, the idea of a course like that is to try to simplify the world
>> to students, but it totally backfires in my opinion. There is so much
>> syntax to learn, so many little details... We spend the entire semester
>> discussing these little details.
>
> Agreed, and if you try to teach all the syntax, you're inevitably
> going to get bogged down like that.

Indeed.

>> I posted here recently a study of the semantics of slices. When I
>> finally got it, I concluded it's not very simple. The course introduces
>> a few examples and expects students to get it all from these examples.
>> I would rather not introduce slices but teach students enough to write
>> procedures that give them the slices. The slices are the fish; learning
>> to write the procedures is the know-how. (I'm fine with even teaching
>> them how to write procedures to add or subtract numbers [and the rest of
>> arithmetic], although none of them would find mysterious what is the
>> meaning of arithmetic expressions such as 3 + 6 - 9, even taking
>> precedence of operators into account. That's syntax they already know.
>> If we teach them the syntax of procedures, we could be essentially done
>> with syntax.)
>
> A language like Python is useful, not because every tiny part of it is
> easy to explain, but because the language *as a whole* does what is
> expected of it. Toy languages are a lot easier to explain on a
> concrete level (look up Brainf*ck - it has very few operations and
> each one can be very simply defined), and that might be tempting in
> terms of "hey, we can teach the entire language in ten minutes", but
> they're utterly useless for students.

Sure. I would never use a toy language like that. I think we need a
compromise --- some syntax, but not too much; in fact, just a little bit
of syntax. For instance, could we do away with slices? We could. If
we learn one way of looping, we can build slices with procedures. This
is a good opportunity in fact --- it will show students how slices
really work and how to get what they want with it. (Then towards the
end we could give out a lecture for anyone interested in Python ---
``while we didn't show you how Pythonists usually write, here's a few
things that Pythonists would do that we didn't do in this course...'')

> Instead, my recommendation would be: Entice students with power.
> Pretend you're teaching some aspect of magic at a wizards' school and
> make sure your students feel massively OP. Sure, they might not
> understand what makes those cantrips work, but they know that they DO
> work. You can have students casting print calls left and right, doing
> complex incantations with list comprehensions, and even defining their
> own classes, all without ever worrying about the details of how it all
> works. Then once the "wow" is achieved, you can delve into the details
> of how things actually function, transforming progressively from
> "wizardry" to "science".

I really like that, but I would predict that, in a typical university,
professors are not really willing to go that way. Everything has to be
extremely simple --- and a mess is made in trying to achive that. (In a
sense, professors are all failing terribly. They're lucky that nobody
is giving them a grade based on how effective they are as evidenced by
the facts, however such thing would be done in practice if one were to
take it seriously.)

> And to be quite frank, a lot of code IS magic to most programmers.

Definitely. You guys are showing me so much Python here that I've never
seen --- which I expect, because I'm only paying attention at Python now
since I'm conducting students through a course that's using it. (I
admire the language, but I never used it in any project on my own. I
probably would if I were not in love with other similar technology.)

> Which isn't a problem. Do you REALLY need to understand how your CPU
> does register renaming in order to benefit from it? Or do you need to
> know every detail of the TCP packet header before using the internet?
> Not likely.

Not at all. (Although, of course, we like to know these stuff.)

> Those details hide away under the covers, and we make happy use of
> them. There's infinite knowledge out there, and you - and your
> students - are free to dip into exactly as much as you're comfortable
> with.

``A man after my own heart.''

Chris Angelico <rosuav@gmail.com> writes:

> On Wed, Aug 11, 2021 at 4:18 AM Hope Rouselle <hrouselle@jevedi.xotimo> wrote:
>>
>> Chris Angelico <rosuav@gmail.com> writes:
>>
>> [...]
>>
>> >> not disagreeing... and yeah I could have thought deeper about the
>> >> answer, but I still think "notthing has been OOP" -> "yes it has, they
>> >> just didn't realize it" was worth mentioning
>> >
>> > Oh yes, absolutely agree.
>>
>> At the same time, inside the machine nothing is OOP --- so all the OOP
>> is no OOP at all and they just didn't realize it? This seems to show
>> that OOP is about perspective. An essential thing for OOP is the
>> keeping of states. Closures can keep state, so having procedures as
>> first-class values allows us to say we are doing OOP too. (Arguments of
>> procedures are messages and function application is message passing,
>> with closures keeping a state --- and all the rest of OOP can be
>> implemented with enough such functional technology.) In summary, OOP
>> should not be defined as some special syntax, otherwise there is no OOP
>> in ``2 + 2''.
>>
>> Having said that, I totally agree with all the nitpicking.
>
> Object orientation is a particular abstraction concept. It's not a
> feature of the machine, it's a feature of the language that you write
> your source code in. I've done OOP using IDL and CORBA, writing my
> code in C and able to subclass someone else's code that might have
> been written in some other language. [1] Central tenets of OOP
> (polymorphism, inheritance, etc) can be implemented at a lower level
> using whatever makes sense, but *at the level that you're writing*,
> they exist, and are useful.
>
> Data types, variables, control flow, these are all abstractions. But
> they're such useful abstractions that we prefer to think that way in
> our code. So, *to us*, those are features of our code. To the
> computer, of course, they're just text that gets processed into
> actually-executable code, but that's not a problem.

Total agreement.

> So I would say that (in Python) there IS object orientation in "2 +
> 2", and even in the Python C API, there is object orientation, despite
> C not normally being considered an object-oriented language.

But would you say that 2 + 2 is also an illustration of object
orientation in any other language too?

Regarding C, I have many times said that myself. If I wrote assembly,
I'm sure I would do my best to create things like procedures --- a label
and some bureaucracy to get arguments in and a return value out.

> ChrisA
>
> [1] And boy oh boy was that good fun. The OS/2 Presentation Manager
> had a wealth of power available. Good times, sad that's history now.

I know OS/2 only by name. I never had the pleasure of using it. In
fact, I don't even know how it looks. I must be a little younger than
you are. But not too younger because I kinda remember its name. Was it
a system that might have thought of competing against Microsoft Windows?
:-) That's what my memory tells me about it.

Am 11.08.2021 um 05:22 schrieb Terry Reedy:
> Python is a little looser about whitespace than one might expect from
> reading 'normal' code when the result is unambiguous in that it cannot
> really mean anything other than what it does.  Two other examples:
>
> >>> if3: print('yes!')
> yes!
> >>> [0]  [0]
> 0

Not sure what you mean here - is it a joke? The first looks like an if
statement, but isn't. The missing space *does* make a difference. (Try
"if0" instead.)

The second is normal indexing, which allows white space. I wouldn't
consider that surprising, but maybe I should? (Honest question, I really
don't know.)

--
Wolfram Hinderer

On 2021-08-11 18:10, Wolfram Hinderer via Python-list wrote:
>
>
> Am 11.08.2021 um 05:22 schrieb Terry Reedy:
>> Python is a little looser about whitespace than one might expect from
>> reading 'normal' code when the result is unambiguous in that it cannot
>> really mean anything other than what it does.  Two other examples:
>>
>> >>> if3: print('yes!')
>> yes!
>> >>> [0]  [0]
>> 0
>
> Not sure what you mean here - is it a joke? The first looks like an if
> statement, but isn't. The missing space *does* make a difference. (Try
> "if0" instead.)
>
I see what you mean. It's a type annotation:

var: type

where the "type" is a print statement!

> The second is normal indexing, which allows white space. I wouldn't
> consider that surprising, but maybe I should? (Honest question, I really
> don't know.)
>

On Thu, Aug 12, 2021 at 5:00 AM Hope Rouselle <hrouselle@jevedi.com> wrote:
>
> Chris Angelico <rosuav@gmail.com> writes:
>
> > On Wed, Aug 11, 2021 at 4:18 AM Hope Rouselle <hrouselle@jevedi.xotimo> wrote:
> >>
> >> Chris Angelico <rosuav@gmail.com> writes:
> >>
> >> [...]
> >>
> >> >> not disagreeing... and yeah I could have thought deeper about the
> >> >> answer, but I still think "notthing has been OOP" -> "yes it has, they
> >> >> just didn't realize it" was worth mentioning
> >> >
> >> > Oh yes, absolutely agree.
> >>
> >> At the same time, inside the machine nothing is OOP --- so all the OOP
> >> is no OOP at all and they just didn't realize it? This seems to show
> >> that OOP is about perspective. An essential thing for OOP is the
> >> keeping of states. Closures can keep state, so having procedures as
> >> first-class values allows us to say we are doing OOP too. (Arguments of
> >> procedures are messages and function application is message passing,
> >> with closures keeping a state --- and all the rest of OOP can be
> >> implemented with enough such functional technology.) In summary, OOP
> >> should not be defined as some special syntax, otherwise there is no OOP
> >> in ``2 + 2''.
> >>
> >> Having said that, I totally agree with all the nitpicking.
> >
> > Object orientation is a particular abstraction concept. It's not a
> > feature of the machine, it's a feature of the language that you write
> > your source code in. I've done OOP using IDL and CORBA, writing my
> > code in C and able to subclass someone else's code that might have
> > been written in some other language. [1] Central tenets of OOP
> > (polymorphism, inheritance, etc) can be implemented at a lower level
> > using whatever makes sense, but *at the level that you're writing*,
> > they exist, and are useful.
> >
> > Data types, variables, control flow, these are all abstractions. But
> > they're such useful abstractions that we prefer to think that way in
> > our code. So, *to us*, those are features of our code. To the
> > computer, of course, they're just text that gets processed into
> > actually-executable code, but that's not a problem.
>
> Total agreement.
>
> > So I would say that (in Python) there IS object orientation in "2 +
> > 2", and even in the Python C API, there is object orientation, despite
> > C not normally being considered an object-oriented language.
>
> But would you say that 2 + 2 is also an illustration of object
> orientation in any other language too?

In some languages it is; in others, it's not. For instance, REXX
doesn't have polymorphism. You can add two numbers together using x+y,
or you can concatenate two strings with x||y. There's no concept of
doing the same operation (spelled the same way) on different data
types. (Partly that's because REXX doesn't actually *have* data types,
but it does a pretty good job of simulating strings, bignums, floats,
arrays, mappings, etc.)

But in many modern programming languages, yes, it would be a
demonstration of some of the object orientation features.

> Regarding C, I have many times said that myself. If I wrote assembly,
> I'm sure I would do my best to create things like procedures --- a label
> and some bureaucracy to get arguments in and a return value out.

Oh absolutely. But you'd also have the option to shortcut things if
you wanted to. For better or for worse.

> > [1] And boy oh boy was that good fun. The OS/2 Presentation Manager
> > had a wealth of power available. Good times, sad that's history now.
>
> I know OS/2 only by name. I never had the pleasure of using it. In
> fact, I don't even know how it looks. I must be a little younger than
> you are. But not too younger because I kinda remember its name. Was it
> a system that might have thought of competing against Microsoft Windows?
> :-) That's what my memory tells me about it.

History lesson!

Once upon a time, IBM and Microsoft looked at what Intel was
producing, and went, hey, we need to design an operating system that
can take advantage of the fancy features of this 80286 thing. So they
collaborate on this plan to make a 16-bit protected mode OS.
Unfortunately, things didn't work out too well, partly because this
was when Microsoft was at its most monopolistic, and they ended up
parting company. IBM continued to make OS/2, but Microsoft took their
part of the code and made Windows NT out of it.

(Aside: Windows NT's 16-bit applications and OS/2's 16-bit
applications were actually identical and compatible. Unfortunately,
Win32 introduced a very new API, so as soon as everyone moved to
32-bit everything, the schism became problematic. But it was actually
possible to package up a single .EXE file with a 16-bit MS-DOS loader,
a Win32 loader, and an OS/2 32-bit loader, all happily coexisting.
PKZIP, the original definition of the zip file format, did exactly
that, or at least had two out of the three (I don't quite remember if
it went the whole way), making it extremely convenient to zip and
unzip files on different computers.)

In the latter half of the 1990s, Windows came in three broad flavours:
the 16-bit Windows 3.x line, which ran purely on top of DOS; the
32-bit Windows 95 line, which was the "home" OS and had to be heavily
compatible with Windows 3, but still doing more things; and the
Windows NT line, which was aimed at businesses. OS/2 was a viable
option for businesses, but almost nobody took it seriously as a home
OS. And Microsoft was using its marketing machine to push Windows
fairly hard, so most people went that way.

OS/2 had all kinds of amazing features (for its time). The default
file system, HPFS ("High Performance File System"... IBM was good at
many things, but imaginative naming wasn't one of them), did a
spectacular job of maintaining reliability and performance on the
ever-growing hard disks of the time. Yes, it coped remarkably well,
even on *gigantic* drives that could carry, ooh, an entire gigabyte of
data! I'm not kidding! We even had a drive that had TWO gigabytes of
space, and HPFS managed it beautifully! Plus, it had this fancy
concept of "extended attributes"; on older systems (like MS-DOS's
"FAT" family), a file might be Read-Only, Hidden, a System file, or
needing to be Archived, and that was it - but on HPFS, you could
attach arbitrary data like "File type: DeScribe Word Processor" or
"Double click action: Run CASMake.cmd". This allowed the GUI to store
all kinds of information *on the file itself* instead of needing
hidden files (or, in Windows' case, the registry) to track that kind
of thing.

The default command interpreter and shell on OS/2 was fairly primitive
by today's standards, and was highly compatible with the MS-DOS one,
but it also had the ability to run REXX scripts. REXX was *way* ahead
of its time. It's a shell language but remarkably well suited to
building GUIs and other tools (seriously, can you imagine designing a
GUI entirely in a bash script??). It had features that we'd consider
fairly normal or even primitive by Python's standards, but back then,
Python was extremely new and didn't really have very much mindshare.
REXX offered arbitrary-precision arithmetic, good databasing support,
a solid C API that made it easy to extend, integrations with a variety
of other systems... this was good stuff for its day. (REXX is still
around, but these days, I'd rather use Python.)

I mentioned the Presentation Manager, because it was one of the best
parts of running OS/2. The kernel was decent, but it was the graphical
shell that was the real pleasure to work with. Probably the most
notable feature, by today's standards, was that it had a single input
queue. If you press a series of keys, they'd go into a global queue,
and the application that has focus would get the first one. When that
key has been handled, the application that has focus would get the
next key from the queue. This means that, if the response to a
keystroke is to change focus, then *even in a slow and lagged out
system*, subsequent keys WOULD be sent to the new target window. That
was AWESOME, and I really miss it. Except that I also don't. Because
if a single application is having issues, now your entire keyboard and
mouse is locked up... which kinda slightly sucks. Good luck resolving
that problem. (We had some neat tools like WatchCat that could get
around the single input queue via interrupt signals, and regain
control. But it was still problematic.)

So, yeah. It was spectacular in its day.... but it kinda got left
behind as the world moved on. These days, instead of running REXX code
on OS/2 in a system that uses eight-bit text for most things, I use
Python on Linux and full Unicode. But OS/2 was an important part of
history, both my own personal journey, and the history of the world of
PCs.