[Python-ideas] Re: Decorators for class non function properties

[Steven D'Aprano]

On Fri, Aug 07, 2020 at 12:22:28PM +1200, Greg Ewing wrote:
> On 7/08/20 2:47 am, David Mertz wrote:
> >The only difference is that in the usual existing style, 'a' doesn't 
> >know that it's called "a".  You and Steven have both, basically, said 
> >"Why would you possibly care about that?"
> 
> I've only really been thinking about attributes, but I suppose
> it might be useful for things in other contexts to know their
> names, so I guess my original proposal is not completely dead.
> But I don't have any real-world use case to put forward.

The classic example is namedtuple:

myrecord = namedtuple("myrecord", ...)

The three-argument form of type() also needs a name argument.

On the other hand, it is arguable that the status quo is more flexible, 
as you don't have to pass the same class name as the variable name you 
bind to.

-- 
Steven
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/VYWJOSGUCCL5YSUZRFR4SEJAXVOO3F4X/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Decorators for class non function properties

[Steven D'Aprano]

On Thu, Aug 06, 2020 at 04:01:47PM -, redrad...@gmail.com wrote:

> I see lots of use-cases for property decorators ...

We have had property decorators since version Python 2.2 which was 18 
years ago. We know that there are many wonderful use-cases for things 
like this. What you are not explaining is why you can do them with 
syntax:

@function
name = value

but not 

name = function(value)



-- 
Steven
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/76FNJ7H56NVAQT77WWUYHAQLVQSIMVQZ/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Decorators for class non function properties

[Steven D'Aprano]

On Thu, Aug 06, 2020 at 04:03:39PM -, redrad...@gmail.com wrote:
> No it is not possible to have something like this:

> ```python
> def function(cls):
> # Where is cls is Neuron class object
> pass
> 
> class Neuron:
> activation = function(Neuron)
> ```


Correct. And it isn't possible with decorator syntax either:


py> def decorator(cls):
... print(cls)
... def inner(func):
... return func
... return inner
... 
... 
py> class Neuron:
... @decorator(Neuron)
... def method(self):
... pass
... 
Traceback (most recent call last):
  File "", line 1, in 
  File "", line 2, in Neuron
NameError: name 'Neuron' is not defined


-- 
Steven
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/RRIABYLKDBBG7GBYYS5OL6M2WIIPRORM/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Decorators for class non function properties

[Greg Ewing]

On 7/08/20 2:47 am, David Mertz wrote:
The only difference is that in the usual existing style, 'a' doesn't 
know that it's called "a".  You and Steven have both, basically, said 
"Why would you possibly care about that?"


I've only really been thinking about attributes, but I suppose
it might be useful for things in other contexts to know their
names, so I guess my original proposal is not completely dead.
But I don't have any real-world use case to put forward.

--
Greg
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/ZPLLO3HZBPMPN7DUP5ZF2TAFCUMEDVCX/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Decorators for class non function properties

[redradist]

No it is not possible to have something like this:
```python
def function(cls):
# Where is cls is Neuron class object
pass

class Neuron:
activation = function(Neuron)
```
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/X4GVYC6GDNJHN4HUORJ5WUNXHZZLC2PW/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Decorators for class non function properties

[redradist]

Also instead of making all class as dataclass, it would be possible to make 
only some properties as instance properties:
```python
class Client:
bank = Bank()

@instance
name = Name()

print(f'Client.bank is {Client.bank}')
client = Client()
print(f'client.name is {client.name}')
```
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/LG6AQY2EFZ5MJRAPS7HKEW7LYKFAAEQH/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Decorators for class non function properties

[redradist]

Actually in example:
```python
class MyClass:
@my_property
name = arg

class MyClass:
def name(self):
...

 def see_name(self):
...
```
I have done mistake ... of course it will not be like this ...
What I wanted to show that @my_property could add more complex behavior than 
just small wrapper in one line

For example:
```python
# Module a.py
class SomeFactory:
def __init__(self, cls):
self.cls = cls

def build_context(self):
return context

def factory(name, value, self, cls):
return SomeFactory(cls)

# Module b.py
class MyClass:
@factory
name = arg
```
And so one ... also could be added optionally logging to track each time when 
somebody read property:
```python
# Module b.py
class MyClass:
@logging # Help to track each time when somebody access property
@factory
name = arg
```
I see lots of use-cases for property decorators ...
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/FY57MAJYDSKZ4DQVRAKG2K6XA7BQ6PC4/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Decorators for class non function properties

[David Mertz]

On Thu, Aug 6, 2020 at 2:52 AM Greg Ewing 
wrote:

> On 6/08/20 6:42 am, David Mertz wrote:
>  @unit("meter") a = 3  # a = unit("meter")("a", 3)
>  @unit("foot") b = 4   # b = unit("foot")("b", 4)
>
> This still doesn't explain why the decorator syntax would be
> significantly better than just calling the function directly.
>
> meters = unit("meter")
> feet = unit("foot")
>
> a = meters(3)
> b = feet(4)
>

The only difference is that in the usual existing style, 'a' doesn't know
that it's called "a".  You and Steven have both, basically, said "Why would
you possibly care about that?"  And honestly, I don't actually disagree.  I
was just trying to make a *plausible* case for wanting it to try to
extrapolate from the suggestion.

I think in the fairly rare case the (original) name matters, attaching it
manually is every bit as good.

N_a = mol(6.02214076e23)
N_a.name = "Avogadro"

I think in the oddball corner cases where we might care about the "binding
name" inside the object itself, __set_name__() gets us enough.  Yes, it's
not for globals or locals.  But putting that funny extra stuff inside an
instance seems like a low burden.


-- 
The dead increasingly dominate and strangle both the living and the
not-yet born.  Vampiric capital and undead corporate persons abuse
the lives and control the thoughts of homo faber. Ideas, once born,
become abortifacients against new conceptions.
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/R4NLH4PHMINQWHQT42SS6F3VUXB6OT4P/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Decorators for class non function properties

[Guido van Rossum]

Maybe I’m lacking context, but I don’t understand the proposal. Can you
explain the semantics and syntax you have in mind in more detail? How do
you get from the first example (@my_property etc.) to the second (def name,
def set_name)?

—Guido

On Thu, Aug 6, 2020 at 01:13  wrote:

> I think a property decorator can be useful, because you consider the
> simplest case with:
> ```python
> class MyClass:
> @my_property
> name = arg
> ```
> but consider it can generate the following code:
> ```python
> class MyClass:
> def name(self):
> ...
>
>  def see_name(self):
> ...
> ```
> Or consider the following example:
> ```python
> class MyClass:
> @factory
> strategy= arg
> ```
> that can will generate:
> ```python
> class MyClass:
> class MyClassStrategy:
> ...
>
> strategy= MyClassStrategy(arg)
> ```
>
> All it will be possible if attribute decorator will have the following
> signature:
> ```python
> def factory(name, value, self, cls):
> # Where name - name of the property
> #value - initial value of the property
> #self - instance of created object before call __init__
> #cls - class object (MyClass)
> ...
> ```
> of course some of properties could be omitted like this:
> ```python
> def factory(name, value, cls):
> # Where name - name of the property
> #value - initial value of the property
> #cls - class object (MyClass)
> ...
> ```
>
> As you can see property decorators could be very powerful thing if it will
> done right ;)
> ___
> Python-ideas mailing list -- python-ideas@python.org
> To unsubscribe send an email to python-ideas-le...@python.org
> https://mail.python.org/mailman3/lists/python-ideas.python.org/
> Message archived at
> https://mail.python.org/archives/list/python-ideas@python.org/message/MCQBK7GRYIUTA5AQAOVMEQNZANXTIDIY/
> Code of Conduct: http://python.org/psf/codeofconduct/
>
-- 
--Guido (mobile)
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/7J2QJ67KXLMJP2BE4GO2ILEUVFJ5UOJC/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Decorators for class non function properties

[Joao S. O. Bueno]

On Thu, 6 Aug 2020 at 00:14, Guido van Rossum  wrote:

> On Wed, Aug 5, 2020 at 7:06 PM Steven D'Aprano 
> wrote:
>
>> *blinks*
>>
>> When did this happen?
>>
>> I'm on Python-Ideas, Python-Dev, and I get announcements of new issues
>> on the bug tracker, and I don't recall ever seeing this feature
>> discussed.
>>
>
> Oddly I barely recall it either, even though according to PEP 487 it was
> posted five times to python-dev, and I approved it. It's a long time ago
> though (two retirements, for me :-).
>


I think that __set_name__ was greatly expected as one way to mitigate `DRY`
with descriptors it was completely uncontroversial - unlike
__init_subclass__ on the same PEP.
I for one had used it a lot of times, and I am a big fan of __set_name__

 --

> --Guido van Rossum (python.org/~guido)
> *Pronouns: he/him **(why is my pronoun here?)*
> 
> 
>
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/5FI3A5AXSCXWP3UYG3HF6HMAN6MYRK35/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Decorators for class non function properties

[Steven D'Aprano]

On Thu, Aug 06, 2020 at 08:11:50AM -, redrad...@gmail.com wrote:

> I think a property decorator can be useful, because you consider the simplest 
> case with:

We already have `property`, which can be used as a decorator.

> ```python
> class MyClass:
> @my_property
> name = arg
> ```

How is it different from

name = my_property(arg)

which is possible right now, you don't need decorator syntax.


> All it will be possible if attribute decorator will have the following 
> signature:

All of it is possible *right now*. You don't need decorator syntax to do 
any of those examples you show, you just need function calls.

You keep showing examples of function calls that do marvellous things, 
but at no point have you shown any reason why those functions need to be 
called using decorator syntax instead of ordinary function call syntax.

With your decorator suggestion, your marvellous function can only take a 
single argument:

@function  # takes a single argument
name = arg

but with regular function calls, you can pass any combinations of 
positional and keyword arguments:

name = function(arg, more, args, key=value, word=thing)

So it seems to me that you want to add special syntax that is *less* 
powerful than what we already have. Why does this have to use decorator 
syntax?

Please don't give us another list of fantastic things that you can do 
with function calls, we already know that function calls can do 
anything. Tell us how the `@function` syntax is better than the 
`function(arg)` syntax.


-- 
Steven
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/2OKPZNDHMR66G5JEJJMF6KCQXD4BUBKG/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Decorators for class non function properties

[Steven D'Aprano]

On Thu, Aug 06, 2020 at 09:57:59AM +0200, Dominik Vilsmeier wrote:

> It seems that the OP has many such transformations and wants to use
> decorators to define a pipeline of transformations:
> 
>     @foo
>     @bar
>     @baz
>     something = initial_value
> 
> instead of
> 
>     something = foo(bar(baz(initial_value)))
> 
> which becomes unreadable for longer function names / more functions in
> general.

something = \
foo(
bar(
baz(
initial_value
)))

is possible right now, and the style is not that far off the 
suggested decorator syntax.

Decorator syntax is a great hammer, and functions and classes make good 
nails. Arbitrary function calls are not good nails, there is no 
need to use a hammer on them.



-- 
Steven
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/QQ6R4KVHWAY36PCUZAAPTLMIXFKDTQUL/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Decorators for class non function properties

[Chris Angelico]

On Thu, Aug 6, 2020 at 6:16 PM  wrote:
>
> I think a property decorator can be useful, because you consider the simplest 
> case with:
> ```python
> class MyClass:
> @my_property
> name = arg
> ```
> but consider it can generate the following code:
> ```python
> class MyClass:
> def name(self):
> ...
>
>  def see_name(self):
> ...
> ```

Hmmm. I don't really like it, but worst case, you can do this with
__set_name__ and mutating the target class. You wouldn't decorate it,
just assign a my_property object to the name you want.

Alternatively, decorate the class itself with something that does
whatever changes you want.

ChrisA
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/ZADQN5GRD43HTGYIBNZSJL7YKYRTXKVU/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Decorators for class non function properties

[redradist]

I think a property decorator can be useful, because you consider the simplest 
case with:
```python
class MyClass:
@my_property
name = arg
```
but consider it can generate the following code:
```python
class MyClass:
def name(self):
...

 def see_name(self):
...
```
Or consider the following example:
```python
class MyClass:
@factory
strategy= arg
```
that can will generate:
```python
class MyClass:
class MyClassStrategy:
...

strategy= MyClassStrategy(arg)
```

All it will be possible if attribute decorator will have the following 
signature:
```python
def factory(name, value, self, cls):
# Where name - name of the property
#value - initial value of the property
#self - instance of created object before call __init__
#cls - class object (MyClass)
...
```
of course some of properties could be omitted like this:
```python
def factory(name, value, cls):
# Where name - name of the property
#value - initial value of the property
#cls - class object (MyClass)
...
```

As you can see property decorators could be very powerful thing if it will done 
right ;)
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/MCQBK7GRYIUTA5AQAOVMEQNZANXTIDIY/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Decorators for class non function properties

[Dominik Vilsmeier]

On 06.08.20 04:58, Guido van Rossum wrote:


On Wed, Aug 5, 2020 at 6:42 PM Steven D'Aprano mailto:st...@pearwood.info>> wrote:

On Wed, Aug 05, 2020 at 06:15:22PM -0700, Guido van Rossum wrote:
> On Wed, Aug 5, 2020 at 5:55 PM Steven D'Aprano
mailto:st...@pearwood.info>> wrote:

> > That require two different rules for decorators:
> >
> > @decorator over a `class name` or `def name` statement:
> >
> > - execute the statement
> > - bind `name = decorator(name)`
> >
>
> But that's not what's done. (Proof: if the decorator raises, the
name
> remains unbound.)

You are technically correct, which is the best kind of correct.

The documentation uses very close to the same wording as me

https://docs.python.org/3/reference/compound_stmts.html#function-definitions

but does make the point that "except that the original function is
not
temporarily bound to the name func". Since I wasn't writing a
reference
manual, I didn't think this level of pedantry was needed :-)

The bottom line is that the function or class statement has to be
executed *in some sense* in order to create the function or class
object, that object has to be passed to the decorator, and finally
the
object returned by the decorator has to be bound to the original name.


But that's the same as it would be for a decorated assignment, right? In
```
@deco
x = func(arg)
```
This executes `func(arg)` to create the value of the expression, then
passes it to the decorator, and finally the decorator's result is
bound to the name `x`.

In both cases there's something that gets executed to create something
(in one case, a function or class object, in another case, some other
object), and then gets bound to a name; in both cases a decorator, if
present, is inserted to transform the value just before it is bound.

A much better argument against decorating assignments is that you can
already write it just fine as
```
x = deco(func(arg))
```
and the decorated version is in no way more readable, nor does it
provide more power or expressivity.


It seems that the OP has many such transformations and wants to use
decorators to define a pipeline of transformations:

    @foo
    @bar
    @baz
    something = initial_value

instead of

    something = foo(bar(baz(initial_value)))

which becomes unreadable for longer function names / more functions in
general.

However one can always define such pipelines in advance and then apply
them when needed:

    pipeline = Pipeline(foo, bar, baz)
    something = pipeline(initial_value)

For single usage one can even define such a pipeline via decorators by
using a function to provide the initial value:

    @foo
    @bar
    @baz
    @pipeline
    def something():
        return initial_value

where `pipeline` simply returns the return value of the function it's
applied to.

___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/GPIZQLP46GAWETDBG33KILMXE5FPDGKI/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Decorators for class non function properties

[Greg Ewing]

On 6/08/20 6:42 am, David Mertz wrote:

@unit("meter") a = 3  # a = unit("meter")("a", 3)
@unit("foot") b = 4   # b = unit("foot")("b", 4)


This still doesn't explain why the decorator syntax would be
significantly better than just calling the function directly.

meters = unit("meter")
feet = unit("foot")

a = meters(3)
b = feet(4)

Seems just as readable to me.

--
Greg
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/GLOEEL3LLGMHQP5UN3RLW55LJOAG2F4Y/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Decorators for class non function properties

[Guido van Rossum]

On Wed, Aug 5, 2020 at 7:06 PM Steven D'Aprano  wrote:

> *blinks*
>
> When did this happen?
>
> I'm on Python-Ideas, Python-Dev, and I get announcements of new issues
> on the bug tracker, and I don't recall ever seeing this feature
> discussed.
>

Oddly I barely recall it either, even though according to PEP 487 it was
posted five times to python-dev, and I approved it. It's a long time ago
though (two retirements, for me :-).


> [looks up the docs]
>
> Okay, apparently it was added in 3.6. But the documentation says:
>
>
> """
> When using the default metaclass type, or any metaclass that ultimately
> calls type.__new__, the following additional customisation steps are
> invoked after creating the class object:
>
> first, type.__new__ collects all of the descriptors in the class
> namespace that define a __set_name__() method;
> """
>
> https://docs.python.org/3/reference/datamodel.html#class-object-creation
>
> but that's not what is happening here, since my_property is not a
> descriptor, it's just an arbitrary instance.
>
> (To be a descriptor, it needs to have `__get__` and/or `__set__`
> methods.)
>
> Have I missed something or does this need a documentation fix?
>

That's a good observation. I think the PEP was only thinking of
descriptors, and the implementation possibly took a shortcut by calling
`__set_name__` on every attribute. Or perhaps the PEP was ambiguous, since
under proposal, item (2) states that the "hook is called on all the
attributes (descriptors) defined in the class".

Now there's a general rule that says "if you use a dunder in a way that's
undocumented, the behavior is undefined" (and this includes making up your
own dunders), which means that technically the implementation could do
whatever it wants -- but since this is Python we probably want to accept
that it's called for every attribute, whether it smells like a descriptor
or not, and it would be nice to fix the docs.

Do you have the powers to submit PRs these days?

-- 
--Guido van Rossum (python.org/~guido)
*Pronouns: he/him **(why is my pronoun here?)*

___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/XCIFYOJQZLKWVG4Z3I4SWYRO6GGSVZQ4/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Decorators for class non function properties

[Guido van Rossum]

On Wed, Aug 5, 2020 at 6:42 PM Steven D'Aprano  wrote:

> On Wed, Aug 05, 2020 at 06:15:22PM -0700, Guido van Rossum wrote:
> > On Wed, Aug 5, 2020 at 5:55 PM Steven D'Aprano 
> wrote:
>
> > > That require two different rules for decorators:
> > >
> > > @decorator over a `class name` or `def name` statement:
> > >
> > > - execute the statement
> > > - bind `name = decorator(name)`
> > >
> >
> > But that's not what's done. (Proof: if the decorator raises, the name
> > remains unbound.)
>
> You are technically correct, which is the best kind of correct.
>
> The documentation uses very close to the same wording as me
>
>
> https://docs.python.org/3/reference/compound_stmts.html#function-definitions
>
> but does make the point that "except that the original function is not
> temporarily bound to the name func". Since I wasn't writing a reference
> manual, I didn't think this level of pedantry was needed :-)
>
> The bottom line is that the function or class statement has to be
> executed *in some sense* in order to create the function or class
> object, that object has to be passed to the decorator, and finally the
> object returned by the decorator has to be bound to the original name.
>

But that's the same as it would be for a decorated assignment, right? In
```
@deco
x = func(arg)
```
This executes `func(arg)` to create the value of the expression, then
passes it to the decorator, and finally the decorator's result is bound to
the name `x`.

In both cases there's something that gets executed to create something (in
one case, a function or class object, in another case, some other object),
and then gets bound to a name; in both cases a decorator, if present, is
inserted to transform the value just before it is bound.

A much better argument against decorating assignments is that you can
already write it just fine as
```
x = deco(func(arg))
```
and the decorated version is in no way more readable, nor does it provide
more power or expressivity. For functions and classes, the old way was
```
def f(a, b, c):
<20 lines of body code>
f = deco(f)
```
which hides the decorator call where it is easily overlooked (especially by
people who are quickly scanning code for function definitions). The
decorator syntax was introduced so that the transformation could be placed
where it is noticed by the reader.

Another way of looking at the difference between decorating expressions vs.
decorating function/class definitions would be that syntactically, `def`
and `class` statements are multi-line definitions, so that it makes sense
that a modifier should be placed on a line by itself; whereas assignments
are single-line definitions, so that modifiers should also be placed
in-line.

-- 
--Guido van Rossum (python.org/~guido)
*Pronouns: he/him **(why is my pronoun here?)*

___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/5UTWAIX2BJLMQQNAOQFEU6STF2UKFVLI/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Decorators for class non function properties

[Steven D'Aprano]

On Thu, Aug 06, 2020 at 11:22:38AM +1000, Chris Angelico wrote:
> On Thu, Aug 6, 2020 at 11:11 AM Steven D'Aprano  wrote:
> > [Dominik Vilsmeier]:
> > > > That should be possible by doing `fred = my_property(42)` and defining
> > > > `__set_name__` on the `my_property` class.
> >
> > Just because you define your own dunder method (which you shouldn't do,
> > since dunders are reserved for the interpreter's use) doesn't make
> > something which is a syntax error stop being a syntax error.
> >
> 
> This isn't "defining your own dunder". The syntax as described already
> works inside a class:
> 
> class my_property:
> def __init__(self, n):
> self.n = n
> def __set_name__(self, cls, name):
> print("I'm a property %r on class %s" % (name, cls.__name__))
> 
> class X:
> fred = my_property(42)
> 
> I'm a property 'fred' on class X


*blinks*

When did this happen?

I'm on Python-Ideas, Python-Dev, and I get announcements of new issues 
on the bug tracker, and I don't recall ever seeing this feature 
discussed.

[looks up the docs]

Okay, apparently it was added in 3.6. But the documentation says:


"""
When using the default metaclass type, or any metaclass that ultimately 
calls type.__new__, the following additional customisation steps are 
invoked after creating the class object:

first, type.__new__ collects all of the descriptors in the class 
namespace that define a __set_name__() method;
"""

https://docs.python.org/3/reference/datamodel.html#class-object-creation

but that's not what is happening here, since my_property is not a 
descriptor, it's just an arbitrary instance.

(To be a descriptor, it needs to have `__get__` and/or `__set__` 
methods.)

Have I missed something or does this need a documentation fix?



-- 
Steven
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/SC6LDISDE2JRFLLBMZNSNHH2SO6ILTAM/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Decorators for class non function properties

[Steven D'Aprano]

On Wed, Aug 05, 2020 at 06:15:22PM -0700, Guido van Rossum wrote:
> On Wed, Aug 5, 2020 at 5:55 PM Steven D'Aprano  wrote:

> > That require two different rules for decorators:
> >
> > @decorator over a `class name` or `def name` statement:
> >
> > - execute the statement
> > - bind `name = decorator(name)`
> >
> 
> But that's not what's done. (Proof: if the decorator raises, the name
> remains unbound.)

You are technically correct, which is the best kind of correct.

The documentation uses very close to the same wording as me

https://docs.python.org/3/reference/compound_stmts.html#function-definitions

but does make the point that "except that the original function is not 
temporarily bound to the name func". Since I wasn't writing a reference 
manual, I didn't think this level of pedantry was needed :-)

The bottom line is that the function or class statement has to be 
executed *in some sense* in order to create the function or class 
object, that object has to be passed to the decorator, and finally the 
object returned by the decorator has to be bound to the original name.


-- 
Steven
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/24RHEAJTRYMH7BPMAV5GQ66DQWAV6THG/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Decorators for class non function properties

[Chris Angelico]

On Thu, Aug 6, 2020 at 11:11 AM Steven D'Aprano  wrote:
> [Dominik Vilsmeier]:
> > > That should be possible by doing `fred = my_property(42)` and defining
> > > `__set_name__` on the `my_property` class.
>
> Just because you define your own dunder method (which you shouldn't do,
> since dunders are reserved for the interpreter's use) doesn't make
> something which is a syntax error stop being a syntax error.
>

This isn't "defining your own dunder". The syntax as described already
works inside a class:

class my_property:
def __init__(self, n):
self.n = n
def __set_name__(self, cls, name):
print("I'm a property %r on class %s" % (name, cls.__name__))

class X:
fred = my_property(42)

I'm a property 'fred' on class X


But AIUI this is implemented by type.__new__, so there's no useful way
to extend this to globals and/or locals.

ChrisA
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/RHSUZ5VWV2IHMBPBD7ZKVVVBVH5M7375/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Decorators for class non function properties

[Steven D'Aprano]

On Wed, Aug 05, 2020 at 02:42:34PM -0400, David Mertz wrote:


> Here's something I think could be more useful (again, I'm +0 at best
> myself).
> 
> >>> @unit("meter") a = 3  # a = unit("meter")("a", 3)

Why does the measurement "3 metres" need to know that it is bound to the 
target name "a"?

If you then did:

x = a
y = a + unit('metre')('b', 0)

what would x.name and y.name be?

And when would you need to know that?

If we're talking about associating units to measurements, surely we 
don't need anything more than function call syntax or operators:

# Something like one or more of these
a = unit('metre', 3)
b = metres(3)
g = 9.8 * metres / seconds**2

for declaring units.


-- 
Steven
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/DPNDAN2WVQZUODG2CWE2SIUJULMCUIFD/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Decorators for class non function properties

[Guido van Rossum]

On Wed, Aug 5, 2020 at 5:55 PM Steven D'Aprano  wrote:

> On Wed, Aug 05, 2020 at 10:40:02PM +1200, Greg Ewing wrote:
>
> > A considerable number of moons ago, I suggested that
> >
> > @my_property
> > fred = 42
> >
> > should expand to
> >
> > fred = my_property("fred", 42)
>
>
> That require two different rules for decorators:
>
> @decorator over a `class name` or `def name` statement:
>
> - execute the statement
> - bind `name = decorator(name)`
>

But that's not what's done. (Proof: if the decorator raises, the name
remains unbound.)


> @decorator over a binding `target = expression`:
>
> - bind `target = decorator("target", expression)`
>
> So we're adding significant complexity to the concept of "decorator".
>

(That said, I'm not a fan of decorating assignments. The reason we invented
decorators in the first place doesn't apply here.)

-- 
--Guido van Rossum (python.org/~guido)
*Pronouns: he/him **(why is my pronoun here?)*

___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/L3SCMWIIRDW2P4IPQBEII72MDWR4AGVB/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Decorators for class non function properties

[Steven D'Aprano]

On Wed, Aug 05, 2020 at 03:35:15PM +0200, Marco Sulla wrote:


[Greg Ewing]
> > > A considerable number of moons ago, I suggested that
> > >
> > > @my_property
> > > fred = 42
> > >
> > > should expand to
> > >
> > > fred = my_property("fred", 42)
> > >
> > > The point being to give the descriptor access to the name of
> > > the attribute, without having to repeat yourself.


[Dominik Vilsmeier]:
> > That should be possible by doing `fred = my_property(42)` and defining
> > `__set_name__` on the `my_property` class.

Just because you define your own dunder method (which you shouldn't do, 
since dunders are reserved for the interpreter's use) doesn't make 
something which is a syntax error stop being a syntax error.


[Marco Sulla]
> I suppose that what Greg Ewing suggests is a way to define a sort of
> custom simple statement.
> 
> For example, instead of the old
> print "Hello"
> 
> and the "new"
> print("Hello")
> 
> you could write
> 
> @print
> "Hello"

Perhaps you should re-read Greg's proposal again. I've left it quoted 
above. This is a proposal for decorator syntax, not a new way to call 
objects for their side-effects. If there's no assignment, it isn't going 
to work, it's still going to be a syntax error.

This would work:

@print
word = "Hello"

but it would print "word Hello", and assign None to `word`.

So no, Greg's proposal is nothing like a "custom simple statement", it 
is a proposal for an extension of decorator syntax to simple 
assignments. Your version would be a syntax error, because there is no 
assignment and no target name.


-- 
Steven
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/EAK4CMCRHMM4RTAE5YKRSW6ABLBGM2CI/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Decorators for class non function properties

[Steven D'Aprano]

On Wed, Aug 05, 2020 at 10:40:02PM +1200, Greg Ewing wrote:

> A considerable number of moons ago, I suggested that
> 
> @my_property
> fred = 42
> 
> should expand to
> 
> fred = my_property("fred", 42)


That require two different rules for decorators:

@decorator over a `class name` or `def name` statement:

- execute the statement
- bind `name = decorator(name)`

@decorator over a binding `target = expression`:

- bind `target = decorator("target", expression)`

So we're adding significant complexity to the concept of "decorator".


> The point being to give the descriptor access to the name of
> the attribute, without having to repeat yourself.

There is a conflict here between DRY and Explicit Is Better Than 
Implicit. In the case of function and class decorators, the factor that 
tips it over the edge is not the repeating of the name, but that 
decorator syntax puts critical information about the object up front, 
near the signature, instead of hidden way down the bottom where is can 
be missed:

@property
def thing(self):
# fifty lines of code


makes it obvious that `thing` is a property to even the most lazy and 
careless reader. If the call to property followed the method declaration 
and it's implementation, it would be far away from the signature, 
obscuring the fact that `thing` is not just a method but a property.

There is no such advantage for this suggested decorator syntax:

name = my_property('name', *args, **kw)


is at worst a trivial violation of DRY, and it may not even be that[1], 
but is completely flexible in how many positional and keyword arguments 
it receives. Whereas:

@my_property
name = arg

takes twice as many lines, can only accept a single positional argument, 
loses on the "Explicit versus Implicit" question, and saves at best only 
a trivial and inconsequential DRY violation.

So unlike the function/class case, where the benefit is both two-fold 
and large, the benefit here is only single and tiny, and in my opinion, 
outweighed by the disadvantages.




[1] See discussion here:

http://wiki.c2.com/?DontRepeatYourself

in particular "It's okay to have mechanical, textual duplication". In 
this case, the single source of truth is the target name:

name = my_property("name", arg)

with the duplication being a single word, mechanically copied into the 
same line. A minor annoyance, but not a DRY violation in any meaningful 
sense.


-- 
Steven
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/NPTHWHSHSFLHY47X3FUILHEZIRR2HOJH/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Decorators for class non function properties

[Greg Ewing]

On 6/08/20 1:35 am, Marco Sulla wrote:

I suppose that what Greg Ewing suggests is a way to define a sort of
custom simple statement.

you could write

@print
"Hello"


My suggestion was only for decorating assignments to a bare name,
so that wouldn't have been legal.

But that was long before __set_name__ existed. It wouldn't be
necessary now for the use case I had in mind, and I can't think
of any other reason to want it.

--
Greg
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/KXIJYONZKRRKZUA2FLR2LBSQSDXHU3DC/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Decorators for class non function properties

[André Roberge]

On Wed, Aug 5, 2020 at 3:40 PM Ethan Furman  wrote:

> On 8/5/20 11:11 AM, Jonathan Goble wrote:
>
> > That's literally useless, because after running that there is nothing
> > stopping you from doing:
> >
> >  >>> a = 10
> >
> > or even:
> >
> >  >>> a = "python has no constants"
> >
> > And now a has a value different from 5.
> >
> > There is nothing even remotely resembling const-ness to that class. In
> > order to get const-ness, you would need the ability to overload
> > assignments, like C++ can do. And Python can't do that, and that's
> > probably a good thing.
>
>  --> from aenum import Constant
>
>  --> class K(Constant):
>  ...   a = 5
>  ...   b = 'hello'
>  ...
>
>  --> K.a
>  
>
>  --> K.a == 5
>  True
>
>  --> K.a - 3
>  2
>
>  --> K.a = 9
>  Traceback (most recent call last):
>...
>  AttributeError: cannot rebind constant 
>
>  --> del K.a
>  Traceback (most recent call last):
>...
>  AttributeError: cannot delete constant 
>
> However, one can, of course:
>
>  del K
>
> There is only so much one can do.  ;-)
>
>
Actually, it is possible to do with Python, using an import hook. See
https://aroberge.github.io/ideas/docs/html/constants.html

André Roberge



> --
> ~Ethan~
> ___
> Python-ideas mailing list -- python-ideas@python.org
> To unsubscribe send an email to python-ideas-le...@python.org
> https://mail.python.org/mailman3/lists/python-ideas.python.org/
> Message archived at
> https://mail.python.org/archives/list/python-ideas@python.org/message/VUZKCKX7CARMZI3BNDQRGA7U4HHDXDMP/
> Code of Conduct: http://python.org/psf/codeofconduct/
>
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/SXWTG564JOGUF3USZJFOV5O3654I76UC/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Decorators for class non function properties

[David Mertz]

On Wed, Aug 5, 2020 at 2:25 PM Jonathan Fine  wrote:

> Real world examples where it would be useful are generally worth much more
> than invented examples.
>

I agree that @const is not really a useful "value decorator." I was just
picking up the example that occurred up-thread.

Here's something I think could be more useful (again, I'm +0 at best
myself).

>>> @unit("meter") a = 3  # a = unit("meter")("a", 3)
>>> @unit("foot") b = 4   # b = unit("foot")("b", 4)
>>> a, a.name, a.unit
(3, "a", "meter")

Implementation left to reader, but basically it's exactly Ricky's
__new__(), just wrapped in a class factory function to parameterize the
unit.



-- 
The dead increasingly dominate and strangle both the living and the
not-yet born.  Vampiric capital and undead corporate persons abuse
the lives and control the thoughts of homo faber. Ideas, once born,
become abortifacients against new conceptions.
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/JV7SYYTRYMODU4KKKFLXEI473SHK6RMA/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Decorators for class non function properties

[Ethan Furman]

On 8/5/20 11:11 AM, Jonathan Goble wrote:

That's literally useless, because after running that there is nothing 
stopping you from doing:


 >>> a = 10

or even:

 >>> a = "python has no constants"

And now a has a value different from 5.

There is nothing even remotely resembling const-ness to that class. In 
order to get const-ness, you would need the ability to overload 
assignments, like C++ can do. And Python can't do that, and that's 
probably a good thing.


--> from aenum import Constant

--> class K(Constant):
...   a = 5
...   b = 'hello'
...

--> K.a


--> K.a == 5
True

--> K.a - 3
2

--> K.a = 9
Traceback (most recent call last):
  ...
AttributeError: cannot rebind constant 

--> del K.a
Traceback (most recent call last):
  ...
AttributeError: cannot delete constant 

However, one can, of course:

del K

There is only so much one can do.  ;-)

--
~Ethan~
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/VUZKCKX7CARMZI3BNDQRGA7U4HHDXDMP/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Decorators for class non function properties

[nate lust]

All,
" And Python can't do that, and that's probably a good thing."

Johnathan, you are right, I emailed this list a year or so ago with a way
to overload assignment and lookup (i.e. what happens when you >>> a) and it
was discussed for a while, but ultimately there were reasons (that I
largely agree with) why that would be problematic in python. The title was
 "A proposal (and implementation) to add assignment and LOAD overloading"
for anyone wanting to read the reasoning.

On Wed, Aug 5, 2020 at 2:13 PM Jonathan Goble  wrote:

> On Wed, Aug 5, 2020 at 2:03 PM Ricky Teachey  wrote:
>
>>
>> And btw this works:
>>
>> >>> class const(int):
>> ... def __new__(cls, name, val):
>> ... obj = super().__new__(cls, val)
>> ... obj.name = name
>> ... return obj
>> ... def about(self):
>> ... print(self.name, '=', self)
>> ...
>> >>> a = const('a', 5)
>> >>> a
>> 5
>> >>> a.about()
>> a = 5
>>
>
> That's literally useless, because after running that there is nothing
> stopping you from doing:
>
> >>> a = 10
>
> or even:
>
> >>> a = "python has no constants"
>
> And now a has a value different from 5.
>
> There is nothing even remotely resembling const-ness to that class. In
> order to get const-ness, you would need the ability to overload
> assignments, like C++ can do. And Python can't do that, and that's probably
> a good thing.
> ___
> Python-ideas mailing list -- python-ideas@python.org
> To unsubscribe send an email to python-ideas-le...@python.org
> https://mail.python.org/mailman3/lists/python-ideas.python.org/
> Message archived at
> https://mail.python.org/archives/list/python-ideas@python.org/message/TCW3TAPS6WTHGENNL2G2M5DTCKQWRJE6/
> Code of Conduct: http://python.org/psf/codeofconduct/
>


-- 
Nate Lust, PhD.
Astrophysics Dept.
Princeton University
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/PGQUKE4HF3IE4DGYVF7PQGTDTGXFNLWP/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Decorators for class non function properties

[Jonathan Fine]

If you really want something like this, you can today write:

>>> def wibble(fn):
... return ', '.join(fn())

>>> @wibble
... def ():
... return 'APPLES'

>>> 
'A, P, P, L, E, S'

This allows you to use a decorator, if that's really what you want to do.

The original post asked for
@wibble
 fruit
to be equivalent to
 fruit = wibble(fruit)

If there are sufficient examples where this is useful, I say go for it. But
only after first trying to get my fruit in some other way.

Real world examples where it would be useful are generally worth much more
than invented examples.

I hope this helps, even if it disappoints.
-- 
Jonathan
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/UVEKJDEN26PGAO7USZJH6NXTCO6XIESQ/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Decorators for class non function properties

[Jonathan Goble]

On Wed, Aug 5, 2020 at 2:03 PM Ricky Teachey  wrote:

>
> And btw this works:
>
> >>> class const(int):
> ... def __new__(cls, name, val):
> ... obj = super().__new__(cls, val)
> ... obj.name = name
> ... return obj
> ... def about(self):
> ... print(self.name, '=', self)
> ...
> >>> a = const('a', 5)
> >>> a
> 5
> >>> a.about()
> a = 5
>

That's literally useless, because after running that there is nothing
stopping you from doing:

>>> a = 10

or even:

>>> a = "python has no constants"

And now a has a value different from 5.

There is nothing even remotely resembling const-ness to that class. In
order to get const-ness, you would need the ability to overload
assignments, like C++ can do. And Python can't do that, and that's probably
a good thing.
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/TCW3TAPS6WTHGENNL2G2M5DTCKQWRJE6/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Decorators for class non function properties

[Ethan Furman]

On 8/5/20 10:54 AM, David Mertz wrote:

I'm not advocating it, and I'm not the one that came up with it. But my 
impression is that it is intended to mean:


a = const('a', 5)

This doesn't seem completely pointless:


class const():

...     def __init__(self, name, val):
... self.name = name
...         self.val = val
...     def about(self):
...         print(self.name, '=', self.val)
...

a = const('a', 5)
a.val

5

a.about()

a = 5

There might be a way to subclass, e.g. int, so that you don't need to 
use `a.val` to get the value.  It wasn't obvious to me how to do it in 
pure Python with 3 minutes thought.


--> from aenum import Constant

--> class K(Constant):
...   a = 5
...

--> K.a


--> K.a == 5
True

--> K.a - 3
2

--
~Ethan~
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/DHVOCMK4OFX7KPX5J2ACJJXPI3UEVEBO/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Decorators for class non function properties

[Ricky Teachey]

On Wed, Aug 5, 2020 at 1:54 PM David Mertz  wrote:

> On Wed, Aug 5, 2020 at 1:27 PM Ricky Teachey  wrote:
>
>> On Wed, Aug 5, 2020 at 11:41 AM Marco Sulla 
>> wrote:
>>
>>> On Wed, 5 Aug 2020 at 15:53, Ricky Teachey  wrote:
>>> from mypython import *
>>> @const a = 5
>>>
>>
>>  I'm probably dim but I have no idea what that is supposed to mean or do.
>> Is this just calling const(a=5)...? what is the point of that?
>>
>
> I'm not advocating it, and I'm not the one that came up with it. But my
> impression is that it is intended to mean:
>
> a = const('a', 5)
>
> This doesn't seem completely pointless:
>
> >>> class const():
> ... def __init__(self, name, val):
> ... self.name = name
> ... self.val = val
> ... def about(self):
> ... print(self.name, '=', self.val)
> ...
> >>> a = const('a', 5)
> >>> a.val
> 5
> >>> a.about()
> a = 5
>
> There might be a way to subclass, e.g. int, so that you don't need to use
> `a.val` to get the value.  It wasn't obvious to me how to do it in pure
> Python with 3 minutes thought.
>

Ah, I get it.

And btw this works:

>>> class const(int):
... def __new__(cls, name, val):
... obj = super().__new__(cls, val)
... obj.name = name
... return obj
... def about(self):
... print(self.name, '=', self)
...
>>> a = const('a', 5)
>>> a
5
>>> a.about()
a = 5

---
Ricky.

"I've never met a Kentucky man who wasn't either thinking about going home
or actually going home." - Happy Chandler
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/IDIBWXT2OCCLJUGLEQZEAX6SAZLF2SF2/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Decorators for class non function properties

[David Mertz]

On Wed, Aug 5, 2020 at 1:27 PM Ricky Teachey  wrote:

> On Wed, Aug 5, 2020 at 11:41 AM Marco Sulla 
> wrote:
>
>> On Wed, 5 Aug 2020 at 15:53, Ricky Teachey  wrote:
>> from mypython import *
>> @const a = 5
>>
>
>  I'm probably dim but I have no idea what that is supposed to mean or do.
> Is this just calling const(a=5)...? what is the point of that?
>

I'm not advocating it, and I'm not the one that came up with it. But my
impression is that it is intended to mean:

a = const('a', 5)

This doesn't seem completely pointless:

>>> class const():
... def __init__(self, name, val):
... self.name = name
... self.val = val
... def about(self):
... print(self.name, '=', self.val)
...
>>> a = const('a', 5)
>>> a.val
5
>>> a.about()
a = 5

There might be a way to subclass, e.g. int, so that you don't need to use
`a.val` to get the value.  It wasn't obvious to me how to do it in pure
Python with 3 minutes thought.


-- 
The dead increasingly dominate and strangle both the living and the
not-yet born.  Vampiric capital and undead corporate persons abuse
the lives and control the thoughts of homo faber. Ideas, once born,
become abortifacients against new conceptions.
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/X3ECJ4ZURNWANTMDFAXNL7PLTTXIKYOZ/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Decorators for class non function properties

[Ricky Teachey]

On Wed, Aug 5, 2020 at 11:41 AM Marco Sulla 
wrote:

> On Wed, 5 Aug 2020 at 15:53, Ricky Teachey  wrote:
> > How about this?
> >
> > @print(sep="\n")
> > 1, 2, 3
>
> If you consider @print as a function decorator, it's quite a problem.
> But I was thinking mainly about a sort of "decorator" for the parser
> and/or the AST compiler.
> This could allow you to have, for example:
>
> from mypython import *
> @const a = 5
>
> with a C extension.
> More than an idea is a question, since I've no knowledge about AST and
> code parsers.
>

 I'm probably dim but I have no idea what that is supposed to mean or do.
Is this just calling const(a=5)...? what is the point of that?
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/V5O3KW2A4VKTVK7KJBEEQ7JTLN2FNDV2/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Decorators for class non function properties

[Marco Sulla]

On Wed, 5 Aug 2020 at 15:53, Ricky Teachey  wrote:
> How about this?
>
> @print(sep="\n")
> 1, 2, 3

If you consider @print as a function decorator, it's quite a problem.
But I was thinking mainly about a sort of "decorator" for the parser
and/or the AST compiler.
This could allow you to have, for example:

from mypython import *
@const a = 5

with a C extension.
More than an idea is a question, since I've no knowledge about AST and
code parsers.
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/GVB3GZOY3VYLOFXJ2WSPA5AUTJSQUYII/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Decorators for class non function properties

[Ricky Teachey]

On Wed, Aug 5, 2020 at 9:38 AM Marco Sulla 
wrote:

> On Wed, 5 Aug 2020 at 13:29, Dominik Vilsmeier 
> wrote:
> >
> > On 05.08.20 12:40, Greg Ewing wrote:
> > > A considerable number of moons ago, I suggested that
> > >
> > > @my_property
> > > fred = 42
> > >
> > > should expand to
> > >
> > > fred = my_property("fred", 42)
> > >
> > > The point being to give the descriptor access to the name of
> > > the attribute, without having to repeat yourself.
> > >
> > That should be possible by doing `fred = my_property(42)` and defining
> > `__set_name__` on the `my_property` class.
>
> I suppose that what Greg Ewing suggests is a way to define a sort of
> custom simple statement.
>
> For example, instead of the old
> print "Hello"
>
> and the "new"
> print("Hello")
>
> you could write
>
> @print
> "Hello"
>

What would this print?

@print
1, 2, 3

Would we also want to do this?

@print()
1, 2, 3

How about this?

@print(sep="\n")
1, 2, 3

---
Ricky.

"I've never met a Kentucky man who wasn't either thinking about going home
or actually going home." - Happy Chandler
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/ZGOSVCCIFEPXJA75K453BHEW5WEG3WF6/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Decorators for class non function properties

[Marco Sulla]

On Wed, 5 Aug 2020 at 13:29, Dominik Vilsmeier  wrote:
>
> On 05.08.20 12:40, Greg Ewing wrote:
> > A considerable number of moons ago, I suggested that
> >
> > @my_property
> > fred = 42
> >
> > should expand to
> >
> > fred = my_property("fred", 42)
> >
> > The point being to give the descriptor access to the name of
> > the attribute, without having to repeat yourself.
> >
> That should be possible by doing `fred = my_property(42)` and defining
> `__set_name__` on the `my_property` class.

I suppose that what Greg Ewing suggests is a way to define a sort of
custom simple statement.

For example, instead of the old
print "Hello"

and the "new"
print("Hello")

you could write

@print
"Hello"
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/4H2JPEDJBAJD7CUPITAI7GECJ5XMUN6X/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Decorators for class non function properties

[Dominik Vilsmeier]

On 05.08.20 12:40, Greg Ewing wrote:


On 5/08/20 9:13 pm, Serhiy Storchaka wrote:

the code can be written as

 class Neuron:
 activation = linear_activation(activation)

I do not see reasons to introduce special syntax for this very specific
code.


A considerable number of moons ago, I suggested that

    @my_property
    fred = 42

should expand to

    fred = my_property("fred", 42)

The point being to give the descriptor access to the name of
the attribute, without having to repeat yourself.


That should be possible by doing `fred = my_property(42)` and defining
`__set_name__` on the `my_property` class.

https://docs.python.org/3/reference/datamodel.html#object.__set_name__
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/COHDEI24E5BRUHTRXU5DH3UJXMWYPKZJ/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Decorators for class non function properties

[Greg Ewing]

On 5/08/20 9:13 pm, Serhiy Storchaka wrote:

the code can be written as

 class Neuron:
 activation = linear_activation(activation)

I do not see reasons to introduce special syntax for this very specific
code.


A considerable number of moons ago, I suggested that

@my_property
fred = 42

should expand to

fred = my_property("fred", 42)

The point being to give the descriptor access to the name of
the attribute, without having to repeat yourself.

--
Greg
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/QUKYFIWYJY42ZMNJM4EXOUWBMKK42VXH/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Decorators for class non function properties

[redradist]

But I can do the same thing with class methods ... but anyway it was introduced 
method decorators to simplify development and add extra power ...
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/W54PL2MHR45B7UXC726VZUA22GGH263W/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Decorators for class non function properties

[Chris Angelico]

On Wed, Aug 5, 2020 at 8:01 PM  wrote:
>
> It could work if we extend syntax like this:
> ```python
> class Neuron:
> activation # By default creates activation with None value\

Why not just "activation = None"?

> activation = linear_activation(activation)
> ```
> and then we could apply as may decorators as needed:
> ```python
> class Neuron:
> activation # By default creates activation with None value
> activation = linear_activation(activation)
> activation = softmax_activation(weights=["w0", 
> "w1"])(linear_activation(activation))
> ```

You can already do this.

ChrisA
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/GPHRQPC53OCTUQ4LDPXSW6NMVCRCNTAE/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Decorators for class non function properties

[redradist]

It could work if we extend syntax like this:
```python
class Neuron:
activation # By default creates activation with None value
activation = linear_activation(activation)
```
and then we could apply as may decorators as needed:
```python
class Neuron:
activation # By default creates activation with None value
activation = linear_activation(activation)
activation = softmax_activation(weights=["w0", 
"w1"])(linear_activation(activation))
```
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/I7LHY3X3MV4U36VHKHK3B3L2QNHWG42T/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Decorators for class non function properties

[Serhiy Storchaka]

05.08.20 10:36, redrad...@gmail.com пише:
> Decorator will do the same thing as general decorator

So the code

class Neuron:
@linear_activation
activation

would be equivalent to the following code?

class Neuron:
activation
activation = linear_activation(activation)

This code does not work unless you define global name "activation", and
if define it, the code can be written as

class Neuron:
activation = linear_activation(activation)

I do not see reasons to introduce special syntax for this very specific
code.
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/XALTCALO7DMMRGUSNLY5X2DY2BEL22ZM/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Decorators for class non function properties

[redradist]

Also there is maybe some addition parameter like self:

```python
class Neuron:
@instance_property
activation

def __init__(self):
# automatically created
pass
...

def instance_property(name, property, self, *args):
# Create property on instance
```
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/LAQOOARQKIBAO2EVH6SC36S6X3JWNNKW/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Decorators for class non function properties

[redradist]

Decorator will do the same thing as general decorator

For example it could be implemented like this:
```python
class linear_activation:
def __init(self, name, property):
...

def linear_activation(name, property):
...
```
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/WXXNZHRVYRBRZBGFWLLIM7IQ3FSQORYF/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Decorators for class non function properties

[redradist]

Disagree, because for example what if I want custom property with two or three 
decorators ?

Like this:
```python
class Neuron:
@softmax_activation(weights=["w0", "w1"])
@linear_activation
activation

def __init__(self):
self.w0 = [...]
self.w1 = [...]
...
```
or for example I just want to apply to my initializer some decorator:
 ```python
class Neuron:
@softmax_activation(weights=["w0", "w1"])
activation = LinearActivation(...)

def __init__(self):
self.w0 = [...]
self.w1 = [...]
...
```

There exist use-cases for this feature ...
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/RQPQSHPTRYVZHPYAR4WR4HEFTQE7LUL7/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Decorators for class non function properties

[Joao S. O. Bueno]

When one needs a custom property, the easy, readable, and that already
works way to create then
is just to create an instance of the their class and assign the instance to
the desired
class attribute. All the class have to do is to have the methods that
identify it as a descriptor: "__get__" and "__set__" for
data descriptors , and optionally "__del__".

The class can be made in a way to make it easier to write the setters and
getter , and have
their "__set__" and "__get__" call these other methods, but that is about
it.
```
class ThresholdProperty:

def __init__(self, threshold=0.5):
 self.threshold = threshold
def __set_name__(self, owner, name):
 self.name = name
def __set__(self, instance, value):
  self.instance.setattr("_" + self.name, value)
def __get__(self, instance, owner):
 if instance is None: return self
 return int(getattr(instance, "_" + self.name) > self.threshold)

class Neuron:
   activation = ThresholdProperty()

```

On Tue, 4 Aug 2020 at 05:16, Chris Angelico  wrote:

> On Tue, Aug 4, 2020 at 6:09 PM  wrote:
> >
> > Hi all,
> >
> > Seems like this topic was previously raised, but what if we add
> possibility to decorate non function properties in class:
> >
> > ```python
> > class Neuron:
> > @linear_activation
> > activation
> > ```
>
> What would that decoration do, exactly?
>
> ChrisA
> ___
> Python-ideas mailing list -- python-ideas@python.org
> To unsubscribe send an email to python-ideas-le...@python.org
> https://mail.python.org/mailman3/lists/python-ideas.python.org/
> Message archived at
> https://mail.python.org/archives/list/python-ideas@python.org/message/V3HHI4FZZBRBX6FB6246342HYDDFDXJT/
> Code of Conduct: http://python.org/psf/codeofconduct/
>
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/75TFH5I6QHGPAW5DJA5WWJ2RKNUB4GA7/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Decorators for class non function properties

[Chris Angelico]

On Tue, Aug 4, 2020 at 6:09 PM  wrote:
>
> Hi all,
>
> Seems like this topic was previously raised, but what if we add possibility 
> to decorate non function properties in class:
>
> ```python
> class Neuron:
> @linear_activation
> activation
> ```

What would that decoration do, exactly?

ChrisA
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/V3HHI4FZZBRBX6FB6246342HYDDFDXJT/
Code of Conduct: http://python.org/psf/codeofconduct/