Mailman 3 June 2021 - Python-ideas

Add `get`as a method to list and tuple
by svrchn921＠outlook.com June 5, 2021

June 5, 2021

The get method exists for dict, which is very useful. I like it very much, i would like it to be added as a method to list and tuple. The syntax would be similar to dict.get, except you provide an index like 0 or 1 instead of a key. It would look like this: ```py fruits = [“apples”, “bananas”] fruits.get(0) # would return “apples” fruits.get(2) # would return None or the default value if passed ``` Thank you for reading this idea.

1 0

Add "try: stmt except: stmt" syntax to Python
by Shreyan Avigyan June 3, 2021

June 3, 2021

Python has support for conditional statement, list comprehensions, dict comprehensions, etc. So we can write these in mere one or two lines. But for try-except it's not possible to write it one or two lines. Many a times, we have one stmt that we want to check and if it raises error then do nothing or just execute one stmt. This idea proposes to add a way to write try-except for one stmt in one line. Thanking you, With Regards

5 14

Re: The Pattern Matching Wildcard Is A Bad Idea
by Alexis Masson June 2, 2021

June 2, 2021

Yeah, that's it exactly. I see these two features - `_` as a joker in `match` statements and `_`as the last value produced by a shell - as incompatible, because you have to account for interferences between them, or face unexpected behaviors in code you run. I expect people to code like I do : first experiment a feature in a shell, then write a clean script that implements it cleanly. To debug that script, go back to the shell to run the script bit by bit, etc, etc. You'd expect code … [View More]that runs in a shell to behave the same in a script, and vice-versa. But, if `_` is both a variable (shell) and a keyword (`match`), that 's not the case. You have to work around the problem, e.g. by reaffecting `_`. My fear is that most people (me included) will most likely forget this step when switching between a shell and a script. Le 02/06/2021 à 15:48, Damian Shaw a écrit : > > The question is even more pressing in REPL, since there /is/ > necessarily such a variable ! > > To clarify, your concern is that someone wants to use the match > statement in the REPL and use "_" to match against the last return > without needing to workaround with something like "last = _" and then > matching against "last"? > > > > On Wed, Jun 2, 2021 at 9:30 AM Alexis Masson <a.masson555(a)ntymail.com > <mailto:a.masson555@ntymail.com>> wrote: > > Hey everyone, > > I meant to say, I agree with the two of you, actually. `_` as a > variable name is terrible, but it /can/ be used all the same ; on > the other hand, wildcards should not be legitimate variable names, > to prevent misunderstandings / accidents / bugs. > > Had I taken part in the discussion aroud pattern matching, I would > have liked the `else` syntax better : having a special syntax for > special cases seems clearer, cleaner, and safer. > Another option that comes to mind is using `*` as the wildcard. > There is already a precedent for using `*` alone, e.g. in `import` > statements. In this case, it means "import everything from this > module", as opposed to listing the items you need. I can easily > see the parallel with `match` statements, thus making it intuitive > to learn and use this new syntax. > > Anyway, yes, `_` as joker has flaws, the biggest one being to be a > resolvable variable name ; what is the expected behaviour when > running a script that has (even accidentally) a viariable named > `_` ? The question is even more pressing in REPL, since there /is/ > necessarily such a variable ! > > I guess it's too late to change anything, though, so we'll have to > get used to it... > >> From https://docs.python.org/3.10/whatsnew/3.10.html >> <https://docs.python.org/3.10/whatsnew/3.10.html>: >> def http_error(status): >> match status: >> case 400: >> return "Bad request" >> case 404: >> return "Not found" >> case 418: >> return "I'm a teapot" >> case _: >> return "Something's wrong with the Internet" >> The wildcard idea looks just wrong and confusing. What if I want >> to use it as a variable and match against it like _ = 504? This >> is how it should be done: >> def http_error(status): >> _ = 504 >> match status: >> case 400: >> return "Bad request" >> case 404: >> return "Not found" >> case 418: >> return "I'm a teapot" >> case _: >> return "Gateway Timeout" >> else: >> return "Something's wrong with the Internet" > >> Don't do that. >> >> There is a very strong convention in Python that a single underscore is >> to be used for two purposes (and a third in the interactive interpreter >> only): >> >> (1) For "don't care" variables; anything that you don't care about and >> aren't intending to use should be named `_`. >> >> first, *_, last = sequence >> >> This tells me that I am only using the first and last items, everything >> else is ignored. >> >> >> (2) For internationalisation. This is a convention that comes from other >> languages, but it is so widespread that we're kinda stuck with it. >> >> print(_("Try again.")) >> >> By convention, the underscore function is used to translate messages >> into the current location's language. >> >> >> (3) And in the interactive interpreter, underscore is a special variable >> which captures the previous result. This doesn't work in scripts. >> >> >>> 5 + 4 >> 9 >> >>> _*10 >> 90 > > _______________________________________________ > Python-ideas mailing list -- python-ideas(a)python.org > <mailto:python-ideas@python.org> > To unsubscribe send an email to python-ideas-leave(a)python.org > <mailto:python-ideas-leave@python.org> > https://mail.python.org/mailman3/lists/python-ideas.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/F2XIF… > <https://mail.python.org/archives/list/python-ideas@python.org/message/F2XIF…> > Code of Conduct: http://python.org/psf/codeofconduct/ > <http://python.org/psf/codeofconduct/> > [View Less]

