Re: some problems for an introductory python test

[Hope Rouselle]

Dennis Lee Bieber  writes:

> On Sun, 15 Aug 2021 00:15:58 -0300, Hope Rouselle 
> declaimed the following:
>
>   Giganews seems to have just vomited up three days worth of traffic...
>
>>Dennis Lee Bieber  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!
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: some problems for an introductory python test

[Hope Rouselle]

Chris Angelico  writes:

> On Tue, Aug 17, 2021 at 3:51 AM Hope Rouselle 
> wrote:
>>
>> Chris Angelico  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=61=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.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: some problems for an introductory python test

[Dennis Lee Bieber]

On Sun, 15 Aug 2021 00:15:58 -0300, Hope Rouselle 
declaimed the following:

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

>Dennis Lee Bieber  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
wlfr...@ix.netcom.comhttp://wlfraed.microdiversity.freeddns.org/

-- 
https://mail.python.org/mailman/listinfo/python-list

Re: some problems for an introductory python test

[Abhiram R]

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 

On Tue, Aug 10, 2021 at 2:56 AM 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, ...)).
>
> 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("a") = {"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
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: some problems for an introductory python test

[Chris Angelico]

On Tue, Aug 17, 2021 at 3:51 AM Hope Rouselle  wrote:
>
> Chris Angelico  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=61=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.
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.)

> 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!

Funny you should mention Tcl.

https://docs.python.org/3/library/tkinter.html

ChrisA
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: some problems for an introductory python test

[Hope Rouselle]

Grant Edwards  writes:

> On 2021-08-12, Hope Rouselle  wrote:
>
>>> OS/2 had all kinds of amazing features (for its time). [...] 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.
>>
>> Yeah, that's kinda nice.  Isn't that a UNIX design?  A file is a
>> sequence of bytes?  Users decide what to put in them?
>
> I think what he's talking about is allowing the user to attach
> arbitrary _metadata_ to the file -- metadata that exists separately
> and independently from the normal data that's just a "sequence of
> bytes". IOW, something similar to the "resource fork" that MacOS used
> to have. https://en.wikipedia.org/wiki/Resource_fork

Got ya.

>> So OS/2 was taking advantage of that to integrate it well with the
>> system.  Windows was doing the same, but integrating the system with
>> files in odd ways --- such as a registry record to inform the system
>> which programs open which files?  (That does sound more messy.)
>
> Windows never had filesystems that supported metadata like OS/2 and
> MacOS did. The registry was an ugly hack that attempted (very poorly)
> to make up for that lack of metadata.

Take a look at NTFS streams.  Maybe you would consider that as a way to
store metadata in Windows.  Pavel Yosifovich talks about them briefly in
chapter 11, page 555, part 1.  Windows 10 System Programming.  Here's
the first paragraph:

--8<---cut here---start->8---
The NTFS filesystem supports /file streams/, which are essentially files
within a file.  Normally, we use the default data stream, but others can
be created and used. These are essentially hidden from normal view and
don’t show up in standard tools such as Windows Explorer.
--8<---cut here---end--->8---

Pavel Yosifovich wrote a tool to let us see these streams:

https://github.com/zodiacon/NtfsStreams

>> UNIX's execve() is able to read the first line of an executable and
>> invoke its interpreter.  I guess OS/2 was doing precisely that in a
>> different way?
>
> No, that's not at all the same thing. The #! line is part of the
> normal file data. It's part of the 'sequence of bytes'. Metadata
> maintained by Unix filesystems comprises a very limited and
> pre-defined set of attributes present in the inode.

Well said.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: some problems for an introductory python test

[Hope Rouselle]

Hope Rouselle  writes:

[...]

>> Granted you may have to restrict some features if [...]
>
> To let students use the entire language feels a bit weird in the sense
> that the group goes in so many different directions.  It definitely put
> teachers in a position they have to be --- I don't know the answer.
  ^^
Sorry.  I meant ``they [hate] to be [in] --- I don't know the answer.''

And, alas, I also find many more typos, grammar and cosmetic
incoherences below, which I fix with brackets.  (Not that they were
needed.  Only this bit above seemed to lose the meaning of the author,
Your Truly.)

> It is not my case.  But I do think that holding a class with wildly
> different backgrounds, each going about in their own weird ways[,] is
> kinda odd.  It doesn't seem to bring people together --- on average.
>
> The better-idea brings people together by leveling everyone out.
> Unpopular languages give us this feature.  Students hardly ever master
> them.  It's a game nobody played.  The rules are very simple.  The
> implications are far-fetching.  Sometimes even the programmer-expert in
> class realizes he is less skilled than the total-novice that never
> handled a compiler: his tricks don't work in the new game.  (It's not
> that we don't allow him to use them.  They're not there.  They don't
> compile.)  (We take [Chess] players, Backgammon and Checkers players [the
> students], we teach them a new game, say, Go, and suddenly everyone is
> learning together.  Assume Go is unpopular.  It's very simple.  Everyone
> learns the rules quickly and we spend the semester looking into
> strategies.  Much better idea.)
>
>>  For my Algorithm/Data Structure course (circa 1978), the instructor
>> allowed us to use any language /he/ could understand (so no SNOBOL). At the
>> time I'd gone through intro/advanced FORTRAN-4, intro/advanced COBOL, Sigma
>> Assembly, UCSD Pascal (not on the campus main computer, just a pair of
>> LSI-11s), and BASIC. The assignment was a "Hashed Head, Multiply-Linked
>> List". I chose to do that assignment using BASIC! In nearly 45 years, I've
>> only seen ONE real-world implementation of the HHMLL -- The file system
>> used by the Commodore Amiga. (Hash the first component of the path/name,
>> that maps to one of 64 entries in the root directory block; each entry
>> points the start of a linked list, follow the list until you reach the
>> block with the component name; if it is a directory block, hash the next
>> component and repeat; if it is a file block, the "entries" point to data
>> blocks instead of lists)
>
> Repeating my criticism with one more illustration.  When ``there's
> always more than one way to do it'', students can't even count on their
> classmates to help each other --- because each one is doing a different
> thing.  This is good in science, but what I like the most in schooling
> is working together and too much freedom like seems not very helpful in
> this direction.
>
> But both worlds [are] possible.  Use a limited tool (which is not
> computationally limited, quite the contrary) and tell them --- you can
> do anything you want with this.  [...] [Although] everyone is more or
> less original, the different solutions are never too far apart, so all
> the exchange is quite possible.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: some problems for an introductory python test

