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

[Stephen J. Turnbull]

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 new monotonic clocks that distinguish
 > between whether they track across system suspend or not. These
 > clocks exist on at least Windows, macOS, and Linux.

Which clocks exist on all three platforms: tracking, non-tracking,
both?

What are some use cases for tracking that can't be done with a
non-tracking clock?  What are some use cases for non-tracking clocks
that can't be done with a tracking clock?  The point is, "do we really
need both, or can we just add the useful one for those who need it
when it exists?"  Why can't this be done in a separate extension
module on PyPI, distributed as wheels for platforms that support it,
for users who need it?[1]  If it is likely that non-core developers
would create buggy implementations so it's worth having a "canonical"
in-stdlib implementation, explain why (to the extent that it makes
that claim plausible; you can't "prove" something like this and nobody
expects you to, it's always a judgment call by the reviewers).

 > P.S.: This is my first time submitting to the Python mailing
 > lists. Suggestions for improvement are appreciated :)

See questions above. :-)  Nothing stops people from adding the facility
as an extension module or a forked stdlib.  So you need to explain why
this needs to be in *every* Python, imposing additional development,
documentation, and maintenance burden on an overstretched core
developer community.  Slight though such burden may be, it needs to be
justified by a fairly large "multiplier" of convenience to the
community of developers-using-Python -- the developers-of-Python have
plenty of alternative tasks that have "large" multipliers.


Footnotes: 
[1]  Typically this would be answered either "a large fraction of
users need it" for values of "large" > 1% ;-), or "there are
industrial use cases where it is extremely difficult to get an
extension module through enterprise vetting processes".
___
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/S62HNA5W3TN6ROATFSFLDE4DBV7QM2XB/
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] Custom keywords (from: Decorators for class non function properties)

[Marco Sulla]

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 can't find a better character.

I give the rest to your imagination:


# previous declarations of x in the same scope are a SyntaxError
@var x = None

# simulate electrical circuit
c = a @nand b

# Java style
@final class A:
@protected _x = 0

# ...maybe someday
@int a = 1
___
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/KRJSKUZQF5JWK7QA2TNLFQTONUS6FC5R/
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: Package kwkey and PEP 472 -- Support for indexing with keyword arguments

[Christopher Barker]

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 would be fine -- rather than clutter up the PEP
namespace...

Maybe we could use a "suspended" status for PEPs?

-CHB



On Tue, 4 Aug 2020 at 14:26, Jonathan Fine  wrote:
> >
> > Thank you all for your posts. I'm busy now and for the next few days, so
> have little time to respond. Here's some comments and suggestions.
> >
> > I hope that Andras, Caleb, Stefano, Neil, Joao Bueno, Todd and Stephan
> will take a special interest in this post. In the previous thread, these
> people saw that the proposed new syntax
> > d[1, 2, a=3, b=4]
> > would bring benefits to their own particular use of Python. (Apologies
> for any omitted names or misunderstanding of posts).
> >
> > I hope the package kwkey shows that it is possible now to write
> > from kwkey import o
> > d[o(1, 2, a=3, b=4)]
> > as a workable present day substitute for the proposed syntax
> > d[1, 2, a=3, b=4]
> >
> > I think using this can safely go ahead, even though there may be
> disagreements on the meaning of 'o' and the implementation of classes that
> take advantage of the new syntax. Indeed, I think going ahead now will
> contribute to understanding and resolving the disagreements, by creating a
> shared experience.
> >
> > I suggest that those who previously suggested uses for the proposed
> syntax now implement some examples. (I give a list below.) They can do this
> using my API, Steven's API, or any other API. Or indeed now, using the
> return value of 'o' directly.
> >
> > I've started this process with a toy example:
> >
> https://github.com/jfine2358/python-kwkey/blob/master/kwkey/example_jfine.py
> >
> > Here are three aspects to the proposed syntax. They are all important,
> and good design will balance between the various parts and interests.
> >
> > First, ordinary programmers, who perhaps want
> > d[1, 2]
> > d[x=1, y=2]
> > d[1, y=2]
> > d[y=2, x=1]
> > to all be equivalent, for d a mapping of whose domain is points in the
> x-y plane. More complicated examples might be found in function annotations
> (Andras Tantos, Caleb Donovick), quantum chemistry (Stefano Borini),
> networkx (Neil Girdhar), numpy and pandas (Joao Bueno), xarrary (Todd,
> Stephan Hoyer).
> >
> > Second, there are those who implement classes that make use of the
> proposed syntax.
> >
> > Third, there are those who implement the extension of Python that allows
> > d[o(1, 2, a=3, b=4)]
> > to be replaced by
> > d[1, 2, 3, 4]
> >
> > I suggest that those who see benefits in feature produce experimental
> implementations via kwkey, just as I did in my kwkey.example_jfine. It is
> possible to do this now, and so have benefits now, in a way that is
> reasonably future proof regarding implementation of the proposed new syntax.
> >
> > If you're a user of kwkey, I will have some time available to help you
> if you want it.
> >
> > I hope this helps some, and harms none.
> > --
> > Jonathan
> >
> >
>
>
> --
> Kind regards,
>
> Stefano Borini
> ___
> 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/QK3YV3BUTF4VCPKNNMHFDWVJDQIJMZ3A/
> Code of Conduct: http://python.org/psf/codeofconduct/
>


