Mailman 3 March 2018 - Python-ideas

Split, slice, join and return "syntax" for str
by Andrés Delfino March 4, 2018

March 4, 2018

Hi! I was thinking: perhaps it would be nice to be able to quicky split a string, do some slicing, and then obtaining the joined string back. Say we have the string: "docs.python.org", and we want to change "docs" to "wiki". Of course, there are a ton of simpler ways to solve this particular need, but perhaps str could have something like this: spam = "docs.python.org" eggs = "wiki." + spam['.'][1:] print(eggs) #wiki.python.org A quick implementation to get the idea and try it: class Mystr(… [View More]

4 4

Re: [Python-ideas] An alternative to PEP 572's Statement-Local Name Bindings
by Robert Vanden Eynde March 4, 2018

March 4, 2018

> What the heck, if it was good enough for PL/1... It would still be parsable indeed. A keyword available in a context would then be something new in the language. > Choice of syntax is important, though. It's all very well > to come up with an "insert syntax here" proposal that has > some big obvious benefit, but if you can't actually come > up with a pleasing syntax for it, then it won't fly. So > it makes sense to consider potential syntaxes along with > other aspects … [View More]

1 0

Re: [Python-ideas] An alternative to PEP 572's Statement-Local Name Bindings
by Robert Vanden Eynde March 4, 2018

March 4, 2018

> Robert Vanden Eynde wrote: >> >> But I think that the implementation of print(y with y = x + 1) would >> be more close to next(y for y in [ x+1 ]) > > > WHy on earth should it be? Expanding that gives you a generator > containing a loop that only executes once that is immediately run > to yield exactly one value. Why bother with all that overhead? > You're probably right.

1 0

Re: [Python-ideas] An alternative to PEP 572's Statement-Local Name Bindings
by Robert Vanden Eynde March 4, 2018

March 4, 2018

> I know Guido is on record as not wanting to allow both "for name in > sequence" and "for name = expr" due to that being a very subtle distinction > between iteration and simple assignment (especially given that Julia uses > them as alternate spellings for the same thing), but I'm wondering if it may > be worth considering such a distinction in *with statements*, such that we > allowed "with name = expr" in addition to "with cm as name" (where "name = > expr" is just an … [View More]

1 0

Re: [Python-ideas] An alternative to PEP 572's Statement-Local Name Bindings
by Greg Ewing March 3, 2018

March 3, 2018

Robert Vanden Eynde wrote: > The "make it a keyword in a context" might lead to things like > "print(where where where = where)", not sure you'd want that :) What the heck, if it was good enough for PL/1... > But that's just a choice of syntax, Choice of syntax is important, though. It's all very well to come up with an "insert syntax here" proposal that has some big obvious benefit, but if you can't actually come up with a pleasing syntax for it, then it won't fly. So it makes … [View More]

1 0

Re: [Python-ideas] An alternative to PEP 572's Statement-Local Name Bindings
by Greg Ewing March 3, 2018

March 3, 2018

Robert Vanden Eynde wrote: > But I think that the implementation of print(y with y = x + 1) would > be more close to next(y for y in [ x+1 ]) WHy on earth should it be? Expanding that gives you a generator containing a loop that only executes once that is immediately run to yield exactly one value. Why bother with all that overhead? -- Greg

1 0

PEP 572: Statement-Local Name Bindings
by Chris Angelico March 3, 2018

March 3, 2018

