🌐 Mailman 3 August 2021 - Python-list - python.org

Re: some problems for an introductory python test
by Greg Ewing Aug. 12, 2021

Aug. 12, 2021

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

3 2

FW: Troubleshoot python app launch
by Tan Jane Aug. 12, 2021

Aug. 12, 2021

From: [1]Tan Jane Sent: Wednesday, 11 August 2021 7:48 PM To: [2]python-list(a)python.org Subject: Troubleshoot python app launch Hi, I encountered attached screenshot issue while launching the python application downloaded for windows. Please advice on the above. Thanks, Jane Sent from [3]Mail for Windows 10 References Visible links 1. mailto:chenghuitan02@gmail.com 2. mailto:python-list@python.org 3. https://go.microsoft.com/fwlink/?LinkId=550986

2 1

Is there a better way to create a list of None objects?
by Stephen Tucker Aug. 12, 2021

Aug. 12, 2021

Hi, I thought I'd share the following piece of code that I have recently written (a) to check that what I have done is reasonable - even optimum, (b) to inform others who might be wanting to do similar things, and (c) to invite comment from the community. ------------------------------------------- # # Yes: Create an empty list of Band Limits for this language # # Note. The rather complicated logic on the right-hand side of the # assignment below is used here because none of the following # alternatives had the desired effect: # # Logic Effect # # [None * 8] TypeError: unsupported operand type(s) for *: ... # [(None) * 8] TypeError: unsupported operand type(s) for *: ... # [((None)) * 8] TypeError: unsupported operand type(s) for *: ... # [(None,) * 8] [(None, None, None, None, None, None, None, None)] # list ((None) * 8) TypeError: unsupported operand type(s) for *: ... # diclll_BLim [thisISO_] = list ((None,) * 8) ------------------------------------------- Thanks in anticipation. Stephen Tucker.

4 4

Re: on slices, negative indices, which are the equivalent procedures?
by Jack Brandom Aug. 12, 2021

Aug. 12, 2021

