Re: some problems for an introductory python test
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
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
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
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
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
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
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: on slices, negative indices, which are the equivalent procedures?
dn writes:
> Apologies for lateness.
That's alright. Thanks for the marvelous post.
> Coincidentally, I've been asked to speak to our local Python Users'
> Group on slicing. Herewith an attempt to modify those demos around your
> data/question. Apologies if the result is thus somewhat lacking in flow.
> Also, whereas I prefer to illustrate 'how it works', I perceive that you
> are used to learning 'rules' and only thereafter their application (the
> teaching-practice under which most of us learned) - so, another reason
> for mixing-things-up, to suit yourself (hopefully).
Well observed. (I suppose it is a habit of mine to try to infer the
axioms of things.)
[...]
> On 06/08/2021 05.35, Jack Brandom wrote:
>> The FAQ at
>>
>> https://docs.python.org/3/faq/programming.html#what-s-a-negative-index
>>
>> makes me think that I can always replace negative indices with positive
>> ones --- even in slices, although the FAQ seems not to say anything
>> about slices.
>
> Yes, it can be done.
I thought your own post confirmed it cannot. I'll point it out below.
>> With slices, it doesn't seem to always work. For instance, I can
>> reverse a "Jack" this way:
>>
> s = "Jack Brandom"
> s[3 : -13 : -1]
>> 'kcaJ'
>>
>> I have no idea how to replace that -13 with a positive index. Is it
>> possible at all?
>
> Yes it is - but read on, gentle reader...
>
> If we envisage a string:
> - a positive index enables the identification of characters, from
> left-to-right
> - a negative index 'counts' from right-to-left, ie it takes the
> right-most elements/characters.
>
> The length of a string (sequence) is defined as len( str ). Accordingly,
> there is a formula which can 'translate' the length and either statement
> of the index's relative-location, to the other. To quote one of the
> web.refs (offered below) "If i or j is negative, the index is relative
> to the end of sequence s: len(s) + i or len(s) + j is substituted. But
> note that -0 is still 0."
>
> Clear as mud? Please continue...
>
>
>> But this example gives me the idea that perhaps each slice is equivalent
>> to a certain loop (which I could write in a procedure). So I'm looking
>> for these procedures. If I can have the procedures in mind, I think I
>> will be able to undersand slices without getting surprised.
>>
>> Do you have these procedures from the top of your mind? While I haven't
>> given up yet, I am not getting too close. Thank you!
>
>
> Us Silver-Surfers have to stick-together. So, let's try closing the gap.
>
> Rather than attempting to re-build Python, perhaps some experimenting
> with sequences, indexing, and slicing is what is required? I can see
> writing a simulation routine as a perfectly-valid (proof of)
> learning-approach - and one we often applied 'back then'. However, is it
> the 'best' approach? (Only you can judge!)
I like extreme clarity and certainty. While my approach did not give me
too much certainty, at least I got a conjecture --- so I posted my
hypothesis here to give everyone a chance to look and spot: ``oh, that's
not gonna work''. Simulating in software is a great way to precisely
describe how something works, so I did it.
[...]
> Alternately, (with apologies for 'cheating') this may be some help:
That's great.
print( " Pos Ltr Neg" )
print( " ndx ndx" )
for positive_index,
> character,
> negative_index in zip( range( 12 ),
>name,
>range( -12, 0 )
> ):
> ... print( f"{ positive_index:4} { character } { negative_index:4}" )
>
> Pos Ltr Neg
> ndx ndx
>0 J -12
>1 a -11
>2 c -10
>3 k -9
>4 -8
>5 B -7
>6 r -6
>7 a -5
>8 n -4
>9 d -3
> 10 o -2
> 11 m -1
So if we begin at, say, -2 and work backwards to the beginning of the
string so as to include the "J", the index must be -13 --- there is no
positive index that could take the place of -13. (And that's because
--- I eventually realized --- there is no positive number to the left of
zero. You, of course, notice the same. So why are you saying it's
possible to substitute negative indices with positive?)
[...]
> Another reason why folk have difficulty with using an index or offset is
> the subtle difference between "cardinal" and "ordinal" numbers. Cardinal
> numbers are for counting, eg the number of letters in the name. Whereas,
> ordinal numbers refer to a position, eg first, second, third... (there
> are also "nominal numbers" which are simply labels, eg Channel 3 TV -
> but we're not concerned with them). There is an implicit problem in that
> Python uses zero-based indexing, whereas spoken language starts with a
> word like "first" or "1st" which looks and sounds more like "one" than
> "zero". Despite it being a junior-school 'math' topic, it is easy to
> fail to recognise which of the two types of num
Re: some problems for an introductory python test
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 the
Re: some problems for an introductory python test
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
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
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: on slices, negative indices, which are the equivalent procedures?
On Wed, 11 Aug 2021 11:59:11 -0300, Jack Brandom
declaimed the following:
>
>Where are these production rules coming from? They're not at
>
> https://docs.python.org/3/reference/grammar.html
>
>The word ``stride'' doesn't appear in this grammar.
>
Possibly from older versions of the grammar, before simplification to
just . Originally, the "stride" term was added in response to
requests from the numerical library developers (NumPy seems to be the
survivor of that cluster). At the time, it wasn't envisioned to be usable
with regular Python objects.
https://en.wikipedia.org/wiki/Array_slicing#1991:_Python
"""
The stride syntax (nums[1:5:2]) was introduced in the second half of the
1990s, as a result of requests put forward by scientific users in the
Python "matrix-SIG" (special interest group).
"""
As for the grammar... Would you prefer that from 2.7?
trailer: '(' [arglist] ')' | '[' subscriptlist ']' | '.' NAME
subscriptlist: subscript (',' subscript)* [',']
subscript: '.' '.' '.' | test | [test] ':' [test] [sliceop]
sliceop: ':' [test]
test: or_test ['if' or_test 'else' test] | lambdef
or_test: and_test ('or' and_test)*
and_test: not_test ('and' not_test)*
not_test: 'not' not_test | comparison
--
Wulfraed Dennis Lee Bieber AF6VN
[email protected]://wlfraed.microdiversity.freeddns.org/
--
https://mail.python.org/mailman/listinfo/python-list
Re: some problems for an introductory python test
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 [email protected]://wlfraed.microdiversity.freeddns.org/ -- https://mail.python.org/mailman/listinfo/python-list
Re: some problems for an introductory python test
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 [email protected]://wlfraed.microdiversity.freeddns.org/ -- https://mail.python.org/mailman/listinfo/python-list
Re: some problems for an introductory python test
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: on slices, negative indices, which are the equivalent procedures?
On 12/08/2021 02.59, Jack Brandom wrote: > dn writes: > ... >> Also, whereas I prefer to illustrate 'how it works', I perceive that you >> are used to learning 'rules' and only thereafter their application (the >> teaching-practice under which most of us learned) - so, another reason >> for mixing-things-up, to suit yourself (hopefully). > > Well observed. (I suppose it is a habit of mine to try to infer the > axioms of things.) After a career involving various forms of vocational training and tertiary education, I've met many different folk, (ultimately) each with his/her own approach. Undoubtedly, the best way to answer someone's question is to understand why they are asking in the first place. Learning a programming language requires the alignment of one's own "mental model" with that of the language's rules and idioms. Thus, understanding your mental model enables a third-party to understand where correction may be necessary or omission exists. [can you tell that my colleagues and I were having just this discussion this morning?] Having spent the last few years working with a series of MOOCs (usual disclaimers: edX platform, not Python topics) I've noticed that when we first started, our trainees were almost-exclusively post-grads, ie had a 'learning habit', curiosity, a set of expectations, and (most of the time) some computing background. As time has gone by, these characteristics have all changed, eg the expectations have broadened and may be more 'interest' than 'professional, and we cannot expect that everyone has met software development previously... That's also a characteristic of the Python language: that as it has become more popular, the 'new entrants' are very different people, and the 'new features' and (newly) added libraries have become more diverse (in application)! NB "axioms" is basically "mental model". >> On 06/08/2021 05.35, Jack Brandom wrote: >>> The FAQ at >>> >>> https://docs.python.org/3/faq/programming.html#what-s-a-negative-index >>> >>> makes me think that I can always replace negative indices with positive >>> ones --- even in slices, although the FAQ seems not to say anything >>> about slices. >> >> Yes, it can be done. > > I thought your own post confirmed it cannot. I'll point it out below. Yes, it can! (key means to starting a 'religious war'). (not starting a 'war', or even meaning to be unkind, I'm embarking on a Socratic approach rather than giving you an immediate answer - you can handle it/beat me up later...) Just maybe you are guilty of (only) 'thinking inside the box'? Have you come-across the 'connect nine dots with four lines' brain-teaser? https://lateralaction.com/articles/thinking-outside-the-box/ >>> With slices, it doesn't seem to always work. For instance, I can >>> reverse a "Jack" this way: >>> >> s = "Jack Brandom" >> s[3 : -13 : -1] >>> 'kcaJ' If this were a fight (between us), there is me 'hitting' you with the answer. However, the 'fight' is waiting for 'the penny to drop' in your mind. So, please continue:- As warned, here's where the misapprehensions begin:- >>> But this example gives me the idea that perhaps each slice is equivalent >>> to a certain loop (which I could write in a procedure). So I'm looking ... Then the old men begin waving their walking-sticks around (whilst others wish there was such a thing as a negative-walking-stick):- >> Us Silver-Surfers have to stick-together. So, let's try closing the gap. ... > I like extreme clarity and certainty. While my approach did not give me > too much certainty, at least I got a conjecture --- so I posted my > hypothesis here to give everyone a chance to look and spot: ``oh, that's > not gonna work''. Simulating in software is a great way to precisely > describe how something works, so I did it. Eminently reasonable. The 'problem' (and it lies at the very roots of instructional design) is that 'learning Python' involves BOTH width and depth, ie there's a lot to learn! 'Pop Psy' talks about a 'learning curve' and how steep it might be... After a while, one realises that it is not necessary to learn the full 'width' - after all, does that mean just 'Python', does it include the PSL (Python Standard Library), does it stop at PyPi, or where? Similarly, with depth - is it worth knowing all there is to know about slicing or might a study of comprehensions yield more 'fruit'? On this list, I've referred more than once to, "some 'dark corner of Python' in which I've never previously ventured". Python is described as having a relatively-shallow learning curve (cf Java, for example), which evidences/presumes a more breadth-first approach. Accordingly, how does one split-up 'learning Python' into manageable "chunks" - or in the words of software development, an MVP (Minimum Viable Product)? An answer to that may be to get 'a good handle on' positive indexing, and then 'move on'. Thus, characteristics such as zero-base, < len( sequence ), etc. Later, wh
Re: on slices, negative indices, which are the equivalent procedures?
On 12/08/2021 10.32, Dennis Lee Bieber wrote:
> On Wed, 11 Aug 2021 11:59:11 -0300, Jack Brandom
> declaimed the following:
>> Where are these production rules coming from? They're not at
>> https://docs.python.org/3/reference/grammar.html
>> The word ``stride'' doesn't appear in this grammar.
>
> Possibly from older versions of the grammar, before simplification to
> just . Originally, the "stride" term was added in response to
> requests from the numerical library developers (NumPy seems to be the
> survivor of that cluster). At the time, it wasn't envisioned to be usable
> with regular Python objects.
>
> https://en.wikipedia.org/wiki/Array_slicing#1991:_Python
> """
> The stride syntax (nums[1:5:2]) was introduced in the second half of the
> 1990s, as a result of requests put forward by scientific users in the
> Python "matrix-SIG" (special interest group).
> """
>
> As for the grammar... Would you prefer that from 2.7?
>
> trailer: '(' [arglist] ')' | '[' subscriptlist ']' | '.' NAME
> subscriptlist: subscript (',' subscript)* [',']
> subscript: '.' '.' '.' | test | [test] ':' [test] [sliceop]
> sliceop: ':' [test]
>
> test: or_test ['if' or_test 'else' test] | lambdef
> or_test: and_test ('or' and_test)*
> and_test: not_test ('and' not_test)*
> not_test: 'not' not_test | comparison
Are you trying to give us nightmares @wulfraed?
Yes, the somewhat piecemeal coverage(s) are explained by changes over
time, and the different applications folk might apply or differing
motivations of the people involved.
I've been trying to remember if we had negative-steps in FORTRAN
do-loops especially once the capability to define subscripting-ranges
came 'in' (but can't be bothered researching further). If it was
available, or available within other, older languages, then might this
explain Python's adoption?
It is quite plain (Ref.Man 6.3.3 and 3.2) that initially the plans for
stride/step did not include the negative 'direction'. Perhaps the
initial coders thought: 'while I'm doing this, adding ... will be easy
to do', aka "famous last words", see also "YAGNI".
Negative-stepping comes-across as a bit of a party-trick. I wonder if
anyone can offer a (professional) application?
Similarly, when adding a __getitem__() to a custom-class, has anyone had
need to implement/account for negative-stepping, to achieve some purpose?
PS I'm waiting (with bated breath*) for @Chris' bared teeth...
* or is that "baited"?
--
Regards,
=dn
--
https://mail.python.org/mailman/listinfo/python-list