-- 
Christopher Barker, PhD

Python Language Consulting
  - Teaching
  - Scientific Software Development
  - Desktop GUI and Web Development
  - wxPython, numpy, scipy, Cython
___
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/SGVLGOOWXN6NSDKCWOWGNO43T2EZHIX5/
Code of Conduct: http://python.org/psf/codeofconduct/

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

[Stefano Borini]

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 Tue, 4 Aug 2020 at 14:26, Jonathan Fine  wrote:
>
> Thank you all for your posts. I'm busy now and for the next few days, so have 
> little time to respond. Here's some comments and suggestions.
>
> I hope that Andras, Caleb, Stefano, Neil, Joao Bueno, Todd and Stephan will 
> take a special interest in this post. In the previous thread, these people 
> saw that the proposed new syntax
> d[1, 2, a=3, b=4]
> would bring benefits to their own particular use of Python. (Apologies for 
> any omitted names or misunderstanding of posts).
>
> I hope the package kwkey shows that it is possible now to write
> from kwkey import o
> d[o(1, 2, a=3, b=4)]
> as a workable present day substitute for the proposed syntax
> d[1, 2, a=3, b=4]
>
> I think using this can safely go ahead, even though there may be 
> disagreements on the meaning of 'o' and the implementation of classes that 
> take advantage of the new syntax. Indeed, I think going ahead now will 
> contribute to understanding and resolving the disagreements, by creating a 
> shared experience.
>
> I suggest that those who previously suggested uses for the proposed syntax 
> now implement some examples. (I give a list below.) They can do this using my 
> API, Steven's API, or any other API. Or indeed now, using the return value of 
> 'o' directly.
>
> I've started this process with a toy example:
> https://github.com/jfine2358/python-kwkey/blob/master/kwkey/example_jfine.py
>
> Here are three aspects to the proposed syntax. They are all important, and 
> good design will balance between the various parts and interests.
>
> First, ordinary programmers, who perhaps want
> d[1, 2]
> d[x=1, y=2]
> d[1, y=2]
> d[y=2, x=1]
> to all be equivalent, for d a mapping of whose domain is points in the x-y 
> plane. More complicated examples might be found in function annotations 
> (Andras Tantos, Caleb Donovick), quantum chemistry (Stefano Borini), networkx 
> (Neil Girdhar), numpy and pandas (Joao Bueno), xarrary (Todd, Stephan Hoyer).
>
> Second, there are those who implement classes that make use of the proposed 
> syntax.
>
> Third, there are those who implement the extension of Python that allows
> d[o(1, 2, a=3, b=4)]
> to be replaced by
> d[1, 2, 3, 4]
>
> I suggest that those who see benefits in feature produce experimental 
> implementations via kwkey, just as I did in my kwkey.example_jfine. It is 
> possible to do this now, and so have benefits now, in a way that is 
> reasonably future proof regarding implementation of the proposed new syntax.
>
> If you're a user of kwkey, I will have some time available to help you if you 
> want it.
>
> I hope this helps some, and harms none.
> --
> Jonathan
>
>


-- 
Kind regards,