dn <PythonList(a)DancesWithMice.info> 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 number is in-use. The len( > sequence ) provides a cardinal number. An index is an ordinal number. That's well-observed. But, as you say, "first" takes us to the number 1. It is not very easy to equate "first" with zero. So I might as well just forget about the distinction between cardinal and ordinal in Python indexing. > Using the "rules" (above) and transforming around len( "Jack" ), one > arrives at suitable 'translation' formulae/formulas: > > negative-index = -1 * ( len( sequence ) - positive-index ) > positive-index = len( sequence ) + negative-index That's nice. I didn't write them in this form and I suppose yours is superior. > The above rules describing an index do not apply to a slice's "start", > "stop", or "step" values! The documentation expresses: > > proper_slice ::= [lower_bound] ":" [upper_bound] [ ":" [stride] ] > lower_bound ::= expression > upper_bound ::= expression > stride ::= expression > > Elsewhere in the docs the rules are described using to i, j, and k. NB > in this context "k" is not the "stride"! 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. [...] > Lesson: > Whereas some like to talk of ( start:stop:step ), it might be more > helpful to verbalise the relationships as "starting at:" and "stopping > before"! That's a nice vocabulary for the context. Thanks. [...] > Many people consider the "stride"/step to indicate a sub-selection of > elements from within the slice's defined extent. However, it may be more > helpful to consider the rôle of the stride as defining the 'direction' > in which elements will be selected (per 'reverse') - and thereafter its > 'step effect'. I agree. And also I stuck with thinking of slices as the procedures I wrote, so I will always think of them as loops. > Remembering the rules governing indexes/indices, be advised that these > do not apply to either the lower_bound or the upper_bound of a slice. > For example: > >>>> name[ +100 ] > Traceback (most recent call last): > File "<stdin>", line 1, in <module> > IndexError: string index out of range > > and: > >>>> name[ -100 ] > Traceback (most recent call last): > File "<stdin>", line 1, in <module> > IndexError: string index out of range > > yet: > >>>> name[ -100:+100 ] > 'Jack Brandom' > > Just as a "lower_bound" of 0 or None is taken to mean the first item in > the sequence, so any ludicrous value is also 'translated'. > > Similarly, despite knowing the length (of the example-data) is 12, a > slice's upper-bound that evaluates to a larger number will be 'rounded > down'. Nice. That's a case where my procedures (simulating slices) fail. Thanks! I'll refine them. [...] > The tricks differ if the 'target' is the family-name: > >>>> name[ 5: ] > 'Brandom' >>>> name[ -7: ] > 'Brandom' > > but to demonstrate with some non-default "bounds", (if you'll permit the > (weak-)humor - and with no insult intended to your good name) we could > describe distaste for a popular breakfast cereal (All Bran™): > >>>> name[ 1:9 ] > 'ack Bran' >>>> name[ -11:-3 ] > 'ack Bran' Lol. It's not even my name. I think maybe we should all use a different name at every post. Or perhaps a different name at every thread. The USENET is a place where poster names don't matter at all. It's only the content that matters. (``USENET is a strange place.'' -- Dennis Ritchie.) [...] > To round things out, here's some 'theory':- > > Contrary to practice, the Python Reference Manual (6.3.3 Slicings) says: > <<< > The formal syntax makes no special provision for negative indices in > sequences; however, built-in sequences all provide a __getitem__() > method that interprets negative indices by adding the length of the > sequence to the index (so that x[-1] selects the last item of x). The > resulting value must be a nonnegative integer less than the number of > items in the sequence, and the subscription selects the item whose index > is that value (counting from zero). Since the support for negative > indices and slicing occurs in the object’s __getitem__() method, > subclasses overriding this method will need to explicitly add that support. That's interesting. Thanks for the reference. It is precisely this kind of thing I was looking for. [...] > Finally, it is not forgotten that you want to code a loop which > simulates a slice with negative attributes. (although it is hoped that > after the above explanations (and further reading) such has become > unnecessary as a learning-exercise!) Has it become unnecessary? For using Python, sure. But as you noticed --- I like to see the rules and be able to write them myself. So it is necessary for certain types. :-) > Please recall that whilst a slice-object will not, a range-object will > work with a for-loop. So: > >>>> rng = range( 4, 0, -1 ) >>>> list( rng ) > [4, 3, 2, 1] >>>> for index in rng: > ... print( name[ index ], end=" " ) > ... > k c a >>> > > Oops! This looks familiar, so apply the same 'solution': > >>>> rng = range( 4, -1, -1 ) >>>> list( rng ) > [4, 3, 2, 1, 0] >>>> for index in rng: > ... print( name[ index ], end=" " ) > ... > k c a J > > The 'bottom line' is that such simulation code will become torturous > simply because indexes/indices follow different rules to slices! > > > Should you wish to persist, then may I suggest modifying mySlice(it, > beg, end, step = 1) to: > > def my_slice( sequence, lower_bound, upper_bound, stride=1 ): I will. Thanks for the advice. > and first splitting the implementation's decision-tree into two paths, > according to whether the stride is positive or negative, before getting > into 'the nitty-gritty'. That I had already done. > Perversely (if not, foolishly) I have indulged (and can't recommend > it!). Nevertheless, if you are determined, I will be happy to forward > some test conditions, upon request (caveat emptor!)... Yes, send me your tests! (``Caveat emptor'' noted.) (I had included all tests that appeared in this thread, but had missed, for example, "Jack Brandom"[-100 : 100]. Didn't occur to me this wouldn't blow an exception.) > Web.Refs/Further reading: > https://docs.python.org/3/tutorial/introduction.html > https://docs.python.org/3/reference/expressions.html#primaries > https://docs.python.org/3/library/functions.html > https://docs.python.org/3/tutorial/controlflow.html > https://docs.python.org/3/library/stdtypes.html#typesseq > https://docs.python.org/3/library/stdtypes.html#ranges > https://docs.python.org/3/reference/simple_stmts.html > https://docs.python.org/3/glossary.html > https://web.archive.org/web/20190321101606/https://plus.google.com/11521205… > https://docs.python.org/3/reference/datamodel.html Thank you so much.

3 4

Re: some problems for an introductory python test
by Hope Rouselle Aug. 11, 2021

Aug. 11, 2021

Chris Angelico <rosuav(a)gmail.com> writes: > On Wed, Aug 11, 2021 at 4:18 AM Hope Rouselle <hrouselle(a)jevedi.xotimo> wrote: >> >> Chris Angelico <rosuav(a)gmail.com> writes: >> >> [...] >> >> >> not disagreeing... and yeah I could have thought deeper about the >> >> answer, but I still think "notthing has been OOP" -> "yes it has, they >> >> just didn't realize it" was worth mentioning >> > >> > Oh yes, absolutely agree. >> >> At the same time, inside the machine nothing is OOP --- so all the OOP >> is no OOP at all and they just didn't realize it? This seems to show >> that OOP is about perspective. An essential thing for OOP is the >> keeping of states. Closures can keep state, so having procedures as >> first-class values allows us to say we are doing OOP too. (Arguments of >> procedures are messages and function application is message passing, >> with closures keeping a state --- and all the rest of OOP can be >> implemented with enough such functional technology.) In summary, OOP >> should not be defined as some special syntax, otherwise there is no OOP >> in ``2 + 2''. >> >> Having said that, I totally agree with all the nitpicking. > > Object orientation is a particular abstraction concept. It's not a > feature of the machine, it's a feature of the language that you write > your source code in. I've done OOP using IDL and CORBA, writing my > code in C and able to subclass someone else's code that might have > been written in some other language. [1] Central tenets of OOP > (polymorphism, inheritance, etc) can be implemented at a lower level > using whatever makes sense, but *at the level that you're writing*, > they exist, and are useful. > > Data types, variables, control flow, these are all abstractions. But > they're such useful abstractions that we prefer to think that way in > our code. So, *to us*, those are features of our code. To the > computer, of course, they're just text that gets processed into > actually-executable code, but that's not a problem. Total agreement. > So I would say that (in Python) there IS object orientation in "2 + > 2", and even in the Python C API, there is object orientation, despite > C not normally being considered an object-oriented language. But would you say that 2 + 2 is also an illustration of object orientation in any other language too? Regarding C, I have many times said that myself. If I wrote assembly, I'm sure I would do my best to create things like procedures --- a label and some bureaucracy to get arguments in and a return value out. > ChrisA > > [1] And boy oh boy was that good fun. The OS/2 Presentation Manager > had a wealth of power available. Good times, sad that's history now. I know OS/2 only by name. I never had the pleasure of using it. In fact, I don't even know how it looks. I must be a little younger than you are. But not too younger because I kinda remember its name. Was it a system that might have thought of competing against Microsoft Windows? :-) That's what my memory tells me about it.