[Hope Rouselle]

Chris Angelico  writes:

> On Fri, Aug 13, 2021 at 2:15 AM Hope Rouselle  wrote:
>>
>> Chris Angelico  writes:
>>
>> > 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.
>>
>> How is it possible that Microsoft would take part of the code of OS/2?
>> Did IBM just hand it to them?
>
> I presume both companies had all of the code. It was a matter of
> licensing, though. There were a few components that were saddled with
> awkward restrictions due to the dual ownership (for instance, HPFS386
> was Microsoft-controlled, but vanilla HPFS was fine - kinda like the
> difference between LZW and LZ77).
>
>> > (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.
>>
>> Beautiful. :-) So if all libraries were around in each system, they had
>> perfect compatibility?
>
> The 16-bit loaders were fine, but the 32-bit loaders were different,
> so this trick basically meant having three different copies of the
> code wrapped up in a single executable.
>
>> > 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.
>>
>> Yeah, that's kinda nice.  Isn't that a UNIX design?  A file is a
>> sequence of bytes?  Users decide what to put in them?  So OS/2 was
>> taking advantage of that to integrate it well with the system.  Windows
>> was doing the same, but integrating the system with files in odd ways
>> --- such as a registry record to inform the system which programs open
>> which files?  (That does sound more messy.)
>
> Something like that, but with a lot more metadata. Modern OSes don't
> seem to work that way any more.
>
>> UNIX's execve() is able to read the first line of an executable and
>> invoke its interpreter.  I guess OS/2 was doing precisely that in a
>> different way?
>
> Kinda, but instead of having the choice of interpreter be inside the
> file contents itself, the choice was in the file's metadata. Still
> part of the file, but if you open and read the file, it isn't any
> different.

Speaking of which, NTFS supports something called file streams.  That's
essentially a way to have files inside files.  Streams are not shown by
tools such as file explorer.  Applications could definitely use that as
metadata.  (End of tangent.)

I think UNIX people would say and I'd agree --- we have that already.
But instead of hiding the stream, which is obscurantism, we let the user
see.  (Just create two files in a directory, one with the extension
.metadata.  And, oh, if you don't like that extension, you can change it
to whatever you like.  Lol.)  I like that.

>> > 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??).
>>
>> I cannot imagine.  I always wondered what REXX was about --- I saw
>> programs sometimes written in some website whose name is something like
>> Rosetta Code.  REXX looked so weird.  (``Who would program in that?'')
>> But I see now there is a context to it.
>
> Yeah. It was a strange choice by today's standards, but back then,
> most of my GUI programs were written in REXX.
>
> https://en.wikipedia.org/wiki/VX-REXX
> http://www.edm2.com/0206/vrexx.html
>
> (There were other tools too - VisPro REXX, VREXX, DrDialog, and
> various others - but VX-REXX was where most of my dev work happened.)

I like that kind of simpler GUI interface.  Cleaner.  Fast!  You know,
the so-called ``modern world'' is totally 

Re: some problems for an introductory python test

[Hope Rouselle]

Dennis Lee Bieber  writes:

> On Wed, 11 Aug 2021 09:27:38 -0300, Hope Rouselle 
> declaimed the following:
>>
>>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.
>
>   Then I would posit you are teaching the wrong level... What you
> describe is what would be found a "data structures" and/or "algorithms"
> course -- which is a second year, if not third year course in my (ancient)
> history. [...] Slicing with a stride isn't really useful to most
> algorithm development -- it's more of trick in normal Python.

I didn't express myself very well.  And it's hard to make sense of the
course.  I say it's interested in teaching computer programming because
it is not allowing the students to dive into the Python language.  It's
very restrictive.  Students will finish the course after learning to use
the loop contructs while and for.  The course calls them ``structures
for repetition''.  I think it's safe to say that the course is designed
by people concerned with education, but not well-versed in programming
languages, so not even the terminology seems quite correct.

So if they're not letting students embrace the whole of the language,
they must be concerned with other things?  They sloppily emphasize
documentation and put in some concerns for procedure signatures.  I have
some trouble defending it.  I see the good intentions, though, and the
job is not easy.

But this course is definitely not teaching any data structures or any
algorithms.  Zero.  Students are using tuples, lists and dictionaries,
strings and numbers, but they're not studying any strategies whatsoever.
The exercises make students use a few basic facts of mathematics, but
there is pretty much no investigation into the strategies behind some of
these facts.  It's not very intelligible.

I *kinda* like that it's restrictive because it allows us to show
students at least a few idioms: otherwise there's so much syntax to
digest that there is no time to show a few useful applications of them.
But then I read your next paragraph and it brings me to a very important
point, which I think it's at the back of your mind too.  Let's see.

>   So... The first thing I would drop is the RESTRICTION to only use what
> you've covered in prior sessions... Let the students read the language
> reference manual, peruse the library reference manual, and allow them to
> use whatever "advanced" techniques they are able to understand on their
> own. 

Precisely.  We kill the spirit of investigation by saying --- don't do
anything I don't allow you to.  This is pretty dangerous.  I have a much
better idea, I think.

You have to give people a tool and say --- use however you want.  If we
don't want them to use things not introduced in previous lessons, we
should give them a precisely-limited tool.  But that's not done.

The much better idea is to use such a limited language.  There are such
languages, made precisely for teaching.  It comes with very little
syntax and lesson after lesson it gets immensely powerful with very
little syntax.