Stefano Borini
___
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/QK3YV3BUTF4VCPKNNMHFDWVJDQIJMZ3A/
Code of Conduct: http://python.org/psf/codeofconduct/

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

[André Roberge]

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. The m-hyphen \2013 –
>4. Copyright © \xa9 and others, Registered ® \xae and trademark ™
>\u2122
>5. Some fractions e.g.  ½ ¼
>6. Non-breaking spaces
>
>
>
SNIP

As part of this discussion, it was suggested that it would be useful if
some more useful messages could be given about the use of some unicode
"fancy quotes". Just in case some people were considering "wasting" time on
this:
= = = =
 $ python -m friendly_traceback scratch.py

Python exception:
SyntaxError: invalid character in identifier

A SyntaxError occurs when Python cannot understand your code.

Python could not understand the code in the file
'scratch.py'
beyond the location indicated below by --> and ^.

   1: def squares(n):
-->2:   print(“Squares:”)
 ^

Likely cause based on the information given by Python:
Did you use copy-paste?
Python indicates that you used some unicode characters not allowed
as part of a variable name; this includes many emojis.
However, I suspect that you used a fancy unicode quotation mark
instead of a normal single or double quote for a string.

= = =
This is just one of many cases now correctly identified by
friendly-traceback.

André Roberge
___
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/Y52MHLTKYRSI36JFGLPFCJR5XC3XELWW/
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: Introduce a boundary parameter for typing.get_type_hints when used with a class object

[Guido van Rossum]

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 considered and indeed it relies on `typing._eval_type`. If
> this was public then all building blocks would be in place.
>
In that case I recommend that you create a bpo issue about adding it and
submit a PR to resolve the issue. I think the public API should have the
same defaults for globalns and localns as get_type_hints(), and it should
probably not expose the recursive_guard argument. Since this is a new
feature and the 3.9 release is already closed for new features, this can be
added in 3.10 -- in earlier releases you'll have to use `_eval_type`. (It
does not seem important enough to add it to the typing_extensions module.)

-- 
--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/75QG32L3QGRO44SKBAC6W557HHSZEXO5/
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: Idea: Extend "for ... else ..." to allow "for ... if break ..." else

[Rob Cliffe via Python-ideas]

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):
    raise SomeException
except SomeException as e:
    handle_break_behaviour(e)
else:
    print("Did not break")


would be sugar for:

try:
    for elem in iterable:
    ...
    if should_break(elem):
        raise SomeException
except SomeException as e:
    handle_break_behaviour(e)
else:
    print("Did not break")

I (and others) have suggested this before and no one has said it's a 
/bad /option, it's just been ignored, despite seeming to be an 
intuitive way to accomplish `else` clarity, "labelled" breaks and 
breaking from multiple loops. Is there a reason that this suggestion 
is worse / no better than adding special break syntax?



It's certainly a reasonable option.  Indeed, I would consider using the 
second (currently legal) version in my own code if it seemed appropriate.

Some pros and cons that occur to me (I may be biased, YMMV):
Pros:
    (1) It can cleanly separate the handling of break-type exceptions 
and other exceptions, if needed.

    (2) It actually clarifies what the dreaded "else" means!
    (3) it allows you to group your "break" cases using exception 
subclasses (although this is probably OTT for most use cases).

Cons:
    (4) It's more work.  You have to decide what exceptions to use and 
(most likely) create them.
    (5) It adds the runtime overhead of setting up the "try" and 
possibly raising the exception.
    (6) Putting (implicitly) try...except around a possibly long 
for-suite feels bad somehow, even though it wouldn't catch other 
unwanted exceptions.

    (7) It does not catch the "zero iterations" case.

If, contra your suggestion, special syntax were to be added, it could 
use "except" instead of "if ... elif".

