[Python-ideas] Re: Callable annotation featureset [Was: Alternative to Callable Annotation]

On Sun, Nov 29, 2020 at 1:49 AM Guido van Rossum wrote: > On Sat, Nov 28, 2020 at 9:32 AM Andrew Svetlov > wrote: > >> I would see support of all argument kinds support in any proposal for a >> new callable: positional only args, named args, keyword-only, *args and >> **kwargs. >> The exact nota

[Python-ideas] Re: Making the for statement work better with nested functions

Hello, On Sun, 29 Nov 2020 13:39:37 +1300 Greg Ewing wrote: > On 29/11/20 4:14 am, Paul Sokolovsky wrote: > > > > On Fri, 27 Nov 2020 13:06:56 +1300 > > Greg Ewing wrote: > > > > There was no mix-up on my side, and neither seems there was on > > yours. Block-level scoping and const'ness are o

[Python-ideas] Add decorator_with_params function to functools module

In the current python codebases, there are a lot of decorators with parameters, and their code in most cases contains a lot of code boilerplates. The purpose of this feature is to add `decorator_with_params` (I think the name can be changed to smth better) function to `functools` module. This fu

[Python-ideas] Re: Making the for statement work better with nested functions

Hello, On Sat, 28 Nov 2020 18:59:14 -0800 Guido van Rossum wrote: > I'm definitely being nerd-sniped here, so take this with a grain of > salt. > > The reason why Python currently doesn't have block scopes is the rule > that assignment creates or updates a variable in the closest scope. > This

[Python-ideas] Making "Any" a builtin

Instead of importing “Any" from the typing module, we can annotate our functions with “Any" right away without the extra step. What do you think? We have the builtin function “any” which some Python users could mistakingly use, but static type checkers should catch that. ___

[Python-ideas] Re: Experimental syntax proposal

Hello André, On Sat, 24 Oct 2020 13:32:30 -0300 André Roberge wrote: > # Experimental Syntax Proposal > > I would like to propose that Python adopts a modified process > before introducing significant changes of its syntax. [] > ## New suggested process > > Assuming one of the options mentio

[Python-ideas] [PoC] Implementing block-scope for the "for" statement variables