4 4

Re: some problems for an introductory python test
by Hope Rouselle Aug. 11, 2021

Aug. 11, 2021

Chris Angelico <rosuav(a)gmail.com> writes: > On Wed, Aug 11, 2021 at 4:18 AM Hope Rouselle <hrouselle(a)jevedi.xotimo> wrote: >> >> I totally agree with you but I didn't know that even numbers were like >> that in Python. In fact, I still don't quite believe it... >> >> >>> 2.__add__(3) >> SyntaxError: invalid syntax > > Yeah, that's because "2." looks like the beginning of a float. > >> But then I tried: >> >> >>> (2).__add__(3) >> 5 >> >> Now I do believe it! :-) Awesome. I had no idea. > > You can also do it this way: > >>>> x = 2 >>>> x.__add__(3) > 5 > > But don't teach this; it ignores several problems. I wouldn't. This is all Python-stuff. The course chooses a language like Python, but it is not trying to teach Python --- it is trying to teach computer programming, that is, strategies in high-precision. [...] >> (*) More opinions >> >> So, yeah, the idea of a course like that is to try to simplify the world >> to students, but it totally backfires in my opinion. There is so much >> syntax to learn, so many little details... We spend the entire semester >> discussing these little details. > > Agreed, and if you try to teach all the syntax, you're inevitably > going to get bogged down like that. Indeed. >> I posted here recently a study of the semantics of slices. When I >> finally got it, I concluded it's not very simple. The course introduces >> a few examples and expects students to get it all from these examples. >> I would rather not introduce slices but teach students enough to write >> procedures that give them the slices. The slices are the fish; learning >> to write the procedures is the know-how. (I'm fine with even teaching >> them how to write procedures to add or subtract numbers [and the rest of >> arithmetic], although none of them would find mysterious what is the >> meaning of arithmetic expressions such as 3 + 6 - 9, even taking >> precedence of operators into account. That's syntax they already know. >> If we teach them the syntax of procedures, we could be essentially done >> with syntax.) > > A language like Python is useful, not because every tiny part of it is > easy to explain, but because the language *as a whole* does what is > expected of it. Toy languages are a lot easier to explain on a > concrete level (look up Brainf*ck - it has very few operations and > each one can be very simply defined), and that might be tempting in > terms of "hey, we can teach the entire language in ten minutes", but > they're utterly useless for students. Sure. I would never use a toy language like that. I think we need a compromise --- some syntax, but not too much; in fact, just a little bit of syntax. For instance, could we do away with slices? We could. If we learn one way of looping, we can build slices with procedures. This is a good opportunity in fact --- it will show students how slices really work and how to get what they want with it. (Then towards the end we could give out a lecture for anyone interested in Python --- ``while we didn't show you how Pythonists usually write, here's a few things that Pythonists would do that we didn't do in this course...'') > Instead, my recommendation would be: Entice students with power. > Pretend you're teaching some aspect of magic at a wizards' school and > make sure your students feel massively OP. Sure, they might not > understand what makes those cantrips work, but they know that they DO > work. You can have students casting print calls left and right, doing > complex incantations with list comprehensions, and even defining their > own classes, all without ever worrying about the details of how it all > works. Then once the "wow" is achieved, you can delve into the details > of how things actually function, transforming progressively from > "wizardry" to "science". I really like that, but I would predict that, in a typical university, professors are not really willing to go that way. Everything has to be extremely simple --- and a mess is made in trying to achive that. (In a sense, professors are all failing terribly. They're lucky that nobody is giving them a grade based on how effective they are as evidenced by the facts, however such thing would be done in practice if one were to take it seriously.) > And to be quite frank, a lot of code IS magic to most programmers. Definitely. You guys are showing me so much Python here that I've never seen --- which I expect, because I'm only paying attention at Python now since I'm conducting students through a course that's using it. (I admire the language, but I never used it in any project on my own. I probably would if I were not in love with other similar technology.) > Which isn't a problem. Do you REALLY need to understand how your CPU > does register renaming in order to benefit from it? Or do you need to > know every detail of the TCP packet header before using the internet? > Not likely. Not at all. (Although, of course, we like to know these stuff.) > Those details hide away under the covers, and we make happy use of > them. There's infinite knowledge out there, and you - and your > students - are free to dip into exactly as much as you're comfortable > with. ``A man after my own heart.''