For example (this is just doodling, it's not a fully thought-out proposal):

    for x in range(10):
        ...
        if :
            break "oops" # under the hood this is a compiled jump, not 
the raising of an exception

        if :
            break 42
    except "oops":
        
    except 42:
        
    except break:
        # catches all "break"s not already explicitly caught
        pass
    else:
        print("Did not break")

Rob Cliffe
___
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/GMFVTUN6EYW5EODMGVWZEBBXCEACXG3G/
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: Changing item dunder method signatures to utilize positional arguments (open thread)

[Todd]

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 start working on this, they are also
> > experienced enough to understand that special cases like this exist
> > for historical reasons.
>
> Ouch.
>
> Who am I to tell beginners what they should and shouldn't be messing
> with, and in what order?  IMNSHO, history (let alone understanding it)
> comes *way* after writing a few dunders, even if you don't count
> __init__ as a dunder.
>

I should have been more clear, I was talking about these specific dunder
methods.  Overriding indexing isn't something that people will typically
deal with before understanding the sequences indexing acts on, which is all
they really need to understand to make sense of the current API.

And history is hard to avoid.  Why is it "def" instead of "function"?  Why
do dunder methods use "__" at all?  Why does indexing use 0 instead of 1?
Some things they are just going to need to accept are the way they are, and
these are all things people are almost certainly going to need to encounter
before making their own classes.

Special cases aren't special enough to break the rules.
>

But they're aren't really any rules being broken here.  It may be a
sub-optimal solution in this case, but not a forbidden or even uncommon
approach.

>
___
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/UJVXA5RF4ZBFS43XEOA6B3ECQ3B3F53X/
Code of Conduct: http://python.org/psf/codeofconduct/

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

[Todd]

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 immediate reason is making the intuition around how to add kwd arg
>>> support to square brackets more obvious and sane.
>>>
>>> A second reason is it might be more intuitive for users who have to
>>> learn and remember that multiple arguments to [ ] get packed into a tuple,
>>> but this doesn't happen anywhere else.
>>>
>>
>> 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 cases like this exist for historical
>> reasons.
>>
>
> Yeah I understand and agree but even non-beginners benefit a lot from
> having consistent behaviors in the language, and not having to remember
> exceptions.
>

But it isn't really an exception.  Lots of arguments accept sequences of
various types.  It doesn't take full advantage of what the language can do,
but it also isn't inconsistent with the language.

Any change has to balanced against the cost of rewriting every textbook and
tutorial on the subject.  Adding labelled indexes wouldn't be as much of an
issue since nobody who doesn't need it needs to think about it.  But
changing the default dunder signature is something everyone dealing with
those dunder methods would need to deal with.

As for my specific idea of how to accomplish the signature change, it's
> true that adding replacement getx/setx/delx dunders to the language would
> in fact be *additional* things to remember, not *fewer *things. But the
> goal would be to eventually replace getitem/setitem/delitem-- so this would
> be a temporary situation and eventually go away. Similar to how most people
> don't have a daily need to remember any number of old, previously standard
> and important, ways of doing things after a few years of transition.
>

The problem is backwards-compatibility.  The current solution isn't going
to go away any time soon, if ever.  It is too fundamental to the language
to change.  The time to do that would have been the python 2-to-3 switch.
Nothing like that is planned.



>
>>  Another reason: it could make writing code for specialized libraries
>> that tend to abuse (for the good of us all!) item dunders, like pandas,
>> much easier. Right now such libraries have to rely on their own efforts to
>> break up a key:
>>
>>>
>>> def __getitem__(self, key):
>>> try:
>>> k1, k2 = key
>>> except TypeError:
>>> raise TypeError("two tuple key required")
>>>
>>> But for regular function calls (as opposed to item getting) we get to
>>> write our signature however we want and rely on the language to handle all
>>> of this for us:
>>>
>>> def f(k1, k2):
>>> # no worries about parsing out the arguments
>>>
>>
>> But this is still a pretty simple piece of code.  Is it worth having
>> everyone start over from scratch to avoid dealing with 4 lines of code?
>> Especially since knowing the number of indices ahead of time is a special
>> case for a small number of projects like pandas.  In most cases, the number
>> of indices cannot be known until runtime, so this would provide no
>> practical benefit for most projects.
>>
>>
>
> This alone wouldn't be enough of a benefit, I agree. I find the combined
> benefits taken together compelling enough to at least warrant the
> exploration.
>

I guess that is where we disagree.  I don't see the advantages as all that
large compared to the disadvantage of everyone having to deal with two
implementations, perhaps for decades.


>
>> ---
>>>
>>> One idea: change the "real" names of the dunders. Give `type` default
>>> versions of the new dunders that direct the call to the old dunder names.
>>> ...
>>>
>>> However the set dunder signature would be a problem, because to mirror
>>> the current behavior we end up writing what is now a syntax error:
>>>
>>> def __setx__(self, /, *__key, __value, **__kwargs):
>>> self.__setitem__(__key, __value, **__kwargs)
>>>
>>> The intended meaning above would be that the last positional argument
>>> gets assigned to __value. Maybe someone could suggest a way to fix this.
>>>
>>
>> The simplest way would be to put "value" first:
>>
>> def __setx__(self, __value, /, *__key, **__kwargs):
>>
>
> I didn't mention that as an option because-- since we are dealing with
> positional only arguments much of the time-- it could become very confusing
> to switch the order of the key and value arguments in actual code.
>

More confusing than changing from a tuple to separate arguments, with
specific requirements for where the ”/” must go for it to work?  I think if
they are making such a big switch already, the order of the 

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

[2QdxY4RzWzUUiLuE]

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 cases like this exist
> for historical reasons.

Ouch.

Who am I to tell beginners what they should and shouldn't be messing
with, and in what order?  IMNSHO, history (let alone understanding it)
comes *way* after writing a few dunders, even if you don't count
__init__ as a dunder.

Special cases aren't special enough to break the rules.
___
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/VVXICTWV2EXQOHZTQ5KVADXG5ACR3CDA/
Code of Conduct: http://python.org/psf/codeofconduct/

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

[Mathew Elman]

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:
> handle_break_behaviour(e)
> else:
> print("Did not break")
>

would be sugar for:

try:
> for elem in iterable:
> ...
> if should_break(elem):
> raise SomeException
> except SomeException as e:
> handle_break_behaviour(e)
> else:
> print("Did not break")
>

I (and others) have suggested this before and no one has said it's a
*bad *option,
it's just been ignored, despite seeming to be an intuitive way to
accomplish `else` clarity, "labelled" breaks and breaking from multiple
loops. Is there a reason that this suggestion is worse / no better than
adding special break syntax?

As for an example for labelled breaks how about something of the form:

def insert_ordered_no_duplicates(duplicate_free_list, item):
> for i, elem in enumerate(duplicate_free_list):
> if elem == item:
> break already_present
> if elem > item:
> break location_found
> case already_present:
> return duplicate_free_list
> case location_found:
> new_list = duplicate_free_list[:]
> new_list.insert(i, item)
> return new_list
> new_list = duplicate_free_list[:]
> new_list.append(item)
> return new_list
>

which you can conceivably have a nested case where you don't want to let
duplicate inserts even be attempted like this:

def insert_many_ordered_strictly_no_duplicates(dup_free_list, items):
> new_list = dup_free_list[:]
> for item in items:
> for i, elem in new_list:
> if elem == item:
> break already_present
> if elem > item:
> break location_found
> case already_present:
> break duplicates_attempted
> case location_found:
> new_list.insert(i, item)
> else:
> new_list.append(item)
> case duplicates_attempted:
> return dup_free_list[:]
> return new_list
>


On Wed, 5 Aug 2020 at 13:40, Rob Cliffe via Python-ideas <
python-ideas@python.org> wrote:

> 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 example - searching in a nested loop. Suppose we're looking
> for the word 'apple' in a collection of books. Once we've found it, we stop.
>
> for book in books:
> for page in book:
> if 'apple' in page:
> break
> if break:
> break
>
> However, suppose we say that we only look at the first 5000 or so words in
> each book. (We suppose a page is a list of words.)
>
> This leads to the following code.
>
> for book in books:
> word_count = 0
> for page in book:
> word_count += len(page)
> if word in page:
> break
> if word_count >= 5000:
> break found
> if break found:
> break
>
> At this time, I'd like us to focus on examples of existing code, and
> semantics that might be helpful. I think once we have this, the discussion
> of syntax will be easier.
>
> By the way, the word_count example is as I typed it, but it has a typo.
> Did you spot it when you read it? (I only noticed it when re-reading my
> message.)
>
> Finally, thank you for your contributions. More examples please.
>
> --
> Jonathan
>
>
>
>
>
> ___
> Python-ideas mailing list -- python-ideas@python.org
> To unsubscribe send an email to 
> python-ideas-leave@python.orghttps://mail.python.org/mailman3/lists/python-ideas.python.org/
> Message archived at 
> https://mail.python.org/archives/list/python-ideas@python.org/message/ECALTXEP7M3YWAQCHLPRWPBJRQKQICBC/
> 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/YV4V2FYLT5SNWOCH7TZNXYCQRAQZ6R33/
> Code of Conduct: http://python.org/psf/codeofconduct/
>

-- 


Notice: 
This email is confidential and may contain copyright material of 
members of the Ocado Group. Opinions and views expressed in this message 
may not necessarily reflect the opinions and views of the members of the 
Ocado Group.

If you are not the intended recipient, please notify us 
immediately and delete all 

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

[Todd]

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 you
please explain what you think are the advantages of your approach, ideally
with some examples where you think your approach is clearer?
___
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/ZTDQM4HEQBL7V4TWHOPNSGPYMXRBR2GH/
Code of Conduct: http://python.org/psf/codeofconduct/

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

[Rishav Kundu via Python-ideas]

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 
they track across system suspend or not. These clocks exist on at least 
Windows, macOS, and Linux.


[1] https://www.python.org/dev/peps/pep-0418/#id56

—
Rishav

P.S.: This is my first time submitting to the Python mailing lists. Suggestions 
for improvement are appreciated :)

