Re: Conditional iteration

By the way,

I think by approving

a = b if condition else c

used to avloind

if condition:
a = b
else:
a = c

which is dealing with same psychological problem, Guido also recognizes some
need...

Is it redundant according to your criteria, yes I would say:

a = {True: a, False: c}[condition]

or

a = [c, a][condition]

would yield exactly the same even in one sentence....

Cheers,

@


at wrote:

My comments below.

Kind regards,
@


Carl Banks wrote:

at wrote:
Well, all I can say that for me as a user it would make sense...

Which is, like, step one out of a hundred for getting a syntax change
into the language.

Curiosity: in what sense is it redundant?

It creates syntactical support for two different ways to do something.
If your plan were adopted, then we'd have two different spellings for
the same thing:

for i in a:
if i != 0:
use(i)

for i in a if i != 0:
use(i)

With the current Python syntax, I can create for every two lines of code a
dozen alternative implementations:

# example 1
a = {}
a['b'] = 'c'

versus:
a = {'b': 'c'}


# example 2
l = []
for l in some_list:
if some_condition:
l.append(l)

versus:
l = []
for x in some_list:
if some_condition:
l = l + [x]

or:
l = [x for x in some_list if some_condition]

(the beautiful one)

So your argument doesn't mean much I would say!


Now, redundant syntax isn't a deal breaker by itself. You have to ask
what is buys you. In this case, all it does is save you a single level
of indentation--that's it. There's no performance benefit. It doesn't
simplify logic. It doesn't make the code any more readable of clear.
It's only a minor improvement in conciseness. It hardly saves any
typing (unless you indent by hand). Even its one clear benefit, saving
indentation, is something you can already get with "if not x:
continue".


Well there is a clear performance benefit, or more precisely a
productivity benefit. And -please- do not underestimate this for a
language like Python, which has many supporters due to its perceived and
high productivity and challenged on this point by languages like Ruby.

'for x in some_list if some_condition:'

is psychological very strong, because the brain will most likely treat the
in the same way as :

for every apple in the fruitbasket take one if green


Basically upon reading this first line you know exactly to what list of
items your next section of code applies.

But again everything is a matter of taste and I assume that's why the
change control body is put into the hand of one person.



Considering how little this syntax change buys, it really doesn't make
a lot of sense for a language that places high emphasis on avoiding
redundancy.


All solution/workarounds I have seen so far involve creation of new
lists (subsets) adding to more processing/computation/memory usage.
Redundant suggests that you know alternatives that don't do that.

Does Guido ever change his mind?

Yes, but I guarantee "it makes sense for me" isn't going to convince
him. By the way, I'd suggest when posting to comp.lang.python and/or
python-list in the future, you put your replies beneath the quoted text
for the benefit of any future readers (not to mention present readers).

I hope this this thread will support the "it makes sense for me" with
arguments. Again it is not my intention to fight windmills, but to see if
there are strong arguments against it on one hand and if there supporters
on the other hand.



Carl Banks

.

Relevant Pages

  • Re: Does Python really follow its philosophy of "Readability counts"?
    ... with enforcing that "shouldn't" in the language itself? ... In Python, direct access to pointers is a MUST NOT. ... where you are allowed to mess with the implementation. ... human assembly language programmers? ...
    (comp.lang.python)
  • Re: Python for Fortran programmers
    ... proposition for Python in the Fortran community", ... compiled language such as Fortran or C++, but I would still prefer to ... greater number of programming errors that are typically detected by a ...
    (comp.lang.fortran)
  • Re: Basic inheritance question
    ... used 'this' in C++ and Java. ... but in Python it doesn't. ... language, they would write a lot of ten liners that is changed a LOT ... Add three levels of inheritence and a couple globals and you'll find out ...
    (comp.lang.python)
  • Re: Is there a "Large Scale Python Software Design" ?
    ... around 20 developers, assuming colocation... ... situation with Python, yet, only with Fortran, C, C++. ... It sure beats "retrofitting" unit tests post facto. ... Jones' estimates for Java's language level; ...
    (comp.lang.python)
  • Re: About alternatives to Matlab
    ... Python will almost certainly be notably slower than moderately ... the powerful and flexible Python language. ... particularly that an OCaml user can easily switch back and forth ... The knowledge is there for the compiler to use but I don't believe any of ...
    (comp.lang.python)
Loading