> Granted you may have to restrict some features if [...]

To let students use the entire language feels a bit weird in the sense
that the group goes in so many different directions.  It definitely put
teachers in a position they have to be --- I don't know the answer.  It
is not my case.  But I do think that holding a class with wildly
different backgrounds, each going about in their own weird ways is kinda
odd.  It doesn't seem to bring people together --- on average.

The better-idea brings people together by leveling everyone out.
Unpopular languages give us this feature.  Students hardly ever master
them.  It's a game nobody played.  The rules are very simple.  The
implications are far-fetching.  Sometimes even the programmer-expert in
class realizes he is less skilled than the total-novice that never
handled a compiler: his tricks don't work in the new game.  (It's not
that we don't allow him to use them.  They're not there.  They don't
compile.)  (We take Ghess players, Backgammon and Checkers players [the
students], we teach them a new game, say, Go, and suddenly everyone is
learning together.  Assume Go is unpopular.  It's very simple.  Everyone
learns the rules quickly and we spend the semester looking into
strategies.  Much better idea.)

>   For my Algorithm/Data Structure course (circa 1978), the instructor
> allowed us to use any language /he/ could understand (so no SNOBOL). At the
> time I'd gone through intro/advanced FORTRAN-4, intro/advanced COBOL, Sigma
> Assembly, UCSD Pascal (not on the campus main computer, just a pair of
> LSI-11s), and BASIC. The assignment was a "Hashed Head, Multiply-Linked
> List". I chose to do that assignment using BASIC! In nearly 45 years, I've
> only seen ONE real-world implementation of the HHMLL -- The file system
> 

Re: some problems for an introductory python test

[Hope Rouselle]

Chris Angelico  writes:

> On Thu, Aug 12, 2021 at 9:23 AM Dennis Lee Bieber  
> wrote:

[...]

>> I was spoiled by the Amiga variant of REXX. Most current
>> implementations (well, Regina is the only one I've looked at) can just pass
>> command to the default shell. The Amiga version took advantage of Intuition
>> Message Ports (OS supported IPC). That allowed it to "address
>> " any application that defined an ARexx port, allowing ARexx
>> to be used as a scripting language for that application (and with multiple
>> applications, one could easily fetch data from app1 and feed it to app2).
>> ARexx did not, to my memory, implement arbitrary precision math.
>
> The same functionality was available in OS/2, but not heavily used.
> You could 'address cmd commandname' to force something to be
> interpreted as a shell command, but that was about it. However, I
> built a MUD that used REXX as its scripting language, and the default
> destination was sending text back to the person who sent the command;
> and you could, of course, still 'address cmd' to run a shell command.
>
>> 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...
>
> Win32 doesn't really have it. Unix sockets are kinda there but you
> identify something by a path to the socket, not the name of the
> application. But I think dbus is probably the closest to what you're
> thinking of.

Win32 offers some APIs that sound like it could be what you guys are
talking about here that I'm not too clear what it is.  There are some
shared memory you can reference by name, so it's as easy to use: both
applications invoke a procedure with a string-argument and exchange
information that way.  (And Win32 does support named pipes as well.)  I
mean I'm sure you know it all better than I do.  (Perhaps I'm too
clueless here.)  I could look up the Win32 APIs I'm thinking of if that
would clarify things.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: some problems for an introductory python test

[Hope Rouselle]

Dennis Lee Bieber  writes:

> On Thu, 12 Aug 2021 06:15:28 +1000, Chris Angelico 
> declaimed the following:
>
>>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 was spoiled by the Amiga variant of REXX. Most current
> implementations (well, Regina is the only one I've looked at) can just pass
> command to the default shell. The Amiga version took advantage of Intuition
> Message Ports (OS supported IPC). That allowed it to "address
> " any application that defined an ARexx port, allowing ARexx
> to be used as a scripting language for that application (and with multiple
> applications, one could easily fetch data from app1 and feed it to app2).
> ARexx did not, to my memory, implement arbitrary precision math.
>
>   Any statement in a REXX script that was not parsable as REXX would be
> passed on the currently "addressed" command host.
>
>   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.)
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: some problems for an introductory python test

[Greg Ewing]

On 13/08/21 5:52 am, Grant Edwards wrote:

I think what he's talking about is allowing the user to attach
arbitrary _metadata_ to the file ... IOW, something similar to the > "resource 
fork" that MacOS used to have.


The resource fork was used for more than just metadata, it was
often the entire contents of the file. Applications had all the
code in there, for example -- the data fork of an application
was usually empty.

--
Greg
--
https://mail.python.org/mailman/listinfo/python-list

Re: some problems for an introductory python test

[Greg Ewing]

On 13/08/21 11:42 am, Cameron Simpson wrote:

2: It took me a while to see, but this is a type annotiation.


Interestingly, it seems to be parsed as a form of assignment with
a missing RHS.

>>> from ast import parse, dump
>>> dump(parse("if0: print('yes!')"))
"Module(body=[AnnAssign(target=Name(id='if0', ctx=Store()), 
annotation=Call(func=Name(id='print', ctx=Load()), 
args=[Constant(value='yes!', kind=None)], keywords=[]), value=None, 
simple=1)], type_ignores=[])"


"An annotated assignment without the assignment? Eeuurgh!"

--
Greg
--
https://mail.python.org/mailman/listinfo/python-list

Re: some problems for an introductory python test

[Cameron Simpson]

On 12Aug2021 12:09, Hope Rouselle  wrote:
>Chris Angelico  writes:
>> [...] 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.
>
>Yeah, that's kinda nice.  Isn't that a UNIX design?  A file is a
>sequence of bytes?  Users decide what to put in them?

Yes, but extended attributes are outside the file data. They're very 
common on UNIX platforms these days. You can label arbitrary files with 
a file type or whatever else. (There are platform specific limitations, 
and even the OS API to deal with them is platform specific - Linux is 
different to FreeBSD is different to MacOS.)

