> From: Brett Cannon [mailto:bac@OCF.Berkeley.EDU]
> [Delaney, Timothy]
>
> > I think the addition of this would lead to a more
> functional style of
> > programming. This may be a plus for some people, and a
> minus for others.
> >
>
> MINUS!
>
> And yes, I have done my fair share of Scheme and Lisp
> programming so this
> is not an ignorant statement. Python is not a functional
> language.
This is true - and yet I find that I program in a more 'functional' way in
Python than in any other language I use. I find that for many problems it is
natural for me to think in a functional way, and I appreciate that Python
allows me to (without imposing it on me).
In particular, I tend to produce a lot of filtering functions (whether run
through list comps, filter or just standalone) and this is one place where
this syntax would be useful. Of course, that presupposes that at least *one*
value passes the filter ... but surely a failure there would be a data error
;)
> concise code and I want to keep the LHS of the assignment simple. But
> then again that might be a bias coming from a right-handed person. =)
Nah - I'm right-handed too, but I've got nothing against the LHS.
The major point I have against it is that you would presumably have
duplication in:
a = t
*a = t
unless that were special-cased. I personally think it should be syntactially
correct if the proposal were to be accepted, but with a strong suggestion in
the documentation that it be avoided ;)
Tim Delaney
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4