___
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/KQV2PB5OK6ULVZYPTSKRSQ45HYDPOD6Q/
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: Changing item dunder method signatures to utilize positional arguments (open thread)

[Ricky Teachey]

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
>> support to square brackets more obvious and sane.
>>
>> A second reason is it might be more intuitive for users who have to learn
>> and remember that multiple arguments to [ ] get packed into a tuple, but
>> this doesn't happen anywhere else.
>>
>
> 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 cases like this exist for historical
> reasons.
>

Yeah I understand and agree but even non-beginners benefit a lot from
having consistent behaviors in the language, and not having to remember
exceptions.

As for my specific idea of how to accomplish the signature change, it's
true that adding replacement getx/setx/delx dunders to the language would
in fact be *additional* things to remember, not *fewer *things. But the
goal would be to eventually replace getitem/setitem/delitem-- so this would
be a temporary situation and eventually go away. Similar to how most people
don't have a daily need to remember any number of old, previously standard
and important, ways of doing things after a few years of transition.


>  Another reason: it could make writing code for specialized libraries
> that tend to abuse (for the good of us all!) item dunders, like pandas,
> much easier. Right now such libraries have to rely on their own efforts to
> break up a key:
>
>>
>> def __getitem__(self, key):
>> try:
>> k1, k2 = key
>> except TypeError:
>> raise TypeError("two tuple key required")
>>
>> But for regular function calls (as opposed to item getting) we get to
>> write our signature however we want and rely on the language to handle all
>> of this for us:
>>
>> def f(k1, k2):
>> # no worries about parsing out the arguments
>>
>
> But this is still a pretty simple piece of code.  Is it worth having
> everyone start over from scratch to avoid dealing with 4 lines of code?
> Especially since knowing the number of indices ahead of time is a special
> case for a small number of projects like pandas.  In most cases, the number
> of indices cannot be known until runtime, so this would provide no
> practical benefit for most projects.
>
>

