Mailman 3 December 2022 - Python-ideas

PEP 671 (late-bound arg defaults), next round of discussion!
by Chris Angelico July 23, 2023

July 23, 2023

I've just updated PEP 671 https://www.python.org/dev/peps/pep-0671/ with some additional information about the reference implementation, and some clarifications elsewhere. *PEP 671: Syntax for late-bound function argument defaults* Questions, for you all: 1) If this feature existed in Python 3.11 exactly as described, would you use it? 2) Independently: Is the syntactic distinction between "=" and "=>" a cognitive burden? (It's absolutely valid to say "yes" and "yes", and feel free to … [View More]

43 364

Call functools.update_wrapper on Mock(wraps=func)
by Lucas Wiman Dec. 30, 2022

Dec. 30, 2022

For code that uses annotations / signature, wrapping a callable in a Mock object does not work correctly: >>> import typing, inspect, functools >>> from unittest.mock import Mock >>> >>> def incr(i: int) -> int: ... return i+1 ... >>> wrapped = Mock(wraps=incr) >>> inspect.signature(wrapped) <Signature (*args, **kwargs)> >>> typing.get_type_hints(wrapped) Traceback (most recent call last): File "<stdin>", line … [View More]

1 0

Re: Idea: Tagged strings in python
by Brendan Barnwell Dec. 24, 2022

Dec. 24, 2022

Sorry, accidentally replied off-list. . . On 2022-12-19 11:36, Chris Angelico wrote: > On Tue, 20 Dec 2022 at 06:29, Brendan Barnwell <brenbarn(a)brenbarn.net> wrote: >> >> On 2022-12-19 03:45, Chris Angelico wrote: >>> On Mon, 19 Dec 2022 at 22:37, Steven D'Aprano <steve(a)pearwood.info> wrote: >>>>> But this much (say with a better validator) gets you static type checking, >>>>> syntax highlighting, and inherent documentation … [View More]of intent. >>>> >>>> Any half-way decent static type-checker will immediately fail as soon as >>>> you call a method on this html string, because it will know that the >>>> method returns a vanilla string, not a html string. >>> >>> But what does it even mean to uppercase an HTML string? Unless you >>> define that operation specifically, the most logical meaning is >>> "convert it into a plain string, and uppercase that". Or, similarly, >>> slicing an HTML string. You could give that a completely different >>> meaning (maybe defining its children to be tags, and slicing is taking >>> a selection of those), but if you don't, slicing isn't really a >>> meaningful operation. >> >> I don't agree with that at all. What it means for an HTML string to be >> a subclass of a normal string is that all normal string operations still >> work on an HTML string --- just like what it means for any instance of a >> subclass to be an instance of the superclass is that you can do anything >> to the subclass that you could do to the superclass. Every character in >> an HTML string is still a character and can still be uppercased. The >> string is still a sequence of characters and can be sliced. All such >> operations still have a perfectly natural meaning. > > And that part is already true. None of this changes. That's guaranteed > by the concept of subclassing. But what you're doing is string > operations on a string. > >> We just want them to >> now return an *HTML* string when they're done instead of a normal one. >> The point of having a subclass is to define *additional* behavior while >> still retaining the superclass behavior as well. > > So how is it still an "HTML" string if you slice out parts of it and > it isn't valid HTML any more? What it means for me for something to "be an HTML string" (or more precisely, to be an instance of HTMLString or whatever the class name is) is for it to be a string that has an extra tag attached to the object that means "this is HTML". That's it. You can make an HTML string that contains utter gobbledegook if you want. Of course, some operations may fail (like if it has a .validate() method) but that doesn't mean it's not still an instance of that class. Or, if you do want that, you can override the slicing method to raise an error if the result isn't valid HTML. The point is that overrides are for specifying the *new* behavior of the subclass (i.e., not allowing certain slice operations); you shouldn't have to override methods just to retain the superclass behavior. I mean, we were talking about this in the context of syntax highlighting. The utility of HTML-string highlighting would be seriously reduced if only *valid* HTML could be in an HTML string. >> Personally I find Python's behavior in this regard (not just for >> strings but for other builtin types) to be one of its most irritating >> warts. > > See my example regarding a StrEnum and tell me whether that would be > more irritating. I can't run that example myself as I don't have Python 3.11 set up. But just from what you showed, I don't find it convincing. Enums are special in that they are specifically designed to allow only a fixed set of values. I see that as the uncommon case, rather than the common one of subclassing an "open-ended" class to create a new "open-ended" class (i.e., one that does not pre-specify exactly which values are allowed). So no, I don't think it would be more irritating. -- Brendan Barnwell "Do not follow where the path may lead. Go, instead, where there is no path, and leave a trail." --author unknown [View Less]

