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

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 = uni

[Python-ideas] Re: Improve handling of Unicode quotes and hyphens

I'm all for clear and helpful error messages, but this feels a tad too verbose (and even a bit patronizing) to me. But the highlighting of character look-alikes is very helpful. Perhaps something like: """ SyntaxError: invalid character in identifier -->2: print(“Squares:”)

[Python-ideas] New monotonic clock that tracks across system suspend

Rishav Kundu via Python-ideas writes: > Consider the monotonic clock defined in pytime.c. Whether or not it > tracks time across system suspend is implementation-defined (and > not documented either). PEP 418 [1] has details along with the raw > system APIs used. > > We could introduce two

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

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 acco

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

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`

[Python-ideas] Custom keywords (from: Decorators for class non function properties)

On Wed, 5 Aug 2020 at 20:10, Ethan Furman wrote: > --> from aenum import Constant > > --> class K(Constant): > ... a = 5 > ... This is exactly what I intended. Think if you're able to do: from aenum import const @const a = 5 Notice that I'm using the "at" char because I

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

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 y

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

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 = decorat

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

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 ar

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

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

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

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

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

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

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

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`

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

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 __s

[Python-ideas] Re: Improve handling of Unicode quotes and hyphens

Like it! Sent from Samsung Mobile on O2 Get Outlook for Android From: André Roberge Sent: Wednesday, August 5, 2020 7:54:06 PM To: Steve Barnes Cc: python-ideas@python.org Subject: Re: [Python-ideas] Re: Improve handling of Unicode quotes

[Python-ideas] Re: Package kwkey and PEP 472 -- Support for indexing with keyword arguments

On Wed, Aug 5, 2020 at 3:01 PM Stefano Borini wrote: > Maybe I should open a new PEP? > I"ll let teh PEP editors decide, but it look slike it was "rejected"m with this comment: "The idea never seemed to gain any traction over its near 5 years in existence as a PEP." So I'd think re-opening it

[Python-ideas] Re: Package kwkey and PEP 472 -- Support for indexing with keyword arguments

I am following, but very swamped with work so I am kind of to the side for a few more days. I am thinking about looking for a sponsor for the PEP, but at this point it's better if I rework the current analysis in light of what you made and the current discussion. Maybe I should open a new PEP? On

[Python-ideas] Re: Improve handling of Unicode quotes and hyphens

Reviving (briefly an old thread) On Mon, May 11, 2020 at 2:13 AM Steve Barnes wrote: > My personal experience of the most common problematic substitutions by > tools such as Outlook, Word & some web tools: > >1. Double Quotes \u201c & \u201d “” >2. Single Quotes \u2018 & \u2019 ‘’ >3

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

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

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

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

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

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 t

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

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 agr

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

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.

[Python-ideas] Re: Introduce a boundary parameter for typing.get_type_hints when used with a class object

On Wed, Aug 5, 2020 at 12:25 AM Dominik Vilsmeier wrote: > On 04.08.20 22:05, Guido van Rossum wrote: > > Maybe get-type-hints can be refactored to make writing such a function > simpler. IIRC the part that takes a single annotation and evaluates it is a > private function. > > That's what I cons

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

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.nam

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

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 ...

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

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 bu

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

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

[Python-ideas] Re: Idea: Extend "for ... else ..." to allow "for ... if break ..." else

On 05/08/2020 15:29, Mathew Elman wrote: Being able to break multiple loops and having "labelled" breaks would be achievable using `except`, i.e. adding `except` to the loop statements before `else` like this: for elem in iterable:     ...     if should_break(elem):     rai

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

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 th

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

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

[Python-ideas] Re: Changing item dunder method signatures to utilize positional arguments (open thread)

On Wed, Aug 5, 2020, 10:38 <2qdxy4rzwzuui...@potatochowder.com> wrote: > On 2020-08-04 at 10:58:51 -0400, > Todd wrote: > > > My main issue with this is that, in my opinion, dunders are not > > something a beginner should be messing with anyway. By the time > > someone is experienced enough to s

[Python-ideas] Re: Changing item dunder method signatures to utilize positional arguments (open thread)

On Wed, Aug 5, 2020, 09:47 Ricky Teachey wrote: > Hi Todd thanks for your response. > > On Tue, Aug 4, 2020 at 11:01 AM Todd wrote: > >> On Tue, Aug 4, 2020 at 8:17 AM Ricky Teachey wrote: >> >>> ... >>> >>> There could be several reasons for changing the item dunder signatures. >>> The immedia

[Python-ideas] Re: Changing item dunder method signatures to utilize positional arguments (open thread)

On 2020-08-04 at 10:58:51 -0400, Todd wrote: > My main issue with this is that, in my opinion, dunders are not > something a beginner should be messing with anyway. By the time > someone is experienced enough to start working on this, they are also > experienced enough to understand that special

[Python-ideas] Re: Idea: Extend "for ... else ..." to allow "for ... if break ..." else

Being able to break multiple loops and having "labelled" breaks would be achievable using `except`, i.e. adding `except` to the loop statements before `else` like this: for elem in iterable: > ... > if should_break(elem): > raise SomeException > except SomeException as e: > han

[Python-ideas] Re: Package kwkey and PEP 472 -- Support for indexing with keyword arguments

On Mon, Aug 3, 2020 at 1:58 PM Jonathan Fine wrote: > The decorator key_to_jfine comes from the kwkey.jfine submodule. It > implements the API that I favour. This is my first contribution to the > exploration of the API. > > I guess the thing I don't understand is why you favor that API. Could y

[Python-ideas] New monotonic clock that tracks across system suspend

Consider the monotonic clock defined in pytime.c. Whether or not it tracks time across system suspend is implementation-defined (and not documented either). PEP 418 [1] has details along with the raw system APIs used. We could introduce two new monotonic clocks that distinguish between whether

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

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 > > >

[Python-ideas] Re: Changing item dunder method signatures to utilize positional arguments (open thread)

Hi Todd thanks for your response. On Tue, Aug 4, 2020 at 11:01 AM Todd wrote: > On Tue, Aug 4, 2020 at 8:17 AM Ricky Teachey wrote: > >> ... >> >> There could be several reasons for changing the item dunder signatures. >> The immediate reason is making the intuition around how to add kwd arg >>

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

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

[Python-ideas] Re: Idea: Extend "for ... else ..." to allow "for ... if break ..." else

I note that both of these examples could be handled by having a way to break out of 2 loops at a time. Rob On 29/07/2020 12:33, Jonathan Fine wrote: Thank you all, particularly Guido, for your contributions. Having some examples will help support the exploration of this idea. Here's a baby ex

[Python-ideas] Re: Idea: Extend "for ... else ..." to allow "for ... if break ..." else

On 29/07/2020 14:51, Ethan Furman wrote: On 7/28/20 10:30 PM, Rob Cliffe via Python-ideas wrote: A possible, unrelated, future language extension is to allow breaking out of more than one loop at a time. I would think that     break would handle that situation. -- ~Ethan~ Maybe.  But no

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

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

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

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

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

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-ideas] Re: Decorators for class non function properties

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

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

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 act

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

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(ac

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

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] Re: Decorators for class non function properties

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-i

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

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 = [...] ... ``` o

[Python-ideas] Re: Introduce a boundary parameter for typing.get_type_hints when used with a class object

On 04.08.20 22:05, Guido van Rossum wrote: Maybe get-type-hints can be refactored to make writing such a function simpler. IIRC the part that takes a single annotation and evaluates it is a private function. That's what I considered and indeed it relies on `typing._eval_type`. If this was publ