Re: How clean/elegant is Python's syntax?
On Friday, May 31, 2013 at 1:06:29 AM UTC+5:30, Steven D'Aprano wrote: > On Thu, 30 May 2013 10:12:22 -0700, rusi wrote: > > > On Thu, May 30, 2013 at 9:34 AM, Ma Xiaojun 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. Interesting point... With interesting (counter)examples: http://blog.languager.org/2016/01/how-long.html [With apologies for necroposting] -- https://mail.python.org/mailman/listinfo/python-list
Re: How clean/elegant is Python's syntax?
On Thu, 30 May 2013 20:38:40 +0100, MRAB wrote: On 30/05/2013 19:44, Chris Angelico wrote: On Fri, May 31, 2013 at 4:36 AM, Ian Kelly ian.g.ke...@gmail.com wrote: On Wed, May 29, 2013 at 8:49 PM, rusi rustompm...@gmail.com wrote: On May 30, 6:14 am, Ma Xiaojun damage3...@gmail.com wrote: What interest me is a one liner: print '\n'.join(['\t'.join(['%d*%d=%d' % (j,i,i*j) for i in range(1,10)]) for j in range(1,10)]) 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) I don't object to changing the join method (one of the more shoe-horned string methods) back into a function, but to my eyes you've got the arguments backward. It should be: def join(sep, iterable): return sep.join(iterable) Trouble is, it makes some sense either way. I often put the larger argument first - for instance, I would write 123412341324*5 rather than the other way around - and in this instance, it hardly seems as clear-cut as you imply. But the function can't be written to take them in either order, because strings are iterable too. (And functions that take args either way around aren't better than those that make a decision.) And additional argument (pun not intended) for putting sep second is that you can give it a default value: def join(iterable, sep=): return sep.join(iterable) I think that is the winning argument. Next question is what should be the default (, or',')? -- Nasrudin walked into a teahouse and declaimed, The moon is more useful than the sun. Why?, he was asked. Because at night we need the light more. -- http://mail.python.org/mailman/listinfo/python-list
Re: How clean/elegant is Python's syntax?
On Fri, May 31, 2013 at 10:08 AM, Alister alister.w...@ntlworld.com wrote: I think that is the winning argument. Next question is what should be the default (, or',')? join, comma_join, whitejoin, linejoin variants, with different defaults? -- Fábio Santos -- http://mail.python.org/mailman/listinfo/python-list
Re: How clean/elegant is Python's syntax?
On May 31, 2:08 pm, Alister alister.w...@ntlworld.com wrote: On Thu, 30 May 2013 20:38:40 +0100, MRAB wrote: And additional argument (pun not intended) for putting sep second is that you can give it a default value: def join(iterable, sep=): return sep.join(iterable) I think that is the winning argument. Yes Next question is what should be the default (, or',')? Hmm... Never thought there was any choice here except . Yes can see the case for each. -- http://mail.python.org/mailman/listinfo/python-list
Re: How clean/elegant is Python's syntax?
On Fri, 31 May 2013 03:27:52 -0700, rusi wrote: On May 31, 2:08 pm, Alister alister.w...@ntlworld.com wrote: On Thu, 30 May 2013 20:38:40 +0100, MRAB wrote: And additional argument (pun not intended) for putting sep second is that you can give it a default value: def join(iterable, sep=): return sep.join(iterable) I think that is the winning argument. Yes Next question is what should be the default (, or',')? Hmm... Never thought there was any choice here except . Yes can see the case for each. to be fair is probably the most sensible although in my programs most joins are using ',' -- We are governed not by armies and police but by ideas. -- Mona Caird, 1892 -- http://mail.python.org/mailman/listinfo/python-list
Re: How clean/elegant is Python's syntax?
On Thu, May 30, 2013 at 1:38 PM, MRAB pyt...@mrabarnett.plus.com wrote: And additional argument (pun not intended) for putting sep second is that you can give it a default value: def join(iterable, sep=): return sep.join(iterable) One argument against the default is that it is specific to the str type. If you then tried to use join with an iterable of bytes objects and the default sep argument, you would get a TypeError. At least not having the default forces you to be explicit about which string type you're joining. -- http://mail.python.org/mailman/listinfo/python-list
Re: How clean/elegant is Python's syntax?
On Fri, May 31, 2013 at 4:16 AM, Fábio Santos fabiosantos...@gmail.com wrote: On Fri, May 31, 2013 at 10:08 AM, Alister alister.w...@ntlworld.com wrote: I think that is the winning argument. Next question is what should be the default (, or',')? join, comma_join, whitejoin, linejoin variants, with different defaults? The more specific versions should not even have the parameter as an argument that can be supplied. Otherwise you could do: comma_join(words, sep=';') which is just unclear, and there is no reason to allow it. -- http://mail.python.org/mailman/listinfo/python-list
Re: How clean/elegant is Python's syntax?
On Sat, Jun 1, 2013 at 1:43 AM, Ian Kelly ian.g.ke...@gmail.com wrote: On Thu, May 30, 2013 at 1:38 PM, MRAB pyt...@mrabarnett.plus.com wrote: And additional argument (pun not intended) for putting sep second is that you can give it a default value: def join(iterable, sep=): return sep.join(iterable) One argument against the default is that it is specific to the str type. If you then tried to use join with an iterable of bytes objects and the default sep argument, you would get a TypeError. At least not having the default forces you to be explicit about which string type you're joining. What about: def join(iterable, sep=None): if sep is not None: return sep.join(iterable) iterable=iter(iterable) first = next(iterable) return first + type(first)().join(iterable) Granted, it has some odd error messages if you pass it stuff that isn't strings: join([[1,2,3],[4,5,6]]) Traceback (most recent call last): File pyshell#241, line 1, in module join([[1,2,3],[4,5,6]]) File pyshell#235, line 5, in join return first + type(first)().join(iterable) AttributeError: 'list' object has no attribute 'join' but you'd get that sort of thing anyway. (NOTE: I am *not* advocating this. I just see it as a solution to one particular objection.) ChrisA -- http://mail.python.org/mailman/listinfo/python-list
Re: How clean/elegant is Python's syntax?
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 -- http://mail.python.org/mailman/listinfo/python-list
Re: How clean/elegant is Python's syntax?
On Thu, May 30, 2013 at 2:18 PM, Steven D'Aprano steve+comp.lang.pyt...@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. -- http://mail.python.org/mailman/listinfo/python-list
Re: How clean/elegant is Python's syntax?
On Thu, May 30, 2013 at 9:34 AM, Ma Xiaojun damage3...@gmail.com wrote: On Thu, May 30, 2013 at 10:49 AM, rusi rustompm...@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! -- http://mail.python.org/mailman/listinfo/python-list
Re: How clean/elegant is Python's syntax?
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;infoo;++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
--
http://mail.python.org/mailman/listinfo/python-list
Re: How clean/elegant is Python's syntax?
On Fri, May 31, 2013 at 1:28 AM, Chris Angelico ros...@gmail.com wrote:
for (int i=0;infoo;++i) if (foo[i].marker)
{
//do something with foo[i]
}
This is interesting!
--
http://mail.python.org/mailman/listinfo/python-list
Re: How clean/elegant is Python's syntax?
On Fri, May 31, 2013 at 3:46 AM, Ma Xiaojun damage3...@gmail.com wrote:
On Fri, May 31, 2013 at 1:28 AM, Chris Angelico ros...@gmail.com wrote:
for (int i=0;infoo;++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
--
http://mail.python.org/mailman/listinfo/python-list
Re: How clean/elegant is Python's syntax?
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;infoo;++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!]
--
http://mail.python.org/mailman/listinfo/python-list
Re: How clean/elegant is Python's syntax?
functional VS imperative? mechanical thinking VS mathematical thinking? Sounds interesting. -- http://mail.python.org/mailman/listinfo/python-list
Re: How clean/elegant is Python's syntax?
On Fri, May 31, 2013 at 3:59 AM, rusi rustompm...@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;infoo;++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
--
http://mail.python.org/mailman/listinfo/python-list
Re: How clean/elegant is Python's syntax?
On Wed, May 29, 2013 at 8:49 PM, rusi rustompm...@gmail.com wrote: On May 30, 6:14 am, Ma Xiaojun damage3...@gmail.com wrote: What interest me is a one liner: print '\n'.join(['\t'.join(['%d*%d=%d' % (j,i,i*j) for i in range(1,10)]) for j in range(1,10)]) 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) I don't object to changing the join method (one of the more shoe-horned string methods) back into a function, but to my eyes you've got the arguments backward. It should be: def join(sep, iterable): return sep.join(iterable) Putting the separator first feels more natural to me because I expect the separator to usually be short as compared to the iterable, which is often a longer expression (as is the case in both of your subsequent usages). Placing the separator first also preserves consistency of interface with the str.join and bytes.join functions, as well as the older string.join function. -- http://mail.python.org/mailman/listinfo/python-list
Re: How clean/elegant is Python's syntax?
On Fri, May 31, 2013 at 4:36 AM, Ian Kelly ian.g.ke...@gmail.com wrote: On Wed, May 29, 2013 at 8:49 PM, rusi rustompm...@gmail.com wrote: On May 30, 6:14 am, Ma Xiaojun damage3...@gmail.com wrote: What interest me is a one liner: print '\n'.join(['\t'.join(['%d*%d=%d' % (j,i,i*j) for i in range(1,10)]) for j in range(1,10)]) 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) I don't object to changing the join method (one of the more shoe-horned string methods) back into a function, but to my eyes you've got the arguments backward. It should be: def join(sep, iterable): return sep.join(iterable) Trouble is, it makes some sense either way. I often put the larger argument first - for instance, I would write 123412341324*5 rather than the other way around - and in this instance, it hardly seems as clear-cut as you imply. But the function can't be written to take them in either order, because strings are iterable too. (And functions that take args either way around aren't better than those that make a decision.) ChrisA -- http://mail.python.org/mailman/listinfo/python-list
Re: How clean/elegant is Python's syntax?
On May 30, 11:36 pm, Ian Kelly ian.g.ke...@gmail.com wrote: On Wed, May 29, 2013 at 8:49 PM, rusi rustompm...@gmail.com wrote: On May 30, 6:14 am, Ma Xiaojun damage3...@gmail.com wrote: What interest me is a one liner: print '\n'.join(['\t'.join(['%d*%d=%d' % (j,i,i*j) for i in range(1,10)]) for j in range(1,10)]) 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) I don't object to changing the join method (one of the more shoe-horned string methods) back into a function, but to my eyes you've got the arguments backward. It should be: def join(sep, iterable): return sep.join(iterable) Putting the separator first feels more natural to me because I expect the separator to usually be short as compared to the iterable, which is often a longer expression (as is the case in both of your subsequent usages). Placing the separator first also preserves consistency of interface with the str.join and bytes.join functions, as well as the older string.join function. This is a subjective view of course... My problem is not method vs function but the order. Ive seen/used join dozens of times. Yet I find .join([apple,bear,cat]) backkwards as compared to [apple,bear,cat].join() The consistency is a separate question -- not arguing about that. Just that I dont like the look -- http://mail.python.org/mailman/listinfo/python-list
Re: How clean/elegant is Python's syntax?
On Thu, May 30, 2013 at 12:44 PM, Chris Angelico ros...@gmail.com wrote: On Fri, May 31, 2013 at 4:36 AM, Ian Kelly ian.g.ke...@gmail.com wrote: I don't object to changing the join method (one of the more shoe-horned string methods) back into a function, but to my eyes you've got the arguments backward. It should be: def join(sep, iterable): return sep.join(iterable) Trouble is, it makes some sense either way. I often put the larger argument first - for instance, I would write 123412341324*5 rather than the other way around - and in this instance, it hardly seems as clear-cut as you imply. But the function can't be written to take them in either order, because strings are iterable too. (And functions that take args either way around aren't better than those that make a decision.) The reason I like having the shorter argument first (at least for function calls) is for when I'm reading the code. If I'm interested in the second argument, then to find it I have to scan over the first argument. I would rather scan over something short like '\n' than something longer like a list comprehension. It sounds like a trivial thing, but it really does make it easier to find where an expression starts and ends when the expression is short. -- http://mail.python.org/mailman/listinfo/python-list
Re: How clean/elegant is Python's syntax?
On 30/05/2013 19:44, Chris Angelico wrote: On Fri, May 31, 2013 at 4:36 AM, Ian Kelly ian.g.ke...@gmail.com wrote: On Wed, May 29, 2013 at 8:49 PM, rusi rustompm...@gmail.com wrote: On May 30, 6:14 am, Ma Xiaojun damage3...@gmail.com wrote: What interest me is a one liner: print '\n'.join(['\t'.join(['%d*%d=%d' % (j,i,i*j) for i in range(1,10)]) for j in range(1,10)]) 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) I don't object to changing the join method (one of the more shoe-horned string methods) back into a function, but to my eyes you've got the arguments backward. It should be: def join(sep, iterable): return sep.join(iterable) Trouble is, it makes some sense either way. I often put the larger argument first - for instance, I would write 123412341324*5 rather than the other way around - and in this instance, it hardly seems as clear-cut as you imply. But the function can't be written to take them in either order, because strings are iterable too. (And functions that take args either way around aren't better than those that make a decision.) And additional argument (pun not intended) for putting sep second is that you can give it a default value: def join(iterable, sep=): return sep.join(iterable) -- http://mail.python.org/mailman/listinfo/python-list
Re: How clean/elegant is Python's syntax?
On Thu, 30 May 2013 10:12:22 -0700, rusi wrote: On Thu, May 30, 2013 at 9:34 AM, Ma Xiaojun damage3...@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 -- http://mail.python.org/mailman/listinfo/python-list
Re: How clean/elegant is Python's syntax?
On Fri, May 31, 2013 at 4:51 AM, Ian Kelly ian.g.ke...@gmail.com wrote: On Thu, May 30, 2013 at 12:44 PM, Chris Angelico ros...@gmail.com wrote: On Fri, May 31, 2013 at 4:36 AM, Ian Kelly ian.g.ke...@gmail.com wrote: I don't object to changing the join method (one of the more shoe-horned string methods) back into a function, but to my eyes you've got the arguments backward. It should be: def join(sep, iterable): return sep.join(iterable) Trouble is, it makes some sense either way. I often put the larger argument first - for instance, I would write 123412341324*5 rather than the other way around - and in this instance, it hardly seems as clear-cut as you imply. But the function can't be written to take them in either order, because strings are iterable too. (And functions that take args either way around aren't better than those that make a decision.) The reason I like having the shorter argument first (at least for function calls) is for when I'm reading the code. If I'm interested in the second argument, then to find it I have to scan over the first argument. I would rather scan over something short like '\n' than something longer like a list comprehension. It sounds like a trivial thing, but it really does make it easier to find where an expression starts and ends when the expression is short. Yes, I do agree with that argument. But there's more to picking argument order than simply sort by predicted length :) I'm not saying it's *wrong* to put sep first, just that it's not as clearly-and-obviously-the-one-right-way as you suggested. ChrisA -- http://mail.python.org/mailman/listinfo/python-list
Re: How clean/elegant is Python's syntax?
On Thursday, May 30, 2013 11:36:54 AM UTC-7, Ian wrote: I don't object to changing the join method (one of the more shoe-horned string methods) back into a function, but to my eyes you've got the arguments backward. It should be: def join(sep, iterable): return sep.join(iterable) Putting the separator first feels more natural to me because I expect the separator to usually be short as compared to the iterable, which is often a longer expression (as is the case in both of your subsequent usages). Placing the separator first also preserves consistency of interface with the str.join and bytes.join functions, as well as the older string.join function. That may all be true, but the join() function shown will return a sequence starting with iterable[0] (followed by sep, and then iterable[1], then sep, etc.). I find it more natural to see iterable as the first argument passed to join() for that reason. Season to taste, I guess. -- http://mail.python.org/mailman/listinfo/python-list
Re: How clean/elegant is Python's syntax?
On Wednesday, May 29, 2013 7:24:48 PM UTC-5, Dan Stromberg wrote: About the only thing I don't like is: var = 1, That binds var to a tuple (singleton) value, instead of 1. I don't understand why Python needs tuples anyway; at least not tuple literals!. I mean, i like the idea of a sequence type that is immutable as much as the next fella, however, i just hate the fact that we had to pay for this type with syntactical multiplicity only to be forever a slave to it's resulting quirkiness! Psst: Guido, i think you got screwed! (And they thought Jack was a fool for acquiring those beans!) With the demand for type literals growing all the larger as time goes on and the ASCII char set remaining static, there must be a better way! (And no folks, I'm not suggesting space cadet keyboards!) -- http://mail.python.org/mailman/listinfo/python-list
Re: How clean/elegant is Python's syntax?
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. -- http://mail.python.org/mailman/listinfo/python-list
Re: How clean/elegant is Python's syntax?
On May 31, 12:36 am, Steven D'Aprano steve +comp.lang.pyt...@pearwood.info wrote: 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. Yes that's the sense in which I am using the term. More such ideas of FP that can be used by all sorts of programmers across the board (not just FPers) is here: http://blog.languager.org/2012/10/functional-programming-lost-booty.html On Thu, 30 May 2013 10:12:22 -0700, rusi wrote: On Thu, May 30, 2013 at 9:34 AM, Ma Xiaojun damage3...@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. Depends on how you define your terms. Comprehensions and lambdas have come into python. From where? [Lambdas have even got into C++ !!] Also LINQ in C# is inspired by comprehensions Generics were not there in C# and Java early editions. Now they've been retrofitted -- Origin SML. Almost every modern language supports garbage collection. Origin Lisp Numpy is a rip-off of APL. [Ripping off is a tribute. Non- acknowledgement is sad...] TAOCP -Vol 1 is a gigantic exercise on how to do lisp without lisp. Also called Greenspun's 10th law: http://c2.com/cgi/wiki?GreenspunsTenthRuleOfProgramming 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. Yes Haskell is HARD. Gets harder with each new major addition. Which is why I suggest using Haskell core (ie minus most fancy features) as an *ideology* rather than as a *technology*. Which is what I am suggesting in my course proposal https://moocfellowship.org/submissions/the-dance-of-functional-programming-languaging-with-haskell-and-python Think with Haskell --- Code into Python Want to contribute wink? Well actually the last applies to anyone who is interested -- suggestions welcome!! -- http://mail.python.org/mailman/listinfo/python-list
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. -- http://mail.python.org/mailman/listinfo/python-list
Re: How clean/elegant is Python's syntax?
On Thu, May 30, 2013 at 4:37 AM, Ma Xiaojun damage3...@gmail.com wrote: 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. Let me put this debate in context by giving an analogous example. A while back, it was loudly proclaimed that it was far easier to write iPhone apps than Android ones, because Android apps had to worry about a variety of different screen resolutions/sizes, while iPhone ones could be certain of what they were going to get. But what this really meant was that writing for iPhone was equivalent to writing for Android on phone model XYZ, and that you could, by targeting Android, also then make your app available on a bunch of other phone models by simply dealing with the differences. Python gives you a lot more choice than VB does. With Visual BASIC, if you don't like the windowing toolkit, tough. You don't have any alternative. With Python, you can pretend it's like VB by simply picking one toolkit and ignoring all the others; it'll be exactly the same. But the benefit is that, if you decide you want one of the others, it's relatively cheap to switch. That said, though, GUIs and databasing are two of the areas where I think Python's standard library could stand to be improved a bit. There are definitely some rough edges there. ChrisA -- http://mail.python.org/mailman/listinfo/python-list
Re: How clean/elegant is Python's syntax?
On Thu, 30 May 2013 04:54:44 +1000, Chris Angelico wrote: snip GUIs and databasing are two of the areas where I think Python's standard library could stand to be improved a bit. There are definitely some rough edges there. Dunno what you mean about standard library, but I'm very happy with wxPython and psycopg2 for GUIs and databasing respectively. -- http://mail.python.org/mailman/listinfo/python-list
Re: How clean/elegant is Python's syntax?
You might try http://wiki.python.org/moin/BeginnersGuide -- MarkJ Tacoma, Washington -- http://mail.python.org/mailman/listinfo/python-list
Re: How clean/elegant is Python's syntax?
On 30May2013 02:13, Ma Xiaojun damage3...@gmail.com wrote: | For the core language, I have mixed feeling. On one hand, I find that | Python has some sweet feature that is quite useful. On the other hand, | I often find Pyhton snippets around hard to understand. I think you will find that is lack of practice. I find Python far far easier to read, even in snippet form. BUT, for years I found it obtuse because I hadn't learnt it. Now that I have, I rarely want to use other things (if Python is apt; often but not always). | I admit that I | never learned Python very formally; I've programmed in many other | languages already. Me too. Use it some more. | Code snippets in BASIC or Pascal seems quite obvious to understand | (Unless I don't understand the algorithm) . Code in BASIC is generally lower level than python; it is less expressive. Because of this, it will be more obvious in terms of being more direct. But it will be less expressive because you will often need more BASIC to do something than you would with Python. So python is usually more succinct, and therefore more more expressive: a shorter but very readable way to do the same thing. Comparison: your English is excellent. Presuming from context that you're in China, many of your compatriots do not speak fluent English (and why should they?) For those speaking English as a second language there are difficulties; English grammar I gather is very different, and it has a fine suite of irregular forms. (Let me say up front that I do not speak Chinese at all.) Anyway, would you rather converse with someone fluent, or not? I would expect you would far rather deal with a fluent English speaker or a fluent Chinese speaker than a speaker using English badly. Python code is a lot like written English. BASIC is like badly written English. Cheers, -- Cameron Simpson c...@zip.com.au Helicopters are considerably more expensive [than fixed wing aircraft], which is only right because they don't actually fly, but just beat the air into submission.- Paul Tomblin -- http://mail.python.org/mailman/listinfo/python-list
Re: How clean/elegant is Python's syntax?
On Wed, May 29, 2013 at 11:13 AM, Ma Xiaojun damage3...@gmail.com wrote: Hi, list. For the core language, I have mixed feeling. On one hand, I find that Python has some sweet feature that is quite useful. On the other hand, I often find Pyhton snippets around hard to understand. I admit that I never learned Python very formally; I've programmed in many other languages already. Code snippets in BASIC or Pascal seems quite obvious to understand (Unless I don't understand the algorithm) . I'm finding it kind of hard to imagine not finding Python's syntax and semantics pretty graceful. About the only thing I don't like is: var = 1, That binds var to a tuple (singleton) value, instead of 1. Oh, and method decorators seem much more complex than they should've been. But on the whole, python is a pretty beautiful language. It's not just another rehash of Pascal though; if that's what you want you might be better off looking elsewhere. -- http://mail.python.org/mailman/listinfo/python-list
Re: How clean/elegant is Python's syntax?
On Thu, May 30, 2013 at 8:24 AM, Dan Stromberg drsali...@gmail.com wrote: I'm finding it kind of hard to imagine not finding Python's syntax and semantics pretty graceful. About the only thing I don't like is: var = 1, That binds var to a tuple (singleton) value, instead of 1. Oh, and method decorators seem much more complex than they should've been. Yes, you touched something. IMHO, Python has far more built-in features so it looks at least complicated from time to time. For example, some people use generating 9x9 multiplication table as an programming exercise. What interest me is a one liner: print '\n'.join(['\t'.join(['%d*%d=%d' % (j,i,i*j) for i in range(1,10)]) for j in range(1,10)]) I don't like code like this. But Python at least allow such practise. But on the whole, python is a pretty beautiful language. It's not just another rehash of Pascal though; if that's what you want you might be better off looking elsewhere. That's a fair point. -- http://mail.python.org/mailman/listinfo/python-list
Re: How clean/elegant is Python's syntax?
On May 30, 6:14 am, Ma Xiaojun damage3...@gmail.com wrote: What interest me is a one liner: print '\n'.join(['\t'.join(['%d*%d=%d' % (j,i,i*j) for i in range(1,10)]) for j in range(1,10)]) 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') I don't like code like this. But Python at least allow such practise. Are you saying VB etc disallow dirty code?? Dirty code is always possible in all languages. Of course the shape and size and smell of the dirt will differ -- http://mail.python.org/mailman/listinfo/python-list
Re: How clean/elegant is Python's syntax?
On Thu, May 30, 2013 at 7:01 AM, Walter Hurry walterhu...@lavabit.com wrote: On Thu, 30 May 2013 04:54:44 +1000, Chris Angelico wrote: snip GUIs and databasing are two of the areas where I think Python's standard library could stand to be improved a bit. There are definitely some rough edges there. Dunno what you mean about standard library, but I'm very happy with wxPython and psycopg2 for GUIs and databasing respectively. They are not part of the standard library. Yes, Python is strongly enhanced by additional packages off PyPI, but that's not the same thing; if I publish a program that requires psycopg2, I can't simply say go get Python from your OS's repository or python.org, I have to also instruct people to install another package. On Debian, I can simply apt-get python-psycopg2, which I would trust to be (a) a stable build, (b) compatible with the apt-gettable python (which is 2.7.3; ditto python3-psycopg2 and python3, for 3.2.3), and (c) from an authoritative source. There's probably a way to do this for other Linuxes too, but I don't know the exact package names everywhere. And on Windows, I have no idea what the best way would be. These days, networking is considered essential. Python's standard library includes basic sockets, HTTP (client and server), etc. AFAIK Python doesn't have obscurities like DNS (obviously you can connect a socket by hostname, but you can't look up an SPF record, nor can you write a DNS server), but networking generally is considered important enough to be inbuilt. Why is databasing second-class? ChrisA -- http://mail.python.org/mailman/listinfo/python-list
Re: How clean/elegant is Python's syntax?
On Thu, May 30, 2013 at 10:24 AM, Dan Stromberg drsali...@gmail.com wrote: I'm finding it kind of hard to imagine not finding Python's syntax and semantics pretty graceful. About the only thing I don't like is: var = 1, That binds var to a tuple (singleton) value, instead of 1. I agree, and would write it as: var = (1,) for clarity. ChrisA -- http://mail.python.org/mailman/listinfo/python-list
