[Python-ideas] Re: f-strings as assignment targets

On Fri, Sep 18, 2020 at 4:56 AM Steven D'Aprano wrote: > But that's a *separate problem*. Regexes can't assign directly either. > And we wouldn't want them to! (It's okay for a regex to have it's own > internal namespace, like named groups, but it shouldn't leak out into > the locals or

[Python-ideas] Re: Allow arbitrary expressions in decorator syntax

I also wanted to add: If @a, b, c def func(): ... was prohibited (i.e. you must use parentheses) because [it looks like] it doesn't make any sense, shouldn't be also the case that any expression with spaces should be parenthesized? Because this looks equally "wrong": @a + b * c**d

[Python-ideas] Re: Allow arbitrary expressions in decorator syntax

I was referring more to the fact that you don't need parentheses around that—if I remove the leading space, it looks like @ is an operator that operates on the first `Spam()`: @Spam() + Spam() def func() pass while instead it's just part of the (compound) statement syntax for

[Python-ideas] Re: Allow arbitrary expressions in decorator syntax

On Fri, Sep 18, 2020 at 3:50 PM Paolo Lammens wrote: > > > class Spam: > > > def __add__(self, other): return self > > > def __call__(self, f): return f > > > > > > @ Spam() + Spam() > > > def func(): > > > pass > I think so, yes. > > > That looks hella

[Python-ideas] Re: f-strings as assignment targets

On Sat, Sep 19, 2020 at 8:59 AM Dennis Sweeney wrote: > > I think it would be easiest to reason about if an Exception is always raised > when not everything is assigned to. Just like the behavior of other unpacking > assignment, either everything is assigned or there's an error. My apologies >

[Python-ideas] Re: f-strings as assignment targets

I think it would be easiest to reason about if an Exception is always raised when not everything is assigned to. Just like the behavior of other unpacking assignment, either everything is assigned or there's an error. My apologies if that wasn't clear from the examples.

[Python-ideas] Re: Allow arbitrary expressions in decorator syntax

Great! I've just read the PEP, and the new grammar is just decorator: '@' namedexpr_test NEWLINE with the only parentheses requirement being tuple displays. Does that mean that the following is valid? class Spam: def __add__(self, other): return self def

[Python-ideas] Re: Allow arbitrary expressions in decorator syntax

I guess the "search before you post" thing doesn't only apply to StackOverflow ;P ___ Python-ideas mailing list -- python-ideas@python.org To unsubscribe send an email to python-ideas-le...@python.org

[Python-ideas] Re: Allow arbitrary expressions in decorator syntax

Don't worry, I've got you covered: https://www.python.org/dev/peps/pep-0614/ Look for it when Python 3.9 drops in a couple of weeks! Brandt ___ Python-ideas mailing list -- python-ideas@python.org To unsubscribe send an email to

[Python-ideas] Re: Allow arbitrary expressions in decorator syntax

On Sat, Sep 19, 2020 at 4:35 AM Paolo Lammens wrote: > > The current grammar for decorators is > > decorator ::= "@" dotted_name ["(" [argument_list [","]] ")"] NEWLINE > > This restricts the decorator syntax to dotted names with an optional call > with an argument list: > Guido's Time Machine

[Python-ideas] Allow arbitrary expressions in decorator syntax

The current grammar for decorators is decorator ::= "@" dotted_name ["(" [argument_list [","]] ")"] NEWLINE This restricts the decorator syntax to dotted names with an optional call with an argument list: @spam.eggsdef f(): ... @ham('foo, 'bar')def g(): ... I love the amount of

[Python-ideas] Re: f-strings as assignment targets

On Fri, Sep 18, 2020, 2:22 AM Ricky Teachey > On Fri, Sep 18, 2020, 6:35 AM Alex Hall > >> The point is that this: >> > >> (a, b) = c >> >> is 'assigning to a literal' just as much as this: >> >> f"{a} {b}" = c >> >> Both are just things that look like expressions with dynamic values but

[Python-ideas] Re: f-string code formatting

Is there a list of supported preprocessor directives or compiler directives supported by CPython and other tools? - from __future__ import ... - __debug__ https://docs.python.org/3/library/constants.html#__debug__ - encoding https://www.python.org/dev/peps/pep-0263/#defining-the-encoding #

[Python-ideas] Re: f-strings as assignment targets

On Fri, Sep 18, 2020 at 12:16 PM Wes Turner wrote: > This functionality MUST be accessible with a function or a method. (?) > > As already mentioned, building up a pattern string and then using that on > the LHS cannot work: > > >>> pattern = "{a:d} {b:d}" > >>> pattern += " {c:s}" > >>>

[Python-ideas] Re: f-strings as assignment targets

This functionality MUST be accessible with a function or a method. (?) As already mentioned, building up a pattern string and then using that on the LHS cannot work: >>> pattern = "{a:d} {b:d}" >>> pattern += " {c:s}" >>> pattern = "12 34 ef" This is the way Parse works; you call parse()

[Python-ideas] Re: A shortcut to load a JSON file into a dict : json.loadf

On Fri, Sep 18, 2020 at 9:39 AM Paolo Lammens wrote: > I'm not so sure about dispatch because it is solely based on type and > isn't very flexible; if in the future any change is made to the definition > of path-like, or another addition is made to `json.load`/`json.dump`, or > whatever, the

[Python-ideas] Re: A shortcut to load a JSON file into a dict : json.loadf

> I understand the theory here: but practicality beats purity -- do we really > imagine that folks will create these path-like and file-like objects, and > then pass them into json.load() and get upset when it behaves oddly? > > And this really doesn't feel that different from the fact that you

[Python-ideas] Re: A shortcut to load a JSON file into a dict : json.loadf

> - inline the existing contents of _load by indenting within the conditional > - just add the new code at the top of the function Yes, this is what I was referring to; I'd choose one of these options. I'm not so sure about dispatch because it is solely based on type and isn't very flexible; if

[Python-ideas] Re: f-strings as assignment targets

On Fri, Sep 18, 2020, 9:16 AM Chris Angelico wrote: > On Fri, Sep 18, 2020 at 11:04 PM Ricky Teachey wrote: > > > > On Fri, Sep 18, 2020, 8:34 AM Chris Angelico wrote: > >> > >> On Fri, Sep 18, 2020 at 10:26 PM Ricky Teachey > wrote: > >> > > >> > On Fri, Sep 18, 2020, 8:17 AM Ricky Teachey

[Python-ideas] Re: f-strings as assignment targets

On Fri, Sep 18, 2020 at 11:04 PM Ricky Teachey wrote: > > On Fri, Sep 18, 2020, 8:34 AM Chris Angelico wrote: >> >> On Fri, Sep 18, 2020 at 10:26 PM Ricky Teachey wrote: >> > >> > On Fri, Sep 18, 2020, 8:17 AM Ricky Teachey wrote: >> >> >> >> >> >> Why not just grow a parse method on str that

[Python-ideas] Re: f-strings as assignment targets

On Fri, Sep 18, 2020, 8:44 AM Eric V. Smith wrote: > > On 9/18/2020 8:19 AM, Ricky Teachey wrote: > > On Fri, Sep 18, 2020, 8:17 AM Ricky Teachey wrote: > >> >> Why not just grow a parse method on str that returns a dict and do it >> this way? >> > >> q = "{a} {b}" >> p = "1 2" >> (a, b) =

[Python-ideas] Re: f-strings as assignment targets

On Fri, Sep 18, 2020, 8:34 AM Chris Angelico wrote: > On Fri, Sep 18, 2020 at 10:26 PM Ricky Teachey wrote: > > > > On Fri, Sep 18, 2020, 8:17 AM Ricky Teachey wrote: > >> > >> > >> Why not just grow a parse method on str that returns a dict and do it > this way? > >> > >> > >> q = "{a} {b}" >

[Python-ideas] Re: f-string code formatting

> As Ricky and Wes have pointed out, IDE refactoring tools are already able to > look inside not just f-strings but regular strings too. Ricky has written the opposite : "As far as I know, none of these tools know how to do the renaming of the FIRST bar to bar_new:", and i can confirm > If

[Python-ideas] Re: f-strings as assignment targets

On 9/18/2020 8:19 AM, Ricky Teachey wrote: On Fri, Sep 18, 2020, 8:17 AM Ricky Teachey > wrote: Why not just grow a parse method on str that returns a dict and do it this way? q = "{a} {b}" p = "1 2" (a, b) = q.parse(p) Sorry that should have

[Python-ideas] Allow required parameters after optional in dataclasses

I would like to do evil and nasty things with my dataclasses: inherit and extend them. In particular, I want to allow non-defaulted fields (ie required parameters to `__init__`) to be specified after defaulted fields (ie optional parameters), specifically in sub-classes (both parent and

[Python-ideas] __typing__: new top level special variable to indicate typing enabled

In short, the idea is simple to add a special variable, available in the global scope, so you can do this: if __typing__: import typing import another_heavy_typing_lib It has similar semantics as typing.TYPE_CHECKING, but it would be available in any context without the need to import

[Python-ideas] Re: f-strings as assignment targets

On Fri, Sep 18, 2020 at 10:26 PM Ricky Teachey wrote: > > On Fri, Sep 18, 2020, 8:17 AM Ricky Teachey wrote: >> >> >> Why not just grow a parse method on str that returns a dict and do it this >> way? >> >> >> q = "{a} {b}" >> p = "1 2" >> (a, b) = q.parse(p) > > > Sorry that should have been:

[Python-ideas] Re: f-strings as assignment targets

On Fri, Sep 18, 2020, 8:17 AM Ricky Teachey wrote: > > Why not just grow a parse method on str that returns a dict and do it this > way? > > q = "{a} {b}" > p = "1 2" > (a, b) = q.parse(p) > Sorry that should have been: (a, b) = q.parse(p).values()

[Python-ideas] Re: f-strings as assignment targets

On Fri, Sep 18, 2020, 6:35 AM Alex Hall wrote: > The point is that this: > > (a, b) = c > > is 'assigning to a literal' just as much as this: > > f"{a} {b}" = c > > Both are just things that look like expressions with dynamic values but > aren't. > I agree with you. It's not that

[Python-ideas] Re: Magic attribute for attribute names retrieving

> Dunder names are reserved for use by the Python interpreter. That's convenient, because my suggestion is to add a magic attribute into the Python specifications ;) It would be a `type` attribute, like `__mro__` or others. > So here we have `__attrs__` is not just a dunder attribute, but

[Python-ideas] Re: f-strings as assignment targets

On Fri, Sep 18, 2020 at 3:46 AM Steven D'Aprano wrote: > If there is anything that might justify the name "tuple (or list) > literal" it would be a tuple with each item a literal: > > (1, "a", None) > > but certainly not one containing expressions or names: > > (spam+1, eggs(),

[Python-ideas] Re: f-string code formatting

On Fri, Sep 18, 2020 at 08:05:27AM -, Joseph Perez wrote: > Steven D'Aprano wrote: > > I'm not aware of many refactoring tools for Python at all, [...] I don't > > know how well IDEs like VisualStudio and PyCharm do refactoring. > > This help me to understand your point of view. > > But if

[Python-ideas] Re: f-string code formatting

Ricky Teachey wrote: > But if you really want it or need it in a situation where find and replace > isn't a great option The example i've given is a good example where find and replace isn't a great option. In fact, you don't want to use find and replace to change a function parameter, because

[Python-ideas] Re: f-string code formatting

Steven D'Aprano wrote: > I'm not aware of many refactoring tools for Python at all, [...] I don't know > how well IDEs like VisualStudio and PyCharm do refactoring. This help me to understand your point of view. But if I consider your proposition, it's evident that a simple comment `#