Re: [Python-ideas] Pattern Matching Syntax

[Tim] >> ... I liked the way he _reached_ that conclusion: by looking at real- >> life Python code that may have been written instead to use constructs >> "like this". I find such examination far more persuasive than abstract >> arguments or made-up examples. [Serhiy Storchaka

Re: [Python-ideas] Pattern Matching Syntax

05.05.18 09:23, Tim Peters пише: [Tim] ... I liked the way he _reached_ that conclusion: by looking at real- life Python code that may have been written instead to use constructs "like this". I find such examination far more persuasive than abstract arguments or made-up examples. [Serhiy

Re: [Python-ideas] Inline assignments using "given" clauses

Tim Peters wrote: "async def", "async for", and "async with" statements were added _without_ making "async" a new reserved word. It may require pain in the parser, but it's often doable anyway. There would be less pain if the parser generator could deal with non-reserved keywords more

Re: [Python-ideas] Inline assignments using "given" clauses

I agree it would be useful to have new keywords without being reserved, and we could even go with mechanism like infix operators created by user. It would allow things like [given for x in range(5) given given = x+1] or even [given for given in range(given) given given = given + 1] haha, but as

Re: [Python-ideas] Inline assignments using "given" clauses

I think that "expr as y" was discarded too quickly. It would be a syntax completely familiar to Python programmers, and the new semantics would be obvious. That choice would also be in line with the Zen of Python. The special cases that may arise over "except" and "with" can be worked out and

[Python-ideas] Runtime assertion with no overhead when not active

Hi folks, I intend to add a runtime assertion feature in python. Before submitting a PEP, I am sending a draft to this mailing list to discuss whether it would make sense (above this message). I have actually been using it for the last 2 years and it has proven to be robust and has achieved its

Re: [Python-ideas] Runtime assertion with no overhead when not active

I meant avoiding the overhead of the expression evaluation enclosed in the assert itself, not the active/disabled state (that comes at virtually no cost). ex: >>> runtime_assert( { i:None for i in range( 1000 ) } ) By using the syntax you describe ('boolean and not expr'), you loose all

Re: [Python-ideas] Runtime assertion with no overhead when not active

05.05.18 15:54, Eloi Gaudry пише: I meant avoiding the overhead of the expression evaluation enclosed in the assert itself, not the active/disabled state (that comes at virtually no cost). ex: runtime_assert( { i:None for i in range( 1000 ) } ) By using the syntax you describe ('boolean

Re: [Python-ideas] Runtime assertion with no overhead when not active

By 'self-contained', I meant that using the assert keyword and its expression is sufficient. An inline assertive expression as the one you describe does not fulfill this assert requirement. My proposal is simply to extend the current assert to non-debug builds and allow to switch it off/on at

Re: [Python-ideas] Inline assignments using "given" clauses

On 6 May 2018 at 00:33, Mikhail V wrote: > recently I have discovered interesting fact: it seems one > can already use 'inline assignment' with current syntax. E.g.: > > if exec("m = input()") or m: > print (m) > > It seem to work as inline assignment correctly. > Yes

Re: [Python-ideas] Runtime assertion with no overhead when not active

05.05.18 18:04, Eloi Gaudry пише: By 'self-contained', I meant that using the assert keyword and its expression is sufficient. An inline assertive expression as the one you describe does not fulfill this assert requirement. Sufficient for what? And why writing with using the existing syntax

Re: [Python-ideas] Inline assignments using "given" clauses

[Nick] >... > There were a couple key reasons I left the "for x in y" case out of the > initial proposal: > > 1. The "for x in y" header is already quite busy, especially when tuple > unpacking is used in the assignment target > 2. Putting the "given" clause at the end would make it ambiguous as

Re: [Python-ideas] Add "default" kw argument to operator.itemgetter and operator.attrgetter

At some point, we're really better off just using a lambda. Maybe I'm slow today, but I'm having trouble seeing how to write this as a lambda. >>> values = {'x': 43, 'y': 55} >>> x, y, z = (lambda *args : tuple(values.get(arg,0) for arg in args))('x','y','z') >>> print(x, y, z) (43, 55, 0)

Re: [Python-ideas] Inline assignments using "given" clauses

On 6 May 2018 at 02:06, Nick Coghlan wrote: > On 4 May 2018 at 22:06, Nick Coghlan wrote: > >> (Note: Guido's already told me off-list that he doesn't like the way this >> spelling reads, but I wanted to share it anyway since it addresses one of >> the

Re: [Python-ideas] Add "default" kw argument to operator.itemgetter and operator.attrgetter

Hi Vincent, Your idea is interesting but we are worried that there are not enough real use cases where it would be useful. Have you encountered situations yourself where this would make a difference? I am asking not for clarifying examples (you already provided one and from that it's perfectly

Re: [Python-ideas] Python-ideas Digest, Vol 138, Issue 32

Hi all! Really interesting discussion on here. Personally I feel that PEP 572, as it stands, undermines the readability of the language, in particular for those new to the language, programming. I have issue with both the in-expression assignment, and the current proposed operator approach.

Re: [Python-ideas] Inline assignments using "given" clauses

On Fri, May 4, 2018 at 3:06 PM, Nick Coghlan wrote: > > With that spelling, the three examples above would become: > > # Exactly one branch is executed here > if m given m = pattern.search(data): > ... > elif m given m = other_pattern.search(data)): >

Re: [Python-ideas] Runtime assertion with no overhead when not active

On Sat, May 05, 2018 at 08:04:45AM +, Eloi Gaudry wrote: > Hi folks, > I intend to add a runtime assertion feature in python. I'm very interested in this idea, but I'm afraid your draft PEP isn't very clear about this feature. Comments below. > Rationale > There is no runtime assert

Re: [Python-ideas] Inline assignments using "given" clauses

05.05.18 18:26, Nick Coghlan пише: 3. writing back to the local namespace via exec doesn't work consistently at function scope (and assuming PEP 558 is eventually accepted, will some day reliably *never* work) At end you can convert the source of the whole script to a string literal and

Re: [Python-ideas] Inline assignments using "given" clauses

On 4 May 2018 at 22:06, Nick Coghlan wrote: > (Note: Guido's already told me off-list that he doesn't like the way this > spelling reads, but I wanted to share it anyway since it addresses one of > the recurring requests in the PEP 572 discussions for a more targeted >

Re: [Python-ideas] Inline assignments using "given" clauses

On 5 May 2018 at 13:36, Tim Peters wrote: > [Nick Coghlan ] > > ... > > The essence of the given clause concept would be to modify *these > specific > > cases* (at least initially) to allow the condition expression to be > followed > > by an inline

Re: [Python-ideas] Pattern Matching Syntax

[Tim] ... I liked the way he _reached_ that conclusion: by looking at real- life Python code that may have been written instead to use constructs "like this". I find such examination far more persuasive than abstract arguments or made-up examples. [Serhiy] >>> I would like