8 28

Re: Idea: Tagged strings in python
by Rob Cliffe Dec. 22, 2022

Dec. 22, 2022

On 19/12/2022 03:23, David Mertz, Ph.D. wrote: > On Sun, Dec 18, 2022 at 8:29 PM Steven D'Aprano <steve(a)pearwood.info> > wrote: > > > However, if you want to allow these types to possibly *do* > something with > > the strings inside (validate them, canonicalize them, do a > security check, > > etc), I think I like the other way: > > class html(str): pass > > class css(str): pass > > The problem with this … [View More]

1 0

Idea: Tagged strings in python
by emil＠emilstenstrom.se Dec. 22, 2022

Dec. 22, 2022

Hi everyone! I'm the maintainer of a small django library called django-components. I've run into a problem that I have a language-level solution (tagged strings) to, that I think would benefit the wider python community. *Problem* A component in my library is a combination of python code, html, css and javascript. Currently I glue things together with a python file, where you put the paths to the html, css and javascript. When run, it brings all of the files together into a component. But … [View More]for small components, having to juggle four different files around is cumbersome, so I've started to look for a way to put everything related to the component _in the same file_. This makes it much easier to work on, understand, and with fewer places to make path errors. Example: class Calendar(component.Component): template_string = '<span class="calendar"></span>' css_string = '.calendar { background: pink }' js_string = 'document.getElementsByClassName("calendar)[0].onclick = function() { alert("click!") }' Seems simple enough, right? The problem is: There's no syntax highlighting in my code editor for the three other languages. This makes for a horrible developer experience, where you constantly have to hunt for characters inside of strings. You saw the missing quote in js_string right? :) If I instead use separate files, I get syntax highlighting and auto-completion for each file, because editors set language based on file type. But should I really have to choose? *Do we need a python language solution to this?* Could the code editors fix this? There's a long issue thread for vscode where this is discussed: https://github.com/Microsoft/vscode/issues/1751 - The reasoning (reasonable imho) is that this is not something that can be done generally, but that it needs to be handled at the python vscode extension level. Makes sense. Could the vscode language extension fix this? Well, the language extension has no way to know what language it should highlight. If a string is HTML or CSS. PyCharm has decided to use a "special python comment" # language=html that makes the next string be highlighted in that language. So if just all editors could standardize on that comment, everything would work? I guess so, but is that really the most intuitive API to standardize around? If the next statement is not a string, what happens? If the comment is on the same line as another statement, does it affect that line, or the next? What if there's a newline in between the comment in the string, does that work? *Suggested solution* I suggest supporting _tagged strings_ in python. They would look like html'<span class="calendar"></span>'. * Python should not hold a list of which tagged strings it should support, it should be possible to use any tag. * To avoid clashes with current raw strings and unicode strings, a tag should be required to be at least 2 characters long (I'm open to other ways to avoid this). I like this syntax because: 1. It's clear what string the tag is affecting. 2. It makes sense when you read it, even though you've never seen the syntax before. 3. It clearly communicates which language to highlight to code editors, since you can use the language identifiers that already exist: https://code.visualstudio.com/docs/languages/identifiers#_known-language-id… - for single letter languages, which are not supported to avoid clash with raw strings and unicode strings, the language extension would have to support "r-lang" and "c-lang" instead. 4. It mimics the syntax of tagged string templates in javascript (https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Template_…). So it has som precedent. (If desirable, I think mimicing javascript further and making tagged strings call a function with the tag's name, would be a great addition to Python too. This would make the syntax for parsing foreign languages much nicer. But this is not required for my specific problem, it's just a nice next possible step for this feature.) *Backwards compatibility* This syntax currently raises a invalid syntax error. So introducing this shouldn't break existing programs. Python's currently supported string types are just single letter, so the suggestion is to require tagged strings to be at least two letters. *Feedback?* What are your thoughts on this? Do you see a value in adding tagged strings to python? Are there other use-cases where this would be useful? Does the suggestion need to support calling tags as functions like in javascript to be interesting? (I'm new to python-ideas, so I hope I haven't broken some unspoken rule with this suggestion.) -- Emil Stenström [View Less]

19 46

Extending LiteralString or Literal with structural validation
by Mathew Elman Dec. 21, 2022

Dec. 21, 2022

This is somewhat inspired by the "Tagged strings in python" thread, but from a different approach. Specifically, rather than messing with runtime python, using static type analysis to help the usability of specific kinds of string literals. It would be useful to take advantage of the `LiteralString` or `Literal` type hints to add structural validation to literals. For *example*, if these could be subclassed to add a validation method: class MyLiteral(LiteralString): def … [View More]

3 3

Re: Idea: Tagged strings in python
by Steven D'Aprano Dec. 20, 2022

Dec. 20, 2022

On Mon, Dec 19, 2022 at 03:48:01PM -0800, Christopher Barker wrote: > On Mon, Dec 19, 2022 at 3:39 AM Steven D'Aprano <steve(a)pearwood.info> wrote > > > In any case, I was making a larger point that this same issue applies to > > other builtins like float, int and more. > > > Actually, I think the issue is with immutable types, rather than builtins. No. >>> class MyList(list): ... def frobinate(self): ... return "something" ... &… [View More]

2 1

[Feature Request] Add attribute font_path to the class tkinter.font.Font
by Jérémie Bergeron Dec. 14, 2022

Dec. 14, 2022

Hi, I think it would be usefull if the class tkinter.font.Font<https://docs.python.org/3/library/tkinter.font.html#module-tkinter.font> would contain the path to the font. With it, we can use many software like fonttools<https://github.com/fonttools/fonttools> to obtain more information about the font, because the class Font is very limited. You could think it would be useless, but it is a nice feature when you know a font name and need more information, but you doesnt know it's … [View More]

2 1

Nonuniform PRNG?
by David Lowry-Duda Dec. 7, 2022

Dec. 7, 2022

Inspired by the recent thread on PRNG, I began to wonder: suppose that I had a pseudorandom number generator that attempted to generate a nonuniform distribution. Suppose for instance that it was to generate a 0 bit 2/3 of the time, and a 1 bit 1/3 of the time. How would one go about testing this PRNG against an idealized (similarly biased) PRNG? - DLD

4 4

Better (?) PRNG
by James Johnson Dec. 7, 2022

Dec. 7, 2022

I wrote the attached python (3) code to improve on existing prng functions. I used the time module for one method, which resulted in disproportionate odd values, but agreeable means. I used the hashlib module for the second. It is evident that the code is amateur, but the program might result in better PRN generation. The "app" lends itself to checking, using statistical tools (see comments.) I remain a fan, James Johnson

8 23

Re: Better (?) PRNG - follow up
by Steven D'Aprano Dec. 7, 2022

Dec. 7, 2022

On Tue, Dec 06, 2022 at 07:58:09PM -0500, David Mertz, Ph.D. wrote: > You have an error in the code you posted. You never use R2 after one > call to SystemRandom. Ah so I do, thanks for picking that up! James, see how *easy* it is for experts to notice bugs, at least some of them, in a short piece of code that gets right to the point? The more extraneous and irrelevant code you give, and that includes old dead comments, the more places for bugs to hide and the harder it is for … [View More]

1 0

Re: Better (?) PRNG - follow up
by James Johnson Dec. 7, 2022

Dec. 7, 2022

I came back to this thread looking for the list of randomness tests, and I keep missing them somehow. The reason for my follow up is this: The random number function in Python has important uses far beyond my personal concerns, and random.randint(0,9) is supposed to be the Mersenne Twister. I used the attached code to generate the attached file. It’s randint(0,9) for n=600, keyed back in by hand, instead of automatically from the script: My question/concern is this: does this dataset look … [View More]like it came from the Mersenne Twister? In 600 iterations, it generated 8,8,8; 0,0,0; 1,1,1 and 5,5,5, with more than 1% (6) occurrences where the same number repeated. I didn't do the +1/-1 test, but the data is in a (python) list that should be easily cut and pasted into a legit datafile. This leads me to question whether the MTPRNG rubber is meeting the Link Mint Mate 23.x.x road. "Catastrophizing," if randint isn't correct in the random library, what about the more crucial PRNG's? I suppose that feeding the random function back without keyboard intervention would yield similar results - it's not my data entry either: I printed the number suggested and the number entered for every instance, before the report. This is why my magic eight ball program had problems, not the design of Mersenne Twister. It may be amatuer as h*ll, but doesn't it point something? James (I thank you for so articulately showing that my hash isn't a PRNG.) On Wed, Nov 16, 2022 at 10:27 AM James Johnson <jj126979(a)gmail.com> wrote: > These are very many reasons that Python PRNG is indeed adequate. > > Maybe documentation for amateurs and newbies could be improved so that > they get the best results possible without knowing how much work it is. > > How to call the built in PRNG seems to change a good bit. > > As for the hack: I feel obligated to connect to the internet and do > research before I speak further. > > IF it DOES do 0-9 randomly, even if it is not useful for larger ranges, it > may serve by CONCATENATING base 10? > > I feel like it’s the punchline to a lame joke now, but thank you all > again. I will be reading for weeks. > > On Wed, Nov 16, 2022 at 9:36 AM Stephen J. Turnbull < > stephenjturnbull(a)gmail.com> wrote: > >> James Johnson writes: >> >> > The scholars here are referencing white papers and using hardware and >> > software interchangeably (?) I am not a randomization expert, and I do >> not >> > seek academic recognition. It's a novel hack is all, >> >> I'm no expert either, but hash functions and PRNGs have been around a >> long time. I'm sure this approach has been discovered independently. >> >> Besides the Mersenne twister that Python uses, POSIX systems like >> Linux, MacOS, and BSD provide a number of random number generation >> facilities, briefly documented in the man pages. BSD man pages for >> random and arc4random mention the Fortuna algorithm and the arc4 >> algorithm. At least the latter is similar to yours in that in "mixes >> in" additional entropy gradually as more random numbers are generated. >> >> For sources of "entropy" (random bits) the man page on /dev/random >> and /dev/urandom provide nice brief explanations. >> >> >> -- > Truth causes consequences; consequences bring pain; pain exorcises guilt! > [View Less]