Also, Python has support for accessing these off-to-the-side data:

https://docs.python.org/3/library/os.html#linux-extended-attributes

Labelled "Linux" but also available for FreeBSD and IIRC OpenBSD. You do 
of course need filesystem support - FAT32 for example would not work 
with this - the filesystem needs a way to store these things. But ext4 
and XFS on Linux, HFS+ on MacOS etc all support this.

I've even got a CPython branch where I'm implementing the MacOS backend 
for these calls, a little stalled.

Cheers,
Cameron Simpson 
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: some problems for an introductory python test

[Cameron Simpson]

On 11Aug2021 09:11, Hope Rouselle  wrote:
>Greg Ewing  writes:
>> 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?

1: "if0" does not mean "if 0"; "if0" is a valid identifier. Like "x0", "x1".

2: It took me a while to see, but this is a type annotiation.

This line:

if0: print('yes!')

says that the name "if0" should contain a value described by the return 
value of the expression "print('yes!')". Like this:

label : str

says that we expect a string in the variable "label".

Remember that Python is strongly typed, but variables may reference 
objects of any type. Type annotations are optional things reflecting 
that in practice most variables are expected to reference specific 
types. This lets is run static linters against programmes to catch 
mistakes exposed by the type descriptions.

Also, type annotations have _no_ runtime effect. So if that expression 
returns an invalid type description, nobody cares!

However, if you hand this code to a type aware linter such as mypy you 
might get bitter complaints about nonsense. (Or, since print() returns 
None, no complaint - it just means you expect this variable to hold the 
value None. You'd get complaints about unused variables etc.)

Cheers,
Cameron Simpson 
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: some problems for an introductory python test

[Dennis Lee Bieber]

On Fri, 13 Aug 2021 04:41:42 +1000, Chris Angelico 
declaimed the following:

>Yeah. It was a strange choice by today's standards, but back then,
>most of my GUI programs were written in REXX.
>
>https://en.wikipedia.org/wiki/VX-REXX
>http://www.edm2.com/0206/vrexx.html
>
There was a library for the Amiga ARexx that supported basic GUI
implementation too...
>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

Of course not -- you'd want an old joyboard for that 
https://en.wikipedia.org/wiki/Joyboard

>
>SysRq should theoretically be that. (That's Alt+PrtSc on a lot of
>keyboards.) I'm not sure how it could best be handled though. It might

While so marked, Windows, at least, interprets  as "grab
image of current Window", whereas  is "grab image of entire
display".


>be that today's GUI systems (X11, Wayland, Cocoa, Win32, etc) just
>wouldn't work with a single input queue. Would be curious to see if
>any modern OS/GUI pair has a synchronous input queue like that.
>

Not "modern" in this era, but I'm fairly certain the Amiga used a
single stream queue. But that stream was fed to every application running,
leaving it up to the application to determine if the event was something it
had to handle, or pass on further. It was also fairly easy to inject events
into the stream (which could help finding some of the easter eggs in the OS
-- rather difficult to hold down , , , ,
 AND, while holding them down, eject and insert a floppy disk.
[without the floppy,  to  put up a credits display for the people
who had worked on parts of the OS... The  floppy mess then brought up
a display with approximately "we created Amiga, CBM messed it up"])



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

-- 
https://mail.python.org/mailman/listinfo/python-list

Re: some problems for an introductory python test

[Grant Edwards]

On 2021-08-12, MRAB  wrote:
>
>> Windows never had filesystems that supported metadata like OS/2 and
>> MacOS did. The registry was an ugly hack that attempted (very poorly)
>> to make up for that lack of metadata.
>> 
> FYI, NTFS does support Alternate Data Streams.

That is interesting -- and it was apparently intended to provide some
sort of compatibility with MacOS data fork and resource
fork. According to one article I found, nobody ever seems to have put
that NTFS feature to use for anything other than hiding malware.

--
Grant

-- 
https://mail.python.org/mailman/listinfo/python-list

Re: some problems for an introductory python test

[Dennis Lee Bieber]

On Thu, 12 Aug 2021 12:09:58 -0300, Hope Rouselle 
declaimed the following:


>How is it possible that Microsoft would take part of the code of OS/2?
>Did IBM just hand it to them?
>

Because IBM subcontracted (IE: "paid") M$ to create an OS with XYZ
features for their latest PC (under supervision of IBM design team)..

https://en.wikipedia.org/wiki/OS/2

IBM owned the rights to OS/2, but it was written, for the most part, by
M$ in parallel with M$ own "Windows" 16-bit OS.

>
>Yeah, that's kinda nice.  Isn't that a UNIX design?  A file is a
>sequence of bytes?  Users decide what to put in them?  So OS/2 was
>taking advantage of that to integrate it well with the system.  Windows
>was doing the same, but integrating the system with files in odd ways
>--- such as a registry record to inform the system which programs open
>which files?  (That does sound more messy.)
>

Not really -- Have you looked at what a hash Linux graphical interfaces
require to associate file types with how to open said files?

On my Debian (VirtualBox) there is:

wulfraed@debian:~$ cat ~/.config/mimeapps.list 
[Added Associations]
text/html=firefox-esr.desktop;
text/plain=gvim.desktop;
x-scheme-handler/http=exo-web-browser.desktop
x-scheme-handler/https=exo-web-browser.desktop
x-scheme-handler/mailto=exo-mail-reader.desktop
application/xml=gvim.desktop;
text/x-scheme=gvim.desktop;
application/vnd.kde.kxmlguirc=gvim.desktop;
text/x-python=gvim.desktop;
application/x-shellscript=gvim.desktop;

[Default Applications]
wulfraed@debian:~$ 

... and all these

wulfraed@debian:~$ ls /usr/share/applications
atril.desktoppanel-desktop-handler.desktop
claws-mail.desktop   panel-preferences.desktop
...
debian-uxterm.desktoppython3.7.desktop

...
org.thonny.Thonny.desktopxsane.desktop
org.xfce.Parole.desktop
wulfraed@debian:~$ 

wulfraed@debian:~$ cat /usr/share/applications/python3.7.desktop 
[Desktop Entry]
Name=Python (v3.7)
Comment=Python Interpreter (v3.7)
Exec=/usr/bin/python3.7
Icon=/usr/share/pixmaps/python3.7.xpm
Terminal=true
Type=Application
Categories=Development;
StartupNotify=true
NoDisplay=true
wulfraed@debian:~$ 

wulfraed@debian:~$ cat /etc/mime.types 
###
#
#  MIME media types and the extensions that represent them.
#
#  The format of this file is a media type on the left and zero or more
#  filename extensions on the right.  Programs using this file will map
#  files ending with those extensions to the associated type.
#
#  This file is part of the "mime-support" package.  Please report a bug
using
#  the "reportbug" command of the "reportbug" package if you would like new
#  types or extensions to be added.
#
#  The reason that all types are managed by the mime-support package
instead
#  allowing individual packages to install types in much the same way as
they
#  add entries in to the mailcap file is so these types can be referenced
by
#  other programs (such as a web server) even if the specific support
package
#  for that type is not installed.
#
#  Users can add their own types if they wish by creating a ".mime.types"
#  file in their home directory.  Definitions included there will take
#  precedence over those listed here.
#
###


application/activemessage
application/andrew-insetez
application/annodex anx
application/applefile
application/atom+xmlatom
...
application/x-python-code   pyc pyo
...
text/x-python   py
...

wulfraed@debian:~$ cat /usr/share/applications/gvim.desktop 
[Desktop Entry]
Name=gVim
GenericName=Text Editor
...
TryExec=gvim
Exec=gvim -f %F
Terminal=false
Type=Application
Keywords=Text;editor;
Icon=gvim
Categories=Utility;TextEditor;Development;
StartupNotify=true
MimeType=text/english;text/plain;text/x-makefile;text/x-c++hdr;text/x-c++src;text/x-chdr;text/x-csrc;text/x-java;text/x-moc;text/x-pascal;text/x-tcl;text/x-tex;application/x-shellscript;text/x-c;text/x-c++;text/x-python;text/x-python3
wulfraed@debian:~$ 

 
ALL of that is needed to link a Python source code file (.py) to GVIM
editor, when clicked on from the desktop.

>UNIX's execve() is able to read the first line of an executable and
>invoke its interpreter.  I guess OS/2 was doing precisely that in a
>different way?
>
No... the UNIX/Linux shebang (and binary file equivalent magic-number)
is a deliberately written part of a file's "data" content (granted, the
linker writes it for executable binaries).

