On 5/26/2021 7:07 AM, Chris Angelico wrote:
Either way, it would be a string. The difference is that string
literals can be placed adjacent to each other:
"{1}" f' - {1+2=} - ' '{2}'
'{1} - 1+2=3 - {2}'
Which goes to show, btw, that an f-string is still a literal, even
though it's not a
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
Ricky Teachey writes:
> Continuing on with Steven's counter proposal and the motivating example of
> symbolic math, for multiple symbols it would be this:
>
> # x, y, z = symbols( 'x,y,z' )
> x, y, z = symbols(@@)
>
> However, even though it works for the symbols example, this meaning
On Wed, May 26, 2021 at 01:33:07PM +0200, Stéfane Fermigier wrote:
> > I think that's a minor win in that you don't have to repeat the
> > variable name.
>
>
> Repetition is not the main issue, in my own experience. The main issue is
> the risk of making a typo in the variable's name when
On Wed, May 26, 2021 at 12:13 PM Steven D'Aprano
wrote:
> On Wed, May 26, 2021 at 08:58:51AM +0200, Stéfane Fermigier wrote:
>
> > For the use cases I have in mind, some kind of context information would
> > need to be passed too, like:
> >
> > class Customer:
> >
> > @permissions({"read":
On Wed, May 26, 2021 at 8:44 PM Steven D'Aprano wrote:
>
> On Tue, May 25, 2021 at 10:10:12PM +1000, Chris Angelico wrote:
> > On Tue, May 25, 2021 at 5:29 PM Steven D'Aprano wrote:
> > > Here's a counter-proposal: we have a special symbol which is transformed
> > > at compile-time to the left
On Wed, May 26, 2021 at 08:10:17PM +1000, Steven D'Aprano wrote:
> - Decorators are a hammer, and some people think that every problem
> is a nail.
Sorry, on re-reading that statement, it comes across as less gracious
than I intended.
So let me explicitly thank Jeremiah for raising this
On Tue, May 25, 2021 at 10:10:12PM +1000, Chris Angelico wrote:
> On Tue, May 25, 2021 at 5:29 PM Steven D'Aprano wrote:
> > Here's a counter-proposal: we have a special symbol which is transformed
> > at compile-time to the left hand assignment target as a string. Let's
> > say we make that
On Wed, May 26, 2021 at 08:58:51AM +0200, Stéfane Fermigier wrote:
> For the use cases I have in mind, some kind of context information would
> need to be passed too, like:
>
> class Customer:
>
> @permissions({"read": USER, "write": MANAGER})
> first_name: str
>
> the function
On Tue, May 25, 2021 at 12:14 PM Steven D'Aprano
wrote:
> On Tue, May 25, 2021 at 10:55:07AM +0200, Stéfane Fermigier wrote:
>
> > I had a similar idea ~8 years ago while working on a RAD (rapid
> application
> > development) framework [*] that had to manage business objects using a
> > variety
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
On Tue, May 25, 2021 at 8:11 AM Chris Angelico wrote:
> On Tue, May 25, 2021 at 5:29 PM Steven D'Aprano
> wrote:
> > Here's a counter-proposal: we have a special symbol which is transformed
> > at compile-time to the left hand assignment target as a string. Let's
> > say we make that special
On Tue, May 25, 2021 at 8:11 AM Chris Angelico wrote:
> On Tue, May 25, 2021 at 5:29 PM Steven D'Aprano
> wrote:
> > Here's a counter-proposal: we have a special symbol which is transformed
> > at compile-time to the left hand assignment target as a string. Let's
> > say we make that special
On Tue, May 25, 2021 at 5:29 PM Steven D'Aprano wrote:
> Here's a counter-proposal: we have a special symbol which is transformed
> at compile-time to the left hand assignment target as a string. Let's
> say we make that special expression `@@` or the googly-eyes symbol.
This is sounding
On Tue, May 25, 2021 at 10:55:07AM +0200, Stéfane Fermigier wrote:
> I had a similar idea ~8 years ago while working on a RAD (rapid application
> development) framework [*] that had to manage business objects using a
> variety of frameworks: an ORM (SQLAlchemy), a full-text engine (Whoosh), as
>
I had a similar idea ~8 years ago while working on a RAD (rapid application
development) framework [*] that had to manage business objects using a
variety of frameworks: an ORM (SQLAlchemy), a full-text engine (Whoosh), as
well as a specifically developed CRUD Web UI framework, permission system,
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.
Your
On 5/24/21 6:36 PM, micro codery wrote:
> 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
I don't have much of substance to say other than this proposal really made
me go "oh I like that" several times. There may be downsides/arguments
against I'm not considering, but I look forward to following the
conversation and hope it gets a serious hearing.
On Mon, May 24, 2021, 9:38 PM micro
19 matches
Mail list logo