This is a suggestion that comes up periodically here or on python-dev. This proposal introduces a way to bind a temporary name to the value of an expression, which can then be used elsewhere in the current statement. The nicely-rendered version will be visible here shortly: https://www.python.org/dev/peps/pep-0572/ ChrisA PEP: 572 Title: Syntax for Statement-Local Name Bindings Author: Chris Angelico <rosuav(a)gmail.com> Status: Draft Type: Standards Track Content-Type: text/x-rst … [View More]Created: 28-Feb-2018 Python-Version: 3.8 Post-History: 28-Feb-2018 Abstract ======== Programming is all about reusing code rather than duplicating it. When an expression needs to be used twice in quick succession but never again, it is convenient to assign it to a temporary name with very small scope. By permitting name bindings to exist within a single statement only, we make this both convenient and safe against collisions. Rationale ========= When an expression is used multiple times in a list comprehension, there are currently several suboptimal ways to spell this, and no truly good ways. A statement-local name allows any expression to be temporarily captured and then used multiple times. Syntax and semantics ==================== In any context where arbitrary Python expressions can be used, a named expression can appear. This must be parenthesized for clarity, and is of the form `(expr as NAME)` where `expr` is any valid Python expression, and `NAME` is a simple name. The value of such a named expression is the same as the incorporated expression, with the additional side-effect that NAME is bound to that value for the remainder of the current statement. Just as function-local names shadow global names for the scope of the function, statement-local names shadow other names for that statement. They can also shadow each other, though actually doing this should be strongly discouraged in style guides. Example usage ============= These list comprehensions are all approximately equivalent:: # Calling the function twice stuff = [[f(x), f(x)] for x in range(5)] # Helper function def pair(value): return [value, value] stuff = [pair(f(x)) for x in range(5)] # Inline helper function stuff = [(lambda v: [v,v])(f(x)) for x in range(5)] # Extra 'for' loop - see also Serhiy's optimization stuff = [[y, y] for x in range(5) for y in [f(x)]] # Expanding the comprehension into a loop stuff = [] for x in range(5): y = f(x) stuff.append([y, y]) # Using a statement-local name stuff = [[(f(x) as y), y] for x in range(5)] If calling `f(x)` is expensive or has side effects, the clean operation of the list comprehension gets muddled. Using a short-duration name binding retains the simplicity; while the extra `for` loop does achieve this, it does so at the cost of dividing the expression visually, putting the named part at the end of the comprehension instead of the beginning. Statement-local name bindings can be used in any context, but should be avoided where regular assignment can be used, just as `lambda` should be avoided when `def` is an option. Open questions ============== 1. What happens if the name has already been used? `(x, (1 as x), x)` Currently, prior usage functions as if the named expression did not exist (following the usual lookup rules); the new name binding will shadow the other name from the point where it is evaluated until the end of the statement. Is this acceptable? Should it raise a syntax error or warning? 2. The current implementation [1] implements statement-local names using a special (and mostly-invisible) name mangling. This works perfectly inside functions (including list comprehensions), but not at top level. Is this a serious limitation? Is it confusing? 3. The interaction with locals() is currently[1] slightly buggy. Should statement-local names appear in locals() while they are active (and shadow any other names from the same function), or should they simply not appear? 4. Syntactic confusion in `except` statements. While technically unambiguous, it is potentially confusing to humans. In Python 3.7, parenthesizing `except (Exception as e):` is illegal, and there is no reason to capture the exception type (as opposed to the exception instance, as is done by the regular syntax). Should this be made outright illegal, to prevent confusion? Can it be left to linters? 5. Similar confusion in `with` statements, with the difference that there is good reason to capture the result of an expression, and it is also very common for `__enter__` methods to return `self`. In many cases, `with expr as name:` will do the same thing as `with (expr as name):`, adding to the confusion. References ========== .. [1] Proof of concept / reference implementation (https://github.com/Rosuav/cpython/tree/statement-local-variables) Copyright ========= This document has been placed in the public domain. .. Local Variables: mode: indented-text indent-tabs-mode: nil sentence-end-double-space: t fill-column: 70 coding: utf-8 End: [View Less]

19 88

breakpoint(): print(*args, **kwargs) before entering pdb
by Carl Bordum Hansen March 2, 2018

March 2, 2018

I played around with a newer Python build, but when using the new `breakpoint` builtin, I missed my weapon of choice: dirty print-debugging. I suggest we combine forces and make the default `sys.breakpointhook` forward *args and **kwargs to print before entering pdb. - Carl Bordum Hansen

2 1

Medium for discussion potential changes to python (was: PEP 572: Statement-Local Name Bindings)
by Alex Walters March 1, 2018

March 1, 2018