The description for OS/2 is close to the little used Windows STREAMS
feature.

https://docs.microsoft.com/en-us/windows/win32/fileio/file-streams

Re: some problems for an introductory python test

[MRAB]

On 2021-08-12 18:52, Grant Edwards wrote:

On 2021-08-12, Hope Rouselle  wrote:


OS/2 had all kinds of amazing features (for its time). [...] 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.


Yeah, that's kinda nice.  Isn't that a UNIX design?  A file is a
sequence of bytes?  Users decide what to put in them?


I think what he's talking about is allowing the user to attach
arbitrary _metadata_ to the file -- metadata that exists separately
and independently from the normal data that's just a "sequence of
bytes". IOW, something similar to the "resource fork" that MacOS used
to have. https://en.wikipedia.org/wiki/Resource_fork


So OS/2 was taking advantage of that to integrate it well with the
system.  Windows was doing the same, but integrating the system with
files in odd ways --- such as a registry record to inform the system
which programs open which files?  (That does sound more messy.)


Windows never had filesystems that supported metadata like OS/2 and
MacOS did. The registry was an ugly hack that attempted (very poorly)
to make up for that lack of metadata.


FYI, NTFS does support Alternate Data Streams.


UNIX's execve() is able to read the first line of an executable and
invoke its interpreter.  I guess OS/2 was doing precisely that in a
different way?


No, that's not at all the same thing. The #! line is part of the
normal file data. It's part of the 'sequence of bytes'. Metadata
maintained by Unix filesystems comprises a very limited and
pre-defined set of attributes present in the inode.


--
https://mail.python.org/mailman/listinfo/python-list

Re: some problems for an introductory python test

[Chris Angelico]

On Fri, Aug 13, 2021 at 5:03 AM Grant Edwards  wrote:
>
> On 2021-08-12, Hope Rouselle  wrote:
>
> >> OS/2 had all kinds of amazing features (for its time). [...] 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.
> >
> > Yeah, that's kinda nice.  Isn't that a UNIX design?  A file is a
> > sequence of bytes?  Users decide what to put in them?
>
> I think what he's talking about is allowing the user to attach
> arbitrary _metadata_ to the file -- metadata that exists separately
> and independently from the normal data that's just a "sequence of
> bytes". IOW, something similar to the "resource fork" that MacOS used
> to have. https://en.wikipedia.org/wiki/Resource_fork

Correct. OS/2's EAs are name/value pairs (with the value potentially
being a set of values - think how a Python dict maps keys to values,
but the values could be lists), with a few names having significance
to the system, like .TYPE and .LONGNAME (used on file systems that
didn't support longnames - yes, that's possible, since EAs could be
stored in a hidden file on a FAT disk).

> > So OS/2 was taking advantage of that to integrate it well with the
> > system.  Windows was doing the same, but integrating the system with
> > files in odd ways --- such as a registry record to inform the system
> > which programs open which files?  (That does sound more messy.)
>
> Windows never had filesystems that supported metadata like OS/2 and
> MacOS did. The registry was an ugly hack that attempted (very poorly)
> to make up for that lack of metadata.

Very poor indeed - it was very very common back then for Windows
programs to blat themselves all over the registry and then leave it
all behind when you nuke that thing. With EAs, it's all part of the
file itself and will be cleaned up by a simple directory removal.

