[Python-ideas] Re: Adding syntax for the empty set

2021-04-09 Thread micro codery
> > > You can now use `{*()}` as a syntax for empty set. > > I saw that in the ast module and think it's clever, mainly in a good way. I don't think it is the same as having dedicated syntax for the empty set partly because I think it needs to be taught. I don't think a new pythonista would turn to

[Python-ideas] Re: division of integers should result in fractions not floats

2021-05-21 Thread micro codery
> If there was some way to make >@syms x, y > translate to x, y = syms('x, y') or something like that then that > would be great. Maybe that doesn't have broad enough use for Python > the language but I would certainly add something like that if I was > providing a SymPy UI based on a modified

[Python-ideas] Decorators on variables

2021-05-24 Thread micro codery
Variable decorators have been suggested here before, as have new statements that could also achieve the same level of access to the binding name. However I propose a much more restricted syntax that would make for less edge cases where what is actually passed to the decorator callable may be ambigu

[Python-ideas] Re: Decorators on variables

2021-05-25 Thread micro codery
On Tue, May 25, 2021 at 12:30 AM Steven D'Aprano wrote: > > Your proposal appears to be: > > @decorator(expression) targetname > > # transformed into: > > targetname = decorator("targetname", expression) > Correct > But in class and function decorator contexts, the equivalent synta

[Python-ideas] Re: Decorators on variables

2021-05-26 Thread micro codery
While I am not at this point dropping the idea of @decorator(expression) targetname a thought occurred to me yesterday after discussing targetname as a string in assignments (and I appreciate the continued discussion in a new thread but this is a new counter proposal so keeping it here). There is a

[Python-ideas] Re: A __decoration_call__ method for Callable objects (WAS: Decorators on variables)

2021-05-27 Thread micro codery
On Thu, May 27, 2021 at 9:34 AM Ricky Teachey wrote: > On Thu, May 27, 2021 at 10:25 AM Steven D'Aprano > wrote: > > No, I understood the OP's proposal perfectly. I was agreeing with you > implicitly when you previously said the inconsistency between the OP's > proposal and current decorator is

[Python-ideas] Re: A __decoration_call__ method for Callable objects (WAS: Decorators on variables)

2021-05-27 Thread micro codery
On Thu, May 27, 2021 at 10:40 AM Matt del Valle wrote: > Bikesheddable, but I don't know why having these two be equivalent: >> >> @decorator var >> @decorator var = None >> >> ..would be a problem. Having an implied default of None for var above >> makes sense to my brain. Do you have an example

[Python-ideas] Re: A __decoration_call__ method for Callable objects (WAS: Decorators on variables)

2021-05-28 Thread micro codery
On Thu, May 27, 2021 at 12:39 PM Ricky Teachey wrote: > On Thu, May 27, 2021 at 2:32 PM micro codery wrote: > >> >> But what is actually valid to follow a decorator in this proposal? >> Any simple expression, any expression? Is it limited to assignment >> espres

[Python-ideas] Re: A __decoration_call__ method for Callable objects (WAS: Decorators on variables)

2021-05-28 Thread micro codery
On Fri, May 28, 2021 at 5:07 PM Rob Cliffe Co wrote: > > > On 29/05/2021 00:51, micro codery wrote: > > > I also don't know what should happen for complicated assignments, and I > think this > has been the death of such variable decorator discussions in the past,

[Python-ideas] Re: A __decoration_call__ method for Callable objects (WAS: Decorators on variables)

2021-05-28 Thread micro codery
Ah, I think you might be missing the context of the original proposal? I do mean bare unbound identifiers - at lease as they occur in this new syntax. # currently works spam = “eggs” spam: eggs # currently a NameError spam # proposed to work, currently illegal @spam eggs @spam(“eggs”) cheese