Hello, This is continuation of the "Making the for statement work better with nested functions" thread (https://mail.python.org/archives/list/[email protected]/thread/3ZKYV6WQPPWR7SBPKRWW743OPSI22RDA/). I post this as a separate thread to draw more attention to and promote this way of proto

[Python-ideas] Re: Experimental syntax proposal

Hello Paul (and everyone else), On Sun, Nov 29, 2020 at 12:00 PM Paul Sokolovsky wrote: > ... > > > # Experimental Syntax Proposal > > > > I would like to propose that Python adopts a modified process > > before introducing significant changes of its syntax. > > [] > > > ## New suggested process

[Python-ideas] Re: Callable annotation featureset [Was: Alternative to Callable Annotation]

That's a fair criticism -- Protocols are usable for this, but the syntax is hardly the most intuitive, and most people would never think of this approach. I guess the alternative would be to duplicate the full syntax allowed in the parameter list of a 'def' statement (with some tweaks perhaps), so

[Python-ideas] Re: Making the for statement work better with nested functions

On 2020-11-25 22:07, Guido van Rossum wrote: Hmm... In the end I think the language design issue is with functions (and how they capture variable references rather than values), and fixing it by changing the for-loop is still just a band-aid, with other problems and inconsistencies. Agreed that t

[Python-ideas] Re: [PoC] Implementing block-scope for the "for" statement variables

29.11.20 18:27, Paul Sokolovsky пише: > Here's example of it in action: > > $ cat example_for1.py > def fun(): > x = 123 > for x in range(5): > print(x) > print("old x:", x) > > fun() I am strong -1. 1. It will break existing code. Including a lot of code written by me. 2

[Python-ideas] Re: adding a timeit.Timer context manager and decorator to time code/functions

The feature I am looking for is more about timing a code block or a function while running the code in dev/production. Not about timing it for benchmarking purposes. To use timeit (or the current Timer class), one has to write the stmt as a string which is not convenient (yet I understand that i

[Python-ideas] Re: Making the for statement work better with nested functions

On Sun, Nov 29, 2020 at 8:28 PM Brendan Barnwell wrote: > After following this thread I'm still not convinced changing the for > loop is really a good idea. I basically agree with Steven D'Aprano that > the supposed benefits of "protecting" against accidental name shadowing > are marginal at bes

[Python-ideas] Re: adding a timeit.Timer context manager and decorator to time code/functions

29.11.20 22:44, [email protected] пише: > The feature I am looking for is more about timing a code block or a function > while running the code in dev/production. Not about timing it for > benchmarking purposes. > To use timeit (or the current Timer class), one has to write the stmt as a > str

[Python-ideas] Re: [PoC] Implementing block-scope for the "for" statement variables

Hello, On Sun, 29 Nov 2020 22:33:28 +0200 Serhiy Storchaka wrote: > 29.11.20 18:27, Paul Sokolovsky пише: > > Here's example of it in action: > > > > $ cat example_for1.py > > def fun(): > > x = 123 > > for x in range(5): > > print(x) > > print("old x:", x) > > > > fun()

[Python-ideas] Re: Making the for statement work better with nested functions

On Sun, Nov 29, 2020 at 12:28 PM Brendan Barnwell wrote: > For me the only problem with the `x=x` default argument "fix" is > that. > . . well, it's in the argument signature. That means it effectively > becomes part of the function's public API, and people can pass in other > values, wh

[Python-ideas] Re: adding a timeit.Timer context manager and decorator to time code/functions

On Sun, 29 Nov 2020 at 21:45, wrote: > To use timeit (or the current Timer class), one has to write the stmt as a > string which is not convenient (yet I understand that if you want to time a > code snippet by running it more than once there may be not alternative than > using stmt as strings)

[Python-ideas] Re: Add decorator_with_params function to functools module

You can use classes as decorators, it's quite more simple: https://towardsdatascience.com/using-class-decorators-in-python-2807ef52d273?gi=ea5091974462 ___ Python-ideas mailing list -- [email protected] To unsubscribe send an email to python-ideas-l

[Python-ideas] Re: Making the for statement work better with nested functions

On Sun, 29 Nov 2020 at 23:34, Guido van Rossum wrote: > OTOH if we were to introduce 'let' or 'const' in the language, it would > surely be usable to solve a whole bunch of other problems, in addition to > giving us a cleaner way to solve the value capture problem. Well, IMHO let could help the

[Python-ideas] Re: Making the for statement work better with nested functions

On 29/11/20 11:02 pm, Paul Sokolovsky wrote: It will be much more obvious if there's a general (standalone) "const", I don't think it will. There's nothing about the problem that points towards constness as a solution, so it doesn't matter how many other places in the language "const" appears.

[Python-ideas] Re: adding a timeit.Timer context manager and decorator to time code/functions

On Mon, Nov 30, 2020 at 10:14 AM Marco Sulla wrote: > > On Sun, 29 Nov 2020 at 21:45, wrote: > > To use timeit (or the current Timer class), one has to write the stmt as a > > string which is not convenient (yet I understand that if you want to time a > > code snippet by running it more than on

[Python-ideas] Re: Making the for statement work better with nested functions

This is a massively less ambitious idea, and doesn't solve the original problem, but: I'd like to see a scope for names that are "obviously ;-)" meant to be short lived. At the moment that's the for loop "counters" and those created by context managers: for i in something: # use i as usual mo

[Python-ideas] Re: Making the for statement work better with nested functions

This is quite good but remove the new keyword, it's not necessary there. ___ Python-ideas mailing list -- [email protected] To unsubscribe send an email to [email protected] https://mail.python.org/mailman3/lists/python-ideas.python.org/

[Python-ideas] Re: Making the for statement work better with nested functions

On 30/11/20 9:46 am, David Mertz wrote: def f(a, b, c=21, _foo=foo, _bar=bar): Of course I know that users COULD call `f(1, 2, _foo=something_else)`. But we have asked them not to politely, and  "we're all consenting adults." This doesn't work so well if the function takes *args or **kwds ar

[Python-ideas] Re: Making the for statement work better with nested functions

On Sun, Nov 29, 2020, 11:52 PM Greg Ewing wrote: > On 30/11/20 9:46 am, David Mertz wrote: > > def f(a, b, c=21, _foo=foo, _bar=bar): > > > > Of course I know that users COULD call `f(1, 2, _foo=something_else)`. > > But we have asked them not to politely, and "we're all consenting > adults." >

[Python-ideas] Re: Making "Any" a builtin

Since Python 3.10, you can use "Any" without "from typing import Any". You can do it in Python 3.7 by "from __future__ import annotations" too. See https://www.python.org/dev/peps/pep-0563/ Regards, On Mon, Nov 30, 2020 at 12:29 AM Abdulla Al Kathiri wrote: > > Instead of importing “Any" from t

[Python-ideas] Re: Callable annotation featureset [Was: Alternative to Callable Annotation]

The proposed examples look awesome, thanks! On Sun, Nov 29, 2020 at 7:27 PM Guido van Rossum wrote: > That's a fair criticism -- Protocols are usable for this, but the syntax > is hardly the most intuitive, and most people would never think of this > approach. > > I guess the alternative would b

[Python-ideas] Re: Making "Any" a builtin

Well, there are some exceptions. E.g. type aliases are still evaluated: # Python 3.10 TT = tuple[int, Any] Similarly, casts: f(cast(Any, arg)) And subclassing from generic classes, e.g. T = TypeVar("T") class B(Generic[T]): ... class C(B[Any]): ... Probably some that I forgot. On Sun, Nov 2

[Python-ideas] Re: Making "Any" a builtin

Oh, note that Abdulla said: "we can annotate our **functions** with “Any" right away without the extra step." Python 3.9.0 (default, Nov 21 2020, 14:01:55) >>> from __future__ import annotations >>> def foo(a: Any, b: Dict[Any, Any]) -> Any: pass -- Inada Naoki

[Python-ideas] Re: Making "Any" a builtin

pbryan@dynamo:~$ python3 Python 3.8.6 (default, Sep 30 2020, 04:00:38) [GCC 10.2.0] on linux Type "help", "copyright", "credits" or "license" for more information. >>> from __future__ import annotations >>> Any Traceback (most recent call last): File "", line 1, in NameError: name 'Any' is not

[Python-ideas] Re: Making "Any" a builtin

Any only works as an annotation: In [3]: def fn(*argv: Any) -> Any: ...: return argv[0] ...: From: Paul Bryan Sent: 30 November 2020 05:55 To: Inada Naoki ; Abdulla Al Kathiri Cc: python-ideas Subject: [Python-ideas] Re: Making "Any" a builtin pbryan@dynamo:

[Python-ideas] Re: Making "Any" a builtin

pbryan@dynamo:~$ python3 Python 3.8.6 (default, Sep 30 2020, 04:00:38) [GCC 10.2.0] on linux Type "help", "copyright", "credits" or "license" for more information. >>> from __future__ import annotations >>> def fn(*argv: Any) -> Any: ... ... ... >>> from typing import get_type_hints >>> get_typ

[Python-ideas] Re: adding a timeit.Timer context manager and decorator to time code/functions

I have read the documentation of the timeit module and also you can pass a function (without arguments) to it (e.g. https://stackoverflow.com/questions/5086430/how-to-pass-parameters-of-a-function-when-using-timeit-timer). My needs are: - simple way to instrument my code to log time for a functi

[Python-ideas] Re: adding a timeit.Timer context manager and decorator to time code/functions

On Sun, Nov 29, 2020 at 10:36 PM wrote: > > My needs are: > - simple way to instrument my code to log time for a function or a code > block (I am not writing a specific script to time/benchmark a specific code) > - have the timing sent to some logger > - be the less intrusive possible > > With th

[Python-ideas] Re: Making the for statement work better with nested functions

On 30Nov2020 04:00, [email protected] wrote: >This is quite good but remove the new keyword, it's not necessary >there. The idea is to introduce names which are not previously present, and _expire_ and the end of the enclosed suite. Without the "new" is valid Python right now and does

[Python-ideas] Re: Making "Any" a builtin

The __future__ import only makes the Any type available for use during **annotations** i.e. if you follow the below with: In [6]: from typing import Any In [7]: get_type_hints(fn) Out[7]: {'argv': typing.Any, 'return': typing.Any} So the Any is out of scope for typing unless it is imported from

[Python-ideas] Re: Making the for statement work better with nested functions

Wouldn't `local` make sense as the opposite of `global` - personally I would rather see that than LET. -Original Message- From: Cameron Simpson Sent: 30 November 2020 07:13 To: [email protected] Cc: [email protected] Subject: [Python-ideas] Re: Making the for statement wo

[Python-ideas] Re: Making "Any" a builtin

I believe the __future__ import makes any annotation a string, it doesn't make Any magically resolvable later. If you don't import Any into the scope of the annotation, it won't be resolved when getting type hints. Based on this, I believe: 1. It is incorrect to say "Any" will "work" by using fro

[Python-ideas] Re: Making "Any" a builtin

On Mon, Nov 30, 2020 at 4:27 PM Paul Bryan wrote: > > I believe the __future__ import makes any annotation a string, it doesn't > make Any magically resolvable later. If you don't import Any into the scope > of the annotation, it won't be resolved when getting type hints. > I don't say it works