2 1

Re: some problems for an introductory python test
by Hope Rouselle Aug. 11, 2021

Aug. 11, 2021

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

6 5

Re: some problems for an introductory python test
by Hope Rouselle Aug. 11, 2021

Aug. 11, 2021

Terry Reedy <tjreedy(a)udel.edu> writes: > On 8/10/2021 5:27 PM, Hope Rouselle wrote: >> Terry Reedy <tjreedy(a)udel.edu> writes: >> >>> On 8/10/2021 9:15 AM, Hope Rouselle wrote: >>>>>>> 2.__add__(3) >>>> SyntaxError: invalid syntax >>>> But then I tried: >>>> >>>>>>> (2).__add__(3) >>>> 5 >>> >>> Add a space is easier. >>>>>> 2 .__add__(3) >>> 5 >>>>>> >> Hah. That's brilliant! So cool. > > Python is a little looser about whitespace than one might expect from > reading 'normal' code when the result is unambiguous in that it cannot > really mean anything other than what it does. Two other examples: > >>>> if3: print('yes!') > yes! That's cool to know too, but I would have expected that. Programming languages tend to ignore whitespace as much as possible. (But someone followed-up with more details... I'll get there.) But the next one... >>>> [0] [0] > 0 Oh! This almost fooled me. It's just a list containing the integer zero followed by the index-operator (or however the brackets are called in this case.) At first I thought maybe there was an implicit operator between lists just like it happens with strings. >>> "a" "," "b" 'a,b' But which operator would it be? It wasn't concatenation, of course. So I looked at what type() thought of it. Then I tried changing numbers: >>> [1] [1] Traceback (most recent call last): File "<pyshell#13>", line 1, in <module> [1] [1] IndexError: list index out of range And that's when it hit me. :-) Thanks!