4 3

Re: The Pattern Matching Wildcard Is A Bad Idea
by Alexis Masson June 2, 2021

June 2, 2021

Hey everyone, I meant to say, I agree with the two of you, actually. `_` as a variable name is terrible, but it /can/ be used all the same ; on the other hand, wildcards should not be legitimate variable names, to prevent misunderstandings / accidents / bugs. Had I taken part in the discussion aroud pattern matching, I would have liked the `else` syntax better : having a special syntax for special cases seems clearer, cleaner, and safer. Another option that comes to mind is using `*` as … [View More]the wildcard. There is already a precedent for using `*` alone, e.g. in `import` statements. In this case, it means "import everything from this module", as opposed to listing the items you need. I can easily see the parallel with `match` statements, thus making it intuitive to learn and use this new syntax. Anyway, yes, `_` as joker has flaws, the biggest one being to be a resolvable variable name ; what is the expected behaviour when running a script that has (even accidentally) a viariable named `_` ? The question is even more pressing in REPL, since there /is/ necessarily such a variable ! I guess it's too late to change anything, though, so we'll have to get used to it... > From https://docs.python.org/3.10/whatsnew/3.10.html > <https://docs.python.org/3.10/whatsnew/3.10.html>: > def http_error(status): > match status: > case 400: > return "Bad request" > case 404: > return "Not found" > case 418: > return "I'm a teapot" > case _: > return "Something's wrong with the Internet" > The wildcard idea looks just wrong and confusing. What if I want to > use it as a variable and match against it like _ = 504? This is how it > should be done: > def http_error(status): > _ = 504 > match status: > case 400: > return "Bad request" > case 404: > return "Not found" > case 418: > return "I'm a teapot" > case _: > return "Gateway Timeout" > else: > return "Something's wrong with the Internet" > Don't do that. > > There is a very strong convention in Python that a single underscore is > to be used for two purposes (and a third in the interactive interpreter > only): > > (1) For "don't care" variables; anything that you don't care about and > aren't intending to use should be named `_`. > > first, *_, last = sequence > > This tells me that I am only using the first and last items, everything > else is ignored. > > > (2) For internationalisation. This is a convention that comes from other > languages, but it is so widespread that we're kinda stuck with it. > > print(_("Try again.")) > > By convention, the underscore function is used to translate messages > into the current location's language. > > > (3) And in the interactive interpreter, underscore is a special variable > which captures the previous result. This doesn't work in scripts. > > >>> 5 + 4 > 9 > >>> _*10 > 90 [View Less]

2 1

The Pattern Matching Wildcard Is A Bad Idea
by Julia Schmidt June 2, 2021

June 2, 2021

From https://docs.python.org/3.10/whatsnew/3.10.html: def http_error(status): match status: case 400: return "Bad request" case 404: return "Not found" case 418: return "I'm a teapot" case _: return "Something's wrong with the Internet" The wildcard idea looks just wrong and confusing. What if I want to use it as a variable and match against it like _ = 504? This is how it should be done: def http_error(… [View More]

