-0 unless archived appropriately. List is the standard for decades. but I guess things change and I get old.
On Wed, Feb 28, 2018, 13:49 Robert Vanden Eynde <robertv...@gmail.com> wrote: > 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 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 <robertv...@gmail.com>: > >> Le 28 févr. 2018 11:43, "Chris Angelico" <ros...@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/2b4ca20963a24cf5faac054226857ea9705471e5) >> : >> >> """ >> 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. >> """ >> > > _______________________________________________ > Python-ideas mailing list > Python-ideas@python.org > https://mail.python.org/mailman/listinfo/python-ideas > Code of Conduct: http://python.org/psf/codeofconduct/ >
_______________________________________________ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/