1 0

on slices, negative indices, which are the equivalent procedures?
by Jack Brandom Aug. 10, 2021

Aug. 10, 2021

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

7 9

Re: some problems for an introductory python test
by Hope Rouselle Aug. 10, 2021

Aug. 10, 2021

Chris Angelico <rosuav(a)gmail.com> writes: > On Wed, Aug 11, 2021 at 4:14 AM Hope Rouselle <hrouselle(a)jevedi.xotimo> wrote: >> >> Chris Angelico <rosuav(a)gmail.com> writes: >> >> > On Tue, Aug 10, 2021 at 7:25 AM Hope Rouselle >> > <hrouselle(a)jevedi.xotimo> wrote: >> >> I came up with the following question. Using strings of length 5 >> >> (always), write a procedure histogram(s) that consumes a string and >> >> produces a dictionary whose keys are each substrings (of the string) of >> >> length 1 and their corresponding values are the number of times each >> >> such substrings appear. For example, histogram("aaaaa") = {"a": 5}. >> >> Students can "loop through" the string by writing out s[0], s[1], s[2], >> >> s[3], s[4]. >> > >> > In other words, recreate collections.Counter? Seems decent, but you'll >> > need to decide whether you want them to use defaultdict, use >> > __missing__, or do it all manually. >> >> Yes, the course introduces very little so there is a lot of recreation >> going on. Hm, I don't know defaultdict and I don't know how to use >> __missing__. The course does introduce dict.get(), though. If students >> use dict.get(), then the procedure could essentially be: >> >> def histogram(s): >> d = {} >> d[s[0]] = d.get(s[0], 0) + 1 >> d[s[1]] = d.get(s[1], 0) + 1 >> d[s[2]] = d.get(s[2], 0) + 1 >> d[s[3]] = d.get(s[3], 0) + 1 >> d[s[4]] = d.get(s[4], 0) + 1 >> return d > > There's nothing wrong with getting students to recreate things, but > there are so many different levels on which you could do this, which > will leave your more advanced students wondering what's legal. :) Here > are several ways to do the same thing: [... very impressive set of solutions...] > It seems *very* strange to have an exercise like this without looping. It is. I agree. > That seems counterproductive. It is. > But if you're expecting them to not use loops, you'll want to also be > very clear about what other features they're allowed to use - or > alternatively, stipulate what they ARE allowed to use, eg "Use only > indexing and the get() method". Yes, I will do that. I mean the course does that all the time. They cannot use anything that has not been introduced. That's another problem because the course introduces various things and students can't quite keep everything in mind. The suggestion to make up a list of things is mostly ignored by nearly all of them. :-)

1 0