Mailman 3 May 2022 - Python-ideas

Expression formed with structural pattern matching
by Matsuoka Takuo May 9, 2022

May 9, 2022

I've been unable to find a discussion on the following subject. I think structural pattern matching could sometimes be more useful to be available to form an expression than to form a statement. To be specific, given the definition of a function of the form ``` def f(): match <expression>: case <pattern 1> if <condition 1>: return <expression 1> case <pattern 2> if <condition 2>: return <expression 2> case ... ...... ``… [View More]` I imagine something like ``` (<expression 1>) if <condition 1> case <pattern 1>\ else <expression 2> if <condition 2> case <pattern 2>\ else ... ...... else <expression last> case _ match (<expression>) ``` as an expression such that it preceded by "lambda : " would specify an equivalent function. This of course doesn't fully characterize the expression, which could be evaluated not just in the scope of the function. To in terms of the two functions, they could be equivalent including how the local namespace is modified. (You might look at a few remarks on the syntax at the bottom.) What may it be good for? Such an expression is analogous to a conditional expression. ``` *** if ... else *** if ... else *** ``` An if-statement gives you a list of statements for each case, but a conditional expression gives an expression for each case. You'd more like the latter at some places (while more the former at some other places). The similar thing can be thought of about structural pattern matching. On the other hand, a match statement can be more preferable than an equivalent if-statement in some cases, so I think there can be something more preferable than a conditional expression in similar cases. Here's a picture of the idea. if-statement ======> conditional expression | | | | V V match statement ===> Do we want something here? I expect some expressions using structural pattern matching would be less repetitive to write and easier to read than equivalent conditional expressions. Comparison would be similar to that of match statements with if-statements. Remark ------ A larger theme may be a kind of expression associated to any kind of compound statement. Note the form of function like f above can be considered with any kind of compound statement. Namely, one can consider a function whose code is a compound statement of the considered kind with every suite a return statement, or perhaps better, of the form yield <expression>. One may then wish for an "expression version" of it like considred above for the case of match statement. Another example of existing such thing than conditional expression is comprehension, essentially corresponding to for-statement (where the dict comprehension is a slight extension of it). Similary, one may consider comprehension corresponding to a while-loop instead of a for-loop. for-loop comprehension can also be done with the functions map (and filter). One can consider a similar function map_while (or "apply_while"?) for while-comprehension. Another thing about comprehension is that the form of the model function f can very meaningfully be modified so the suite is to be of the form yield from <expression>. I've seen a proposal of syntax for the corresponding comprehension. An expression analogue of match statement seems to be a good place to start from (whether the larger theme may go anywhere). Remarks on the syntax --------------------- (1) "if <condition i>" can be omitted where no guard is necessary. (2) I expect the last case in the expression not being the wildcard pattern "_" without a guard would result in SyntaxError raised. (<expression last> can be None if the match statement in the original definition of the function doesn't have this case.) (3) Parentheses around <expression 1> and <expression> in the expression are in case those expressions are themselves conditional or similarly formed with structural pattern matching (let me call an expression of the form a match expression for short). Actual necessity of parentheses in these and other places (such as around a match expression within a conditional expression) depends on the order in which parts are to be placed in a match expression, as well as conventions such as whether priority be set between conditional and match expressions. Requiring some redundant parentheses any way might help with avoiding bugs and/or making parsing easier (for programs as well as for human beings). Conditional expression seems to be taking this approach. >>> True if False if False else False else False File "<stdin>", line 1 True if False if False else False else False ^ SyntaxError: invalid syntax Best regards, Takuo Matsuoka [View Less]

1 0

Auto assignment of attributes
by Pablo Alcain May 8, 2022

May 8, 2022

