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
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
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: sairamkumar2...@gmail.com
Cc: python-ideas@python.org
Subject: [Python-ideas] Re: Making the for statement
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
On 30Nov2020 04:00, sairamkumar2...@gmail.com 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
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
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
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
>>>
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
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
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
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
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
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."
>
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
This is quite good but remove the new keyword, it's not necessary there.
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
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
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 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.
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
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 -- python-ideas@python.org
To unsubscribe send an email to
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)
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,
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()
29.11.20 22:44, sdemen...@gmail.com пише:
> 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
>
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
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
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.
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
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),
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
Hello,
This is continuation of the "Making the for statement work better with
nested functions" thread
(https://mail.python.org/archives/list/python-ideas@python.org/thread/3ZKYV6WQPPWR7SBPKRWW743OPSI22RDA/).
I post this as a separate thread to draw more attention to and promote
this way of
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
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.
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
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
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
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
38 matches
Mail list logo
