Hello,
One of my absolute favorite places to go to practice Python questions from
is https://projecteuler.net . It's just Maths based questions that cannot
be solved by hand without consuming a Ton of time because of the high
limits.
This is how I learnt Python. By solving problems from the site in Python!
Happy to provide more tips wrt this if required.

Regards
Abhi R <http://abhiramr.com>

On Tue, Aug 10, 2021 at 2:56 AM Hope Rouselle <hrouselle@jevedi.xotimo>
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, ...)).
>
> 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!
> --
> https://mail.python.org/mailman/listinfo/python-list
>

--
-Abhiram R

On Sun, 15 Aug 2021 00:15:58 -0300, Hope Rouselle <hrouselle@jevedi.com>
declaimed the following:

Giganews seems to have just vomited up three days worth of traffic...

>Dennis Lee Bieber <wlfraed@ix.netcom.com> writes:
>
>>
>> Granted, the fact that the Amiga used a shared common address space for
>> all running applications made IPC quite easy -- one looked up the
>> application message port, then added a small packet to the linked list
>> associated with the port. That small packet basically held the address of
>> the message port for returning data, and the address of the data being
>> passed. The closet thing I've seen to that capability on systems with
>> process-isolated virtual memory is (Open)VMS "mailbox" structures. The
>> difference being that the entire data had to be written (QIO) to the
>> mailbox, and the receiver had to read (another QIO call) the message --
>> this allowed the address space to change.
>>
>> I've not seen anything equivalent in my light perusal of the Win32 API
>> (the various guide books aren't layed out in any way to be a reference),
>> and Linux seems to use UNIX sockets for IPC... No way to search for a
>> connection point by name...
>
>I don't know anything about Amiga, REXX et cetera, so I might be totall
>off here. But since you spoke of your perusal of the Win32 API, let me
>add a tiny bit. I gave myself a quick tour through the Win32 API using
>Pavel Yosifovich's book ``Windows 10 System Programming''. It's a two
>volume work. The thing that impressed me the most was the many ways to
>do the IPC. The purpose the work is clearly to show what is available
>and it it probably does the job well. (I ignored Windows for most of my
>life and now I decided to take a look at it. I don't feel it has much
>of the elegance of UNIX. It's what it is.)

For a book that was published only a year ago -- it seems to be hard to
find... Amazon has v1, but not v2.

I have the "Windows Internals 6th" both volumes.

The closet those get to IPC is something called ALPC -- and that is
declared to be internal only, not available to third party programmers.

"Programming Windows 6th" is focused on using C# (which, for the most
part, means using the "managed" API, not the Win32 API directly).

"Mailslots" (I'm using Google to find Windows IPC options) initially
sound close to Amiga message ports... Except there is no status return
inherent to the system; Amiga messages contain a return address so a
program can wait for the status of processing by the destination address.
They also don't qualify as VMS mailboxes as there can only be one reader
(the creator of the mailslot). VMS mailboxes allow multiple writers and/or
multiple readers.

"File mapping" doesn't provide any form of queuing -- multiple
"writers" would require manually implementing some protocol to track "next
available space" in the mapped file. It would allow bidirectional message
passing, but again that requires some rather nasty overhead information
(when is the return status valid -- it is presumed the client wanting the
return status would get it from the same memory space as the message it
sent, and that space can't be reused until the client explicitly frees it
-- again by some overhead protocol changing headers of free space.

"Data Copy" also sounds close to Amiga message ports (closer than
"Mailslots"), but the online documentation doesn't indicate if it queues
messages. The documentation doesn't illustrate HOW to return TRUE or FALSE
(processed/rejected). It advices that the receiver should treat the data as
read-only -- though I have to wonder if it /could/ write a return status
into the same message structure before "returning TRUE".

Named Pipes and Sockets both have the "tied to endpoints" problem, and
in the case of Pipes, may only allow one sender to connect at a time
(sockets are also one connection, but normally the receivers spawns a
thread for each active connection and the connections are made using
different allocated sockets).

--
Wulfraed Dennis Lee Bieber AF6VN
wlfraed@ix.netcom.com http://wlfraed.microdiversity.freeddns.org/

Chris Angelico <rosuav@gmail.com> writes:

> On Tue, Aug 17, 2021 at 3:51 AM Hope Rouselle <hrouselle@jevedi.com>
> wrote:
>>
>> Chris Angelico <rosuav@gmail.com> writes:
>> >> Wow, I kinda feel the same as you here. I think this justifies
>> >> perhaps
>> >> using a hardware solution. (Crazy idea?! Lol.)
>> >
>> > uhhh........ Yes. Very crazy idea. Can't imagine why anyone would
>> > ever
>> > think about doing that.
>>
>> Lol. Really? I mean a certain panic button. You know the GNU Emacs.
>> It has this queue with the implications you mentioned --- as much as it
>> can. (It must of course get the messages from the system, otherwise it
>> can't do anything about it.) And it has the panic button C-g. The
>> keyboard has one the highest precedences in hardware interrupts,
>> doesn't
>> it not? A certain very important system could have a panic button that
>> invokes a certain debugger, say, for a crisis-moment.
>>
>> But then this could be a lousy engineering strategy. I am not an
>> expert
>> at all in any of this. But I'm surprised with your quick
>> dismissal. :-)
>>
>> > Certainly nobody in his right mind would have WatchCat listening on
>> > the serial port's Ring Indicator interrupt, and then grab a paperclip
>> > to bridge the DTR and RI pins on an otherwise-unoccupied serial port
>> > on the back of the PC. (The DTR pin was kept high by the PC, and
>> > could
>> > therefore be used as an open power pin to bring the RI high.)
>>
>> Why not? Misuse of hardware? Too precious of a resource?
>>
>> > If you're curious, it's pins 4 and 9 - diagonally up and in from the
>> > short
>> > corner. http://www.usconverters.com/index.php?main_page=page&id=61&chapter=0
>>
>> You know your pins! That's impressive. I thought the OS itself could
>> use something like that. The fact that they never do... Says
>> something,
>> doesn't it? But it's not too obvious to me.
>>
>> > And of COURSE nobody would ever take an old serial mouse, take the
>> > ball out of it, and turn it into a foot-controlled signal... although
>> > that wasn't for WatchCat, that was for clipboard management
>> > between my
>> > app and a Windows accounting package that we used. But that's a
>> > separate story.
>>
>> Lol. I feel you're saying you would. :-)
>
> This was all a figure of speech, and the denials were all tongue in
> cheek. Not only am I saying we would, but we *did*. All of the above.

Cool! :-)

> The Ring Indicator trick was one of the best, since we had very little
> other use for serial ports, and it didn't significantly impact the
> system during good times, but was always reliable when things went
> wrong.
>
> (And when I posted it, I could visualize the port and knew which pins
> to bridge, but had to go look up a pinout to be able to say their pin
> numbers and descriptions.)

Nice!

>> I heard of Python for the first time in the 90s. I worked at an ISP.
>> Only one guy was really programming there, Allaire ColdFusion. But,
>> odd enough, we used to say we would ``write a script in Python'' when
>> we meant to say we were going out for a smoke. I think that was
>> precisely because nobody knew that ``Python'' really was. I never
>> expected it to be a great language. I imagined it was something like
>> Tcl. (Lol, no offense at all towards Tcl.)
>
> Haha, that's a weird idiom!

Clueless people --- from Rio de Janeiro area in Brazil. :-) It was
effectively just an in-joke.

> Funny you should mention Tcl.
>
> https://docs.python.org/3/library/tkinter.html

Cool! Speaking of GUIs and Python, that Google software called Backup
and Sync (which I think it's about to be obsoleted by Google Drive) is
written in Python --- it feels a bit heavy. The GUI too seems a bit
slow sometimes. Haven't tried their ``Google Drive'' as a replacement
yet.

Dennis Lee Bieber <wlfraed@ix.netcom.com> writes:

> On Sun, 15 Aug 2021 00:15:58 -0300, Hope Rouselle <hrouselle@jevedi.com>
> declaimed the following:
>
> Giganews seems to have just vomited up three days worth of traffic...
>
>>Dennis Lee Bieber <wlfraed@ix.netcom.com> writes:
>>
>>>
>>> Granted, the fact that the Amiga used a shared common address space for
>>> all running applications made IPC quite easy -- one looked up the
>>> application message port, then added a small packet to the linked list
>>> associated with the port. That small packet basically held the address of
>>> the message port for returning data, and the address of the data being
>>> passed. The closet thing I've seen to that capability on systems with
>>> process-isolated virtual memory is (Open)VMS "mailbox" structures. The
>>> difference being that the entire data had to be written (QIO) to the
>>> mailbox, and the receiver had to read (another QIO call) the message --
>>> this allowed the address space to change.
>>>
>>> I've not seen anything equivalent in my light perusal of the Win32 API
>>> (the various guide books aren't layed out in any way to be a reference),
>>> and Linux seems to use UNIX sockets for IPC... No way to search for a
>>> connection point by name...
>>
>>I don't know anything about Amiga, REXX et cetera, so I might be totall
>>off here. But since you spoke of your perusal of the Win32 API, let me
>>add a tiny bit. I gave myself a quick tour through the Win32 API using
>>Pavel Yosifovich's book ``Windows 10 System Programming''. It's a two
>>volume work. The thing that impressed me the most was the many ways to
>>do the IPC. The purpose the work is clearly to show what is available
>>and it it probably does the job well. (I ignored Windows for most of my
>>life and now I decided to take a look at it. I don't feel it has much
>>of the elegance of UNIX. It's what it is.)
>
> For a book that was published only a year ago -- it seems to be hard to
> find... Amazon has v1, but not v2.

Indeed. I believe it's because it's not quite released yet. I had
found it here:

https://leanpub.com/windows10systemprogrammingpart2

And this seems to be a sort-of-early-release. I'm not really sure.

> I have the "Windows Internals 6th" both volumes.
>
> The closet those get to IPC is something called ALPC -- and that is
> declared to be internal only, not available to third party programmers.
>
> "Programming Windows 6th" is focused on using C# (which, for the most
> part, means using the "managed" API, not the Win32 API directly).

Makes sense.

> "Mailslots" (I'm using Google to find Windows IPC options) initially
> sound close to Amiga message ports... Except there is no status return
> inherent to the system; Amiga messages contain a return address so a
> program can wait for the status of processing by the destination address.
> They also don't qualify as VMS mailboxes as there can only be one reader
> (the creator of the mailslot). VMS mailboxes allow multiple writers and/or
> multiple readers.
>
> "File mapping" doesn't provide any form of queuing -- multiple
> "writers" would require manually implementing some protocol to track "next
> available space" in the mapped file. It would allow bidirectional message
> passing, but again that requires some rather nasty overhead information
> (when is the return status valid -- it is presumed the client wanting the
> return status would get it from the same memory space as the message it
> sent, and that space can't be reused until the client explicitly frees it
> -- again by some overhead protocol changing headers of free space.
>
> "Data Copy" also sounds close to Amiga message ports (closer than
> "Mailslots"), but the online documentation doesn't indicate if it queues
> messages. The documentation doesn't illustrate HOW to return TRUE or FALSE
> (processed/rejected). It advices that the receiver should treat the data as
> read-only -- though I have to wonder if it /could/ write a return status
> into the same message structure before "returning TRUE".
>
> Named Pipes and Sockets both have the "tied to endpoints" problem, and
> in the case of Pipes, may only allow one sender to connect at a time
> (sockets are also one connection, but normally the receivers spawns a
> thread for each active connection and the connections are made using
> different allocated sockets).

Thanks for these summaries!