This alone wouldn't be enough of a benefit, I agree. I find the combined
benefits taken together compelling enough to at least warrant the
exploration.


> ---
>>
>> One idea: change the "real" names of the dunders. Give `type` default
>> versions of the new dunders that direct the call to the old dunder names.
>> ...
>>
>> However the set dunder signature would be a problem, because to mirror
>> the current behavior we end up writing what is now a syntax error:
>>
>> def __setx__(self, /, *__key, __value, **__kwargs):
>> self.__setitem__(__key, __value, **__kwargs)
>>
>> The intended meaning above would be that the last positional argument
>> gets assigned to __value. Maybe someone could suggest a way to fix this.
>>
>
> The simplest way would be to put "value" first:
>
> def __setx__(self, __value, /, *__key, **__kwargs):
>

I didn't mention that as an option because-- since we are dealing with
positional only arguments much of the time-- it could become very confusing
to switch the order of the key and value arguments in actual code.

But if that is the case then the __setx__ hurdle appears insurmountable,
apart from modifying the language so that function signatures can behave
similar to this syntax feature:

first, *rest, last = [1, 2, 3, 4, 5, 6]
assert first == 1
assert last == 6
assert rest == [2, 3, 4, 5]

... so then you could write a function signature in this way:

def f(first, *rest, last, /):
return first, rest, last