6 8

Re: Better (?) PRNG
by Chris Angelico Dec. 6, 2022

Dec. 6, 2022

(I'm assuming that you sent this personally by mistake, and am redirecting back to the list. My apologies if you specifically didn't want this to be public.) On Tue, 15 Nov 2022 at 22:34, James Johnson <jj126979(a)gmail.com> wrote: > > It’s been a couple of years ago, but as I recall the duplicates seemed to be of two or three responses, not randomly distributed. > > I looked at my code, and I DID salt the hash at every update. > > At this point, my curiosity is engaged … [View More]

4 10

Enhancing variable scope control
by Anony Mous Dec. 6, 2022

Dec. 6, 2022

As it stands now, to create a local scope, you must define a function. However, there are many cases where various things can reasonably be done inline. Preparatory code is often done this way. Good coding practice is generally accepted to be that variables are local if at all possible. However, in direct, inline Python code, we're inherently creating variables with a global scope. We don't actually need a function for this kind of code; but a local scope would often be valuable (as we see … [View More]with lambda.) Moving things off into a function can create a circumstance where we have to go looking for the function. When something is a "one-shot" as in global preparatory code, that's doing more work, and creating more indirection, than needs actually be done. But global operations have their own pitfalls, one of which is variable collisions. So Python sort of drives us to make "one-use" functions where lambdas are insufficient to the case in order to control locality. You can end up writing things like... def PrepOne(): for MyCount in range(0,10): pass PrepOne() ...which achieves the locality desired for variable MyCount, but is clunky. It also clutters the global namespace with prepOne, which has no good reason to exist. So I'm thinking of something along these lines: local: # <== or whatever syntax makes sense for MyCount in range(0,10): pass So in that example, the code is inline - runs as part of the global, sequential code execution - but the variable MyCount is local and goes "poof" once the local: scope is exited. This is the scoping equivalent of a pair of curly braces in c and c++. I would like to see it be nestable, as scopes are in c/c++: local: # <== or whatever syntax makes sense for MyCount in range(0,10): local: for YourCount in range(0,MyCount+1) pass There, MyCount is available in both scopes (the first local: is an enclosing scope) and YourCount is available only in the second local: scope. Or, local: could be very strict, and require further syntax to incorporate a previous scope, something like this: local: # <== or whatever syntax makes sense for MyCount in range(0,10): local: incorporate MyCount # <== or whatever syntax makes sense for YourCount in range(0,MyCount+1) pass Lastly, I suggest that the global keyword be used to expose global scope variables, just as it is within def functions: TheirCount = 10 local: # <== or whatever syntax makes sense global TheirCount for MyCount in range(0,TheirCount): local: for YourCount in range(0,TheirCount) pass This would also be useful within normal functions, and again allows the program flow to be linear rather than calling a function-within-a-function. [View Less]

