[Python-ideas] Re: use type hints and slices to specify a valid numerical range, example: `Angle = int[0:361]`

Oops, obviously I meant: def plusone(i: int[1:1_000_000_000]): return i+1 random.seed(42) for n in range(1_000_000): plusone(random.randint(1, 1_000_000_001)) Or a zillion other things. I can construct orbitals of Mandelbrot set that may or may not be bounded. Or bounds that depend on

[Python-ideas] Re: use type hints and slices to specify a valid numerical range, example: `Angle = int[0:361]`

On Fri, Aug 07, 2020 at 05:44:31PM -0400, Ricky Teachey wrote: > Would it make good semantic sense- and be useful- to specify valid > numerical ranges using slices and type-hint syntax? My suggestion would be > to, at minimum, provide this functionality for int and float. We know that

[Python-ideas] Re: use type hints and slices to specify a valid numerical range, example: `Angle = int[0:361]`

On Sat, Aug 8, 2020, 1:12 AM Steven D'Aprano > Static languages often check what > bounds they can at compile time, and optionally insert bound checking > runtime code for ambiguous places. Yep. That's an assert, or it's moral equivalent. Here's a deterministic program using the hypothetical

[Python-ideas] Re: use type hints and slices to specify a valid numerical range, example: `Angle = int[0:361]`

On Fri, Aug 07, 2020 at 11:48:40PM -0400, David Mertz wrote: > On Fri, Aug 7, 2020, 6:03 PM Paul Moore wrote: > > > > x: int[0:] # any ints greater than or equal to zero would match, others > > would fail > > > x: int[:101] # any ints less than 101 match > > > x: int[0:101:2] # even less than

[Python-ideas] Re: use type hints and slices to specify a valid numerical range, example: `Angle = int[0:361]`