That should probably be its own thread From: Python-ideas [mailto:python-ideas-bounces+tritium-list=sdamon.com@python.org] On Behalf Of Robert Vanden Eynde Sent: Wednesday, February 28, 2018 4:48 PM Cc: python-ideas <python-ideas(a)python.org> Subject: Re: [Python-ideas] PEP 572: Statement-Local Name Bindings We are currently like a dozen of people talking about multiple sections of a single subject. Isn't it easier to talk on a forum? Am I the only one who thinks mailing list … [View More]isn't easy when lots of people talking about multiple subjects? Of course we would put the link in the mailing list so that everyone can join. A forum (or just few "issues" thread on github) is where we could have different thread in parallel, in my messages I end up with like 10 comments not all related, in a forum we could talk about everything and it would still be organized by subjects. Also, it's more interactive than email on a global list, people can talk to each other in parallel, if I want to answer about a mail that was 10 mail ago, it gets quickly messy. We could all discuss on a gist or some "Issues" thread on GitHub. 2018-02-28 22:38 GMT+01:00 Robert Vanden Eynde <robertve92(a)gmail.com <mailto:robertve92@gmail.com> >: Le 28 févr. 2018 11:43, "Chris Angelico" <rosuav(a)gmail.com <mailto:rosuav@gmail.com> > a écrit : > It's still right-to-left, which is as bad as middle-outward once you > combine it with normal left-to-right evaluation. Python has very > little of this [..] I agree [....] >> 2) talking about the implementation of thektulu in the "where =" part. > ? In the Alternate Syntax, I was talking about adding a link to the thektulu (branch where-expr) <https://github.com/thektulu/cpython/commits/where-expr> implementation as a basis of proof of concept (as you did with the other syntax). >> 3) "C problem that an equals sign in an expression can now create a name inding, rather than performing a comparison." As you agreed, with the "ch with ch = getch()" syntax we won't accidentally switch a "==" for a "=". I agree this syntax : ``` while (ch with ch = getch()): ... ``` doesn't read very well, but in the same way as in C or Java while(ch = getch()){} or worse ((ch = getch()) != null) syntax. Your syntax "while (getch() as ch):" may have a less words, but is still not clearer. As we spoke on Github, having this syntax in a while is only useful if the variable does leak. >> 5) Any expression vs "post for" only > I don't know what the benefit is here, but sure. As long as the > grammar is unambiguous, I don't see any particular reason to reject > this. I would like to see a discussion of pros and cons, some might think like me or disagree, that's a strong langage question. > 6) with your syntax, how does the simple case work (y+2 with y = x+1) ? What simple case? The case where you only use the variable once? I'd write it like this: (x + 1) + 2 >> The issue is not only about reusing variable. > If you aren't using the variable multiple times, there's no point > giving it a name. Unless I'm missing something here? Yes, variables are not there "just because we reuse them", but also to include temporary variables to better understand the code. Same for functions, you could inline functions when used only once, but you introduce them for clarity no ? ``` a = v ** 2 / R # the acceleration in a circular motion f = m * a # law of Newton ``` could be written as ``` f = m * (v ** 2 / R) # compute the force, trivial ``` But having temporary variables help a lot to understand the code, otherwise why would we create temporary variables ? I can give you an example where you do a process and each time the variable is used only one. >> 8) >> (lambda y: [y, y])(x+1) >> Vs >> (lambda y: [y, y])(y=x+1) Ewww. Remind me what the benefit is of writing the variable name that many times? "Explicit" doesn't mean "utterly verbose". Yep it's verbose, lambdas are verbose, that's why we created this PEP isn't it :) > 10) Chaining, in the case of the "with =", in thektulu, parenthesis were > mandatory: > > print((z+3 with z = y+2) with y = x+2) > > What happens when the parenthesis are dropped ? > > print(z+3 with y = x+2 with z = y+2) > > Vs > > print(z+3 with y = x+2 with z = y+2) > > I prefer the first one be cause it's in the same order as the "post for" > > [z + 3 for y in [ x+2 ] for z in [ y+2 ]] > With my proposal, the parens are simply mandatory. Extending this to > make them optional can come later. Indeed, but that's still questions that can be asked. >> 11) Scoping, in the case of the "with =" syntax, I think the parenthesis >> introduce a scope : >> >> print(y + (y+1 where y = 2)) >> >> Would raise a SyntaxError, it's probably better for the variable beeing >> local and not in the current function (that would be a mess). >> >> Remember that in list comp, the variable is not leaked : >> >> x = 5 >> stuff = [y+2 for y in [x+1] >> print(y) # SyntaxError > Scoping is a fundamental part of both my proposal and the others I've > seen here. (BTW, that would be a NameError, not a SyntaxError; it's > perfectly legal to ask for the name 'y', it just hasn't been given any > value.) By my definition, the variable is locked to the statement that > created it, even if that's a compound statement. By the definition of > a "(expr given var = expr)" proposal, it would be locked to that > single expression. Confer the discussion on scoping on github (https://github.com/python/peps/commit/2b4ca20963a24cf5faac054226857ea970547…) : """ In the current implementation it looks like it is like a regular assignment (function local then). Therefore in the expression usage, the usefulness would be debatable (just assign before). But in a list comprehension after the for (as I mentioned in my mail), aka. when used as a replacement for for y in [ x + 1 ] this would make sense. But I think that it would be much better to have a local scope, in the parenthesis. So that print(y+2 where y = x + 1) wouldn't leak y. And when there are no parenthesis like in a = y+2 where y = x+1, it would imply one, giving the same effect as a = (y+2 where y = x+1). Moreover, it would naturally shadow variables in the outermost scope. This would imply while data where data = sock.read(): does not leak data but as a comparison with C and Java, the syntax while((data = sock.read()) != null) is really really ugly and confusing. """ [View Less]

5 7

Upgrading python-ideas to MM3?
by Nick Coghlan March 1, 2018

March 1, 2018

Hi folks, A number of smaller python.org mailing lists have been successfully migrated to the PSF's Mailman 3 infrastructure, for example, the core-workflow mailing list: https://mail.python.org/mm3/archives/list/core-workflow@python.org/ The biggest practical gain from the upgrade is to allow folks that prefer a more forum-like experience to use the native web gateway rather than subscribing to the list. (Although it does come with some general account management improvements as well, since … [View More]

4 8