10 14

Re: Enhancing variable scope control
by Rob Cliffe Dec. 4, 2022

Dec. 4, 2022

On 04/12/2022 17:08, Chris Angelico wrote: > On Mon, 5 Dec 2022 at 04:07, Rob Cliffe via Python-ideas > <python-ideas(a)python.org> wrote: >> >> >> On 30/11/2022 20:27, Anony Mous wrote: >>> Danceswithmice wrote: >>> >>> >>> >>> The idea is that YOU write "local:", and the interpreter, without you >>> ever seeing it, promotes that into a hidden function with a hidden >>> name and a hidden call. >>… [View More]

1 0

Re: Enhancing variable scope control
by Rob Cliffe Dec. 4, 2022

Dec. 4, 2022

On 30/11/2022 20:27, Anony Mous wrote: > Danceswithmice wrote: > > > > The idea is that YOU write "local:", and the interpreter, without you > ever seeing it, promotes that into a hidden function with a hidden > name and a hidden call. > > --- > > p.f.moore wrote: > > > That would make "return" in the local scope exit the scope, not the > enclosing function. Which is almost certainly not what people would expect > from a "local scope" statement. … [View More]

2 1

Re: Enhancing variable scope control
by Anony Mous Dec. 3, 2022

Dec. 3, 2022

