[Python-ideas] Re: Allowing non-ASCII bracket and quote characters in source code
On Tue, Jan 18, 2022 at 1:15 AM Steven D'Aprano wrote: > I would be more sympathetic to this idea if: > > 2. I had a guarantee that all of the bracket characters would be both > available and easily distinguishable in any typeface I used. > I don't think the "distinguishable" part matters that much; if the different variants of the same type of bracket look the same, we're just back to what we see now. However, it's a problem if they're just displayed as "unknown character" markers, and you can't tell which kind they are, nor whether they're opening or closing. I suspect "rainbow parentheses" in editors is probably going to be a better approach. ___ Python-ideas mailing list -- python-ideas@python.org To unsubscribe send an email to python-ideas-le...@python.org https://mail.python.org/mailman3/lists/python-ideas.python.org/ Message archived at https://mail.python.org/archives/list/python-ideas@python.org/message/4IHBRQRBCLSUSN2Y2FSGRW6TZHT4M6NB/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Allowing non-ASCII bracket and quote characters in source code
Perhaps the time isn't ripe for this, and perhaps it never will be, but UTF8 seems to be handled by just about everything these days. I suspect this is a crazy suggestion, but on the other hand perhaps people looking back from 2100 will think "It was crazy that they stuck exclusively with ASCII syntax characters for so long after Unicode was widely available". Sometimes when you have quite a few levels of brackets, and there are more than one of the same type, might it be better to allow variants of each type of bracket character? Unicode provides bold, double, small, superscript, subscript, and white-filled (hollow) variants of round, square and curly brackets, and top and bottom ticked variants of square brackets. Perhaps not enough platforms will be able to display them? And entering them may be fiddly, although programmable editors and IDEs could let you type the standard characters but pick variants on a round-robin basis within each expression. But it might be handled better in the display in editors and IDEs (perhaps syntax coloring brackets by their depth). Or some might say not to write such deeply nested bracketed expressions. Implementation parsers could simply translate all the brackets to the base types, or they could treat them as equivalent but distinct, and check that the open and close brackets match, which might catch a few errors. There are also other quote characters available, such as the guillemets traditionally used in French. There's absolutely no need to use such things, but for people working on code which will be used internally in, say, French or Quebecois organizations might welcome it. OK, shoot this one down now :-) ___ Python-ideas mailing list -- python-ideas@python.org To unsubscribe send an email to python-ideas-le...@python.org https://mail.python.org/mailman3/lists/python-ideas.python.org/ Message archived at https://mail.python.org/archives/list/python-ideas@python.org/message/NIJX6QQPTCRZNGZH2FY77LEFGUW2A7JL/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Limit scope of variables using round brackets
This is clearly one for me to abandon! Thanks for the explanations. John On Mon, Jan 17, 2022 at 7:04 PM Paul Moore wrote: > On Mon, 17 Jan 2022 at 18:51, John Sturdy wrote: > > > > My idea is to support the style in which each variable comes into > existence at a single well-defined point, whatever path is taken through > the code, and so in the case of that example, it would be encouraging the > use of conditional expressions. > > But that's a style that Python explicitly rejected right back when it > was first designed, and it's fundamental to the language that you > *don't* explicitly declare variables. So sorry, but it's never going > to happen[1]. > > If you want to be really precise, technically "the style in which each > variable comes into existence at a single well-defined point" is > actually what Python already does. The "well-defined point" is the > start of the scope (function or class definition) where the variable > is used, though, and not at some new "let" keyword. > > To see this, look at the following: > > >>> def f(): > ... print(n) > ... n = 1 > ... > >>> f() > Traceback (most recent call last): > File "", line 1, in > File "", line 2, in f > UnboundLocalError: local variable 'n' referenced before assignment > > The variable "n" exists when the print statement runs (it's unbound, > but it exists - that's what the exception says), and that's because > the variable comes into existence at the *start* of the scope > (function). > > And the choice to only have a limited number of ways to define scopes > is *also* a fundamental design principle of Python, so arguing that > suites should each define their own scope won't get you very far > either. > > Essentially, you're proposing to change Python to no longer be Python, > in some fairly fundamental ways. Don't be surprised if you get very > few supporters for your idea... > > Paul > > [1] In theory, the SC could say that such a change is fine, but I > can't see that ever happening. > ___ Python-ideas mailing list -- python-ideas@python.org To unsubscribe send an email to python-ideas-le...@python.org https://mail.python.org/mailman3/lists/python-ideas.python.org/ Message archived at https://mail.python.org/archives/list/python-ideas@python.org/message/WNJSIYW6EGAV5PHQK2JWYA7EXEY4YJNH/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Limit scope of variables using round brackets
My idea is to support the style in which each variable comes into existence at a single well-defined point, whatever path is taken through the code, and so in the case of that example, it would be encouraging the use of conditional expressions. A worse case of what can be done with the scope rules for variables declared as they are now is that some code paths define the variable and some don't, so later on in the program it might or might not be defined (I have seen this done, and find it takes extra mental work to work with). I was thinking of all blocks defining scopes, like they do in C and many other languages. It would be possible to add another statement type just for this, I suppose, and have "let x = y in:" and a suite under it. On Mon, Jan 17, 2022 at 5:24 PM Christopher Barker wrote: > On Mon, Jan 17, 2022 at 7:36 AM John Sturdy wrote: > >> For example, it bugs me that you can write: >> >> if a: >> b = f(x) >> else: >> b = g(y) >> >> and get the same variable 'b' from it in the lines of code following >> that, regardless of which path was taken. >> > > Really? But that is a VERY common pattern. In fact, I would find it very > hard to write an enormous amount of code without it. and what if you > refactored that to be: > > b = f(x) if a else g(x) > > Do you really want that to mean something different ?!?! > > Or are what you are getting at that if you want those two forms to be the > same, then you'd need to do something like: > > b = None > if a: > b = f(x) > else: > b = g(y) > > Which means essentially that you'd like to have to declare names in order > to ues them outside the very narrowest of scopes. > > But this is not how Python works, and it never has, it would be a really > massive change, and I for one, would not like it :-( > > Also -- which blocks would create a new scope? All of them: > > for (else) > while (else) > with > if (elif, else) > try (except, else) > > I guess what I'm getting at is that I'm pretty sure I would find this > useful rarely, and an annoyance often. > > - CHB > > > > -- > Christopher Barker, PhD (Chris) > > Python Language Consulting > - Teaching > - Scientific Software Development > - Desktop GUI and Web Development > - wxPython, numpy, scipy, Cython > ___ Python-ideas mailing list -- python-ideas@python.org To unsubscribe send an email to python-ideas-le...@python.org https://mail.python.org/mailman3/lists/python-ideas.python.org/ Message archived at https://mail.python.org/archives/list/python-ideas@python.org/message/URWFCXR3OOER3BVTIOVTAQFME6LSDQBF/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Limit scope of variables using round brackets
One of the few things I don't like about Python is that variable scope continues after the end of the suite the variable was created in --- probably because I think of local variable declarations as equivalent to lambdas that are called immediately, which works for most modern programming languages as well as for the theory. For example, it bugs me that you can write: if a: b = f(x) else: b = g(y) and get the same variable 'b' from it in the lines of code following that, regardless of which path was taken. I think a way to address this that would be more compatible with Python's style would be to add a new declaration syntax, perhaps borrowing from other languages and using the keyword 'let' where the variable is first assigned (and the rest of the assignment / declaration being as before). The variables declared this way would exist up to the end of the suite in which they were declared; there would be no need for any further syntax to delimit the scope. This would be fully forward-compatible, and those like me who don't like the existing scope rule could personally regard the old way of creating variables as deprecated. It would be easy for those coming to Python from various other popular languages, and I don't think it would be confusing to those learning Python as their first programming language --- the teacher / course writer could just pick either and stick with it. John On Mon, Jan 17, 2022 at 10:18 AM Stephen J. Turnbull < stephenjturnb...@gmail.com> wrote: > Iyad Ahmed writes: > > Example use cases: > > > >- Loop variables and similar, it is sometimes more comfortable to > scope > >it to the loop body only > >- Not having to name variables var1, var2, var3, or makeup > unnecessarily > >unique variable names, in some situations > > I am not authoritative, so don't take this as a denial of the idea, > but I want to give you some idea of why I suspect it is unlikely to > succeed. > > 1. Python has a well-defined notion of *suites*, ie, indented groups > of statements. If this were going to happen, I would imagine that > it would be at the statement level, and most likely the syntax > would be something like "block:" or "scope:" followed by an > indented suite. (This is a quibble about syntax, not a reason it > would be opposed in principle.) > 2. Many statements in Python have suites, but only class and def > create scopes. This is by design. It makes the rules for scopes > simple. Since they can be used anywhere a statement can go, you > can use them to create scopes (at the cost of having to invoke > them later, of course). The exceptional case is that > comprehensions have been changed to not leak their iteration > variables, but this is basically done by implicitly defining and > calling a function to create the scope if I remember correctly. > 3. It's often useful to refer to the loop variable after exiting a > loop. For example, if there's an explicit break in a loop > controlled by a range or list, the loop variable tells you how far > you got before exiting. I doubt a proposal to "close" the scope > of the loop variable would be accepted. > 4. It's generally considered bad style to have very long or deeply > indented function bodies. Variable name collisions are more > likely with global variables than with other variables in the same > local scope. Perhaps for this reason, Python programmers don't > frequently request more scopes. Again, the exception was the > change in comprehension semantics mentioned above. which was a > pain point for many. Programmers tend to think of displays more > as "variable literals" than as "open-coded constructors", and > therefore expect the scope to be closed. > > Again, I'm not authoritative, but my recommendation is to consider the > above points carefully while advocating this idea. > > Steve > ___ > Python-ideas mailing list -- python-ideas@python.org > To unsubscribe send an email to python-ideas-le...@python.org > https://mail.python.org/mailman3/lists/python-ideas.python.org/ > Message archived at > https://mail.python.org/archives/list/python-ideas@python.org/message/BHMQ6VZL7WJP2H3CWP2B2LQH45FJZFJG/ > Code of Conduct: http://python.org/psf/codeofconduct/ > ___ Python-ideas mailing list -- python-ideas@python.org To unsubscribe send an email to python-ideas-le...@python.org https://mail.python.org/mailman3/lists/python-ideas.python.org/ Message archived at https://mail.python.org/archives/list/python-ideas@python.org/message/LKMB5OLQQHVBO2T7BXBVHU5PUNDMAMFU/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Context managers in expressions
Thanks, Mark... I had missed that aspect entirely. I think there might be a way round it... which actually was something I had been thinking of including in the same suggestion but thought was perhaps too obscure, but now I've realized it would integrate well with it. That is to have a value-returning form of try... except... But perhaps the two of them together are too much of a change. John On Mon, Oct 25, 2021 at 10:03 PM Mark Gordon wrote: > What should happen if the context manager attempts to suppress a raised > exception? In cases where you applied the context manager to an entire > line, e.g. > > data = fail() with contextlib.suppress(Exception) > > Then it would make sense to treat it like > > with contextlib.suppress(Exception): > data = fail() > > Where `data` remains unassigned after the block executes assuming `fail` > raises an exception. However, with the initial proposal you run into > trouble when you apply this to sub-expressions that are expected to > themselves have a value. For example, what should happen here? > > more_work(fail() with contextlib.suppress(Exception)) > > We have no value to pass as an argument to `more_work` so there's no way > we can call it. Yet it would be odd to not call it if there's no exception > being raised since it exists outside of any context manager itself. > ___ > Python-ideas mailing list -- python-ideas@python.org > To unsubscribe send an email to python-ideas-le...@python.org > https://mail.python.org/mailman3/lists/python-ideas.python.org/ > Message archived at > https://mail.python.org/archives/list/python-ideas@python.org/message/Y7WZDD2AFGUX3ND2OX3EUN2VUK27O4E5/ > Code of Conduct: http://python.org/psf/codeofconduct/ > ___ Python-ideas mailing list -- python-ideas@python.org To unsubscribe send an email to python-ideas-le...@python.org https://mail.python.org/mailman3/lists/python-ideas.python.org/ Message archived at https://mail.python.org/archives/list/python-ideas@python.org/message/DAY57GUMKNHWKJYAAQWFIDVVD4AU6TDL/ Code of Conduct: http://python.org/psf/codeofconduct/