4 3

A __decoration_call__ method for Callable objects (WAS: Decorators on variables)
by Ricky Teachey June 1, 2021

June 1, 2021

On Wed, May 26, 2021 at 7:54 AM Steven D'Aprano <steve(a)pearwood.info> wrote: > On Wed, May 26, 2021 at 01:33:07PM +0200, Stéfane Fermigier wrote: > > > Last point that I like in the decorator syntax: it's > > > > I can compose N different decorators and keep the intent obvious: > > > > @acl(READ, WRITE) > > @constraint(10 < _ < 100) > > @not_null > > @indexed > > @depends_on(whatever) > > @inject > > @... … [View More]> > first_name: str > > Hmm, that's a good point. > > On the other hand, it would be terribly confusing if the same syntax: > > @decorate > > had radically different meaning depending on whether it was followed by > a class/function or a bare name. > > > -- > Steve > ....and previously Steve also said: On Tue, May 25, 2021 at 3:28 AM Steven D'Aprano <steve(a)pearwood.info> wrote: > On Mon, May 24, 2021 at 06:36:47PM -0700, micro codery wrote: > > > Basically this would add syntax to python that would transform > > @decorator("spam this") variable > > into > > variable = decorator("variable", "spam this") > > That is confusingly different from decorator syntax in other contexts.... > > @decorator("spam this") > def func(): pass > > # transformed to: > > def func(): pass > func = decorator("spam this")(func) > > ...the critical difference is that the argument "spam this" should be > passed to the decorator *factory*, which then returns the actual > decorator that gets applied to the variable. (Or function/ class in the > case of regulator decorator syntax.) Well, in actuality even if it were implemented the way you described, it is still going to be very different--- I might even say radically different. These two ideas of a decorator syntax result are not the same: RESULT A: function decorator # func = decorator("spam")(func) RESULT B: variable decorator # name = decorator("spam")("name") ...because func is passed as an object, but "name" a string representing the name of the object. Two very different things. For this reason I think I would agree even more so that the differences in the decorator behavior would be an extremely significant point of confusion. This got me to thinking: what if access to the variable name were provided by another means, and ONLY when the decorator syntax is employed? So then I started to write this big long email and it kind of got out of hand. Hopefully it isn't a disaster. FIRST LAYER: RICK'S (LIKELY HALF-BAKED) COUNTER PROPOSAL Maybe employment of decorator syntax could OPTIONALLY trigger a new dunder method-- here I'll just call it __decoration_call__-- with the signature: def __decoration_call__(self, obj: Any, by_name: str) -> Any: ... Before I describe what I intend by this, first I will stipulated that what I am proposing here should only be implemented so that the behavior of all currently existing decorators (i.e., all callables) would remain exactly as it does today. So, for any existing callable with the name decorator, this: @decorator("spam this") def func(): ... ...continues to mean this, just as it does today: def func(): ... func = decorator("spam this")(func) My idea is to optionally allow any callable object to write a __decoration_call__ method that gets called in lieu of the __call__ method when the callable object is employed using decorator syntax. When this happens, the decorated named is supplied- not counting self- as the first argument (e.g., by_name), which contains the str value of the name the decorator was applied to. Let's explain using code examples. In actuality, unless I'm wrong (I might be; not an expert) current decorator syntax is really sugar for: def func(): ... func = decorator.__call__("spam this").__call__(func) My proposal is to make it such that: @decorator def func(): ... ...*can result* in this: def func(): ... func = decorator.__decoration_call__( func, "func") And also so that this: @decorator("spam this") def func(): ... ...*can result* in this: def func(): ... func = decorator.__call__("spam this").__decoration_call__(func, "func") I say "*can result*" because this has the following limitations: 1. occurs only when the callable object is employed as a decorator 2. occurs only when __decoration_call__ exists (and if it doesn't, just revert back to the usual __call__(func_object, obj)) Here is an example to further illustrate the suggested behavior. It is not intended to demonstrate a useful example. You could write a callable object like this: class Decorator: def __call__(self, obj): print("spam") return obj def __decoration_call__(self , obj, by_name): print("eggs") print(by_name) return obj decorator = Decorator() And the behavior would be like this: def func(): ... func = decorator(func) # Console output: # 'spam' @decorator def func(): ... # Console output: # 'eggs' # 'func' In order to preserve current behavior, the built-in <class 'function'> type would not grow its own new __decoration_call__ method. So in the case of existing normal functions, and also in the case of existing custom Callable objects, the fallback would be to just use __call__ as normal. In this way, all of the proposal is optional. But as illustrated above, the new dunder can be implemented by any customized Callable class. I think __decoration_call__ by itself could provide a lot of interesting possibilities for existing class and function decoration. But my main motivation for this is as a different way of implementing the variable decorator idea proposed by Jeremiah. SECOND LAYER: VARIABLE DECORATORS With __decoration_call__ in place, we could do a lot of interesting things if we take the additional step of broadening existing decorator syntax such that you can decorate not just functions and classes but also variables (similar the variable decorator proposal recently proposed by Jeremiah). But first let's define the variable decorator syntax behavior. Using the same decorator object I have defined above, and borrowing Jeremiah's original example, the new syntax would transform this: @decorator variable ...into this: variable = decorator.__decoration_call__(None, "variable") EXPLANATION OF None: in the example above there is no assignment on the decorated line, and so there is no object to pass to the dunder at that point . Because of this, the first argument, which is usually the object being decorated, is supplied as None in the call to __decoration_call__ . Only the name being assigned to the as-yet uncreated object exists. And the new syntax would transform this: @decorator variable = "spam" ...into this: variable = decorator.__decoration_call__(variable, "variable") With the behavior of this variable decoration defined as shown above, here are some of the interesting possibilities I was considering. One possibility is avoiding the pitfalls of name repetition in the RAD framework context previously mentioned by Stéfane Fermigier in Jeremiah's variable decorator thread (see his post for examples). It could see other frameworks, like web frameworks, making use if this too. (Here I will repeat some of the possibilities suggested by Jeremiah in his first post) The standard library and other library functions could, as needed, make use of __decoration_call__ as they see fit. I could see factories like namedtuple, make_dataclass, several typing factories, and Enum, implementing __decoration_call__ so you can say things like: @namedtuple Point = "x y z" @make_dataclass Point = [("x", int), ("y", int), ("z", int)] @typing.TypeVar T = (str, bytes) @typing.NewType UserId = int @enum.Enum Colors = "RED GREEN BLUE" Admittedly, these examples are not all that compelling on their own, but I think they read really well and they would allow you to avoid retyping a name (and potentially making a mistake in retyping it), so I think I really like it. ___ SIDEBAR I also note that the above examples use a different idiom than suggested by Jeremiah. He has suggested these: @namedtuple("x y z") Point @make_dataclass([("x", int), ("y", int), ("z", int)]) Point @typing.TypeVar( (str, bytes) ) T @typing.NewType(int) UserId @enum.Enum("RED GREEN BLUE") Colors ...but using my proposal I do not see a way to make this idiom easily work with the existing factories. I am not sure which of these two idioms people would prefer. I can see pros and cons for both idioms. If people preferred the second idiom, new decorator objects could be added for it. ___ One interesting possibility might be to modify inspect.getsource so that it can retrieve the RHS of the line on which it appears*: @inspect.getsource my_var = 1/2 print(my_var) # Result # '@inspect.getsource my_var = 1/2' * NOTE: I am admittedly hand-waving this. Maybe there are reasons getsource would not be able to do this? Using the rhs string from this new version of getsource, it would be a pretty simple matter for a symbolic math library like sympy to replace the float value resulting from 1/2 in my_var with a symbolic math value: @sympy.sympify my_var = 1/2 # Result is not 0.5, but: # 1/2 ...or create a Fraction (using a modified Fraction type): @Fraction my_var = 1/2 # Result is not 0.5, but: # Fraction(1, 2) ..or a Decimal (using a modified Decimal type): @Decimal my_var = 0.5 # Result is not 0.5, but: # Decimal('0.5') MAYBE A DEFAULT DUNDER AFTER ALL...? One final possibility: I have said above we would not supply any default __decoration_call__ method, and instead fallback on __call__. But it might be beneficial to supply a default __decoration_call__ with the following implementation: def __decoration_call__(self, func, by_name): if func is None: return self(by_name) return self(func) This would allow things like this, "out of the box": @typing.NewType Color = str @Color GREEN ...which becomes: Color = typing.NewType.__decoration_call__(str, "Color") GREEN = Color.__decoration_call__(None, "GREEN") In the above, Color is just a stand-in for str. If there is a default __decoration_call__ method as I wrote above, then: Color.__decoration_call__(None, "GREEN") ...is actually just: str.__decoration_call__(None, "GREEN") ..and the default implementation just returns: str("GREEN") ...and assigns it to the name, GREEN. Guess I'll leave it at that. Let's see how this is received. --- Ricky. "I've never met a Kentucky man who wasn't either thinking about going home or actually going home." - Happy Chandler [View Less]

