We are currently like a dozen of people talking about multiple sections of a single subject.We could all discuss on a gist or some "Issues" thread on GitHub.
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._______________________________________________2018-02-28 22:38 GMT+01:00 Robert Vanden Eynde <robertve92@gmail.com>:I agree this syntax :Le 28 févr. 2018 11:43, "Chris Angelico" <rosuav@gmail.com> a écrit :As you agreed, with the "ch with ch = getch()" syntax we won't accidentally switch a "==" for a "=".
> 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)
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."
```
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 motionf = 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) :
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/
"""
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 ina = y+2 where y = x+1, it would imply one, giving the same effect asa = (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 leakdatabut as a comparison with C and Java, the syntax while((data = sock.read()) != null) is really really ugly and confusing.