first, rest, last = f(1, 2, 3, 4, 5, 6)
assert first == 1
assert last == 6
assert rest == [2, 3, 4, 5]

So I suppose  that would be yet another change that would need to happen
first.

---
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/SJLSHJSOVOIYOXQ2BMUC52AES6ZBIAUX/
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: Idea: Extend "for ... else ..." to allow "for ... if break ..." else

[Rob Cliffe via Python-ideas]

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 example - searching in a nested loop. Suppose we're 
looking for the word 'apple' in a collection of books. Once we've 
found it, we stop.


    for book in books:
        for page in book:
            if 'apple' in page:
                break
        if break:
            break

However, suppose we say that we only look at the first 5000 or so 
words in each book. (We suppose a page is a list of words.)


This leads to the following code.

    for book in books:
        word_count = 0
        for page in book:
            word_count += len(page)
            if word in page:
                break
            if word_count >= 5000:
                break found
        if break found:
            break

At this time, I'd like us to focus on examples of existing code, and 
semantics that might be helpful. I think once we have this, the 
discussion of syntax will be easier.


By the way, the word_count example is as I typed it, but it has a 
typo. Did you spot it when you read it? (I only noticed it when 
re-reading my message.)


Finally, thank you for your contributions. More examples please.

--
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/ECALTXEP7M3YWAQCHLPRWPBJRQKQICBC/
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/YV4V2FYLT5SNWOCH7TZNXYCQRAQZ6R33/
Code of Conduct: http://python.org/psf/codeofconduct/

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

[Rob Cliffe via Python-ideas]

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 note that you're extending Jonathan's proposal by allowing 
the the label to follow an enclosing loop, not the inner loop (at least 
he certainly didn't say explicitly that he was proposing that).
Also, you have to create the label, even if you don't want to do 
anything when you get there other than 'pass', which is a bit inelegant.

Rob

___
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/LEBAC5QKDXVCBZJ5NUXTSLFBCW2TW42L/

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/5VKZJA5RTFS7ONNNLNYLVSMSPBEELLIS/
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: Introduce a boundary parameter for typing.get_type_hints when used with a class object

[Dominik Vilsmeier]

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 public then all building blocks would be in place.



On Tue, Aug 4, 2020 at 12:57 David Mertz mailto:me...@gnosis.cx>> wrote:

This definitely feels to me like though if an oddball case that
"write your own function" seems like the best solution. I accept
the OP needs it, but I have trouble imagining that many others would.

On Tue, Aug 4, 2020, 7:42 AM Dominik Vilsmeier
mailto:dominik.vilsme...@gmx.de>> wrote:

In one of my projects I'm reusing class-level type annotations
to identify relevant attributes for serialization, e.g.
similar to the following:

    attrs = {name: getattr(obj, name) for name in
get_type_hints(type(obj))}

This is convenient because it merges the type annotations from
the various stages in the class hierarchy, e.g.

    class Base:
        a: int
    class Derived(Base):
        b: str

results in `attrs == dict(a=..., b=...)`.

However it becomes inconvenient if external base classes are
involved that define their own, unrelated type annotations, e.g.

    class External:  # from some other distribution
        unrelated: float
    class Base(External):
        a: int

It would be helpful if `get_type_hints` had a `boundary`
parameter that, when used with a class object, determines the
upper boundary for the MRO. So it could be used in the
following way:

    get_type_hints(type(derived_obj), boundary=Base)

to exclude any type annotations further up the class hierarchy
(including the ones from `Base`).

Regarding the implementation this would effectively skip over
base classes in the reverse MRO until it reaches the `boundary`.

What do you think?
___
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/T6K4DWENPM7LYXSDVYQYDVFEVBMA5K3L/
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/OBZ5UEYTPEJG65MYFYMSBUTI46N7HSW7/
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/EMGFABAEMVUEEJMGM7STLBVP2TWRSS3R/
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/FLHUAOHM666MIOBFXAYNAZCVY6RERXUM/
Code of Conduct: http://python.org/psf/codeofconduct/