Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.python > #46405 > unrolled thread

Re: How clean/elegant is Python's syntax?

Back to article view | Back to comp.lang.python

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  Re: How clean/elegant is Python's syntax? Ma Xiaojun <damage3025@gmail.com> - 2013-05-30 02:37 +0800
    Re: How clean/elegant is Python's syntax? Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2013-05-30 06:18 +0000
      Re: How clean/elegant is Python's syntax? Ma Xiaojun <damage3025@gmail.com> - 2013-05-30 16:54 +0800
        Re: How clean/elegant is Python's syntax? rusi <rustompmody@gmail.com> - 2013-05-30 10:12 -0700
          Re: How clean/elegant is Python's syntax? Chris Angelico <rosuav@gmail.com> - 2013-05-31 03:28 +1000
            Re: How clean/elegant is Python's syntax? rusi <rustompmody@gmail.com> - 2013-05-30 10:59 -0700
              Re: How clean/elegant is Python's syntax? Chris Angelico <rosuav@gmail.com> - 2013-05-31 04:22 +1000
          Re: How clean/elegant is Python's syntax? Ma Xiaojun <damage3025@gmail.com> - 2013-05-31 01:46 +0800
          Re: How clean/elegant is Python's syntax? Chris Angelico <rosuav@gmail.com> - 2013-05-31 03:50 +1000
          Re: How clean/elegant is Python's syntax? Ma Xiaojun <damage3025@gmail.com> - 2013-05-31 01:50 +0800
          Re: How clean/elegant is Python's syntax? Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2013-05-30 19:36 +0000
      Re: How clean/elegant is Python's syntax? Michael Torrie <torriem@gmail.com> - 2013-05-30 17:30 -0600

#46405 — Re: How clean/elegant is Python's syntax?

A bit more context.

If visiting z.cn (Amazon China), one can see that there are plenty of
new (published in 2010 or later) books on QBASIC, Visual Basic, Visual
Foxpro.

This is weird, if one want to do development legally these tools won't
be a option for new programmers.

However, I also like to know whether there are any technical arguments
that Python is superior in the context of education.

For pure procedural paradigm, I haven't seen much advantages of Python.
Yes, Python has true OOP but I don't like this argument since I don't
like Java-ism true OOP.
Yes, Python has much more libraries. But it seems that Python is more
useful and suitable in CLI and Web applications. People are still
discussing whether to replace tkinter with wxPython or not. VB and VFP
people are never bothered with such issue.

[toc] | [next] | [standalone]

#46437

On Thu, 30 May 2013 02:37:35 +0800, Ma Xiaojun wrote:


> For pure procedural paradigm, I haven't seen much advantages of Python.

Nice syntax with a minimum of boiler plate -- "executable pseudo-code", 
as they say. Extensive library support -- "batteries included". These are 
both good advantages.


> Yes, Python has true OOP but I don't like this argument since I don't
> like Java-ism true OOP.

Java is not the best example of OOP. In some ways, it is a terrible 
example of OOP: some values are not objects, classes are not first-class 
values, and the language is horribly verbose. There are good reasons for 
some of these things, but good reasons or bad, Java is *not* the exemplar 
of OOP that some Java coders believe.

In some ways, Python is a more pure OOP language than Java: everything in 
Python is an object, including classes themselves.

In other ways, Python is a less pure and more practical language. You 
don't have to wrap every piece of functionality in a class. Python 
encourages you to write mixed procedural, functional and object oriented 
code, whatever is best for the problem you are trying to solve, which is 
very much in contrast to Java:

http://steve-yegge.blogspot.com.au/2006/03/execution-in-kingdom-of-
nouns.html


> Yes, Python has much more libraries. But it seems that Python is more
> useful and suitable in CLI and Web applications. 

That is fair. All languages have their strengths and weaknesses. I 
wouldn't use Python to program low-level device driver code, and I 
wouldn't write a web-app in C.


> People are still
> discussing whether to replace tkinter with wxPython or not. VB and VFP
> people are never bothered with such issue.

Which people? "People" can discuss any rubbish they like. For many 
reasons, tkinter will not be replaced. For the standard library, it is a 
good, stable, powerful but not cutting-edge GUI library. If you don't 
like it, you can install a third-party framework like wxPython. Using 
tkinter is not compulsory.

In the case of VB and VFP, they aren't bothered by such issues because 
they're used to closed-source, proprietary programming where you use what 
you are given and like it. In the open-source world, if you don't like 
what you are given, you find something else, and if you can't find it, 
you make it yourself.



-- 
Steven

[toc] | [prev] | [next] | [standalone]