The problem of assigning init arguments as attributes has appeared several times in the past ( https://mail.python.org/archives/list/python-ideas@python.org/message/VLI3D… was the most recent we could find) and is already handled in dataclasses. Lately, discussing this topic with a friend, we thought that using a specific token could be a possible approach, so you could do: class MyClass: def __init__(self, @a, @b, c): pass and it would be analogous to doing: class MyClass: … [View More] def __init__(self, a, b, c): self.a = a self.b = b Then, you would instantiate the class as usual, and the variables tagged with `@` would be bound to the object: >>> objekt = MyClass(2, 3, 4) >>> print(objekt.b) 3 >>> print(objekt.c) AttributeError: 'MyClass' object has no attribute 'c' We have a working implementation here if anyone wants to take a look at: https://github.com/pabloalcain/cpython/tree/feature/auto_attribute. Keep in mind that we have limited knowledge about how to modify cpython itself, and which would the best places be to do the modifications, so it's more than likely that some design decisions aren't very sound ( https://devguide.python.org/grammar/ and https://devguide.python.org/parser/ were incredibly helpful). Besides the implementation, we would like to know what the community thinks on whether this might have any value. While developing this, we realized that Crystal already has this feature (eg https://github.com/askn/crystal-by-example/blob/master/struct/struct.cr) with the same syntax; which is kind of expected, considering it's syntax is based on Ruby. Random collection of thoughts: 1. If auto-assignment made sense in general, one of the reasons we went for this rather than the decorator approach is that we wouldn't like to have a list of strings that can vary decoupled from the actual argument name. 2. The current implementation of `@` works for any function, not only init. We don't know if this would actually be a desirable feature. 3. It also works with any function in the wild. This mostly allows for monkey-patching to work out of the box: >>> class Klass: ... def __init__(self): ... pass ... >>> def add_parameter(k, @p): ... pass ... >>> Klass.add_parameter = add_parameter >>> objekt = Klass() >>> print(objekt.p) Traceback (most recent call last): File "<stdin>", line 1, in <module> AttributeError: 'Klass' object has no attribute 'p' >>> objekt.add_parameter(11) >>> print(objekt.p) 11 Again, we are not sure if this is desirable, but it's what made most sense for us at the moment. 4. Adding the `@` token to the argument doesn’t remove the variable from the function/method scope, so this would be perfectly valid: >>> def my_function(k, @parameter): ... print(parameter) >>> my_function(objekt, 4) 4 >>> k.parameter 4 5. We didn’t implement it for lambda functions. Cheers, Pablo and Quimey [View Less]

12 50

Adding a .find() method to list
by python-ideas＠lucas.rs May 8, 2022

May 8, 2022

In its current implementation, the list type does not provide a simple and straightforward way to retrieve one of its elements that fits a certain criteria. If you had to get the user where user['id'] == 2 from this list of users, for example, how would you do it? users = [ {'id': 1,'name': 'john'}, {'id': 2, 'name': 'anna'}, {'id': 3, 'name': 'bruce'}, ] # way too verbose and not pythonic ids = [user['id'] for user in users] index = ids.index(2) user_2 = users[index] # short, … [View More]

6 6

Get the value of an attribute of an object hierarchy with a path expression
by Dr. Guta Gábor May 5, 2022

May 5, 2022

This proposal is about adding a builtin function or a package to the standard library to access an element in an object hierarchy with default behavior i.e. if at any level the attribute/key/index does not exist in the path the function returns a default value. Motivation: mapping an object tree to a tuple or a flat object cannot be achieved compactly with proper error handling. Need: I have found a half dozen of packages implementing this functionality on github and there is a high number of … [View More]

5 7

Re: Auto assignment of attributes
by Christopher Barker May 4, 2022

May 4, 2022

Bringing this back on list -- I hope that was an accident. (NOTE: getting a touch off-topic here -- but I do bring it back around at the end) On Wed, May 4, 2022 at 4:38 AM Paul Moore <p.f.moore(a)gmail.com> wrote: > On Tue, 3 May 2022 at 17:46, Christopher Barker <pythonchb(a)gmail.com> > wrote: > > On Tue, May 3, 2022 at 5:39 AM Paul Moore <p.f.moore(a)gmail.com> wrote: > >> > >> > > I have classes with 20+ parameters (packaging … [View More]metadata). You can > argue > >> > > that a dataclass would be better, > > > > I sure would — I’ve done exactly this, and it seems to me to be exactly > the right solution. > > Sorry, you're right. There are issues with a dataclass based approach > (I've tried it, so I know ;-)) but they aren't around repeating self.x > = x over and over. My point here was that the @-based solution isn't > useful as often as people are claiming. Agreed here -- I'm probably responsible for much of the talk about dataclasses, so sorry about that. In fact, my only point there was that dataclasses are a solution to the "I'm writing many versions of self.x = x in my __init__ method, and that seems unnecessary" problem, and that I think that very problem is the strongest case for auto-assignment. Ergo, auto-assignment isn't a critical feature. > "lots of > parameters are simply hard, and in practical cases, @ doesn't help > enough to make a difference" Agreed -- if it's a complex case, neither datclasses nor auto-assignment would help. I've used attrs, which has field converters. ... > The problem with __post_init__ (I think) is > that it confuses the type checkers (beware, untested code below!): > Does the attrs approach work any better for this? @dataclass > class Metadata: > version: str # Actually a Version, but that's not the type we > want the constructor to accept. > > def __post_init__(self): > self.version = Version(self.version) > > And the reality is worse. We want the constructor to take a Version, > or anything that can be converted to a Version > (which, if I check the > source of the library, *is* just str - but I don't want to necessarily > copy that declaration as it might change). And yet we want the > typechecker to know that metadata.version is always a Version. All of > that information is available statically (we call Version on the input > data, and self.version is always the result of that call) but I can't > see how to explain that to the type checker. Frankly, I see that as a limitation of static typing -- how does one describe "anything that can be turned into a Version? -- sure, the Version __init__ can take either a Version or a str -- but only certain strs will make any sense -- so what's the point? Honestly, I think if you want your code to be statically "safe" then you should have this metadata class require a Version object, which would require its users to do the conversion first. Which is why I like the Dynamic nature of Python, and haven't gotten excited about static typing. I suppose the way to solve this without dataclasses or auto-assignment is to type the class attribute and the __init__ parameter separately, yes? (which auto-assignment wouldn't help with, either) (untested, and probably wrong, 'cause I'm not that familiar with typing) Class Metadata: version: Version ... def __init__(self, version: Version | str, ...): ... Is that right? What this tells me is that if you want dataclasses to be more typing-friendly, then there should be a way to specify the __init__ type separately, which could be done with a parameter to the Field object. Bringing it back OT: As much as I hate to say it: For folks advocating an auto-assignment feature -- you should probably consider how it would play with static typing :-( -CHB > I'm not obsessive about > typing, but dataclasses do naturally encourage using them. And if I do > use types, I want them to be *right*, or VS Code and mypy will spend > all their time complaining about correct code :-( > > This is all irrelevant to the discussion at hand, and quite possibly > way too nitpicking to even be worth caring about, but it's what I mean > when I say "things are still hard". > > Paul > -- Christopher Barker, PhD (Chris) Python Language Consulting - Teaching - Scientific Software Development - Desktop GUI and Web Development - wxPython, numpy, scipy, Cython [View Less]

3 2

Re: infile and outfile parameters for the input function
by Steven D'Aprano May 4, 2022

May 4, 2022

On Mon, May 02, 2022 at 08:23:31PM -0700, Christopher Barker wrote: > On Mon, May 2, 2022 at 11:18 AM Steven D'Aprano > > > why one couldn't just use the redirect_stdout context manager. > > > > (Plus not-yet-existing, but hopefully soon, redirect_stdin.) > > > I have no use for this but thread safety could be an issue. No more of an issue than it is for other context managers, or for setting sys.stdio directly. > I have no idea if that’s an issue for … [View More]

1 0

infile and outfile parameters for the input function
by sam.z.ezeh＠gmail.com May 3, 2022

May 3, 2022

Previously discussed here [1] [2], it was raised that the input function could take file objects to display prompts in places other than sys.stdout and receive input from places other than sys.stdin. Locally, the patch I have produces the following help text: ``` Help on built-in function input in module builtins: input(prompt=None, /, infile=None, outfile=None) Read a string from a stream, or from standard input by default. The trailing newline is stripped. The output file is … [View More]

4 7

contextlib.redirect_stdio function
by sam.z.ezeh＠gmail.com May 3, 2022

May 3, 2022

Previously raised here [1], contextlib.redirect_stdio would be a utility function to help redirect standard input, output and error. The idea of a function called "stdio" that does the same thing was also raised. The function would combine the functionality of contextlib.redirect_stdout and contextlib.redirect_stderr which work as described in the documentation [2]. It would also add "contextlib.redirect_stdin" functionality which currently appears to be missing. The usage described in the … [View More]

2 3

int.to_base, int.from_base
by Simon de Vlieger May 2, 2022

May 2, 2022

Hey there, The `int()` function allows to specify a base to convert from, for example: >>> int("foo", 26) 10788 Which is documented as: > The base defaults to 10. Valid bases are 0 and 2-36. For other common bases functions exist in the base64 module in stdlib. I often need other bases, or bases with custom alphabets. Doing so involves a bit of code every time that I think could be generalized so I'd like to propose an `int.to_base()`, and `int.from_base`. These would not … [View More]

5 8