These objections -- such as they are -- are all applicable to every instance of "I wrote a function" or even "I named a variable" in any particular namespace: not just within imports, either. Anywhere. Global context. Sub functions. etc. Collisions, etc... not a big deal. Change a name. It'll still work the same. Nothing to it. No matter what the context is in Python. If you were talking about using a compiled library without the source code (and here come the back hats), depending on the … [View More]linking and permissions, you could probably *still* change the name(s) in the library. But we're talking about an interpreted scripting language. We have the source code for everything. Or should. There is no mystery to be had. You want your own TestDottedQuad? You fear collisions? Fine. Write it as MyTest23DottedQuad87qxy or whatever. Be really random about it if it assuages your concerns. Or just rename your new instance, or the one extending the library (remember,it's an addition, if it's there, something added it. So you *can* change it if that's your call.) if you can't stand to write a new name for yours. Either way, bingo. Your functionality is present in your project. The other functionality is present as well. Both can be used with your strings. Choose. Enjoy your choice. You want to write it the hard way, as a loose function that can't handle class objects like strings? You can do that too. Something immutable is broken or not functional for your purposes? Lift the code, fix it, give it your own name, and use it. As an extension or directly. Whatever floats your boat. There. Done. Easily. Or... like these non-Python Ruby people that keep mysteriously polluting the argument - just tell the team "we're not going to do that." Again, problem solved. You do *not* have to cripple a language to resolve this in any particular direction. But wait.... you told them and they won't/can't comply? That's not a language issue. That's a "your team needs different staffing" issue. And mind you, this is all in the context of "big projects." Doing something yourself? Not even worth a handwave. Write what you need, test it, secure it, make it work, move on. There are myriad ways to get naming issues into compliance with whatever metric you want. Regardless of circumstance. This "we're going to save you from yourself" mentality serves to coddle weak and/or lazy programmers while crippling the rest. The entire idea that these naming issues (and that's all they are) cannot be coped with absolutely trivially is both nonsensical and insupportable. For instance: Obviously if you were to say "extend library with X", and X was already present (remember, these are immutable), such an attempt would fail. Bang. Exception. The very first time you tried it. Therefore, you're already directly on the path of "going to need a non-colliding name to use my particular function." See how easy that was? It's absurd to claim that this is any kind of meaningful obstacle. If it happens, you just fix it. Like any other programming issue. This is what we do. Are you thinking "but what if it wasn't tested so no one saw an exception?" In that case, again, we have a staffing issue. Not a language issue. As for the "big project" argument put forth earlier, that is also invalid. In any big project, if the devs aren't outright newbs anyway, people are given responsibility for specific functionality, and if random person X wants to mod existing function Y, they submit a suggestion, it goes through the appropriate process and gets accepted (possibly altered, such as... the name), or not. Pull requests, etc. Whatever the process is. But should there not be that (obvious and common these days) process, Any function in the project is subject to name collisions, any use of any library with name X / function X is subject to collisions, etc. And how do we get out of such things? if library A and library B have the same names, or prehaps function X and function Y, we change one of them. Now you have your multiple names and/or namespaces and/or names within namespaces. Likewise, if a function is added (at any level) and there is a name collision, we can change that too. We can notify our crew and say "globally edit 'TestDottedQuad' to 'MyTest23DottedQuad87qxy', and by the way, we're having subs for lunch." Trivial. If your crew isn't up for such things... well. That's a different problem entirely. I appreciate that you have strong feelings about this, but you (neither of the respondents here) have not presented any good arguments. Not even one. That doesn't mean there aren't supporters of your positions - of course there are - but every level of computing history is replete with bad ideas supported by many, and good ideas trampled on by just as many. Perceptrons/Minsky. Scrums. Clumsy typing systems. Chiclet keyboards. Freeform formatting. "Comment every line of code." Segment registers (and oh boy did that one cost us progress!) etc., etc., etc. > I concur... Concurring with one another doesn't ensure that you're right. It may also mean you're both wrong in similar or identical ways. To reiterate: I've already implemented this functionality through the auspices of a preprocessor, which also means, no monkey patching. It works very well, does exactly what I wanted, and improved my particular circumstance significantly. And then we have: > I find that implausible. Okay. However, since I know the truth of it, I'll proceed to not worry in the least that your thought process ended up there. [View Less]

