[Python-ideas] Re: Arrow functions polyfill

On 24/02/2021 14:04, Random832 wrote: On Tue, Feb 23, 2021, at 17:01, Rob Cliffe via Python-ideas wrote: As far as I know, there is no case of valid syntax using 'lambda' where replacing 'lambda' by 'def' results in valid syntax. Can anyone provide a counter-example? If not, I would support al

[Python-ideas] Re: Dataclasses, keyword args, and inheritance

In response to Eric V. Smith, if something like what you're suggesting were to be implemented I would much rather it be done with context managers than special values, because otherwise you once again end up in a situation where it's impossible to easily subclass a dataclass (which was one of the

[Python-ideas] Re: Dataclasses, keyword args, and inheritance

This might be a bit of an extreme step to take, but has new syntax for this ever been discussed? Here I am using the same indicator for keyword arguments as in a function signature, hanging on a line by itself: @dataclasses.dataclass class Comparator: a: Any b: Any * key: Optional[

[Python-ideas] Re: Dataclasses, keyword args, and inheritance

On 3/11/21 4:20 AM, Ricky Teachey wrote: This might be a bit of an extreme step to take, but has new syntax for this ever been discussed? Here I am using the same indicator for keyword arguments as in a function signature, hanging on a line by itself: @dataclasses.dataclass class Comparator:

[Python-ideas] Re: Dataclasses, keyword args, and inheritance

On Thu, Mar 11, 2021 at 10:00 AM Ethan Furman wrote: > On 3/11/21 4:20 AM, Ricky Teachey wrote: > > > This might be a bit of an extreme step to take, but has new syntax for > this ever been discussed? Here I am using the same indicator for keyword > arguments as in a function signature, hanging o

[Python-ideas] Re: Dataclasses, keyword args, and inheritance

Given that @dataclass is a decorator, and otherwise you're just defining a class, some concerns: 1. Such proposed syntax would require a change to the language specification.  2. It would seem that / and * in a class not decorated with @dataclass would be of no other utility. Paul On Thu, 2021-

[Python-ideas] Re: Dataclasses, keyword args, and inheritance

On Thu, Mar 11, 2021 at 10:20 AM Paul Bryan wrote: > Given that @dataclass is a decorator, and otherwise you're just defining a > class, some concerns: > > 1. Such proposed syntax would require a change to the language > specification. > > 2. It would seem that / and * in a class not decorated wi

[Python-ideas] Re: Dataclasses, keyword args, and inheritance

On 3/11/2021 10:23 AM, Ricky Teachey wrote: On Thu, Mar 11, 2021 at 10:20 AM Paul Bryan > wrote: Given that @dataclass is a decorator, and otherwise you're just defining a class, some concerns: 1. Such proposed syntax would require a change to the language

[Python-ideas] Re: Dataclasses, keyword args, and inheritance

On Thu, Mar 11, 2021 at 11:59 AM Eric V. Smith wrote: > On 3/11/2021 10:23 AM, Ricky Teachey wrote: > > On Thu, Mar 11, 2021 at 10:20 AM Paul Bryan wrote: > >> Given that @dataclass is a decorator, and otherwise you're just defining >> a class, some concerns: >> >> 1. Such proposed syntax would

[Python-ideas] Re: Dataclasses, keyword args, and inheritance

On 3/10/21 9:47 PM, Eric V. Smith wrote: I'm not sure of the best way to achieve this. Using flags to field() doesn't sound awesome, but could be made to work. Or maybe special field names or types? I'm not crazy about that, but using special types would let you do something like: @dataclass

[Python-ideas] Re: Dataclasses, keyword args, and inheritance

It's current convention (and is used by typing module and static type checkers) that string annotations evaluate to valid Python types. On Thu, 2021-03-11 at 10:45 -0800, Ethan Furman wrote: > On 3/10/21 9:47 PM, Eric V. Smith wrote: > > > I'm not sure of the best way to achieve this. Using flags

[Python-ideas] Re: Add lazy import statement to protect legitimate circular imports from failing

I don't really have any knowledge of the Python interpreter's internals so I'm afraid any suggestions of mine on implementation details are going to be shots in the dark. That said, my intuition tells me that something similar to the proxy object pattern currently used by many lazy import impleme

[Python-ideas] Re: Add lazy import statement to protect legitimate circular imports from failing

On Fri, Mar 12, 2021 at 8:10 AM Matt del Valle wrote: > > I don't really have any knowledge of the Python interpreter's internals so > I'm afraid any suggestions of mine on implementation details are going to be > shots in the dark. > > That said, my intuition tells me that something similar to

[Python-ideas] Re: Add lazy import statement to protect legitimate circular imports from failing

Of course, you could encapsulate your imports inside of functions, that import only once called. However, there are plenty of cases where that is not practical. Probably one of countless examples of performing lazy imports, for precisely the reason of preventing circular imports: https://github.co

[Python-ideas] Re: Add lazy import statement to protect legitimate circular imports from failing

On Fri, Mar 12, 2021 at 8:24 AM Paul Bryan wrote: > > Probably one of countless examples of performing lazy imports, for precisely > the reason of preventing circular imports: > https://github.com/fondat/fondat-core/blob/main/fondat/lazy.py > In the case of circular imports, at what point should

[Python-ideas] Re: Add lazy import statement to protect legitimate circular imports from failing

It would be resolved at the time the value is accessed in the lazy map. The map then stores the resultant value to avoid attempting to re- import the module on every access. On Fri, 2021-03-12 at 08:31 +1100, Chris Angelico wrote: > On Fri, Mar 12, 2021 at 8:24 AM Paul Bryan wrote: > > > > Proba

[Python-ideas] Re: Dataclasses, keyword args, and inheritance

On 3/11/21 10:50 AM, Paul Bryan wrote: On Thu, 2021-03-11 at 10:45 -0800, Ethan Furman wrote: On 3/10/21 9:47 PM, Eric V. Smith wrote: I'm not sure of the best way to achieve this. Using flags to field() doesn't sound awesome, but could be made to work. Or maybe special field names or types? I

[Python-ideas] Re: Dataclasses, keyword args, and inheritance

If you're proposing something like this, then I think it would be compatible: class Hmm: # this: int that: float # pos: PosOnly # these: str those: str # key: KWOnly # some: list On Thu, 2021-03-11 at 14:06 -0800, Ethan Furman wrote: > On 3/11/21 10:50 AM, Paul Bryan wrote: > > On Th

[Python-ideas] Re: Dataclasses, keyword args, and inheritance

Disclaimer: I posted this earlier today but I think due to some first-post moderation related issues (that I've hopefully now gotten sorted out!) it may not have gone through. I'm posting this again just in case. If it's gone through and you've already seen it then I'm super sorry, please just igno

[Python-ideas] Re: Dataclasses, keyword args, and inheritance

The syntax of what you're proposing seems fairly intuitive (they might not even need to be callable).  I'm struggling to envision how the context manager would acquire scope to mark fields up in the (not yet defined) dataclass, and to capture the attributes that are being defined within. On Thu,

[Python-ideas] Re: Dataclasses, keyword args, and inheritance

That's basically my suggestion with dataclasses.KEYWORD_ONLY, and obviously POSITIONAL_ONLY also needs to exist. I'd be flexible on how to spell these. I'm currently thinking we need some way to switch back to "normal" (non-keyword-only, non-positional-only) fields. But I'm not done with my p

[Python-ideas] Re: Dataclasses, keyword args, and inheritance

Just off the top of my head, a context manager like this would give access to the required local scope, if inspecting the execution frames isn't considered too hacky. class LocalsProcessor: def __enter__(self): self.locals_ref = inspect.currentframe().f_back.f_locals self.local