ChrisA
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: some problems for an introductory python test

[Grant Edwards]

On 2021-08-12, Hope Rouselle  wrote:

>> OS/2 had all kinds of amazing features (for its time). [...] 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.
>
> Yeah, that's kinda nice.  Isn't that a UNIX design?  A file is a
> sequence of bytes?  Users decide what to put in them?

I think what he's talking about is allowing the user to attach
arbitrary _metadata_ to the file -- metadata that exists separately
and independently from the normal data that's just a "sequence of
bytes". IOW, something similar to the "resource fork" that MacOS used
to have. https://en.wikipedia.org/wiki/Resource_fork

> So OS/2 was taking advantage of that to integrate it well with the
> system.  Windows was doing the same, but integrating the system with
> files in odd ways --- such as a registry record to inform the system
> which programs open which files?  (That does sound more messy.)

Windows never had filesystems that supported metadata like OS/2 and
MacOS did. The registry was an ugly hack that attempted (very poorly)
to make up for that lack of metadata.

> UNIX's execve() is able to read the first line of an executable and
> invoke its interpreter.  I guess OS/2 was doing precisely that in a
> different way?

No, that's not at all the same thing. The #! line is part of the
normal file data. It's part of the 'sequence of bytes'. Metadata
maintained by Unix filesystems comprises a very limited and
pre-defined set of attributes present in the inode.

--
Grant



-- 
https://mail.python.org/mailman/listinfo/python-list

Re: some problems for an introductory python test

[Chris Angelico]

On Fri, Aug 13, 2021 at 2:15 AM Hope Rouselle  wrote:
>
> Chris Angelico  writes:
>
> > 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.
>
> How is it possible that Microsoft would take part of the code of OS/2?
> Did IBM just hand it to them?

I presume both companies had all of the code. It was a matter of
licensing, though. There were a few components that were saddled with
awkward restrictions due to the dual ownership (for instance, HPFS386
was Microsoft-controlled, but vanilla HPFS was fine - kinda like the
difference between LZW and LZ77).

> > (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.
>
> Beautiful. :-) So if all libraries were around in each system, they had
> perfect compatibility?

The 16-bit loaders were fine, but the 32-bit loaders were different,
so this trick basically meant having three different copies of the
code wrapped up in a single executable.

> > 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.
>
> Yeah, that's kinda nice.  Isn't that a UNIX design?  A file is a
> sequence of bytes?  Users decide what to put in them?  So OS/2 was
> taking advantage of that to integrate it well with the system.  Windows
> was doing the same, but integrating the system with files in odd ways
> --- such as a registry record to inform the system which programs open
> which files?  (That does sound more messy.)

Something like that, but with a lot more metadata. Modern OSes don't
seem to work that way any more.

> UNIX's execve() is able to read the first line of an executable and
> invoke its interpreter.  I guess OS/2 was doing precisely that in a
> different way?

Kinda, but instead of having the choice of interpreter be inside the
file contents itself, the choice was in the file's metadata. Still
part of the file, but if you open and read the file, it isn't any
different.

> > 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??).
>
> I cannot imagine.  I always wondered what REXX was about --- I saw
> programs sometimes written in some website whose name is something like
> Rosetta Code.  REXX looked so weird.  (``Who would program in that?'')
> But I see now there is a context to it.

Yeah. It was a strange choice by today's standards, but back then,
most of my GUI programs were written in REXX.

https://en.wikipedia.org/wiki/VX-REXX
http://www.edm2.com/0206/vrexx.html

(There were other tools too - VisPro REXX, VREXX, DrDialog, and
various others - but VX-REXX was where most of my dev work happened.)

> > Probably the most
> > notable feature, by today's standards, was that it had a single input
> > 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.)
>
> Wow, I kinda feel the same as you here.  I think this justifies perhaps
> using a hardware solution.  (Crazy idea?! 

Re: some problems for an introductory python test

[Hope Rouselle]

Chris Angelico  writes:

[...]

>> > [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.

How is it possible that Microsoft would take part of the code of OS/2?
Did IBM just hand it to them?

> (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.

Beautiful. :-) So if all libraries were around in each system, they had
perfect compatibility?

> 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.

Yeah, that's kinda nice.  Isn't that a UNIX design?  A file is a
sequence of bytes?  Users decide what to put in them?  So OS/2 was
taking advantage of that to integrate it well with the system.  Windows
was doing the same, but integrating the system with files in odd ways
--- such as a registry record to inform the system which programs open
which files?  (That does sound more messy.)

UNIX's execve() is able to read the first line of an executable and
invoke its interpreter.  I guess OS/2 was doing precisely that in a
different way?

> 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??). 

I cannot imagine.  I always wondered what REXX was about --- I saw
programs sometimes written in some website whose name is something like
Rosetta Code.  REXX looked so weird.  (``Who would program in that?'')
But I see now there is a context to it.

> 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.)

Yeah, REXX looks horrible at first.  But arbitrary-precision is
definitely very attractive. 

Re: some problems for an introductory python test

[Chris Angelico]