5 4

Re: Enhancing variable scope control
by Anony Mous Dec. 2, 2022

Dec. 2, 2022

> This is very, very deliberately a design goal of Python. I suspect we're likely not talking about this same "this." Or if we are, I'd love to hear a justification -- any justification -- against what I'm talking about, because to date, I've never run into one. Many have tried, too. :) I'm talking about adding new functionality. NOT modifying existing functions. NOT replacing existing functions. NOT modifying existing, standard class internal variables or states. So If I add … [View More]

3 2

Re: Enhancing variable scope control
by Anony Mous Dec. 1, 2022

Dec. 1, 2022

>> the string class, which has some annoying tight couplings to "string" and 'string') > What does that mean? > It sounds like you are complaining that the syntax for creating strings creates strings. Or possibly the other way around: that strings are created by string syntax. What did you expect? Here's my understanding: You can't extend the string class to add new functionality. You can only subclass it. Because of this, "character-strings" cannot be suffixed with new … [View More]

2 1

zip(x, y, z, strict=True)
by Ram Rachum Dec. 1, 2022

Dec. 1, 2022

Here's something that would have saved me some debugging yesterday: >>> zipped = zip(x, y, z, strict=True) I suggest that `strict=True` would ensure that all the iterables have been exhausted, raising an exception otherwise. This is useful in cases where you're assuming that the iterables all have the same lengths. When your assumption is wrong, you currently just get a shorter result, and it could take you a while to figure out why it's happening. What do you think?

27 179

Re: Enhancing variable scope control
by Anony Mous Dec. 1, 2022

Dec. 1, 2022

Danceswithmice wrote: > The larger criticism of the above is the chosen-name The name is irrelevant; an extremely minor implementation detail, and one that is meaningless if the idea itself does not pass muster. Users would not see the name in any case; it's an interpreter level issue. So on with the concept, then: > However, deliberating over the choice of name for the function makes the code easy to read The idea is that YOU write "local:", and the interpreter, without you ever … [View More]

3 2

Re: Enhancing variable scope control
by Anony Mous Dec. 1, 2022

Dec. 1, 2022

Barry wrote: > The ways scoping works in python is very hard to change as you are asking for i think was a major reason to reject. Perhaps it isn't all that difficult; For instance, a "local:" declaration could be treated as if it were "def function()" with an immediately succeeding call as far as the interpreter is concerned. That buys the scoping for (nearly) free. We write... local: for MyVal in range(0,10) pass ...interpreter codes that, out of sight, as: def … [View More]

4 3