9 29

The name Ellipsis should be a constant
by André Roberge June 1, 2021

June 1, 2021

In Python `...` is referred to as `Ellipsis` and cannot be assigned to. Yet, one can assign any value to the name `Ellipsis`. Consider the following: ``` >>> ... Ellipsis >>> ... == Ellipsis True >>> Ellipsis Ellipsis >>> Ellipsis = 3 >>> Ellipsis 3 >>> ... = 4 File "<stdin>", line 1 ... = 4 ^ SyntaxError: cannot assign to Ellipsis >>> # But I just did assign a new value to the name Ellipsis above. >>> … [View More]

14 33

Re: symbolic math in Python
by Oscar Benjamin June 1, 2021

June 1, 2021

On Tue, 1 Jun 2021 at 05:16, Neil Girdhar <mistersheik(a)gmail.com> wrote: > > Hi Oscar, > > The problem that the original poster was trying to address with > additional syntax is the automatic naming of symbols. He wants to > omit this line: > > x = symbols("x") > > You're right that if you have many one-character symbol names, you can > use a shortcut, but this benefit is lost if you want descriptive names > like: > > momentum = symbols('… [View More]momentum') > > He is proposing new syntax to eliminate the repeated name. The > function approach specifies each name exactly once. This is one of > the benefits of JAX over TensorFLow. > > Second, the function approach allows the function to be a single > object that can be used in calcuations. You might ask for: > > grad(equation, 2)(2, 3, 4 5) # derivative with respect to parameter 2 > of equation evaluated at (2, 3, 4, 5) > > With the symbolic approach, you need to keep the equation object as > well as the symbols that compose it to interact with it. This makes more sense in a limited context for symbolic manipulation where symbols only represent function parameters so that all symbols are bound. How would you handle the situation where the same symbols are free in two different expressions that you want to manipulate in tandem though? In this example we have two different equations containing the same symbols and we want to solve them as a system of equations: p, m, h = symbols('p, m, h') E = p**2 / 2*m lamda = h / p E1 = 5 lamda1 = 2 [(p1, m1)] = solve([Eq(E, E1), Eq(lamda, lamda1)], [p, m]) I don't see a good way of doing this without keeping track of the symbols as separate objects. I don't think this kind of thing comes up in Jax because it is only designed for the more limited symbolic task of evaluating and differentiating Python functions. Also for simple expressions like this I think that a decorated function seems quite cumbersome: @symbolic def E(p, m): return p**2 / (2*m) @symbolic def lamda(h, p): return h / p > Finally, the function can just be called with concrete values: > > equation(2, 3, 4, 5) # gives 25 > > which is convenient. That is convenient but I think again this only really makes sense if all of your expressions are really just functions and all of your symbols are bound symbols representing function parameters. It is possible in sympy to convert an expression into a function but you need to specify the ordering of the symbols as function parameters: expression = p**2 / (2*m) function = lambdify([p, m], expression) function(1, 2) # 0.25 The need to specify the ordering comes from the fact that the expression itself is not conceptually a function and does not have an ordered parameter list. -- Oscar [View Less]

2 4