On Thu, Aug 12, 2021 at 9:23 AM Dennis Lee Bieber  wrote:
>
> On Thu, 12 Aug 2021 06:15:28 +1000, Chris Angelico 
> declaimed the following:
>
>
> >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 was spoiled by the Amiga variant of REXX. Most current
> implementations (well, Regina is the only one I've looked at) can just pass
> command to the default shell. The Amiga version took advantage of Intuition
> Message Ports (OS supported IPC). That allowed it to "address
> " any application that defined an ARexx port, allowing ARexx
> to be used as a scripting language for that application (and with multiple
> applications, one could easily fetch data from app1 and feed it to app2).
> ARexx did not, to my memory, implement arbitrary precision math.

The same functionality was available in OS/2, but not heavily used.
You could 'address cmd commandname' to force something to be
interpreted as a shell command, but that was about it. However, I
built a MUD that used REXX as its scripting language, and the default
destination was sending text back to the person who sent the command;
and you could, of course, still 'address cmd' to run a shell command.

> 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...
>

Win32 doesn't really have it. Unix sockets are kinda there but you
identify something by a path to the socket, not the name of the
application. But I think dbus is probably the closest to what you're
thinking of.

ChrisA
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: some problems for an introductory python test

[Dennis Lee Bieber]

On Wed, 11 Aug 2021 09:27:38 -0300, Hope Rouselle 
declaimed the following:



>
>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.
>

Then I would posit you are teaching the wrong level... What you
describe is what would be found a "data structures" and/or "algorithms"
course -- which is a second year, if not third year course in my (ancient)
history. Such a course presumes one already knows at least on programming
language well enough that they can take description of an algorithm (or
even more detailed, pseudo-code) and translate it into the language they
know. This means the students /must/ know basic if/then/else, iterative
looping (which may, at common core, mean coding with a numerical index,
rather than pulling objects themselves out of the indexable structure --
since not all languages support object iteration), conditional looping
(including how to turn a "repeat/until" into the equivalent "while" (I was
tempted to say "while/wend" but that is specific to languages that need
block terminators). Slicing with a stride isn't really useful to most
algorithm development -- it's more of trick in normal Python.

So... The first thing I would drop is the RESTRICTION to only use what
you've covered in prior sessions... Let the students read the language
reference manual, peruse the library reference manual, and allow them to
use whatever "advanced" techniques they are able to understand on their
own. Granted you may have to restrict some features if discussing a
"common" data structure (queue, stack, maybe even advanced list
manipulation -- allow pop() and del, as those are how one would implement
queue and stack). Same for sorting -- if covering bubble, insertion, heap,
and (horrors) multipass sort/merge using working files, obviously the
Python sort()/sorted() are off-limits.

For my Algorithm/Data Structure course (circa 1978), the instructor
allowed us to use any language /he/ could understand (so no SNOBOL). At the
time I'd gone through intro/advanced FORTRAN-4, intro/advanced COBOL, Sigma
Assembly, UCSD Pascal (not on the campus main computer, just a pair of
LSI-11s), and BASIC. The assignment was a "Hashed Head, Multiply-Linked
List". I chose to do that assignment using BASIC! In nearly 45 years, I've
only seen ONE real-world implementation of the HHMLL -- The file system
used by the Commodore Amiga. (Hash the first component of the path/name,
that maps to one of 64 entries in the root directory block; each entry
points the start of a linked list, follow the list until you reach the
block with the component name; if it is a directory block, hash the next
component and repeat; if it is a file block, the "entries" point to data
blocks instead of lists)



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

-- 
https://mail.python.org/mailman/listinfo/python-list

Re: some problems for an introductory python test

[Dennis Lee Bieber]

On Thu, 12 Aug 2021 06:15:28 +1000, Chris Angelico 
declaimed the following:


>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 was spoiled by the Amiga variant of REXX. Most current
implementations (well, Regina is the only one I've looked at) can just pass
command to the default shell. The Amiga version took advantage of Intuition
Message Ports (OS supported IPC). That allowed it to "address
" any application that defined an ARexx port, allowing ARexx
to be used as a scripting language for that application (and with multiple
applications, one could easily fetch data from app1 and feed it to app2).
ARexx did not, to my memory, implement arbitrary precision math.

Any statement in a REXX script that was not parsable as REXX would be
passed on the currently "addressed" command host.

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...


But I've harangued long enough.



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

-- 
https://mail.python.org/mailman/listinfo/python-list

Re: some problems for an introductory python test

[Chris Angelico]

On Thu, Aug 12, 2021 at 7:25 AM Rob Cliffe via Python-list
 wrote:
>
> On 11/08/2021 19:10, MRAB wrote:
> > 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.)
> >>
> I looked at the if3 example, and I was gobsmacked.  I momentarily
> assumed that "if3" was parsed as "if 3", although that clearly makes no
> sense ("if3" is a valid identifier).
> Then I saw the "if0" example and I was even more gobsmacked, because it
> showed that my assumption was wrong.
> I've never used type annotations, I've never planned to used them. And
> now that all is revealed, I'm afraid that my reaction is: I'm even more
> inclined never to use them, because these examples are (to me) so confusing.

Don't judge a feature based on its weirdest example. Based on this
example, you should avoid ever using the len() built-in function:

>>> def show_count(n, word):
... return "{{}} {{:{0}.{0}}}".format(len(word)-(n==1)).format(n, word)
...
>>> show_count(0, "things")
'0 things'
>>> show_count(1, "things")
'1 thing'
>>> show_count(5, "things")
'5 things'
>>> show_count(2, "widgets")
'2 widgets'
>>> show_count(1, "widgets")
'1 widget'

Any syntax can be abused. And the same thing would happen in any other
context. The only difference is that, in a declaration like "if3:
print()", the name if3 doesn't have to have been assigned already,
avoiding this problem:

>>> {
... if3: print("Hello")
... }
Traceback (most recent call last):
  File "", line 2, in 
NameError: name 'if3' is not defined

ChrisA
-- 
https://mail.python.org/mailman/listinfo/python-list

RE: some problems for an introductory python test

[Avi Gross via Python-list]

This conversation has, of course, veered away from the original question so
I am starting afresh.

My memory of the original question is about how one sets up a test for
material covered in class or associated materials for what sounds like a
beginner class. I am not sure whether this would be the place for anyone to
ask such a question, especially as we have no real idea what was taught and
expected. Python is too rich a language and can be taught all kinds of ways
including many that largely ignore object-orientedness or other ways that
professionals use and appreciate.

There are lots of others who have taught such classes and plenty of books.
One can look to see what kinds of questions they use, and, where allowed,
borrow some, suitably adjusted. Any textbooks actually used for a course may
be an excellent place to start.

When I have taught, I like to do things incrementally. Tests are made up
based on what is talked about and stressed, perhaps with harder questions
asking for some innovation. So you may end up teaching how to do some things
without loops such as the example where you largely repeat some code in-line
five times. You might show how to do the same thing using dreaded
GOTO-statements in the OLD days but rarely now. Nowadays you might introduce
while loops or their repeat/do/for variants. In Python, you may well
introduce abbreviated variants such as list comprehensions.

So if testing the above, it is fair to specify in a question what NOT to
use. You can ask for no use of loops, or you can specify you want them to
use nothing but methods X or Y and so on. And since there are so many
modules out there, you might specify that no importing is allowed as that
defeats the purpose. I mean, if the purpose is to teach them how to
logically write a program that implements an algorithm as compared to just
calling a function already made.

As noted, some very decent projects are simply asking the student to create
something others have already done and one way to test how well they did it
is to compare the output of their work with a debugged solution.

Real programmers may at some point shift to using all kinds of constructs
that help them write lots of code faster and with fewer errors but beginner
students need something not very low level (like assembler?) but also not
very high level, I would think.

But debates about object oriented are fine for us philosophers but not
really of much use for the question I thought was asked.


-- 
https://mail.python.org/mailman/listinfo/python-list

Re: some problems for an introductory python test

[Rob Cliffe via Python-list]

On 11/08/2021 19:10, MRAB wrote:

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.)

I looked at the if3 example, and I was gobsmacked.  I momentarily 
assumed that "if3" was parsed as "if 3", although that clearly makes no 
sense ("if3" is a valid identifier).
Then I saw the "if0" example and I was even more gobsmacked, because it 
showed that my assumption was wrong.
I've never used type annotations, I've never planned to used them. And 
now that all is revealed, I'm afraid that my reaction is: I'm even more 
inclined never to use them, because these examples are (to me) so confusing.

Rob Cliffe
--
https://mail.python.org/mailman/listinfo/python-list

Re: some problems for an introductory python test

[Chris Angelico]

On Thu, Aug 12, 2021 at 5:00 AM Hope Rouselle  wrote:
>
> Chris Angelico  writes:
>
> > On Wed, Aug 11, 2021 at 4:18 AM Hope Rouselle  
> > wrote:
> >>
> >> Chris Angelico  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 

Re: some problems for an introductory python test

[Hope Rouselle]

Chris Angelico  writes:

> On Wed, Aug 11, 2021 at 4:18 AM Hope Rouselle  wrote:
>>
>> Chris Angelico  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.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: some problems for an introductory python test

[Hope Rouselle]

Chris Angelico  writes:

> On Wed, Aug 11, 2021 at 4:18 AM Hope Rouselle  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 

Re: some problems for an introductory python test

[Hope Rouselle]

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

Re: some problems for an introductory python test

[Greg Ewing]

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

Re: some problems for an introductory python test

[Hope Rouselle]

Terry Reedy  writes:

> On 8/10/2021 5:27 PM, Hope Rouselle wrote:
>> Terry Reedy  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 "", line 1, in 
[1] [1]
IndexError: list index out of range

And that's when it hit me. :-)  Thanks!
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: some problems for an introductory python test

[MRAB]

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.)


