What do you think about this code:

for n in range(2, 10): ... for x in range(2, n): ... if n % x == 0: ... print n, 'equals', x, '*', n/x ... break ... else: ... # loop fell through without finding a factor ... print n, 'is a prime number'

I don't like this 'for - else' trick. IMHO it's confusing and not readable.

BTW, This code is taken from the python tutorial:

http://docs.python.org/tutorial/controlflow.html#break-and-continue-statements-and-else-clauses-on-loops

Ahik

--
You received this message because you are subscribed to the Google Groups "PyWeb-IL" group.
To post to this group, send email to pyweb-il <at> googlegroups.com.
To unsubscribe from this group, send email to pyweb-il+unsubscribe <at> googlegroups.com.
For more options, visit this group at http://groups.google.com/group/pyweb-il?hl=en.

The use of assigment through left arrow (←) would solve this. Which reminds me of the fact that I would have loved having a language like python that uses more of unicode for its syntax.

Then "python" might look like:

    ∀ n ∈ names:
      if n ≠ "foo":
        α ← n
        ß = re∘search⟨"foo", α⟩

No more overloading of parens, decimal dots, minus signs, etc.

Of course it would take some time to learn how to type all these chars on the keyboard, but by some clever editors macro tricks, you would quickly get over this.

Here's another pythonic construct that imo would look nicer.

    f← λ x: x↑2
    a←f⟨2⟩

But I'm dreaming. Nobody will ever do anything as crazy as this... ☺

Cheers,
Dov

On Thu, Jul 1, 2010 at 15:28, Amit Aronovitch <aronovitch <at> gmail.com> wrote:

 

On Thu, Jul 1, 2010 at 2:48 PM, Ahik Man <ahik.man <at> gmail.com> wrote:

What do you think about this code:

for n in range(2, 10): ... for x in range(2, n): ... if n % x == 0: ... print n, 'equals', x, '*', n/x ... break ... else: ... # loop fell through without finding a factor ... print n, 'is a prime number'

I don't like this 'for - else' trick. IMHO it's confusing and not readable.

‎I really like this (very natural) programmatial construct.
I use it all the time, and feel handicapped in languages such as C, where you have to define an extra boolean flag and manually set/check it to achieve the same result.

  As for the choice of keywords, it is not that bad (maybe just got used to it after years of usage), but I agree the semantics might not be obvious to unaware readers. Certainly not up to Python's praised readability standards.

  Personally, I don't like the choice of '=' as the syntactical marker for name-binding. It makes people think it is an operator, and expect c-like semantics. Source of endless bugs for newbies and repeated misunderstandings in mailing lists.

 Well, the advantage of having a BDFL is that someone is in charge of making such choices and we do not have to argue about this any more. Only other option is to try to keep everyone happy by supporting several versions of the syntax (works fine in Perl, but takes its toll in readability and/or learning-curve).

   AA

_______________________________________________
Python-il mailing list
Python-il <at> hamakor.org.il
http://hamakor.org.il/cgi-bin/mailman/listinfo/python-il

_______________________________________________
Python-il mailing list
Python-il <at> hamakor.org.il
http://hamakor.org.il/cgi-bin/mailman/listinfo/python-il