#46444

On Thu, May 30, 2013 at 2:18 PM, Steven D'Aprano
<steve+comp.lang.python@pearwood.info> wrote:
> Which people? "People" can discuss any rubbish they like. For many
> reasons, tkinter will not be replaced. For the standard library, it is a
> good, stable, powerful but not cutting-edge GUI library. If you don't
> like it, you can install a third-party framework like wxPython. Using
> tkinter is not compulsory.

I'm new to tkinter and find tkdocs.com seems quite good.
But tkdocs.com's Python code sample is in Python 3.
And wxPython doesn't support Python 3 yet.
( May not be big issue but it's kind of bad. )

I observation about tkinter is that it seems lack of sophisticated features.
For example, there is nothing like DataWindow in PowerBuilder?

Python's IDLE is written in tkinter.
But anyone willing to use IDLE is a successful example of tkinter?
I actually use Gedit more than PyDev, etc.
But the non-fancy state of IDLE does reflect something, I guess.

> In the case of VB and VFP, they aren't bothered by such issues because
> they're used to closed-source, proprietary programming where you use what
> you are given and like it. In the open-source world, if you don't like
> what you are given, you find something else, and if you can't find it,
> you make it yourself.

I doesn't mean that choices are bad. I just kind of doubt that whether
Python with a open source GUI toolkit can cover the features provided
by VB standard controls and some external Windows built-in controls.
I'm almost sure that tkinter lacks the features provided by
sophisticated controls.
I have limited knowledge to VFP.

[toc] | [prev] | [next] | [standalone]

#46513

On Thu, May 30, 2013 at 9:34 AM, Ma Xiaojun <damage3025@gmail.com>
wrote:
>
> On Thu, May 30, 2013 at 10:49 AM, rusi <rustompmody@gmail.com> wrote:
> > Ha,Ha! The join method is one of the (for me) ugly features of python.
> > You can sweep it under the carpet with a one-line join function and
> > then write clean and pretty code:
> >
> > #joinwith
> > def joinw(l,sep): return sep.join(l)
> >
> > def mktable(m,n):
> >     return [[(j,i,i*j) for i in range(1,m+1)] for j in range(1,n+1)]
> >
> > def prettyrow(r):
> >     return joinw(['%d*%d=%d' % ele for ele in r],'\t')
> >
> > def prettytable(t):
> >     return joinw([prettyrow(r) for r in t],'\n')
>
> Wait a minute! Isn't the most nature way of doing/thinking "generating
> 9x9 multiplication table" two nested loop?

Thats like saying that the most natur(al) way of using a car is to
attach a horse to it.
Sure if all you've seen are horse-carriages then a horseless carriage
will seem nonsensical.  Once you get used to horseless carriages the
horsed ones would seem quite a nuisance [global warming aside!!]

The only problem with this analogy is that you have to imagine the
world of horse/horseless 'cars' in 1900 and not 2013.

Likewise in the world of programming, 90% of programmers think
imperative/OO programming is natural while functional programming is
strange.  Just wait 10 years and see if things are not drastically
different!

>
> I understand that using "join", we don't need to worry about "one
> element doesn't need white space" issue. And that's it.

More evidence of the above!
join like list-comprehensions are tools for functional programming and
not merely ways of writing loops in short.

The key difference between the two is seen not in the code you write
but in the natural language (English) you use to describe it:

> Wait a minute! Isn't the most nature way of doing/thinking "generating
> 9x9 multiplication table" two nested loop?

You associate the primal (f)act of thinking about programming with
*doing* the generating.
By contrast the functional programmer thinks about what *is* the
result.

Please also note the difference in emphasis in your code and mine.
Rewriting to make it more obvious:

# The main multiplication table building function
def multtable(m,n):
    return [[(j,i,i*j) for i in range(1,m+1)] for j in range(1,n+1)]

# The 'icing' to get it into the shape you want
def joinw(l,sep): return sep.join(l)
def prettytable(t):
    return joinw([joinw(['%d*%d=%d' % ele for ele in r],'\t') for r in
t],'\n')

The call that puts them together:
>>> print prettytable(multtable(6,7))

The nice thing about the last is that it separates three things:
1. Computing the actual table
2. The string form of that table that looks the way we want
3. Printing that string

And I can see each of these separately:

In [2]: multtable(2,3)
Out[2]: [[(1, 1, 1), (1, 2, 2)], [(2, 1, 2), (2, 2, 4)], [(3, 1, 3),
(3, 2, 6)]]

In [3]: prettytable(_)
Out[3]: '1*1=1\t1*2=2\n2*1=2\t2*2=4\n3*1=3\t3*2=6'

In [4]: print _
1*1=1	1*2=2
2*1=2	2*2=4
3*1=3	3*2=6

-------------------
I would be pleasantly surprised if the double nested loop you think
natural, allowed for such a modular separation!

[toc] | [prev] | [next] | [standalone]

#46516

On Fri, May 31, 2013 at 3:12 AM, rusi <rustompmody@gmail.com> wrote:
> You associate the primal (f)act of thinking about programming with
> *doing* the generating.
> By contrast the functional programmer thinks about what *is* the
> result.

I wish you'd explain that to my boss :) He often has trouble
understanding why sometimes I put two syntactic statements on one
line, such as:

for (int i=0;i<nfoo;++i) if (foo[i].marker)
{
    //do something with foo[i]
}

In Python, that would probably be done with a list comprehension or
some other form of filtered iteration, and is to my mind a single
operation - "iterate over all the marked foo" is just as much a valid
loop header as "iterate over all the foo". This is a simple example,
and what you say about thinking about what *is* the result doesn't
really translate well into a C++ example, but the broader concept
applies: there's a difference between code as the compiler/interpreter
sees it and code as the programmer sees it, and there is not always a
1:1 correspondence of statements.

ChrisA

[toc] | [prev] | [next] | [standalone]

#46521

On May 30, 10:28 pm, Chris Angelico <ros...@gmail.com> wrote:
> On Fri, May 31, 2013 at 3:12 AM, rusi <rustompm...@gmail.com> wrote:
> > You associate the primal (f)act of thinking about programming with
> > *doing* the generating.
> > By contrast the functional programmer thinks about what *is* the
> > result.
>
> I wish you'd explain that to my boss :) He often has trouble
> understanding why sometimes I put two syntactic statements on one
> line, such as:
>
> for (int i=0;i<nfoo;++i) if (foo[i].marker)
> {
>     //do something with foo[i]
>
> }
>
> In Python, that would probably be done with a list comprehension or
> some other form of filtered iteration, and is to my mind a single
> operation - "iterate over all the marked foo" is just as much a valid
> loop header as "iterate over all the foo". This is a simple example,
> and what you say about thinking about what *is* the result doesn't
> really translate well into a C++ example, but the broader concept
> applies: there's a difference between code as the compiler/interpreter
> sees it and code as the programmer sees it, and there is not always a
> 1:1 correspondence of statements.
>
> ChrisA

I had a blog post about line-length in programs
http://blog.languager.org/2012/10/layout-imperative-in-functional.html

followed by an interesting discussion on the haskell mailing list
http://groups.google.com/group/haskell-cafe/browse_thread/thread/f146ec7753c5db56/09eb73b1efe79fec

The comment by Alexander Solla was insightful and is probably what you
are saying.

[Probably!! I am not sure what you are saying!]

[toc] | [prev] | [next] | [standalone]

#46524

On Fri, May 31, 2013 at 3:59 AM, rusi <rustompmody@gmail.com> wrote:
> On May 30, 10:28 pm, Chris Angelico <ros...@gmail.com> wrote:
>> On Fri, May 31, 2013 at 3:12 AM, rusi <rustompm...@gmail.com> wrote:
>> > You associate the primal (f)act of thinking about programming with
>> > *doing* the generating.
>> > By contrast the functional programmer thinks about what *is* the
>> > result.
>>
>> I wish you'd explain that to my boss :) He often has trouble
>> understanding why sometimes I put two syntactic statements on one
>> line, such as:
>>
>> for (int i=0;i<nfoo;++i) if (foo[i].marker)
>> {
>>     //do something with foo[i]
>>
>> }
>>
>> In Python, that would probably be done with a list comprehension or
>> some other form of filtered iteration, and is to my mind a single
>> operation - "iterate over all the marked foo" is just as much a valid
>> loop header as "iterate over all the foo". This is a simple example,
>> and what you say about thinking about what *is* the result doesn't
>> really translate well into a C++ example, but the broader concept
>> applies: there's a difference between code as the compiler/interpreter
>> sees it and code as the programmer sees it, and there is not always a
>> 1:1 correspondence of statements.
>>
>> ChrisA
>
> I had a blog post about line-length in programs
> http://blog.languager.org/2012/10/layout-imperative-in-functional.html
>
> followed by an interesting discussion on the haskell mailing list
> http://groups.google.com/group/haskell-cafe/browse_thread/thread/f146ec7753c5db56/09eb73b1efe79fec
>
> The comment by Alexander Solla was insightful and is probably what you
> are saying.
>
> [Probably!! I am not sure what you are saying!]

Unfortunately a lot of your code specifics don't mean much to me
because I don't speak Haskell, but you are making several similar
points. A line of code should not be defined by the language's syntax,
but by the programmer's intention. A Python example might be:

for x in filter(lambda x: x%5 and x%6,range(40)):
    # do something with the numbers that don't count by 5 or 6

Stupid example, but it still puts the conditional inside the loop
header. I'm sure you can come up with a more useful case!

ChrisA

[toc] | [prev] | [next] | [standalone]

#46518

On Fri, May 31, 2013 at 1:28 AM, Chris Angelico <rosuav@gmail.com> wrote:
> for (int i=0;i<nfoo;++i) if (foo[i].marker)
> {
>     //do something with foo[i]
> }

This is interesting!

[toc] | [prev] | [next] | [standalone]

#46519

On Fri, May 31, 2013 at 3:46 AM, Ma Xiaojun <damage3025@gmail.com> wrote:
> On Fri, May 31, 2013 at 1:28 AM, Chris Angelico <rosuav@gmail.com> wrote:
>> for (int i=0;i<nfoo;++i) if (foo[i].marker)
>> {
>>     //do something with foo[i]
>> }
>
> This is interesting!

Yeah, but that's C++. It won't work in Python without this directive:

from __future__ import braces

ChrisA

[toc] | [prev] | [next] | [standalone]

#46522

functional VS imperative?

mechanical thinking VS mathematical thinking?

Sounds interesting.

[toc] | [prev] | [next] | [standalone]

#46537

On Thu, 30 May 2013 10:12:22 -0700, rusi wrote:

> On Thu, May 30, 2013 at 9:34 AM, Ma Xiaojun <damage3025@gmail.com>
> wrote:

>> Wait a minute! Isn't the most nature way of doing/thinking "generating
>> 9x9 multiplication table" two nested loop?
> 
> Thats like saying that the most natur(al) way of using a car is to
> attach a horse to it.
>[...]
> Likewise in the world of programming, 90% of programmers think
> imperative/OO programming is natural while functional programming is
> strange.  Just wait 10 years and see if things are not drastically
> different!

It won't be. Functional programming goes back to Lisp, which is nearly as 
old as Fortran and older than Cobol. There have been many decades for 
functional languages to become mainstream, but they've never quite done 
it. There's no reason to think that the next decade will see a change to 
this.

That's not to say that functional programming isn't one of the big three 
programming paradigms. But it's third out of the three, and quite a bit 
behind the other two:

Procedural
OOP
Functional

with Logic programming a distant fourth. Well, perhaps even third, ahead 
of Functional, taking into account that SQL is a form of Logic 
programming.

Some modern Functional languages are really neat, like Haskell, but I 
think the sad truth is that to really master them (and not just make do 
with a small percentage of their functionality) is beyond 90% of 
programmers. I'm not ashamed to admit that I struggle with advanced FP 
concepts.

But even if only a minority of programmers can master languages like 
Lisp, Haskell, or Scheme, doesn't mean that *all* programmers can't learn 
something from them. Functional programming is at least 50% a philosophy:

* pass arguments to functions, and return results, rather than getting 
and setting state from a variable.

This is a good strategy: it makes it easier to reason about the code, 
easier to document, easier to test, and makes it practical to use it in 
threaded code.



-- 
Steven

[toc] | [prev] | [next] | [standalone]

#46557

On 05/30/2013 12:18 AM, Steven D'Aprano wrote:
> In some ways, Python is a more pure OOP language than Java: everything in 
> Python is an object, including classes themselves.
> 
> In other ways, Python is a less pure and more practical language. You 
> don't have to wrap every piece of functionality in a class. Python 
> encourages you to write mixed procedural, functional and object oriented 
> code, whatever is best for the problem you are trying to solve, which is 
> very much in contrast to Java.

Depending on your understanding of what object-oriented means,
procedural and functional code is still object-oriented.  In fact
modules (the "file") are in essence singleton objects that define
attributes, but in practice there can only be one instance of this
object (module).  Seems like in Java a lot of code is needed to
implement singletons (factory, etc).  module-level code (procedural
code) could simply be thought of as singleton initialization/constructor
code that's automatically run when the singleton is created, using
import or __import__().

At the function level, a simple function is still an object that
implements callable.

Python's implementation of OO isn't quite smalltalk pure, but it is much
more consistent than in Java or C++.

But yes, Python does not force you to shoe-horn your programming into
one particular pattern.

[toc] | [prev] | [standalone]

Back to top | Article view | comp.lang.python

csiph-web