On Sat, Aug 8, 2020, 12:18 AM Ricky Teachey > Yes, it's hard in the sense that it would require solving the halting >> problem. >> > > That doesn't sound so hard. ;) > > Thanks for educating me. Could it at least be useful for: > > 1. Providing semantic meaning to code (but this is probably not

[Python-ideas] Re: use type hints and slices to specify a valid numerical range, example: `Angle = int[0:361]`

On Fri, Aug 7, 2020 at 11:48 PM David Mertz wrote: > On Fri, Aug 7, 2020, 6:03 PM Paul Moore wrote: > >> > x: int[0:] # any ints greater than or equal to zero would match, >> others would fail >> > x: int[:101] # any ints less than 101 match >> > x: int[0:101:2] # even less than 101 >> >> I

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

On Fri, Aug 7, 2020 at 10:47 PM Steven D'Aprano wrote: > On Fri, Aug 07, 2020 at 12:09:28PM -0400, Ricky Teachey wrote: > > > I was actually trying to help the kwd arg case here. As illustrated by > the > > quote I included from Greg Ewing, there seems to be not even close to a > > consensus

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

On Fri, Aug 7, 2020 at 6:02 PM Greg Ewing wrote: > On 4/08/20 9:12 am, Guido van Rossum wrote: > > then presumably calling `c[1, index=2]` would just be an error (since it > > would be like attempting to call the method with two values for the > > `index` argument), > > Hmmm, does this mean that

[Python-ideas] Re: use type hints and slices to specify a valid numerical range, example: `Angle = int[0:361]`

On Fri, Aug 7, 2020, 6:03 PM Paul Moore wrote: > > x: int[0:] # any ints greater than or equal to zero would match, others > would fail > > x: int[:101] # any ints less than 101 match > > x: int[0:101:2] # even less than 101 > > I suspect the biggest issue with this is that it's likely to be

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

On Fri, Aug 7, 2020 at 9:25 PM Edwin Zimmerman wrote: > On 8/7/2020 8:28 PM, Greg Ewing wrote: > > I don't think anyone has the appetite for a Python 4 any > > time soon. > > > I'm included in "anyone" here. From reading this list, it seems to me > that "Python 4" is invoked as some folks

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

On Fri, Aug 07, 2020 at 12:09:28PM -0400, Ricky Teachey wrote: > I was actually trying to help the kwd arg case here. As illustrated by the > quote I included from Greg Ewing, there seems to be not even close to a > consensus over what the semantic meaning of this should be: > > m[1, 2, a=3,

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

On Fri, Aug 7, 2020 at 6:29 PM Stephan Hoyer wrote: > On Fri, Aug 7, 2020 at 9:12 AM Ricky Teachey wrote: > >> On Fri, Aug 7, 2020 at 4:19 AM Steven D'Aprano >> wrote: >> >>> On Fri, Aug 07, 2020 at 05:54:18PM +1000, Steven D'Aprano wrote: >>> >>> > This proposal doesn't say anything about

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

On Fri, Aug 7, 2020 at 9:12 AM Ricky Teachey wrote: > On Fri, Aug 7, 2020 at 4:19 AM Steven D'Aprano > wrote: > >> On Fri, Aug 07, 2020 at 05:54:18PM +1000, Steven D'Aprano wrote: >> >> > This proposal doesn't say anything about reversing the decision made >> all >> > those years ago to bundle

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

On 8/7/2020 8:28 PM, Greg Ewing wrote: >  I don't think anyone has the appetite for a Python 4 any > time soon. > I'm included in "anyone" here.  From reading this list, it seems to me that "Python 4" is invoked as some folks favorite magical justification for proposing major breaking changes. 

[Python-ideas] Re: Inline Try-Except Clause

On Fri, Aug 07, 2020 at 06:40:33PM +0100, Rob Cliffe via Python-ideas wrote: > > > On 07/08/2020 17:16, Serhiy Storchaka wrote: > >The main problem to me with the exception catching expression is that > >you need to add the exception name and several keywords, and it makes > >real-world

[Python-ideas] Re: Inline Try-Except Clause

On 8/08/20 3:24 am, Paul Moore wrote: def is_valid_specifier(s): try: packaging.specifiers.SpecifierSet(s) return True except packahing.specifiers.InvalidSpecifier: return False This doesn't quite follow the pattern, because it doesn't return the result of

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

On 4/08/20 9:12 am, Guido van Rossum wrote: then presumably calling `c[1, index=2]` would just be an error (since it would be like attempting to call the method with two values for the `index` argument), Hmmm, does this mean that classes providing index notation would now need to document the

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

On 8/08/20 4:09 am, Ricky Teachey wrote: If that incongruity were to be fixed, it seems to me it would become *obvious* that the semantic meaning of ` m[1, 2, a=3, b=2]` should definitely be: m.__get__(1, 2, a=3, b=4) It would certainly achieve that goal. The question is whether it would be

[Python-ideas] Re: use type hints and slices to specify a valid numerical range, example: `Angle = int[0:361]`

On Fri, Aug 7, 2020 at 6:01 PM Paul Moore wrote: > On Fri, 7 Aug 2020 at 22:46, Ricky Teachey wrote: > > > > This was inspired by a tweet today from Brandon Rhodes. I looked for > something like it on the mypy issues page and didn't find anything. > > > > Would it make good semantic sense- and

[Python-ideas] Re: Inline Try-Except Clause

On Fri, Aug 7, 2020 at 10:44 AM Rob Cliffe wrote: > > On 07/08/2020 16:58, Guido van Rossum wrote: > > On Fri, Aug 7, 2020 at 8:15 AM David Mertz wrote: > >> I think getting Guido on board would be a huge step. Python has added >> quite a bit of new syntax since 2014, and Guido himself is

[Python-ideas] Re: use type hints and slices to specify a valid numerical range, example: `Angle = int[0:361]`

On Fri, 7 Aug 2020 at 22:46, Ricky Teachey wrote: > > This was inspired by a tweet today from Brandon Rhodes. I looked for > something like it on the mypy issues page and didn't find anything. > > Would it make good semantic sense- and be useful- to specify valid numerical > ranges using slices

[Python-ideas] use type hints and slices to specify a valid numerical range, example: `Angle = int[0:361]`

This was inspired by a tweet today from Brandon Rhodes. I looked for something like it on the mypy issues page and didn't find anything. Would it make good semantic sense- and be useful- to specify valid numerical ranges using slices and type-hint syntax? My suggestion would be to, at minimum,

[Python-ideas] Re: Inline Try-Except Clause

On Fri, 7 Aug 2020 at 16:32, Alex Hall wrote: > Paul, do you want to write `[s for s in strings if > (packaging.specifiers.SpecifierSet(s) except > packaging.specifiers.InvalidSpecifier: False)]`? That's a mouthful. No, I would (obviously?) use some from ... imports to simplify it. But even

[Python-ideas] Re: Inline Try-Except Clause

On 07/08/2020 16:58, Guido van Rossum wrote: On Fri, Aug 7, 2020 at 8:15 AM David Mertz > wrote: I think getting Guido on board would be a huge step. Python has added quite a bit of new syntax since 2014, and Guido himself is currently advocating another

[Python-ideas] Re: Inline Try-Except Clause

On 07/08/2020 17:16, Serhiy Storchaka wrote: The main problem to me with the exception catching expression is that you need to add the exception name and several keywords, and it makes real-world examples too long, so you will need to split the expression on several lines, and add extra

[Python-ideas] Re: Propouse add context to json module.

On Fri, 07 Aug 2020 08:54:37 - "Kazantcev Andrey" wrote: > Chris Angelico wrote: > > Why do you want dump and load to take parameters from "somewhere > > else"? > > Because developers of libraries don't think about configuring json.dump > method in mos of cases. Then you should report

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

On 2020-08-07 13:13, Jonathan Fine wrote: We are discussing a proposal to extend Python's syntax to allow     d[1, 2, a=3, b=4] We are also discussing the associated semantics. At present     d[1, 2]     d[(1, 2)] are semantically equivalent. Python behaves as though it's wrapping

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

Jonathan, I took a look at your package, and the code, it's a really nice exploration of the solutions. I did find having to include the o() call in the sdaprano version quite distracting (I realise it's needed to get it to work in current cpython without silly tricks in the interpreter)...

[Python-ideas] Re: Inline Try-Except Clause

06.08.20 23:32, Chris Angelico пише: > On Fri, Aug 7, 2020 at 6:28 AM wrote: >> >>> Have a look at PEP 463, which looks into this in some detail. >> >> I wish this PEP had gained more traction. Sooner or later, everyone wants >> an expression form of a try/except. >> >> When it comes to

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

On Fri, 7 Aug 2020 at 14:14, Jonathan Fine wrote: > At present > d[1, 2] > d[(1, 2)] > are semantically equivalent. > > There is a proposal, that > d[1, 2, a=3, b=4] > d[(1, 2), a=3, b=4] > be semantically equivalent. > > I find this troubling, for example because >fn(1, 2,

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

On Fri, Aug 7, 2020 at 4:19 AM Steven D'Aprano wrote: > On Fri, Aug 07, 2020 at 05:54:18PM +1000, Steven D'Aprano wrote: > > > This proposal doesn't say anything about reversing the decision made all > > those years ago to bundle all positional arguments in a subscript into a > > single

[Python-ideas] Re: Inline Try-Except Clause

On Sat, Aug 8, 2020 at 1:58 AM Guido van Rossum wrote: > > On Fri, Aug 7, 2020 at 8:15 AM David Mertz wrote: >> >> I think getting Guido on board would be a huge step. Python has added quite >> a bit of new syntax since 2014, and Guido himself is currently advocating >> another new big change

[Python-ideas] Re: Inline Try-Except Clause

On Fri, Aug 7, 2020 at 8:15 AM David Mertz wrote: > I think getting Guido on board would be a huge step. Python has added > quite a bit of new syntax since 2014, and Guido himself is currently > advocating another new big change (pattern matching). His opinion may have > shifted. > Alas, it

[Python-ideas] Re: Propouse add context to json module.

06.08.20 11:03, Kazantcev Andrey пише: > JSON serialization used in many different libraries without the ability for > configuration (Example > https://github.com/aio-libs/aioredis/blob/8a207609b7f8a33e74c7c8130d97186e78cc0052/aioredis/commands/pubsub.py#L18). > Propose to add something like

[Python-ideas] Re: Inline Try-Except Clause

On Fri, Aug 7, 2020 at 11:32 AM Alex Hall wrote: > > def not_valid(instance, schema): > >> > try: >> > return validate(instance, schema) >> > except ValidationError as err: >> > return str(err) > > > David, your example involves capturing the exception which was deferred

[Python-ideas] Re: Inline Try-Except Clause

On Fri, Aug 7, 2020 at 5:24 PM Paul Moore wrote: > On Fri, 7 Aug 2020 at 16:21, David Mertz wrote: > > > > On Fri, Aug 7, 2020 at 4:58 AM Brendan Barnwell > wrote: > >> > >> It seems that the rationale that was used in the PEP was fairly > >> narrowly focused on the comparison with things like

[Python-ideas] Re: Inline Try-Except Clause

> > For an example. Anyone is free to use, but I'm not claiming it's > necessarily the best. This is from... well, probably not yesterday like I > said in other comment, but a couple days ago. The module `jsonschema` has > an API where it raises an exception if `validate()` doesn't succeed (None

[Python-ideas] Re: Inline Try-Except Clause

On Fri, 7 Aug 2020 at 16:21, David Mertz wrote: > > On Fri, Aug 7, 2020 at 4:58 AM Brendan Barnwell wrote: >> >> It seems that the rationale that was used in the PEP was fairly >> narrowly focused on the comparison with things like dict.get() and the >> idea of EAFP. A somewhat broader

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

Rob Cliffe writes: > Did you see Guido's post when I raised a similar object to detecting > "zero iterations", where it would be unacceptable to slow down all > for-loops, so they would have to be compiled differently? Yes. My confusion (as you'll see elsewhere) was about the AST, not the

[Python-ideas] Re: Inline Try-Except Clause

On Fri, Aug 7, 2020 at 4:58 AM Brendan Barnwell wrote: > It seems that the rationale that was used in the PEP was fairly > narrowly focused on the comparison with things like dict.get() and the > idea of EAFP. A somewhat broader justification might be something along > these lines: > For an

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

Guido van Rossum writes: > Maybe you’re thinking of a “one-pass” compiler, like the original Pascal > compiler, that generates code during parsing. Not really. The "after" phrasing comes from the parsing part which does move through the source pretty much linearly in both the traditional and

[Python-ideas] Re: Inline Try-Except Clause

I think getting Guido on board would be a huge step. Python has added quite a bit of new syntax since 2014, and Guido himself is currently advocating another new big change (pattern matching). His opinion may have shifted. FWIW, I'm +1 on the concept. I've wanted it quite often, as recently as

[Python-ideas] Re: Propouse add context to json module.

What about __json__()? ___ 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

[Python-ideas] Re: Inline Try-Except Clause

On Thu, 6 Aug 2020 at 14:57, Jonathan Grant wrote: > Instead of writing this: > > try: > return my_dict[“a”][“b”][“c”][“d”] > except: > return “some default” > > [...] > > I propose we allow for an inline exception handler, like `eor`: > > return my_dict[“a”][“b”][“c”][“d”] eor “some

[Python-ideas] Re: bpo-41231: wraps default behavior with __annotations__

"3" would "break stuff around". I'd be glad if "2" worked - but that have to be well documented and easy to see. "1" is basically a workaround the current behavior, and people who care for it will have to continue doing that until Python 3.10 is widespread - but ultimately it basically requires

[Python-ideas] Re: Inline Try-Except Clause

On Fri, Aug 7, 2020 at 10:36 PM Rob Cliffe wrote: > OK, some of the arguments are a bit exaggerated. (This can be corrected.) > But this is not an objection to the PEP per se, just to the way some of the > arguments are worded. > Or, looking at that differently: It's an objection to the PEP,

[Python-ideas] Re: Inline Try-Except Clause

On 07/08/2020 06:52, Chris Angelico wrote: On Fri, Aug 7, 2020 at 11:01 AM Jonathan Grant wrote: How can we start to revive this PEP? [I.e. PEP 463 Exception-catching expressions] Have a read of the PEP's rejection notice at the top. To revive the PEP, the objections to it need to be

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

We are discussing a proposal to extend Python's syntax to allow d[1, 2, a=3, b=4] We are also discussing the associated semantics. At present d[1, 2] d[(1, 2)] are semantically equivalent. There is a proposal, that d[1, 2, a=3, b=4] d[(1, 2), a=3, b=4] be semantically

[Python-ideas] bpo-41231: wraps default behavior with __annotations__

Hi! Some time ago I opened a bug and sent a patch, but I realize that I should have started a chat here first, better late than never. The default behavior of the `functools.wraps` decorator, is to copy over the `__annotations__` from the wrapped function to the wrapper function. This is ok

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

On Thu, Aug 06, 2020 at 02:46:01PM +0100, MRAB wrote: > On 2020-08-06 14:16, Stestagg wrote: > > In the "New syntax", wouldn't these examples map to: > > > > d[1, 2, a=3]  =>  d.__getitem__((1, 2), a=3) > > and > > d[(1, 2), a=3]  =>  d.__getitem__((1, 2), a=3) That is certainly what I would

[Python-ideas] Re: Inline Try-Except Clause

On Fri, 7 Aug 2020 at 09:56, Brendan Barnwell wrote: > > Have a read of the PEP's rejection notice at the top. To revive the > > PEP, the objections to it need to be solved. > > It seems that the rationale that was used in the PEP was fairly > narrowly focused on the comparison with

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

Ok so let's do it like this. I'll open a PR against the PEP and I will aggregate all the feedback from this discussion as additional notes. I'll have to re-read the PEP myself, It's been a while. As I said, I'm swamped so I might start working on it probably on Monday. On Wed, 5 Aug 2020 at

[Python-ideas] Re: Propouse add context to json module.

Chris Angelico wrote: > Why do you want dump and load to take parameters from "somewhere > else"? Because developers of libraries don't think about configuring json.dump method in mos of cases. I would like to have a mechanism that would allow tweaking the behaviour for the entire program. I

[Python-ideas] Re: Inline Try-Except Clause

On 2020-08-06 22:52, Chris Angelico wrote: On Fri, Aug 7, 2020 at 11:01 AM Jonathan Grant wrote: How can we start to revive this PEP? And I completely agree, making the syntax `... except ... with ...` is much better than `eor`. Have a read of the PEP's rejection notice at the top. To

[Python-ideas] Re: Propouse add context to json module.

On Fri, 7 Aug 2020 at 09:26, Kazantcev Andrey wrote: > > The problem in this code > > lib.py > ``` > from json import dumps > > def some_func(): > # do something > res = dumps(...) > # do something > ``` > > I wish dump and load themselves could take parameters from somewhere else, >

[Python-ideas] Re: Propouse add context to json module.

On Fri, Aug 7, 2020 at 6:24 PM Kazantcev Andrey wrote: > > The problem in this code > > lib.py > ``` > from json import dumps > > def some_func(): > # do something > res = dumps(...) > # do something > ``` > > If I patch dumps like you propose lib doesn't see any change. Also, it's

[Python-ideas] Re: Propouse add context to json module.

The problem in this code lib.py ``` from json import dumps def some_func(): # do something res = dumps(...) # do something ``` If I patch dumps like you propose lib doesn't see any change. Also, it's all hacks. I wish dump and load themselves could take parameters from somewhere

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

On Fri, Aug 07, 2020 at 12:22:28PM +1200, Greg Ewing wrote: > On 7/08/20 2:47 am, David Mertz wrote: > >The only difference is that in the usual existing style, 'a' doesn't > >know that it's called "a".  You and Steven have both, basically, said > >"Why would you possibly care about that?" > >

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

On Fri, Aug 07, 2020 at 05:54:18PM +1000, Steven D'Aprano wrote: > This proposal doesn't say anything about reversing the decision made all > those years ago to bundle all positional arguments in a subscript into a > single positional parameter. What's done is done, that's not going to >

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

On Tue, Aug 04, 2020 at 10:58:51AM -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

[Python-ideas] Re: Propouse add context to json module.

On Fri, Aug 7, 2020 at 5:50 PM Kazantcev Andrey wrote: > > Chris Angelico wrote: > > > Not gonna be 100% reliable and I don't think it belongs in the stdlib, > > but might be useful. > > That is the problem. Sometimes libs import only methods. I don't see that often, do you have a specific

[Python-ideas] Re: Propouse add context to json module.

Chris Angelico wrote: > Not gonna be 100% reliable and I don't think it belongs in the stdlib, > but might be useful. That is the problem. Sometimes libs import only methods. ___ Python-ideas mailing list -- python-ideas@python.org To unsubscribe send

[Python-ideas] Re: Propouse add context to json module.

On Fri, Aug 7, 2020 at 5:22 PM Kazantcev Andrey wrote: > > Maybe use context as a context manager. > > For example > > ``` > with json.Context(ensure_ascii=False): > json.dumps(...) > ``` > > Implementation can be done via contextlib. If all you want is a way to parameterize naive calls to

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

On Thu, Aug 06, 2020 at 04:01:47PM -, redrad...@gmail.com wrote: > I see lots of use-cases for property decorators ... We have had property decorators since version Python 2.2 which was 18 years ago. We know that there are many wonderful use-cases for things like this. What you are not

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

On Thu, Aug 06, 2020 at 04:03:39PM -, redrad...@gmail.com wrote: > No it is not possible to have something like this: > ```python > def function(cls): > # Where is cls is Neuron class object > pass > > class Neuron: > activation = function(Neuron) > ``` Correct. And it isn't

[Python-ideas] Re: Propouse add context to json module.

Maybe use context as a context manager. For example ``` with json.Context(ensure_ascii=False): json.dumps(...) ``` Implementation can be done via contextlib. ___ Python-ideas mailing list -- python-ideas@python.org To unsubscribe send an email to