--
https://mail.python.org/mailman/listinfo/python-list

Re: some problems for an introductory python test

[Wolfram Hinderer via Python-list]

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

Re: some problems for an introductory python test

[Terry Reedy]

On 8/10/2021 5:27 PM, Hope Rouselle wrote:

Terry Reedy  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

--
https://mail.python.org/mailman/listinfo/python-list

Re: some problems for an introductory python test

[Hope Rouselle]

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

Re: some problems for an introductory python test

[Hope Rouselle]

Chris Angelico  writes:

> On Wed, Aug 11, 2021 at 4:14 AM Hope Rouselle  wrote:
>>
>> Chris Angelico  writes:
>>
>> > On Tue, Aug 10, 2021 at 7:25 AM Hope Rouselle
>> >  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("a") = {"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. :-)
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: some problems for an introductory python test

[Terry Reedy]

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

--
https://mail.python.org/mailman/listinfo/python-list

Re: some problems for an introductory python test

[Chris Angelico]

On Wed, Aug 11, 2021 at 4:18 AM Hope Rouselle  wrote:
>
> Chris Angelico  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.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: some problems for an introductory python test

[Chris Angelico]

On Wed, Aug 11, 2021 at 4:18 AM Hope Rouselle  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
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: some problems for an introductory python test

[Chris Angelico]

On Wed, Aug 11, 2021 at 4:14 AM Hope Rouselle  wrote:
>
> Chris Angelico  writes:
>
> > On Tue, Aug 10, 2021 at 7:25 AM Hope Rouselle  
> > 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("a") = {"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(, {'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
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: some problems for an introductory python test

[Hope Rouselle]

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

Re: some problems for an introductory python test

[Hope Rouselle]

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

Re: some problems for an introductory python test

[Hope Rouselle]

Chris Angelico  writes:

> On Tue, Aug 10, 2021 at 7:25 AM Hope Rouselle  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("a") = {"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.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: some problems for an introductory python test

[Chris Angelico]

On Tue, Aug 10, 2021 at 1:41 PM Mats Wichmann  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
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: some problems for an introductory python test

[Mats Wichmann]

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

--
https://mail.python.org/mailman/listinfo/python-list

Re: some problems for an introductory python test

[Chris Angelico]

On Tue, Aug 10, 2021 at 8:19 AM Mats Wichmann  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
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: some problems for an introductory python test

[Mats Wichmann]

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)

>>> 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!






--
https://mail.python.org/mailman/listinfo/python-list

Re: some problems for an introductory python test

[Chris Angelico]

On Tue, Aug 10, 2021 at 7:25 AM Hope Rouselle  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("a") = {"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
-- 
https://mail.python.org/mailman/listinfo/python-list

some problems for an introductory python test

[Hope Rouselle]

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("a") = {"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