Re: Python -Vs- Ruby: A regexp match to the death!
On Aug 9, 8:19 am, Mike Kent mrmak...@cox.net wrote: On Aug 8, 8:43 pm, rantingrick rantingr...@gmail.com wrote: Xah, this is really you, isn't it. Come on, confess. *MOI*, How could *I* be xah. I really don't like Ruby however he gushes over it all the time. And he does not like Python that much either. We are total opposites, really. -- http://mail.python.org/mailman/listinfo/python-list
Re: Python -Vs- Ruby: A regexp match to the death!
On Aug 8, 8:15 pm, Steven D'Aprano st...@remove-this-
cybersource.com.au wrote:
On Sun, 08 Aug 2010 17:43:03 -0700, rantingrick wrote:
Ruby has what they
call a Here Doc. Besides picking the most boneheaded name for such an
object
It's standard terminology that has been around for a long time in many
different languages.
Just because something has been around around for a long time does not
necessarily mean it's was a good idea to begin with. STRAWMAN!
As you can see it is another example of tacked on functionality that was
not carefully considered before hand.
I disagree. It's an old and venerable technique, and very useful on the
rare occasion that you have lots of quotation marks in a string.
(...snip...)
Python strings have four delimiters:
(1) single quote '
(2) double quote
(3) single-quote here-doc '''
(4) double-quote here-doc
plus equivalent raw-strings of each kind.
Trying writing that as a single literal in Python without escapes. There
are work-arounds, of course, like using implicit concatenation, but
they're ugly.
Yes, with the choices we have today writing strings like you mention
is terribly asinine. And don't forget about filepaths and regexps too
with all the backslashing nonsense! However, there is a simple
solution to this mess. Python double quote strings and Python
multiline strings(that are delimited by leading and trailing
double quote triplets) should behave as they do today.
However Python 'single quote strings' and Python '''multiline
strings'''(that are delimited by leading and trailing single quote
triplets) should be raw so that they do not interpret escape
sequences. Yes i know this would break backwards compatibility *again*
but this functionality should have been made available in Py3000 since
we were already breaking it anyhow.
Why do we need both X AND '''X''' this if they do exactly the
same thing? Also why do we need both X AND 'X' if they do exactly
the same thing. A real chance to make something special was missed and
i hope one day we come to the realization that this proposed
functionality of strings (raw and normal) is sorely needed in Python.
In Ruby they decided to be more general, so you can define whatever
heredoc you need to quote whatever literal string you need. That's not
bone-headed.
The fact that Ruby has multi line strings (*ahem*... HEREDOC's) is not
at all the point i take issue with. I take issue with the boneheaded
syntax. Have you ever tried to grep Ruby heredocs? It would have been
so much easier if they had made a spec like this...
mystring = :{
blah blah blah
blahblah
blah blah blah
blah
}:
Or at least *some* static token instead of just creating something on
the fly each time now thats boneheaded!
--
http://mail.python.org/mailman/listinfo/python-list
Re: Python -Vs- Ruby: A regexp match to the death!
On Aug 8, 8:15 pm, Steven D'Aprano st...@remove-this- cybersource.com.au wrote: In Ruby they decided to be more general, so you can define whatever heredoc you need to quote whatever literal string you need. That's not bone-headed. Devils Advocate! PS: Man you're irb main was so full of cobweb i could barley see the code... haa... h... hachew!. ;-) -- http://mail.python.org/mailman/listinfo/python-list
Re: Python -Vs- Ruby: A regexp match to the death!
On Mon, 09 Aug 2010 00:29:19 -0700, rantingrick wrote: On Aug 8, 8:15 pm, Steven D'Aprano st...@remove-this- cybersource.com.au wrote: In Ruby they decided to be more general, so you can define whatever heredoc you need to quote whatever literal string you need. That's not bone-headed. Devils Advocate! PS: Man you're irb main was so full of cobweb i could barley see the code... haa... h... hachew!. ;-) irb's default prompt is a bit too verbose for my tastes, but Python allows you to customise its prompt too. You'll often see people here posting copy/pastes with a customised prompt, so obviously some people like that sort of thing. Me, my biggest gripe with the interactive interpreter is that using as a prompt clashes with as the standard quoting character in email and news, but Guido has refused to even consider changing it. And that it's quite finicky about blank lines between methods and inside functions. Makes it hard to paste code directly into the interpreter. And that pasting doesn't strip out any leading prompts. It needs a good doctest mode. -- Steven -- http://mail.python.org/mailman/listinfo/python-list
Re: Python -Vs- Ruby: A regexp match to the death!
Hi Steven, On 2010-08-09 10:21, Steven D'Aprano wrote: And that it's quite finicky about blank lines between methods and inside functions. Makes it hard to paste code directly into the interpreter. And that pasting doesn't strip out any leading prompts. It needs a good doctest mode. ipython [1] should help here: IPython 0.10 -- An enhanced Interactive Python. ? - Introduction and overview of IPython's features. %quickref - Quick reference. help - Python's own help system. object? - Details about 'object'. ?object also works, ?? prints more. In [1]: %paste? Type: Magic function Base Class: type 'instancemethod' String Form:bound method InteractiveShell.magic_paste of IPython.iplib.InteractiveShell object at 0xb740096c Namespace: IPython internal File: /usr/lib/pymodules/python2.6/IPython/Magic.py Definition: %paste(self, parameter_s='') Docstring: Allows you to paste execute a pre-formatted code block from clipboard. The text is pulled directly from the clipboard without user intervention. The block is dedented prior to execution to enable execution of method definitions. '' and '+' characters at the beginning of a line are ignored, to allow pasting directly from e-mails, diff files and doctests (the '...' continuation prompt is also stripped). The executed block is also assigned to variable named 'pasted_block' for later editing with '%edit pasted_block'. You can also pass a variable name as an argument, e.g. '%paste foo'. This assigns the pasted block to variable 'foo' as string, without dedenting or executing it (preceding and + is still stripped) '%paste -r' re-executes the block previously entered by cpaste. IPython statements (magics, shell escapes) are not supported (yet). See also cpaste: manually paste code into terminal until you mark its end. Unfortunatey, when I enter In [2]: %paste at the prompt it gives me (before I pasted anything) In [2]: %paste File string, line 1 http://pypi.python.org/pypi/ipython/0.10 ^ SyntaxError: invalid syntax So far, I couldn't find anything on the net on this. [1] http://pypi.python.org/pypi/ipython Stefan -- http://mail.python.org/mailman/listinfo/python-list
Re: Python -Vs- Ruby: A regexp match to the death!
On Aug 8, 8:43 pm, rantingrick rantingr...@gmail.com wrote: Hello folks, You all know i been forced to use Ruby and i am not happy about that. ***Blablabla cut long rant*** Xah, this is really you, isn't it. Come on, confess. -- http://mail.python.org/mailman/listinfo/python-list
Re: Python -Vs- Ruby: A regexp match to the death!
On 2010-08-09 06:42 , Stefan Schwarzer wrote: Hi Steven, On 2010-08-09 10:21, Steven D'Aprano wrote: And that it's quite finicky about blank lines between methods and inside functions. Makes it hard to paste code directly into the interpreter. And that pasting doesn't strip out any leading prompts. It needs a good doctest mode. ipython [1] should help here: IPython 0.10 -- An enhanced Interactive Python. ? - Introduction and overview of IPython's features. %quickref - Quick reference. help - Python's own help system. object? - Details about 'object'. ?object also works, ?? prints more. In [1]: %paste? Type: Magic function Base Class:type 'instancemethod' String Form:bound method InteractiveShell.magic_paste ofIPython.iplib.InteractiveShell object at 0xb740096c Namespace: IPython internal File: /usr/lib/pymodules/python2.6/IPython/Magic.py Definition: %paste(self, parameter_s='') Docstring: Allows you to paste execute a pre-formatted code block from clipboard. The text is pulled directly from the clipboard without user intervention. The block is dedented prior to execution to enable execution of method definitions. '' and '+' characters at the beginning of a line are ignored, to allow pasting directly from e-mails, diff files and doctests (the '...' continuation prompt is also stripped). The executed block is also assigned to variable named 'pasted_block' for later editing with '%edit pasted_block'. You can also pass a variable name as an argument, e.g. '%paste foo'. This assigns the pasted block to variable 'foo' as string, without dedenting or executing it (preceding and + is still stripped) '%paste -r' re-executes the block previously entered by cpaste. IPython statements (magics, shell escapes) are not supported (yet). See also cpaste: manually paste code into terminal until you mark its end. Unfortunatey, when I enter In [2]: %paste at the prompt it gives me (before I pasted anything) In [2]: %paste File string, line 1 http://pypi.python.org/pypi/ipython/0.10 ^ SyntaxError: invalid syntax Yes, that's because you had that URL in your clipboard, not Python code. What were you expecting to happen? -- Robert Kern I have come to believe that the whole world is an enigma, a harmless enigma that is made terrible by our own mad attempt to interpret it as though it had an underlying truth. -- Umberto Eco -- http://mail.python.org/mailman/listinfo/python-list
Re: Python -Vs- Ruby: A regexp match to the death!
Hi Robert, On 2010-08-09 22:23, Robert Kern wrote: On 2010-08-09 06:42 , Stefan Schwarzer wrote: Unfortunatey, when I enter In [2]: %paste at the prompt it gives me (before I pasted anything) In [2]: %paste File string, line 1 http://pypi.python.org/pypi/ipython/0.10 ^ SyntaxError: invalid syntax Yes, that's because you had that URL in your clipboard, not Python code. What were you expecting to happen? I got that traceback as soon as I typed in %paste and pressed enter, without pasting anything in the terminal. I had assumed it works like :paste in Vim, activating a kind of paste mode where everything pasted into the terminal is modified as the help text suggests. Ok, I just noticed I should have actually _read_ the help text, not just scanned it. ;-) Sorry for the confusion. Stefan -- http://mail.python.org/mailman/listinfo/python-list
Re: Python -Vs- Ruby: A regexp match to the death!
On 2010-08-09 23:43, Stefan Schwarzer wrote: I got that traceback as soon as I typed in %paste and pressed enter, without pasting anything in the terminal. I had assumed it works like :paste in Vim, activating a I meant :set paste of course. Stefan -- http://mail.python.org/mailman/listinfo/python-list
Re: Python -Vs- Ruby: A regexp match to the death!
On 9 Aug, 10:21, Steven D'Aprano st...@remove-this- cybersource.com.au wrote: And that it's quite finicky about blank lines between methods and inside functions. Makes it hard to paste code directly into the interpreter. The combination of editor, debugger and interpreter is what I miss most from Matlab. In Matlab we can have a function or script open in an editor, and use it directly from the interpreter. No need to reimport or anything: edit and invoke. It is also possible to paste data directly from the clipboard into variables in the interpreter. ipython does not have that annoying prompt. -- http://mail.python.org/mailman/listinfo/python-list
Re: Python -Vs- Ruby: A regexp match to the death!
On 8/9/10 4:43 PM, Stefan Schwarzer wrote: Hi Robert, On 2010-08-09 22:23, Robert Kern wrote: On 2010-08-09 06:42 , Stefan Schwarzer wrote: Unfortunatey, when I enter In [2]: %paste at the prompt it gives me (before I pasted anything) In [2]: %paste File string, line 1 http://pypi.python.org/pypi/ipython/0.10 ^ SyntaxError: invalid syntax Yes, that's because you had that URL in your clipboard, not Python code. What were you expecting to happen? I got that traceback as soon as I typed in %paste and pressed enter, without pasting anything in the terminal. I had assumed it works like :paste in Vim, activating a kind of paste mode where everything pasted into the terminal is modified as the help text suggests. %cpaste will do that. I implemented %paste because not all terminals will correctly paste arbitrary amounts of code correctly. Grabbing the text directly from the clipboard is less error-prone and removes redundant user interaction. -- Robert Kern I have come to believe that the whole world is an enigma, a harmless enigma that is made terrible by our own mad attempt to interpret it as though it had an underlying truth. -- Umberto Eco -- http://mail.python.org/mailman/listinfo/python-list
Re: Python -Vs- Ruby: A regexp match to the death!
rantingrick wrote:
Hello folks,
[snip]
-
Strings
-
Single line strings are exactly the same in both languages except in
Ruby double quoted strings are backslash interpreted and single quote
strings are basically raw. Except Ruby introduces more cruft (as
usual) in the form of what i call lazy man stings
a = %w{ one two three}
[one, two, three]
s = %{one two three}
one two three
repat = %r{one two three}
/one two three/
... only good for hand coding!
From Perl.
--
Multi Line Strings
--
Ha. Ruby does not really have multi line strings. Ruby has what they
call a Here Doc. Besides picking the most boneheaded name for such
an object they also introduced and even more boneheaded syntax. To
define a Here Doc (god i hate that name!) you start with double
greater than and immediately follow with an identifier token of
you choice (it can be anything your dirty little mind can come up
with.
HEREDOC
this is the body
of a
here doc. Why the
hell did they not just
use triple quotes like Python did.
Now i will need to remember some token to know where'
i stopped
HEREDOC
As you can see it is another example of tacked on functionality that
was not carefully considered before hand. Anyway here are the
regexp's...
Python: r'.*?'
Python: r'''.*?'''
Ruby: r'(\w+).*?(\1)'
Also from Perl.
I don't know what the point of your post was. We already know that we
prefer Python; that's why we're here! :-)
And anyway, being nasty about other languages feels unPythonic to me...
--
http://mail.python.org/mailman/listinfo/python-list
Re: Python -Vs- Ruby: A regexp match to the death!
On Sun, 08 Aug 2010 17:43:03 -0700, rantingrick wrote:
Ha. Ruby does not really have multi line strings.
Except, of course, it does, as you go on to show.
Ruby has what they
call a Here Doc. Besides picking the most boneheaded name for such an
object
It's standard terminology that has been around for a long time in many
different languages.
http://en.wikipedia.org/wiki/Here_document
they also introduced and even more boneheaded syntax. To define a
Here Doc (god i hate that name!) you start with double greater than
and immediately follow with an identifier token of you choice (it
can be anything your dirty little mind can come up with.
HEREDOC
this is the body
of a
here doc. Why the
hell did they not just
use triple quotes like Python did.
Now i will need to remember some token to know where' i stopped
HEREDOC
Incorrect.
[st...@sylar ~]$ irb
irb(main):001:0 s = END
SyntaxError: compile error
(irb):1: syntax error
s = END
^
from (irb):1
irb(main):002:0 s = -END
irb(main):003:0 Multi-line text
irb(main):004:0 goes here
irb(main):005:0 END
= Multi-line text\ngoes here\n
irb(main):006:0 puts s
Multi-line text
goes here
= nil
irb(main):007:0
As you can see it is another example of tacked on functionality that was
not carefully considered before hand.
I disagree. It's an old and venerable technique, and very useful on the
rare occasion that you have lots of quotation marks in a string.
Whether those rare occasions are common enough to require specialist
syntax is another question. In Python, the idea is that two heredocs ('''
and ) is enough for anybody. That makes it difficult to write a string
literal like, e.g.:
Python strings have four delimiters:
(1) single quote '
(2) double quote
(3) single-quote here-doc '''
(4) double-quote here-doc
plus equivalent raw-strings of each kind.
Trying writing that as a single literal in Python without escapes. There
are work-arounds, of course, like using implicit concatenation, but
they're ugly.
In Ruby they decided to be more general, so you can define whatever
heredoc you need to quote whatever literal string you need. That's not
bone-headed.
--
Steven
--
http://mail.python.org/mailman/listinfo/python-list
Re: Python and Ruby
On Feb 9, 10:41 pm, Jonathan Gardner jgard...@jonathangardner.net wrote: On Feb 9, 1:51 am, waku w...@idi.ntnu.no wrote: 'stupid', 'wrong', 'deficient', 'terrible', ... you're using strong words instead of concrete arguments, it might intimidate your opponents, but is hardly helpful in a fair discussion. In today's day and age, I don't know how a text editor which cannot do simple indentation can be considered anything but stupid, wrong, deficient, and terrible. There is simply no excuse for this kind of behavior on the part of the text editor. i thought we were not discussing text editors, why should you insist so much on diverting attention from the issue of a programmer being *forced* to keep perfect indentation to the issue of an editor doing autoindent or the like. I mean, how long has vi had the auto indent feature? How many decades has emacs supported the same? This isn't new technology, or difficult technology to implement. It's not even non-standard anymore. Heck, far more advanced features, such as syntax highlighting, are standard in all text editors. wow! and then, back to the issue of enforced indentation in python? Your problem is you're using something like Windows Notepad to edit your code. thin ice! you haven't got the faintest idea of what i use to edit my code, do you. Windows Notepad is a terrible tool for writing anything, let alone writing code. Why in the world would any programming language adapt itself to the mental deficiencies of Windows Notepad? I mean, if you were an artist, would you use MS Paint to do anything serious? If you did, would you complain that the art world has a problem because they don't accept your paintings? I strongly suggest you download one of the *hundreds* of free text editors available for the Windows platform that give you the indentation features you so sorely lack. I suggest ViM, though it has a steep learning curve. listen to what people say before responding, and stop showing off. again, you haven't used a single reasonable argument here. vQ -- http://mail.python.org/mailman/listinfo/python-list
Re: Python and Ruby
waku wrote: On Feb 9, 10:41 pm, Jonathan Gardner jgard...@jonathangardner.net wrote: On Feb 9, 1:51 am, waku w...@idi.ntnu.no wrote: 'stupid', 'wrong', 'deficient', 'terrible', ... you're using strong words instead of concrete arguments, it might intimidate your opponents, but is hardly helpful in a fair discussion. In today's day and age, I don't know how a text editor which cannot do simple indentation can be considered anything but stupid, wrong, deficient, and terrible. There is simply no excuse for this kind of behavior on the part of the text editor. i thought we were not discussing text editors, why should you insist so much on diverting attention from the issue of a programmer being *forced* to keep perfect indentation to the issue of an editor doing autoindent or the like. It's as sensible to complain about people being *forced* to keep perfect indentation as it is to complain about people being *forced* to use braces to delimit code blocks. This is called syntax, and it's a part of the language, so get over it - this aspect of Python has been present in the language since its inception, and it isn't going to change. regards Steve -- Steve Holden +1 571 484 6266 +1 800 494 3119 PyCon is coming! Atlanta, Feb 2010 http://us.pycon.org/ Holden Web LLC http://www.holdenweb.com/ UPCOMING EVENTS:http://holdenweb.eventbrite.com/ -- http://mail.python.org/mailman/listinfo/python-list
Re: Python and Ruby
On Wed, 10 Feb 2010 09:51:11 -0500 Steve Holden st...@holdenweb.com wrote: [snip] It's as sensible to complain about people being *forced* to keep perfect indentation as it is to complain about people being *forced* to use braces to delimit code blocks. This is called syntax, and it's a part of the language, so get over it - this aspect of Python has been present in the language since its inception, and it isn't going to change. Amen. Now everybody do a quick from __future__ import braces and get back to work. /W -- INVALID? DE! -- http://mail.python.org/mailman/listinfo/python-list
Re: Python and Ruby
On Feb 2, 10:49 pm, Jonathan Gardner jgard...@jonathangardner.net wrote: On Feb 2, 2:21 am,wakuw...@idi.ntnu.no wrote: [...] there are languages where indentation can be either enforced and allow one to omit some syntactic nuissance like braces or begin-end clauses, or made optional, requiring other syntactic means for delimiting blocks etc. (consider f# with its #light declaration, for example.) If you're writing experimental code, you're doing it wrong. Every line of code you write may end up on the space shuttle one day (so to speak!) Why not write the code well-formatted in the first place, so that any bugs you introduce are as easily visible as possible? you're missing the large part of the language's customers that use it specifically for experimenting. they're not developing space shuttles, but rather explore available data, experiment with algorithms, etc. (and for space shuttles, i doubt python is the first choice anyway.) yes, i am writing lots of experimental code, and i know many who do, too, and there is *nothing* wrong about it. and then, i sometimes use ipython to interactively experiment, saving the input to a log file, and editing it afterwards as needed. and just the mere fact that i *have* to adapt my editor to ipython's indentation policy (or vice versa) whenever working with others' code because otherwise the code fails, is fairly annoying. there is nothing wrong or stupid about the editor in this respect. The only reason why you may want to write crap code without proper formatting is because your text editor is stupid. 'proper' formatting is, in some languages, something achieved by simply running a pretty formatter. in some, it's the job of the programmer. it has nothing to do with the claimed stupidity of the editor. If that's the case, get rid of your text editor and find some tools that help you do the right thing the first time. [...] If you're text editor has a problem with indenting, you have a terrible text editor. Period, end of sentence. you're just wrong. You can't screw in bolts with a hammer, and you can't level with a saw. ... and you can't freely format you code with python. Don't try to write code in any language without a real text 'real'? meaning one able to guess how to combine code from multiple developers with different indentation policies, for example, one using tabs, another four spaces, and yet another eight? (which is not at all uncommon, and not quite wrong or stupid.) editor that can do proper indentation. Don't let your teammates use deficient text editors either. I wouldn't appreciate it if I delivered precision components that my teammates tried to install with sledgehammers. This is the 21st Century. Good text editors are not hard to find on any platform. 'stupid', 'wrong', 'deficient', 'terrible', ... you're using strong words instead of concrete arguments, it might intimidate your opponents, but is hardly helpful in a fair discussion. vQ -- http://mail.python.org/mailman/listinfo/python-list
Re: Python and Ruby
On Feb 9, 1:51 am, waku w...@idi.ntnu.no wrote: 'stupid', 'wrong', 'deficient', 'terrible', ... you're using strong words instead of concrete arguments, it might intimidate your opponents, but is hardly helpful in a fair discussion. In today's day and age, I don't know how a text editor which cannot do simple indentation can be considered anything but stupid, wrong, deficient, and terrible. There is simply no excuse for this kind of behavior on the part of the text editor. I mean, how long has vi had the auto indent feature? How many decades has emacs supported the same? This isn't new technology, or difficult technology to implement. It's not even non-standard anymore. Heck, far more advanced features, such as syntax highlighting, are standard in all text editors. Your problem is you're using something like Windows Notepad to edit your code. Windows Notepad is a terrible tool for writing anything, let alone writing code. Why in the world would any programming language adapt itself to the mental deficiencies of Windows Notepad? I mean, if you were an artist, would you use MS Paint to do anything serious? If you did, would you complain that the art world has a problem because they don't accept your paintings? I strongly suggest you download one of the *hundreds* of free text editors available for the Windows platform that give you the indentation features you so sorely lack. I suggest ViM, though it has a steep learning curve. -- http://mail.python.org/mailman/listinfo/python-list
Re: Python and Ruby
Robert Kern wrote: On 2010-02-04 14:55 PM, Jonathan Gardner wrote: On Feb 3, 3:39 pm, Steve Holdenst...@holdenweb.com wrote: Robert Kern wrote: On 2010-02-03 15:32 PM, Jonathan Gardner wrote: I can explain all of Python in an hour; I doubt anyone will understand all of Python in an hour. With all respect, talking about a subject without a reasonable chance of your audience understanding the subject afterwards is not explaining. It's just exposition. I agree. If the audience doesn't understand then you haven't explained it. On the contrary, that explanation would have everything you need. It would take an hour to read or listen to the explanation, but much more than that time to truly understand everything that was said. Like I said, that's exposition, not explanation. There is an important distinction between the two words. Simply providing information is not explanation. If it takes four hours for your audience to understand it, then you explained it in four hours no matter when you stopped talking. And if it takes six months? Would you seriously say it took you six months to explain something because it took that long for your audience to understand it? At some point you have to make the transition from person A explaining and person(s) B understanding -- they don't necessarily happen synchronously. As a real-life example, I've read several Python books, tutorials, and this list for quite some time, some of which has very good explanatory material, and yet some of the points I didn't fully comprehend until much, much later. Every time, though, it's still the same reaction: I *love* Python! :D ~Ethan~ -- http://mail.python.org/mailman/listinfo/python-list
Re: Python and Ruby
Steve Holden wrote: Jeez, Steve, you're beginning to sound like some kind of fallacy zealot... ;) Death to all those who confuse agumentum ad populum with argumentum ad verecundiam!!! Yeah, what did the zealots ever do for us? They produced Python? . . . Oh Python! Shut up! -- http://mail.python.org/mailman/listinfo/python-list
Re: Python and Ruby
On 2010-02-04 17:46 PM, Ethan Furman wrote: Robert Kern wrote: On 2010-02-04 14:55 PM, Jonathan Gardner wrote: On Feb 3, 3:39 pm, Steve Holdenst...@holdenweb.com wrote: Robert Kern wrote: On 2010-02-03 15:32 PM, Jonathan Gardner wrote: I can explain all of Python in an hour; I doubt anyone will understand all of Python in an hour. With all respect, talking about a subject without a reasonable chance of your audience understanding the subject afterwards is not explaining. It's just exposition. I agree. If the audience doesn't understand then you haven't explained it. On the contrary, that explanation would have everything you need. It would take an hour to read or listen to the explanation, but much more than that time to truly understand everything that was said. Like I said, that's exposition, not explanation. There is an important distinction between the two words. Simply providing information is not explanation. If it takes four hours for your audience to understand it, then you explained it in four hours no matter when you stopped talking. And if it takes six months? Would you seriously say it took you six months to explain something because it took that long for your audience to understand it? At some point you have to make the transition from person A explaining and person(s) B understanding -- they don't necessarily happen synchronously. Then it's exposition and understanding, not explanation and understanding. -- Robert Kern I have come to believe that the whole world is an enigma, a harmless enigma that is made terrible by our own mad attempt to interpret it as though it had an underlying truth. -- Umberto Eco -- http://mail.python.org/mailman/listinfo/python-list
Re: Python and Ruby
Robert Kern wrote: On 2010-02-04 17:46 PM, Ethan Furman wrote: Robert Kern wrote: On 2010-02-04 14:55 PM, Jonathan Gardner wrote: On Feb 3, 3:39 pm, Steve Holdenst...@holdenweb.com wrote: Robert Kern wrote: On 2010-02-03 15:32 PM, Jonathan Gardner wrote: I can explain all of Python in an hour; I doubt anyone will understand all of Python in an hour. With all respect, talking about a subject without a reasonable chance of your audience understanding the subject afterwards is not explaining. It's just exposition. I agree. If the audience doesn't understand then you haven't explained it. On the contrary, that explanation would have everything you need. It would take an hour to read or listen to the explanation, but much more than that time to truly understand everything that was said. Like I said, that's exposition, not explanation. There is an important distinction between the two words. Simply providing information is not explanation. If it takes four hours for your audience to understand it, then you explained it in four hours no matter when you stopped talking. And if it takes six months? Would you seriously say it took you six months to explain something because it took that long for your audience to understand it? At some point you have to make the transition from person A explaining and person(s) B understanding -- they don't necessarily happen synchronously. Then it's exposition and understanding, not explanation and understanding. Hmm. Well, I can see your point -- after all, if are explaining but your audience is not understanding, are you really explaining? Okay, looking in the dictionary... ex⋅plain –verb (used with object) 1. to make plain or clear; render understandable or intelligible: to explain an obscure point. 2. to make known in detail: to explain how to do something. un⋅der⋅stand –verb (used with object) 1. to perceive the meaning of; grasp the idea of; comprehend: to understand Spanish; I didn't understand your question. 2. to be thoroughly familiar with; apprehend clearly the character, nature, or subtleties of: to understand a trade. 3. to assign a meaning to; interpret: He understood her suggestion as a complaint. 4. to grasp the significance, implications, or importance of: He does not understand responsibility. For me, at least, it boils down to this feeling that understanding is not a True/False item, but more of a scale (like all the the numbers between 0.0 and 1.0 [not including 1.0 of course -- this *is* Python! ;)]). As a personal example, decorators are not that difficult to grasp -- you take your function and wrap it in another function; but what you can do with them! They are truly impressive once your understanding deepens. And at the end of the day (or this thread, whichever comes first ;) Python is awesome, and that's what counts. ~Ethan~ -- http://mail.python.org/mailman/listinfo/python-list
Re: Python and Ruby
On Feb 4, 1:03 am, John Bokma j...@castleamber.com wrote: Jonathan Gardner jgard...@jonathangardner.net writes: I can explain all of Python in an hour; OK, in that case I would say give it a go. Put it on YouTube, or write a blog post about it (or post it here). I am sure you will help a lot of people that way. Someone already did: Advanced Python or Understanding Python http://video.google.com/videoplay?docid=7760178035196894549 (76 minutes). Worth watching. Regards, -- Marius Gedminas -- http://mail.python.org/mailman/listinfo/python-list
Re: Python and Ruby
In article 7x8wb9j4r2@ruckus.brouhaha.com, Paul Rubin no.em...@nospam.invalid wrote: Lou Pecora pec...@anvil.nrl.navy.mil writes: after much noodling around and reading it hit me that I could just put all that output of different types of variables into a list, hit it with a repr() function to get a string version, and write the string to a file -- no formatting necessary-- three lines of code. Later reading in the string version (no formatting necessary), and hitting it with an eval() function returned all the values I originally had in those variables. How simple, but beautiful. FYI: I do that too sometimes, but in general using repr/eval that way is poor style and not very reliable. It's better to use the pickle module, which is intended for that sort of thing, or the json module if your datatypes are suitable and you want to follow a semi-standard. Yeah, I should look into pickle. Haven't messed with that. Most of what I do is numerical calculations for my consumption/research so quick and easy comes first. Thanks for the hint. -- -- Lou Pecora -- http://mail.python.org/mailman/listinfo/python-list
Re: Python and Ruby
Marius Gedminas mged...@gmail.com writes: On Feb 4, 1:03 am, John Bokma j...@castleamber.com wrote: Jonathan Gardner jgard...@jonathangardner.net writes: I can explain all of Python in an hour; OK, in that case I would say give it a go. Put it on YouTube, or write a blog post about it (or post it here). I am sure you will help a lot of people that way. Someone already did: Advanced Python or Understanding Python http://video.google.com/videoplay?docid=7760178035196894549 (76 minutes). Worth watching. Thanks, I will. And let you know if it succeeds at explain all of Python in 76 minutes. It's not a fair test, since I am not new to Python, but let me see first ;-) -- John Bokma j3b Hacking Hiking in Mexico - http://johnbokma.com/ http://castleamber.com/ - Perl Python Development -- http://mail.python.org/mailman/listinfo/python-list
Re: Python and Ruby
Marius Gedminas mged...@gmail.com writes: On Feb 4, 1:03 am, John Bokma j...@castleamber.com wrote: Jonathan Gardner jgard...@jonathangardner.net writes: I can explain all of Python in an hour; OK, in that case I would say give it a go. Put it on YouTube, or write a blog post about it (or post it here). I am sure you will help a lot of people that way. Someone already did: Advanced Python or Understanding Python http://video.google.com/videoplay?docid=7760178035196894549 (76 minutes). Worth watching. Certainly worth watching (I learned some stuff), but in my opinion you /need to have some Python experience/ to be able to follow so no (IMO), someone didn't do it already. -- John Bokma j3b Hacking Hiking in Mexico - http://johnbokma.com/ http://castleamber.com/ - Perl Python Development -- http://mail.python.org/mailman/listinfo/python-list
Re: Python and Ruby
On Feb 3, 3:39 pm, Steve Holden st...@holdenweb.com wrote: Robert Kern wrote: On 2010-02-03 15:32 PM, Jonathan Gardner wrote: I can explain all of Python in an hour; I doubt anyone will understand all of Python in an hour. With all respect, talking about a subject without a reasonable chance of your audience understanding the subject afterwards is not explaining. It's just exposition. I agree. If the audience doesn't understand then you haven't explained it. On the contrary, that explanation would have everything you need. It would take an hour to read or listen to the explanation, but much more than that time to truly understand everything that was said. -- http://mail.python.org/mailman/listinfo/python-list
Re: Python and Ruby
On 2010-02-04 14:55 PM, Jonathan Gardner wrote: On Feb 3, 3:39 pm, Steve Holdenst...@holdenweb.com wrote: Robert Kern wrote: On 2010-02-03 15:32 PM, Jonathan Gardner wrote: I can explain all of Python in an hour; I doubt anyone will understand all of Python in an hour. With all respect, talking about a subject without a reasonable chance of your audience understanding the subject afterwards is not explaining. It's just exposition. I agree. If the audience doesn't understand then you haven't explained it. On the contrary, that explanation would have everything you need. It would take an hour to read or listen to the explanation, but much more than that time to truly understand everything that was said. Like I said, that's exposition, not explanation. There is an important distinction between the two words. Simply providing information is not explanation. If it takes four hours for your audience to understand it, then you explained it in four hours no matter when you stopped talking. -- Robert Kern I have come to believe that the whole world is an enigma, a harmless enigma that is made terrible by our own mad attempt to interpret it as though it had an underlying truth. -- Umberto Eco -- http://mail.python.org/mailman/listinfo/python-list
Re: Python and Ruby
On Jan 28, 2:29 am, Jonathan Gardner jgard...@jonathangardner.net
wrote:
On Jan 27, 5:47 am, Simon Brunning si...@brunningonline.net wrote:
I think Python is a little cleaner, but I'm sure you'd find Ruby fans
who'd argue the complete opposite.
Are you sure about that?
There's a lot of line noise in Ruby. How are you supposed to pronounce
@@? What about {|..| ... }?
There's a lot of magic in Ruby as well. For instance, function calls
are made without parentheses. Blocks can only appear as the first
argument. There's a lot more, if you put your mind to it.
Indentation is also optional in Ruby. You can quickly fool a newbie by
not indenting your code properly, which is impossible in Python.
Python is much, much cleaner. I don't know how anyone can honestly say
Ruby is cleaner than Python.
I will. I developed on both (Python was first) and I think that ruby I
very clean and maybe cleaner than Python. Also I don't know any
situation where you need to pronounce your code symbol by symbol. You
might need to pronounce some semantics.
And you're wrong with blocks.
About indent your right. It helps newbies indent code becouse they
must to. But most of professional developers started with Pascal and
then C and they all indent well :) it is about culture and it is what
about teacher should say.
--
http://mail.python.org/mailman/listinfo/python-list
Re: Python and Ruby
On Feb 2, 9:11 pm, John Bokma j...@castleamber.com wrote: Jonathan Gardner jgard...@jonathangardner.net writes: I can explain, in an hour, every single feature of the Python language to an experienced programmer, all the way up to metaclasses, Either you're a hell of a talker, or I am far, far away from being an experienced programmer. It's advocacy like this, IMO, that keeps people away from a language, because you can't feel nothing but a failure after a statement like this. I can explain all of Python in an hour; I doubt anyone will understand all of Python in an hour. Coming from perl to python, the big aha! moment was when I realized there wasn't anything more than what I saw before me. I kept expecting something big around the corner, kind of like when I first discovered refs in perl, or when I realized how hard it truly was to write OO code in perl that actually does what you think it should do. Perl has trained me to be fearful of the language, constantly on the lookout for jabberwockies. If you fall into one of those traps in perl, it's because you weren't smart enough and aren't worthy of the language, or so they say. It's never perl's fault. I mean, doesn't everyone know what the Schwartzian Transform is? Python is the complete opposite. Go through http://docs.python.org/reference/ . Once you've familiarized yourself with all the operators, statements, and the special methods, you're done with syntax and the core language. There is no more. The next step is to learn the basic objects and functions in builtins. That's in the first seven chapters of http://docs.python.org/library/index.html. You can always fall back to the help function to remind yourself if you forget. I do it all the time. After that, it's merely figuring out which standard libraries do what and how. The documentation there is complete and awesome, and there are more than enough people willing to point you in the right direction here. There are no dragons in this forest. Heck, this isn't even a forest--- it's a single-room apartment with everything you need right there where you can see it. The thermostat is set to room temperature, and no matter what happens outside, you're safe and protected from it all. -- http://mail.python.org/mailman/listinfo/python-list
Re: Python and Ruby
On 2010-02-03 15:32 PM, Jonathan Gardner wrote: I can explain all of Python in an hour; I doubt anyone will understand all of Python in an hour. With all respect, talking about a subject without a reasonable chance of your audience understanding the subject afterwards is not explaining. It's just exposition. -- Robert Kern I have come to believe that the whole world is an enigma, a harmless enigma that is made terrible by our own mad attempt to interpret it as though it had an underlying truth. -- Umberto Eco -- http://mail.python.org/mailman/listinfo/python-list
Re: Python and Ruby
In article 1944d953-25ad-440b-9317-a7a4b4de6...@f17g2000prh.googlegroups.com, Jonathan Gardner jgard...@jonathangardner.net wrote: I can explain all of Python in an hour; I doubt anyone will understand all of Python in an hour. Coming from perl to python, the big aha! moment was when I realized there wasn't anything more than what I saw before me. I kept expecting something big around the corner, kind of like when I first discovered refs in perl, or when I realized how hard it truly was to write OO code in perl that actually does what you think it should do. Perl has trained me to be fearful of the language, constantly on the lookout for jabberwockies. If you fall into one of those traps in perl, it's because you weren't smart enough and aren't worthy of the language, or so they say. It's never perl's fault. I mean, doesn't everyone know what the Schwartzian Transform is? Python is the complete opposite. Go through http://docs.python.org/reference/ . Once you've familiarized yourself with all the operators, statements, and the special methods, you're done with syntax and the core language. There is no more. The next step is to learn the basic objects and functions in builtins. That's in the first seven chapters of http://docs.python.org/library/index.html. You can always fall back to the help function to remind yourself if you forget. I do it all the time. After that, it's merely figuring out which standard libraries do what and how. The documentation there is complete and awesome, and there are more than enough people willing to point you in the right direction here. There are no dragons in this forest. Heck, this isn't even a forest--- it's a single-room apartment with everything you need right there where you can see it. The thermostat is set to room temperature, and no matter what happens outside, you're safe and protected from it all. That's a pretty accurate description of how I transitioned to Python from C and Fortran. I kept trying to think of how to output data and parameter variables of different types to files for later reading in. How to format them all consistently and then get them back in with the exact same accuracy. I was stuck in printf and scanf land. Then after much noodling around and reading it hit me that I could just put all that output of different types of variables into a list, hit it with a repr() function to get a string version, and write the string to a file -- no formatting necessary-- three lines of code. Later reading in the string version (no formatting necessary), and hitting it with an eval() function returned all the values I originally had in those variables. How simple, but beautiful. I was making it harder when Python was making it easier. Trained on the wrong language. -- -- Lou Pecora -- http://mail.python.org/mailman/listinfo/python-list
Re: Python and Ruby
Jonathan Gardner jgard...@jonathangardner.net writes: On Feb 2, 9:11 pm, John Bokma j...@castleamber.com wrote: Jonathan Gardner jgard...@jonathangardner.net writes: I can explain, in an hour, every single feature of the Python language to an experienced programmer, all the way up to metaclasses, Either you're a hell of a talker, or I am far, far away from being an experienced programmer. It's advocacy like this, IMO, that keeps people away from a language, because you can't feel nothing but a failure after a statement like this. I can explain all of Python in an hour; OK, in that case I would say give it a go. Put it on YouTube, or write a blog post about it (or post it here). I am sure you will help a lot of people that way. Coming from perl to python, the big aha! moment was when I realized there wasn't anything more than what I saw before me. I kept expecting something big around the corner, kind of like when I first discovered refs in perl, or when I realized how hard it truly was to write OO code in perl that actually does what you think it should do. There are very nice frameworks to help you (e.g. Moose). OO is not that hard IMO, but I can imagine it's very hard if you don't understand references sufficiently. Perl has trained me to be fearful of the language, constantly on the lookout for jabberwockies. If you fall into one of those traps in perl, it's because you weren't smart enough and aren't worthy of the language, or so they say. Odd, you gave me the same feeling when you stated you could explain me all features of Python in an hour. It's never perl's fault. I mean, doesn't everyone know what the Schwartzian Transform is? Doesn't everyone know what the big O notation is? I mean, Schwartzian transform is not unique to Perl, and it strikes me as odd that you think it is. It's all about understanding that general sort on average is O(n log n), and hence does O(n log n) comparisons. Which means that if you do an expensive calculation in a custom compare function or do a lot of comparisons it might be cheaper to do precalculate the keys (O(n)). Randal Schwartz was the person who made this idea popular in the Perl community, hence the Perl community named it after him, but it was long known before that and used in other languages. [How to learn Python] I am fully aware of how to learn a language, I've done so several times (or many times even). I only disagree with your statement that you can explain all features of Python to me in an hour. But I love to be wrong on this, and to stand corrected. There are no dragons in this forest. Heck, this isn't even a forest--- it's a single-room apartment with everything you need right there where you can see it. The thermostat is set to room temperature, and no matter what happens outside, you're safe and protected from it all. Why does this sound like some religious speech? I always say: if there was a really easy to learn programming language, I would be programming in it. And no, I don't think Python is it. (Nor Perl for that matter). I do agree that Python /looks/ more simple (and certainly cleaner, unless you're using regexp a lot) than Perl, and certainly to some extend Python /is/ simpler. But in my (relatively long experience) programming boils mostly down to which libraries you know, and how well you can use them. Finally, note that simpeler doesn't always make your code more easy to grasp. There is a reason that human languages are rich and often have many ways to say something. Programming, after all, is also communication with other humans (if only with one self). -- John Bokma j3b Hacking Hiking in Mexico - http://johnbokma.com/ http://castleamber.com/ - Perl Python Development -- http://mail.python.org/mailman/listinfo/python-list
Re: Python and Ruby
Lou Pecora pec...@anvil.nrl.navy.mil writes: after much noodling around and reading it hit me that I could just put all that output of different types of variables into a list, hit it with a repr() function to get a string version, and write the string to a file -- no formatting necessary-- three lines of code. Later reading in the string version (no formatting necessary), and hitting it with an eval() function returned all the values I originally had in those variables. How simple, but beautiful. FYI: I do that too sometimes, but in general using repr/eval that way is poor style and not very reliable. It's better to use the pickle module, which is intended for that sort of thing, or the json module if your datatypes are suitable and you want to follow a semi-standard. -- http://mail.python.org/mailman/listinfo/python-list
Re: Python and Ruby
Robert Kern wrote: On 2010-02-03 15:32 PM, Jonathan Gardner wrote: I can explain all of Python in an hour; I doubt anyone will understand all of Python in an hour. With all respect, talking about a subject without a reasonable chance of your audience understanding the subject afterwards is not explaining. It's just exposition. I agree. If the audience doesn't understand then you haven't explained it. regards Steve -- Steve Holden +1 571 484 6266 +1 800 494 3119 PyCon is coming! Atlanta, Feb 2010 http://us.pycon.org/ Holden Web LLC http://www.holdenweb.com/ UPCOMING EVENTS:http://holdenweb.eventbrite.com/ -- http://mail.python.org/mailman/listinfo/python-list
Re: Python and Ruby
Timothy N. Tsvetkov timothy.tsvet...@gmail.com wrote: Jonathan Gardner jgard...@jonathangardner.net Python is much, much cleaner. I don't know how anyone can honestly say Ruby is cleaner than Python. I developed on both (Python was first) and I think that ruby I very clean and maybe cleaner than Python. And you're wrong with blocks. You say 'static', and I say 'dynamic'. You say 'consistent', and I say 'erratic'. Static! Dynamic! Consistent! Erratic! Let's join the right news group. -- http://mail.python.org/mailman/listinfo/python-list
Re: Python and Ruby
Nobody nob...@nowhere.com writes: A better metric is whether using N features has O(N) complexity, or O(N^2) (where you have to understand how each feature relates to each other feature) or even O(2^N) (where you have to understand every possible combination of interactions). M. Felleisen wrote a paper trying to formalize some metric on the expressive power of programming languages. I skimmed through it for about a minute and wasn't convinced, but it apparently has gathered some respect. I want to read it more carefully sometime: http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.51.4656 -- http://mail.python.org/mailman/listinfo/python-list
Re: Python and Ruby
Steven D'Aprano wrote: On Sat, 30 Jan 2010 16:58:34 +, tanix wrote: [...] The very idea of using a number of blanks to identify your block level is as insane as it gets. Not at all. People do it all the time. The very idea of expecting people to count nested braces to identify block level is what is crazy, which is why in languages with braces people still indent the blocks. for reading written code, it's surely helpful to have the code indented, though for *human* reading, the count of blanks seems rather inessential, as long as intended difference in indents is more pronounced than incidental difference between same-level lines. for writing new code, it's not necessarily that helpful to be *forced* to keep with strict indenting rules. in early development phases, code is often experimental, and parts of it may need to be blocked or unblocked as the codebase grows, and for experimentation, the need to carefully and consistently indent and de-indent large chunks of code can easily lead to a mess (blame it on the programmer, not the language, but still). yes, there are editors that help you indent chunks of code, but see below. there are languages where indentation can be either enforced and allow one to omit some syntactic nuissance like braces or begin-end clauses, or made optional, requiring other syntactic means for delimiting blocks etc. (consider f# with its #light declaration, for example.) [...] In any case, if your IDE mixes tabs and spaces, your IDE is broken and you should fix your tools rather than blame the language. as long as you are limited to your own code, sure. but if many work on the same bit, and use different editors and indentation policies, blanks-tabs indentation issues are not unlikely. you can have blanks converted to tabs and vice versa automatically, but that's clearly a nuisance. Braces is the most reliable way to identify blocks. Nonsense. For the compiler, both are equally reliable, and for the human reader, indents beat braces easily. if blanks and tabs are mixed together as indentation, the setting of your ide can easily mess up the indentation, making the structure unclear. in some editors, you can have braces highlighted, so that it's even easier to see where a block ends or starts. and more advanced editors help one see the structure of the code, whereby both indentation and braces are made less important for the reader. but yes, indentation surely helps in reading the code. Sane compilers ignore blanks altogether. Really? So a sane compiler sees no difference between: for x in mylist: and forxinmylist: I'm glad I don't have to program using a compiler you consider sane. the point here was, i think, that blanks may have no syntactic meaning, though they can still be essential at the lexical level. your example targeted the lexical level, and that's rather irrelevant to the problem of syntactically meaningful indentation discussed here. vQ -- http://mail.python.org/mailman/listinfo/python-list
Re: Python and Ruby
Jonathan Gardner wrote: One of the bad things with languages like perl and Ruby that call without parentheses is that getting a function ref is not obvious. You need even more syntax to do so. In perl: foo(); # Call 'foo' with no args. $bar = foo; # Call 'foo; with no args, assign to '$bar' $bar = foo; # Don't call 'foo', but assign a pointer to it to '$bar' # By the way, this '' is not the bitwise-and '' $bar-() # Call whatever '$bar' is pointing at with no args Compare with python: foo() # Call 'foo' with no args. bar = foo() # 'bar' is now pointing to whatever 'foo()' returned bar = foo # 'bar' is now pointing to the same thing 'foo' points to bar() # Call 'bar' with no args One is simple, consistent, and easy to explain. The other one requires the introduction of advanced syntax and an entirely new syntax to make function calls with references. If you get rid of the syntax specific to Perl, then having to explicitly obtain a function reference, or to dereference the result, is not such a big deal: foo # Call 'foo' with no args. bar = foo# Call 'foo; with no args, assign to 'bar' bar = foo # Don't call 'foo', but assign a pointer to it to 'bar' bar^ # Call whatever 'bar' is pointing at with no args (Here I use ^ instead of - to dereference.) Compared with Python, it saves 3 lots of (), but needs and ^ added. Still a net saving. One of the bad things with languages like perl and Ruby that call without parentheses is that getting a function ref is not obvious. I'd say that having this symbol in front of foo makes it more obvious than just foo by itself. But I agree not quite as clean. Another thing is that you have to know whether bar is a function, or a function ref, and use the appropriate syntax. Sometimes this is helpful, sometimes not. -- Bartc -- http://mail.python.org/mailman/listinfo/python-list
Re: Python and Ruby
On Feb 2, 2:21 am, waku w...@idi.ntnu.no wrote: for writing new code, it's not necessarily that helpful to be *forced* to keep with strict indenting rules. in early development phases, code is often experimental, and parts of it may need to be blocked or unblocked as the codebase grows, and for experimentation, the need to carefully and consistently indent and de-indent large chunks of code can easily lead to a mess (blame it on the programmer, not the language, but still). yes, there are editors that help you indent chunks of code, but see below. there are languages where indentation can be either enforced and allow one to omit some syntactic nuissance like braces or begin-end clauses, or made optional, requiring other syntactic means for delimiting blocks etc. (consider f# with its #light declaration, for example.) If you're writing experimental code, you're doing it wrong. Every line of code you write may end up on the space shuttle one day (so to speak!) Why not write the code well-formatted in the first place, so that any bugs you introduce are as easily visible as possible? The only reason why you may want to write crap code without proper formatting is because your text editor is stupid. If that's the case, get rid of your text editor and find some tools that help you do the right thing the first time. as long as you are limited to your own code, sure. but if many work on the same bit, and use different editors and indentation policies, blanks-tabs indentation issues are not unlikely. you can have blanks converted to tabs and vice versa automatically, but that's clearly a nuisance. If you're text editor has a problem with indenting, you have a terrible text editor. Period, end of sentence. You can't screw in bolts with a hammer, and you can't level with a saw. Don't try to write code in any language without a real text editor that can do proper indentation. Don't let your teammates use deficient text editors either. I wouldn't appreciate it if I delivered precision components that my teammates tried to install with sledgehammers. This is the 21st Century. Good text editors are not hard to find on any platform. -- http://mail.python.org/mailman/listinfo/python-list
Re: Python and Ruby
On Feb 1, 6:21 pm, Nobody nob...@nowhere.com wrote: You don't need to know the entire language before you can use any of it (if you did, Python would be deader than a certain parrot; Python's dark corners are *really* dark). I'm curious. What dark corners are you referring to? I can't think of any. Especially with the direction Python 3 is going, it seems like even the slightly dim corners are being rounded away. I can explain, in an hour, every single feature of the Python language to an experienced programmer, all the way up to metaclasses, __getattribute__, __new__ and __get__. These are the darkest corners I know of, and these are not at all dark. It takes a few paragraphs of documentation to explain all the details of each these features. I hold the entire Python language in my head, and I can still remember when my next meeting is. Compare that to something like Haskell, where you have to read entire books before you truly understand what monads are actually doing behind the scenes, and how Haskell actually interprets and runs your program, or to understand what the esoteric error messages that crop up are actually caused be. Yes, there are people that know how to do stuff in Haskell. These are really smart people, the cream of the crop, so to speak. But that doesn't make Haskell a simple language. -- http://mail.python.org/mailman/listinfo/python-list
Re: Python and Ruby
On Feb 1, 6:36 pm, John Bokma j...@castleamber.com wrote:
Jonathan Gardner jgard...@jonathangardner.net writes:
One of the bad things with languages like perl
FYI: the language is called Perl, the program that executes a Perl
program is called perl.
without parentheses is that getting a function ref is not obvious. You
need even more syntax to do so. In perl:
foo(); # Call 'foo' with no args.
$bar = foo; # Call 'foo; with no args, assign to '$bar'
$bar = foo; # Don't call 'foo', but assign a pointer to it to '$bar'
# By the way, this '' is not the bitwise-and ''
It should be $bar = \foo
Your example actually calls foo...
I rest my case. I've been programming perl professionally since 2000,
and I still make stupid, newbie mistakes like that.
One is simple, consistent, and easy to explain. The other one requires
the introduction of advanced syntax and an entirely new syntax to make
function calls with references.
The syntax follows that of referencing and dereferencing:
$bar = \...@array; # bar contains now a reference to array
$bar-[ 0 ]; # first element of array referenced by bar
$bar = \%hash; # bar contains now a reference to a hash
$bar-{ key }; # value associated with key of hash ref. by bar
$bar = \foo; # bar contains now a reference to a sub
$bar-( 45 ); # call sub ref. by bar with 45 as an argument
Consistent: yes. New syntax? No.
Except for the following symbols and combinations, which are entirely
new and different from the $...@% that you have to know just to use
arrays and hashes.
\@, -[ ]
\%, -{ }
\, -( )
By the way:
* How do you do a hashslice on a hashref?
* How do you invoke reference to a hash that contains a reference to
an array that contains a reference to a function?
Compare with Python's syntax.
# The only way to assign
a = b
# The only way to call a function
b(...)
# The only way to access a hash or array or string or tuple
b[...]
Also, it helps to think of
$ as a thing
@ as thingies indexed by numbers
% as thingies indexed by keys
I'd rather think of the task at hand than what each of the funky
symbols on my keyboard mean.
--
http://mail.python.org/mailman/listinfo/python-list
Re: Python and Ruby
On Feb 2, 7:23 am, bartc ba...@freeuk.com wrote: Jonathan Gardner wrote: One of the bad things with languages like perl and Ruby that call without parentheses is that getting a function ref is not obvious. You need even more syntax to do so. In perl: foo(); # Call 'foo' with no args. $bar = foo; # Call 'foo; with no args, assign to '$bar' $bar = foo; # Don't call 'foo', but assign a pointer to it to '$bar' # By the way, this '' is not the bitwise-and '' $bar-() # Call whatever '$bar' is pointing at with no args Compare with python: foo() # Call 'foo' with no args. bar = foo() # 'bar' is now pointing to whatever 'foo()' returned bar = foo # 'bar' is now pointing to the same thing 'foo' points to bar() # Call 'bar' with no args One is simple, consistent, and easy to explain. The other one requires the introduction of advanced syntax and an entirely new syntax to make function calls with references. If you get rid of the syntax specific to Perl, then having to explicitly obtain a function reference, or to dereference the result, is not such a big deal: foo # Call 'foo' with no args. bar = foo # Call 'foo; with no args, assign to 'bar' bar = foo # Don't call 'foo', but assign a pointer to it to 'bar' bar^ # Call whatever 'bar' is pointing at with no args (Here I use ^ instead of - to dereference.) Compared with Python, it saves 3 lots of (), but needs and ^ added. Still a net saving. On one shoulder, a demon taunts the programmer: Ohmygosh, you can save three keystrokes if you introduce an entirely new syntax with odd squiggles that make no pronounceable sound in the English language! Perhaps one day, you can program APL in Python! The angel that sits on the other shoulder says, Alas, poor programmer, one day, you'll have to read that and understand it. And heaven help us when we hire a poor college graduate to maintain the code we wrote five years ago. Or worse, when that poor college graduate writes code and expects us to read it! Thankfully, Guido has banished that demon from the realm of Python a long time ago. One of the bad things with languages like perl and Ruby that call without parentheses is that getting a function ref is not obvious. I'd say that having this symbol in front of foo makes it more obvious than just foo by itself. But I agree not quite as clean. Another thing is that you have to know whether bar is a function, or a function ref, and use the appropriate syntax. Sometimes this is helpful, sometimes not. Thankfully, in Python, everything is a ref, so everything is consistent. -- http://mail.python.org/mailman/listinfo/python-list
Re: Python and Ruby
On Feb 1, 6:50 pm, Nobody nob...@nowhere.com wrote:
On Mon, 01 Feb 2010 14:13:38 -0800, Jonathan Gardner wrote:
I judge a language's simplicity by how long it takes to explain the
complete language. That is, what minimal set of documentation do you
need to describe all of the language?
That's not a particularly good metric, IMHO.
A simple core language doesn't necessarily make a language simple to
use. You can explain the entirety of pure lambda calculus or combinators
in five minutes, but you wouldn't want to write real code in either (and
you certainly wouldn't want to read such code which was written by someone
else).
For a start, languages with a particularly simple core tend to delegate
too much to the library. One thing which puts a lot of people off of
lisp is the lack of infix operators; after all, (* 2 (+ 3 4)) works fine
and doesn't require any additional language syntax. For an alternative,
Tcl provides the expr function which essentially provides a sub-language
for arithmetic expressions.
A better metric is whether using N features has O(N) complexity, or O(N^2)
(where you have to understand how each feature relates to each other
feature) or even O(2^N) (where you have to understand every possible
combination of interactions).
With a handful of statements,
and a very short list of operators, Python beats out every language in
the Algol family that I know of.
Not once you move beyond the 10-minute introduction, and have to start
thinking in terms of x + y is x.__add__(y) or maybe y.__radd__(x) and also
that x.__add__(y) is x.__getattribute__('__add__')(y) (but x + y *isn't*
equivalent to the latter due to __slots__), and maybe .__coerce__() gets
involved somewhere, and don't even get me started on __metaclass__ or
__init__ versus __new__ or ...
Yes, the original concept was very nice and clean, but everything since
then has been wedged in there by sheer force with a bloody great hammer.
I strongly suggest you read the documentation on these bits of Python.
If you're scared of __new__ versus __init__, then you haven't been
programming very long in any language. There is a case when you need
one over the other. The same goes for the other concepts.
Programming languages that don't provide these features (like
Javascript) are nice for toy programs, but lack the power to
accommodate the needs of large apps.
--
http://mail.python.org/mailman/listinfo/python-list
Re: Python and Ruby
Jonathan Gardner jgard...@jonathangardner.net writes: Compare with Python's syntax. # The only way to assign a = b # The only way to call a function b(...) # The only way to access a hash or array or string or tuple b[...] For all of your examples, there are other ways supported. I do wish this focus on “only way” would depart, it's a fallacy and not helpful. What is important (and supports the main point of your message) is that for each of the above, whether or not they are the only way, they are the one *obvious* way to do the operation. -- \ “The cost of education is trivial compared to the cost of | `\ ignorance.” —Thomas Jefferson | _o__) | Ben Finney -- http://mail.python.org/mailman/listinfo/python-list
Re: Python and Ruby
Ben Finney wrote: Jonathan Gardner jgard...@jonathangardner.net writes: Compare with Python's syntax. # The only way to assign a = b # The only way to call a function b(...) # The only way to access a hash or array or string or tuple b[...] For all of your examples, there are other ways supported. I do wish this focus on “only way” would depart, it's a fallacy and not helpful. And besides which most people get the quote wrong. The authoritative version from the Zen is, as you clearly already know There should be one-- and preferably only one --obvious way to do it. What is important (and supports the main point of your message) is that for each of the above, whether or not they are the only way, they are the one *obvious* way to do the operation. Quite. People might be interested to know the history of the Zen, which I got directly from Tim Peters over lunch one day. It was composed, apparently, during the commercial breaks one evening while he was watching professional wrestling on the television! So it's wise not to take the Zen too seriously. It wasn't written to guide, but to amuse. The fact that it can do both is a testament to Tim's sagacity. regards Steve -- Steve Holden +1 571 484 6266 +1 800 494 3119 PyCon is coming! Atlanta, Feb 2010 http://us.pycon.org/ Holden Web LLC http://www.holdenweb.com/ UPCOMING EVENTS:http://holdenweb.eventbrite.com/ -- http://mail.python.org/mailman/listinfo/python-list
Re: Python and Ruby
On Feb 2, 5:01 pm, Jonathan Gardner jgard...@jonathangardner.net
wrote:
On Feb 1, 6:36 pm, John Bokma j...@castleamber.com wrote:
Jonathan Gardner jgard...@jonathangardner.net writes:
One of the bad things with languages like perl
FYI: the language is called Perl, the program that executes a Perl
program is called perl.
without parentheses is that getting a function ref is not obvious. You
need even more syntax to do so. In perl:
foo(); # Call 'foo' with no args.
$bar = foo; # Call 'foo; with no args, assign to '$bar'
$bar = foo; # Don't call 'foo', but assign a pointer to it to '$bar'
# By the way, this '' is not the bitwise-and ''
It should be $bar = \foo
Your example actually calls foo...
I rest my case. I've been programming perl professionally since 2000,
and I still make stupid, newbie mistakes like that.
One is simple, consistent, and easy to explain. The other one requires
the introduction of advanced syntax and an entirely new syntax to make
function calls with references.
The syntax follows that of referencing and dereferencing:
$bar = \...@array; # bar contains now a reference to array
$bar-[ 0 ]; # first element of array referenced by bar
$bar = \%hash; # bar contains now a reference to a hash
$bar-{ key }; # value associated with key of hash ref. by bar
$bar = \foo; # bar contains now a reference to a sub
$bar-( 45 ); # call sub ref. by bar with 45 as an argument
Consistent: yes. New syntax? No.
Except for the following symbols and combinations, which are entirely
new and different from the $...@% that you have to know just to use
arrays and hashes.
\@, -[ ]
\%, -{ }
\, -( )
By the way:
* How do you do a hashslice on a hashref?
* How do you invoke reference to a hash that contains a reference to
an array that contains a reference to a function?
Compare with Python's syntax.
# The only way to assign
a = b
locals().__setitem__('a', 'b')
print a
b
# The only way to call a function
b(...)
def b(a):
...print a*2
apply(b, (3,))
6
# The only way to access a hash or array or string or tuple
b[...]
b={}
b[1] = 'a'
print b.__getitem__(1)
a
--
http://mail.python.org/mailman/listinfo/python-list
Re: Python and Ruby
Jonathan Gardner wrote: On Feb 2, 7:23 am, bartc ba...@freeuk.com wrote: Jonathan Gardner wrote: One of the bad things with languages like perl and Ruby that call without parentheses is that getting a function ref is not obvious. You need even more syntax to do so. In perl: foo(); # Call 'foo' with no args. ... If you get rid of the syntax specific to Perl, then having to explicitly obtain a function reference, or to dereference the result, is not such a big deal: foo # Call 'foo' with no args. bar = foo # Call 'foo; with no args, assign to 'bar' bar = foo # Don't call 'foo', but assign a pointer to it to 'bar' bar^ # Call whatever 'bar' is pointing at with no args (Here I use ^ instead of - to dereference.) Compared with Python, it saves 3 lots of (), but needs and ^ added. Still a net saving. On one shoulder, a demon taunts the programmer: Ohmygosh, you can save three keystrokes if you introduce an entirely new syntax with odd squiggles that make no pronounceable sound in the English language! Perhaps one day, you can program APL in Python! ... Thankfully, Guido has banished that demon from the realm of Python a long time ago. You mean (bitwise AND in Python) and ^ (bitwise XOR in Python)? :-) -- Bartc -- http://mail.python.org/mailman/listinfo/python-list
Re: Python and Ruby
Jonathan Gardner jgard...@jonathangardner.net writes: I can explain, in an hour, every single feature of the Python language to an experienced programmer, all the way up to metaclasses, Either you're a hell of a talker, or I am far, far away from being an experienced programmer. It's advocacy like this, IMO, that keeps people away from a language, because you can't feel nothing but a failure after a statement like this. -- John Bokma j3b Hacking Hiking in Mexico - http://johnbokma.com/ http://castleamber.com/ - Perl Python Development -- http://mail.python.org/mailman/listinfo/python-list
Re: Python and Ruby
Jonathan Gardner jgard...@jonathangardner.net writes:
On Feb 1, 6:36 pm, John Bokma j...@castleamber.com wrote:
[..]
It should be $bar = \foo
Your example actually calls foo...
I rest my case. I've been programming perl professionally since 2000,
and I still make stupid, newbie mistakes like that.
Uhm, in another post you wrote that you could explain Python in an hour
to an experienced programmer and you *still* make mistakes like that in
Perl!?
By the way, the language is called Perl. If you write I've been
programming perl in a Perl related group some people might read it as
that you've been working on the internals of the perl executable (in C)
One is simple, consistent, and easy to explain. The other one requires
the introduction of advanced syntax and an entirely new syntax to make
function calls with references.
The syntax follows that of referencing and dereferencing:
$bar = \...@array; # bar contains now a reference to array
$bar-[ 0 ]; # first element of array referenced by bar
$bar = \%hash; # bar contains now a reference to a hash
$bar-{ key }; # value associated with key of hash ref. by bar
$bar = \foo; # bar contains now a reference to a sub
$bar-( 45 ); # call sub ref. by bar with 45 as an argument
Consistent: yes. New syntax? No.
Except for the following symbols and combinations, which are entirely
new and different from the $...@% that you have to know just to use
arrays and hashes.
\@, -[ ]
@array, one item: $array[ 1 ];
$arrayref, one item: $arrayref-[ 1 ];
\%, -{ }
%hash, one item: $hash{ key };
hence: $hashref, one item: $hash-{ key }
\, -( )
should now be clear ;-)
You *should* have no problem with that if you have been
programming professionally Perl since 2000 IMNSHO. Otherwise print my
post or copy it on a post-it note ;-).
Remember that all this was added to Perl in version 5. So it had to be
added in a way that wouldn't break Perl 4. Perl is, in my experience
quite good in backwards compatibility. Quite some Perl modules on CPAN
work from 5.00x-5.10 and most likely will work without trouble in 5.12.
By the way:
* How do you do a hashslice on a hashref?
I will reply like it's a genuine question, and not like Oh, look, how
silly Perl works. I don't care about that much. I do like Perl and am
starting to like Python.
@$hashref{ 'key1', 'key2', 'key3' };
* How do you invoke reference to a hash that contains a reference to
an array that contains a reference to a function?
I guess you mean:
$hashref-{ key }[ index ]( arguments );
The long version is:
$hashref-{ key }-[ index ]-( arguments );
[ Python advocacy snipped]
I'd rather think of the task at hand than what each of the funky
symbols on my keyboard mean.
Then just quit programming Perl ;-) Perl has always come naturally to
me, no idea why. Recently I said to a close friend:
Python is like my desk, which I prefer to keep clean and neat.
Perl is like my livingroom, which I prefer to keep clean and neat to
some extend, but some mess is allowed. For example, the cat can be
there. Toys of my daughter are allowed to be all over the place. A
pleasant mess, but not too much.
I won't repeat what I said about PHP ;-).
--
John Bokma j3b
Hacking Hiking in Mexico - http://johnbokma.com/
http://castleamber.com/ - Perl Python Development
--
http://mail.python.org/mailman/listinfo/python-list
Re: Python and Ruby
On Tue, 02 Feb 2010 23:11:49 -0600, John Bokma wrote: Jonathan Gardner jgard...@jonathangardner.net writes: I can explain, in an hour, every single feature of the Python language to an experienced programmer, all the way up to metaclasses, Either you're a hell of a talker, or I am far, far away from being an experienced programmer. It's advocacy like this, IMO, that keeps people away from a language, because you can't feel nothing but a failure after a statement like this. Surely you're exaggerating? Without making any aspersions towards Jonathan either way, the Internet is full of both blowhards and geniuses. Anyone who lets the off-the-cup claims of either ruin their self-confidence is unlikely to be thinking about learning Python, they're probably sitting alone in a dark room staring as the walls close in. Either that or on MySpace. -- Steven -- http://mail.python.org/mailman/listinfo/python-list
Re: Python and Ruby
Steven D'Aprano ste...@remove.this.cybersource.com.au writes: On Tue, 02 Feb 2010 23:11:49 -0600, John Bokma wrote: Jonathan Gardner jgard...@jonathangardner.net writes: I can explain, in an hour, every single feature of the Python language to an experienced programmer, all the way up to metaclasses, Either you're a hell of a talker, or I am far, far away from being an experienced programmer. It's advocacy like this, IMO, that keeps people away from a language, because you can't feel nothing but a failure after a statement like this. Surely you're exaggerating? No, because if I was I would've put a smiley there somewhere. I am learning Python, for a time to be honest. I can manage in the language quite well. I consider myself quite an experienced Perl programmer, I have no problems with the constructs Jonathan elsewhere in this thread claims to have problems with after 10 years of professional Perl programming. They come natural to me. But I don't see myself being able to understand every Python feature in a talk of an hour *with* the current understanding of Python I have (read halfway through Programming In Python 3, read selected chapters on decorators, etc.). Without making any aspersions towards Jonathan either way, the Internet is full of both blowhards and geniuses. Anyone who lets the off-the-cup claims of either ruin their self-confidence is unlikely to be thinking about learning Python, they're probably sitting alone in a dark room staring as the walls close in. I am quite serious about learning Python, I do write professionally in it [1], but I am convinced that I need at least several months more of studying to feel comfortable with most (not even all) of Python. To me a much more relastic view on learning a programming language is: http://norvig.com/21-days.html [1] very small programs, and my customer is fully aware of that I am learning a new language but trust me, which is great. -- John Bokma j3b Hacking Hiking in Mexico - http://johnbokma.com/ http://castleamber.com/ - Perl Python Development -- http://mail.python.org/mailman/listinfo/python-list
Re: Python and Ruby
John Bokma j...@castleamber.com writes: Steven D'Aprano ste...@remove.this.cybersource.com.au writes: On Tue, 02 Feb 2010 23:11:49 -0600, John Bokma wrote: Jonathan Gardner jgard...@jonathangardner.net writes: I can explain, in an hour, every single feature of the Python language to an experienced programmer, all the way up to metaclasses, Either you're a hell of a talker, or I am far, far away from being an experienced programmer. It's advocacy like this, IMO, that keeps people away from a language, because you can't feel nothing but a failure after a statement like this. Surely you're exaggerating? No, because if I was I would've put a smiley there somewhere. I am learning Python, for a time to be honest. I can manage in the language quite well. Clarification: for a beginner that is. [1] very small programs, and my customer is fully aware of that I am learning a new language but trust me, which is great. Should've been but trusts me,. -- John Bokma j3b Hacking Hiking in Mexico - http://johnbokma.com/ http://castleamber.com/ - Perl Python Development -- http://mail.python.org/mailman/listinfo/python-list
Re: Python and Ruby
Steven D'Aprano wrote: On Sun, 31 Jan 2010 22:43:56 -0800, alex23 wrote: Steven D'Aprano ste...@remove.this.cybersource.com.au wrote: You're using that term wrong. It looks to me that you don't actually know what a straw man argument is. A straw man argument is when somebody responds to a deliberately weakened or invalid argument as if it had been made by their opponent. Jeez, Steve, you're beginning to sound like some kind of fallacy zealot... ;) Death to all those who confuse agumentum ad populum with argumentum ad verecundiam!!! Yeah, what did the zealots ever do for us? regards Steve -- Steve Holden +1 571 484 6266 +1 800 494 3119 PyCon is coming! Atlanta, Feb 2010 http://us.pycon.org/ Holden Web LLC http://www.holdenweb.com/ UPCOMING EVENTS:http://holdenweb.eventbrite.com/ -- http://mail.python.org/mailman/listinfo/python-list
Re: Python and Ruby
Terry Reedy wrote: On 1/31/2010 7:25 PM, Steven D'Aprano wrote: On Sun, 31 Jan 2010 15:40:36 -0800, Chris Rebert wrote: On Sun, Jan 31, 2010 at 2:36 PM, Steven D'Aprano st...@remove-this-cybersource.com.au wrote: On Sun, 31 Jan 2010 04:28:41 -0800, Ed Keith wrote: In most functional languages you just name a function to access it and you do it ALL the time. for example, in if you have a function 'f' which takes two parameters to call the function and get the result you use: f 2 3 If you want the function itself you use: f How do you call a function of no arguments? It's not really a function in that case, it's just a named constant. (Recall that functions don't/can't have side-effects.) Three of you gave essentially identical answers, but I still do not see how given something like def f(): return 1 I differentiate between 'function object at address xxx' and 'int 1' objects. But in a functional environment you don't need to. That's pretty much the whole point. regards Steve -- Steve Holden +1 571 484 6266 +1 800 494 3119 PyCon is coming! Atlanta, Feb 2010 http://us.pycon.org/ Holden Web LLC http://www.holdenweb.com/ UPCOMING EVENTS:http://holdenweb.eventbrite.com/ -- http://mail.python.org/mailman/listinfo/python-list
Re: Python and Ruby
On Jan 30, 8:43 am, Nobody nob...@nowhere.com wrote: On Wed, 27 Jan 2010 15:29:05 -0800, Jonathan Gardner wrote: Python is much, much cleaner. I don't know how anyone can honestly say Ruby is cleaner than Python. I'm not familiar with Ruby, but most languages are cleaner than Python once you get beyond the 10-minute introduction stage. Probably too little, too late (haven't read all of the replies yet...) I judge a language's simplicity by how long it takes to explain the complete language. That is, what minimal set of documentation do you need to describe all of the language? With a handful of statements, and a very short list of operators, Python beats out every language in the Algol family that I know of. I can think of only one language (or rather, a class of languages) that can every hope to be shorter than Python. I doubt you've heard of it based on your comments, but I suggest you look into it. Unfortunately, to fully appreciate that language, you're going to have to study a textbook called SICP. At the end of that textbook, you are blessed to not only see but understand the complete compiler for the language, in the language itself. -- http://mail.python.org/mailman/listinfo/python-list
Re: Python and Ruby
On Jan 31, 3:01 am, rantingrick rantingr...@gmail.com wrote: On Jan 30, 10:43 am, Nobody nob...@nowhere.com wrote: That's also true for most functional languages, e.g. Haskell and ML, as well as e.g. Tcl and most shells. Why require f(x) or (f x) if f x will suffice? yuck! wrapping the arg list with parenthesis (python way) makes the most sense. Its to easy to misread somthing like this onetwothree four five six onetwothree(four, five, six) #ahhh... plain english. In Lisp-ish languages, you have a list of stuff that represents a function call: (a b c d) means: Call a with values (b, c, d) While this certainly doesn't agree with what you learned in Algebra, it is a reasonable syntax that exposes the code-data duality of programs. There is, however, one fatal flaw. Why is the first element so different than the rest? This is inconsistent with what people who are unfamiliar with the language would expect. Indeed, in teaching Lisp, learners have to be reminded about how the evaluator looks at lists and processes them. I would expect a clear, simple language to have exactly one way to call a function. This calling notation would clearly distinguish between the function and its parameters. There are quite a few options, and it turns out that function(arg, arg, arg) is a really good compromise. One of the bad things with languages like perl and Ruby that call without parentheses is that getting a function ref is not obvious. You need even more syntax to do so. In perl: foo(); # Call 'foo' with no args. $bar = foo; # Call 'foo; with no args, assign to '$bar' $bar = foo; # Don't call 'foo', but assign a pointer to it to '$bar' # By the way, this '' is not the bitwise-and '' $bar-() # Call whatever '$bar' is pointing at with no args Compare with python: foo() # Call 'foo' with no args. bar = foo() # 'bar' is now pointing to whatever 'foo()' returned bar = foo # 'bar' is now pointing to the same thing 'foo' points to bar() # Call 'bar' with no args One is simple, consistent, and easy to explain. The other one requires the introduction of advanced syntax and an entirely new syntax to make function calls with references. Note that the Algebra notation of functions allows for an obvious, simple way to refer to functions without calling them, leading to syntax such as f o g (x) and more. -- http://mail.python.org/mailman/listinfo/python-list
Re: Python and Ruby
On Jan 31, 12:43 pm, Nobody nob...@nowhere.com wrote: If it was common-place to use Curried functions and partial application in Python, you'd probably prefer f a b c to f(a)(b)(c) as well. That's just the point. It isn't common to play with curried functions or monads or anything like that in computer science today. Yes, Haskell exists, and is a great experiment in how such a language could actually work. But at the same time, you have to have a brain the size of the titanic to contain all the little details about the language before you could write any large-scale application. Meanwhile, Python's syntax and language is simple and clean, and provides tremendous expressiveness without getting in the way of the programmer. Comparing Python's syntax to Haskell's syntax, Python is simpler. Comparing what Python can do to what Haskell can do, Haskell is much faster at certain tasks and allows the expression of certain things that are difficult to express in Python. But at the end of the day, the difference really doesn't matter that much. Now, compare Python versus Language X along the same lines, and the end result is that (a) Python is extraordinarily more simple than Langauge X, and (b) Python is comparable in expressiveness to Language X. That's the #1 reason why I like Python, and why saying Ruby and Python are similar isn't correct. -- http://mail.python.org/mailman/listinfo/python-list
Re: Python and Ruby
On Mon, Feb 1, 2010 at 2:28 PM, Jonathan Gardner jgard...@jonathangardner.net wrote: On Jan 31, 3:01 am, rantingrick rantingr...@gmail.com wrote: On Jan 30, 10:43 am, Nobody nob...@nowhere.com wrote: That's also true for most functional languages, e.g. Haskell and ML, as well as e.g. Tcl and most shells. Why require f(x) or (f x) if f x will suffice? yuck! wrapping the arg list with parenthesis (python way) makes the most sense. Its to easy to misread somthing like this onetwothree four five six onetwothree(four, five, six) #ahhh... plain english. In Lisp-ish languages, you have a list of stuff that represents a function call: (a b c d) means: Call a with values (b, c, d) While this certainly doesn't agree with what you learned in Algebra, it is a reasonable syntax that exposes the code-data duality of programs. There is, however, one fatal flaw. Why is the first element so different than the rest? This is inconsistent with what people who are unfamiliar with the language would expect. Indeed, in teaching Lisp, learners have to be reminded about how the evaluator looks at lists and processes them. I would expect a clear, simple language to have exactly one way to call a function. This calling notation would clearly distinguish between the function and its parameters. There are quite a few options, and it turns out that function(arg, arg, arg) is a really good compromise. One of the bad things with languages like perl and Ruby that call without parentheses is that getting a function ref is not obvious. You need even more syntax to do so. In perl: foo(); # Call 'foo' with no args. $bar = foo; # Call 'foo; with no args, assign to '$bar' $bar = foo; # Don't call 'foo', but assign a pointer to it to '$bar' # By the way, this '' is not the bitwise-and '' $bar-() # Call whatever '$bar' is pointing at with no args Compare with python: foo() # Call 'foo' with no args. bar = foo() # 'bar' is now pointing to whatever 'foo()' returned bar = foo # 'bar' is now pointing to the same thing 'foo' points to bar() # Call 'bar' with no args One is simple, consistent, and easy to explain. The other one requires the introduction of advanced syntax and an entirely new syntax to make function calls with references. Ruby isn't nearly as bad as Perl in this regard; at least it doesn't introduce extra syntax (though there are extra method calls): foo# Call 'foo' with no args. bar = foo # Call 'foo; with no args, assign to bar bar = method(:foo) # 'bar' is now referencing the 'foo' function bar.call# Call 'bar' (i.e. 'foo') with no args Cheers, Chris -- http://blog.rebertia.com -- http://mail.python.org/mailman/listinfo/python-list
Re: Python and Ruby
Jonathan Gardner jgard...@jonathangardner.net writes: I judge a language's simplicity by how long it takes to explain the complete language. That is, what minimal set of documentation do you need to describe all of the language? With a handful of statements, and a very short list of operators, Python beats out every language in the Algol family that I know of. Python may have been like that in the 1.5 era. By now it's more complex, and not all that well documented. Consider the different subclassing rules for new and old style classes, the interaction of metaclasses and multiple inheritance, the vagaries of what operations are thread-safe without locks, the inter-thread signalling mechanism that can only be invoked through the C API, the mysteries of generator-based coroutines, etc. I've never used Ruby and I think its syntax is ugly, but everyone tells me it's more uniform. Simplicity is not necessarily such a good thing anyway. Consider FORTH. -- http://mail.python.org/mailman/listinfo/python-list
Re: Python and Ruby
On Sun, 31 Jan 2010 22:36:32 +, Steven D'Aprano wrote: for example, in if you have a function 'f' which takes two parameters to call the function and get the result you use: f 2 3 If you want the function itself you use: f How do you call a function of no arguments? There's no such thing. All functions take one argument and return a value. As functions don't have side-effects, there is seldom much point in having a function with no arguments or which doesn't return a value. In cases where it is useful (i.e. a value must have function type), you can use the unit type () (essentially a zero-element tuple), e.g.: f () = 1 or: f x = () -- http://mail.python.org/mailman/listinfo/python-list
Re: Python and Ruby
Nobody wrote: On Sun, 31 Jan 2010 22:36:32 +, Steven D'Aprano wrote: for example, in if you have a function 'f' which takes two parameters to call the function and get the result you use: f 2 3 If you want the function itself you use: f How do you call a function of no arguments? There's no such thing. All functions take one argument and return a value. As functions don't have side-effects, there is seldom much point in having a function with no arguments or which doesn't return a value. In cases where it is useful (i.e. a value must have function type), you can use the unit type () (essentially a zero-element tuple), e.g.: f () = 1 or: f x = () A function with no arguments could be used as a lazy constant, generated only on demand. -- http://mail.python.org/mailman/listinfo/python-list
Re: Python and Ruby
On Mon, Feb 1, 2010 at 6:14 PM, MRAB pyt...@mrabarnett.plus.com wrote: Nobody wrote: On Sun, 31 Jan 2010 22:36:32 +, Steven D'Aprano wrote: for example, in if you have a function 'f' which takes two parameters to call the function and get the result you use: f 2 3 If you want the function itself you use: f How do you call a function of no arguments? There's no such thing. All functions take one argument and return a value. As functions don't have side-effects, there is seldom much point in having a function with no arguments or which doesn't return a value. In cases where it is useful (i.e. a value must have function type), you can use the unit type () (essentially a zero-element tuple), e.g.: f () = 1 or: f x = () A function with no arguments could be used as a lazy constant, generated only on demand. The usefulness of that depends on a language's evaluation strategy. Haskell, for instance, uses lazy evaluation by default, so your use case doesn't apply in that instance. Cheers, Chris -- http://blog.rebertia.com -- http://mail.python.org/mailman/listinfo/python-list
Re: Python and Ruby
On Mon, 01 Feb 2010 14:35:57 -0800, Jonathan Gardner wrote: If it was common-place to use Curried functions and partial application in Python, you'd probably prefer f a b c to f(a)(b)(c) as well. That's just the point. It isn't common to play with curried functions or monads or anything like that in computer science today. Yes, Haskell exists, and is a great experiment in how such a language could actually work. But at the same time, you have to have a brain the size of the titanic to contain all the little details about the language before you could write any large-scale application. No, not really. Haskell (and previously ML) are often used as introductory languages in Comp.Sci. courses (at least in the UK). You don't need to know the entire language before you can use any of it (if you did, Python would be deader than a certain parrot; Python's dark corners are *really* dark). The lack of mutable state (or at least, the isolation of it within monads) eliminates a lot of potential problems. How many Python novices get tripped up by x = y = [] ; x.append(...); # now y has changed? And in spite of the category theory behind monads, Haskell's I/O system really isn't any more complex than that of any other language, beyond the constraint that you can only use it in procedures (i.e. something returning an IO instance), not in functions. Which for the most part, is a net win, as it forces you to maintain a reasonable degree of structure. Now, if you actually want to use everything the language has to offer, you can run into some fairly hairy error messages. But then I've found that to be a common problem with generic programming in general. E.g. error messages relating to the C++ STL can be quite insanely complex (particularly when the actual error is there are so many nested templates that the mangled function name is longer than the linker can handle and it's trying to explain *where* the error is). -- http://mail.python.org/mailman/listinfo/python-list
Re: Python and Ruby
Jonathan Gardner jgard...@jonathangardner.net writes:
One of the bad things with languages like perl
FYI: the language is called Perl, the program that executes a Perl
program is called perl.
without parentheses is that getting a function ref is not obvious. You
need even more syntax to do so. In perl:
foo(); # Call 'foo' with no args.
$bar = foo; # Call 'foo; with no args, assign to '$bar'
$bar = foo; # Don't call 'foo', but assign a pointer to it to '$bar'
# By the way, this '' is not the bitwise-and ''
It should be $bar = \foo
Your example actually calls foo...
[..]
One is simple, consistent, and easy to explain. The other one requires
the introduction of advanced syntax and an entirely new syntax to make
function calls with references.
The syntax follows that of referencing and dereferencing:
$bar = \...@array; # bar contains now a reference to array
$bar-[ 0 ]; # first element of array referenced by bar
$bar = \%hash;# bar contains now a reference to a hash
$bar-{ key };# value associated with key of hash ref. by bar
$bar = \foo; # bar contains now a reference to a sub
$bar-( 45 ); # call sub ref. by bar with 45 as an argument
Consistent: yes. New syntax? No.
Also, it helps to think of
$ as a thing
@ as thingies indexed by numbers
% as thingies indexed by keys
--
John Bokma j3b
Hacking Hiking in Mexico - http://johnbokma.com/
http://castleamber.com/ - Perl Python Development
--
http://mail.python.org/mailman/listinfo/python-list
Re: Python and Ruby
On Mon, 01 Feb 2010 14:13:38 -0800, Jonathan Gardner wrote:
I judge a language's simplicity by how long it takes to explain the
complete language. That is, what minimal set of documentation do you
need to describe all of the language?
That's not a particularly good metric, IMHO.
A simple core language doesn't necessarily make a language simple to
use. You can explain the entirety of pure lambda calculus or combinators
in five minutes, but you wouldn't want to write real code in either (and
you certainly wouldn't want to read such code which was written by someone
else).
For a start, languages with a particularly simple core tend to delegate
too much to the library. One thing which puts a lot of people off of
lisp is the lack of infix operators; after all, (* 2 (+ 3 4)) works fine
and doesn't require any additional language syntax. For an alternative,
Tcl provides the expr function which essentially provides a sub-language
for arithmetic expressions.
A better metric is whether using N features has O(N) complexity, or O(N^2)
(where you have to understand how each feature relates to each other
feature) or even O(2^N) (where you have to understand every possible
combination of interactions).
With a handful of statements,
and a very short list of operators, Python beats out every language in
the Algol family that I know of.
Not once you move beyond the 10-minute introduction, and have to start
thinking in terms of x + y is x.__add__(y) or maybe y.__radd__(x) and also
that x.__add__(y) is x.__getattribute__('__add__')(y) (but x + y *isn't*
equivalent to the latter due to __slots__), and maybe .__coerce__() gets
involved somewhere, and don't even get me started on __metaclass__ or
__init__ versus __new__ or ...
Yes, the original concept was very nice and clean, but everything since
then has been wedged in there by sheer force with a bloody great hammer.
--
http://mail.python.org/mailman/listinfo/python-list
Re: Python and Ruby
Nobody nob...@nowhere.com writes: On Mon, 01 Feb 2010 14:35:57 -0800, Jonathan Gardner wrote: If it was common-place to use Curried functions and partial application in Python, you'd probably prefer f a b c to f(a)(b)(c) as well. That's just the point. It isn't common to play with curried functions or monads or anything like that in computer science today. Yes, Haskell exists, and is a great experiment in how such a language could actually work. But at the same time, you have to have a brain the size of the titanic to contain all the little details about the language before you could write any large-scale application. No, not really. Haskell (and previously ML) are often used as introductory languages in Comp.Sci. courses (at least in the UK). At least in the early 90's this was also the case in the Netherlands, at the University of Utrecht. We got Miranda/Gofer, and in a different, more advanced course Linda (Miranda for parallel machines). Also the inner workings of functional programming languages was a course. (Can't recall the name of the book that was used, but it was quite good IMO). I want to start (re)learning Haskell later this year, because I liked Miranda/Gofer a lot back then. -- John Bokma j3b Hacking Hiking in Mexico - http://johnbokma.com/ http://castleamber.com/ - Perl Python Development -- http://mail.python.org/mailman/listinfo/python-list
Re: Python and Ruby
On Jan 30, 10:43 am, Nobody nob...@nowhere.com wrote: That's also true for most functional languages, e.g. Haskell and ML, as well as e.g. Tcl and most shells. Why require f(x) or (f x) if f x will suffice? yuck! wrapping the arg list with parenthesis (python way) makes the most sense. Its to easy to misread somthing like this onetwothree four five six onetwothree(four, five, six) #ahhh... plain english. -- http://mail.python.org/mailman/listinfo/python-list
Re: Python and Ruby
On Sun, 31 Jan 2010 03:01:51 -0800, rantingrick wrote: On Jan 30, 10:43 am, Nobody nob...@nowhere.com wrote: That's also true for most functional languages, e.g. Haskell and ML, as well as e.g. Tcl and most shells. Why require f(x) or (f x) if f x will suffice? yuck! wrapping the arg list with parenthesis (python way) makes the most sense. Its to easy to misread somthing like this onetwothree four five six onetwothree(four, five, six) #ahhh... plain english. I think the readability factor is mostly down to what you're familiar with. But consistency is also important: in Python, you always refer to an object the same way. Given an object called x, you ALWAYS refer to the object itself as x. In languages that don't use parentheses, x refers to the object, unless the object is a function, in which case x refers to the result of calling the object with no arguments. Other languages need special syntax to get access to the function object itself. Because it's hard to do, people don't do it often. But in Python, getting the function object is easy, and so treating functions as first- class objects is easy. -- Steven -- http://mail.python.org/mailman/listinfo/python-list
Re: Python and Ruby
--- On Sun, 1/31/10, Steven D'Aprano st...@remove-this-cybersource.com.au wrote: From: Steven D'Aprano st...@remove-this-cybersource.com.au Subject: Re: Python and Ruby To: python-list@python.org Date: Sunday, January 31, 2010, 6:35 AM On Sun, 31 Jan 2010 03:01:51 -0800, rantingrick wrote: On Jan 30, 10:43 am, Nobody nob...@nowhere.com wrote: That's also true for most functional languages, e.g. Haskell and ML, as well as e.g. Tcl and most shells. Why require f(x) or (f x) if f x will suffice? yuck! wrapping the arg list with parenthesis (python way) makes the most sense. Its to easy to misread somthing like this onetwothree four five six onetwothree(four, five, six) #ahhh... plain english. I think the readability factor is mostly down to what you're familiar with. But consistency is also important: in Python, you always refer to an object the same way. Given an object called x, you ALWAYS refer to the object itself as x. In languages that don't use parentheses, x refers to the object, unless the object is a function, in which case x refers to the result of calling the object with no arguments. Other languages need special syntax to get access to the function object itself. Because it's hard to do, people don't do it often. But in Python, getting the function object is easy, and so treating functions as first- class objects is easy. In most functional languages you just name a function to access it and you do it ALL the time. for example, in if you have a function 'f' which takes two parameters to call the function and get the result you use: f 2 3 If you want the function itself you use: f The reason no parentheses are used is to support Currying (http://en.wikipedia.org/wiki/Currying). To get a new function which is equivalent to f with the first parameter set to a constant 2 you use: f 2 this give you a function which take only one parameter. Using parenthesis make currying more complicated, so most functional languages do not use them. It did take me a LONG time to get used to this, but it is only syntax, I do not let syntax bother me. Semantics on the other hand, are a big deal. -EdK Ed Keith e_...@yahoo.com Blog: edkeith.blogspot.com -- http://mail.python.org/mailman/listinfo/python-list
Re: Python and Ruby
On Sat, 30 Jan 2010 16:58:34 +, tanix wrote:
I'm not familiar with Ruby, but most languages are cleaner than Python
once you get beyond the 10-minute introduction stage.
I'd have to agree. The only ones that beat Python in that department are
Javascript and PHP. Plus CSS and HTML if you can call those languages.
The very idea of using a number of blanks to identify your block level is
as insane as it gets.
I don't have a problem with layout (indentation level as a syntax element).
First of all, combinations of blanks and tabs,
depending on how your ide is setup to expand tabs, may get you bugs, you'd
never imagine in your wild dreams.
If you IDE places tab stops other than every 8 columns, it's broken.
Configurable tab stops in a text editor is one of those features that
differentiates a coder from a software engineer. A coder implements it
because it's easy to implement, without giving a moment's thought to the
wider context (such as: how to communicate the non-standard tab stops to
any other program which needs to read the file).
Even so, it's quite simple to implement layout in a way which doesn't
care about tab widths:
1. If the current line begins with exactly the same sequence of whitespace
characters as the last non-blank line, it's part of the same block.
2. If the sequence of whitespace characters at the beginning of the
current line is an extension of that for the last non-blank line
(i.e. it starts with the previous sequence, then adds some more
whitespace), then it's the first line of a inner block.
3. If the current line begins with a left substring of the sequence for
the last non-blank line, then it belongs to an outer block (whichever one
has that sequence).
4. If none of the above are true, it's a syntax error.
Braces is the most reliable way to identify blocks.
No they aren't. Indentation is much easier for humans to process than
scanning the file for braces (and not missing any). If you have any
indentation in the code, humans will interpret it as indicating the
nesting, even if the compiler doesn't. E.g.:
if(x) {
if(y)
foo();
else
bar();
}
See the problem? The compiler will match the else with if(y), but a human
will tend to match it with if(x).
Layout ensures that a human sees what the compiler sees.
Given that any sane program uses indentation to reflect the program's
structure, braces (or begin, or end (or endif/endwhile/etc)) are
redundant.
--
http://mail.python.org/mailman/listinfo/python-list
Re: Python and Ruby
On Sun, 31 Jan 2010 03:01:51 -0800, rantingrick wrote: That's also true for most functional languages, e.g. Haskell and ML, as well as e.g. Tcl and most shells. Why require f(x) or (f x) if f x will suffice? yuck! wrapping the arg list with parenthesis (python way) makes the most sense. Its to easy to misread somthing like this onetwothree four five six onetwothree(four, five, six) #ahhh... plain english. Note: Functional languages allow: f (a,b,c) but that means something else, i.e. calling a function with a tuple as its argument (in functional languages, a function always has exactly one argument). The syntax: f a b c is equivalent to the Python expression: f(a)(b)(c) i.e. each argument is applied in turn, with all applications except the last yielding a function. Defining f as: f a b c = expression is shorthand for: f = \a - (\b - (\c - expression)) or, in Python syntax: f = lambda a: (lambda b: (lambda c: expression)) This style (known as Currying, or a Curried function, after the mathematician Haskell Curry) is common in functional languages, as it allows you to partially apply functions, e.g.: map (f a b) someList whereas an uncurried function would require a lambda expression: map (\c - f (a,b,c)) someList IOW, while the uncurried form is allowed, it has no advantages and one disadvantage, so it's seldom used (and where it is used, it's normally a case of a function whose sole argument is a naturally-occurring tuple, rather than one which is constructed simply to satisfy the mechanics of a function call). Partial application is common enough that Haskell supports it for infix operators as well, e.g. map (/ 2) someList -- (/ 2) = \x - x / 2, i.e. halve map (1 /) someList -- (1 /) = \x - 1 / x, i.e. reciprocal If it was common-place to use Curried functions and partial application in Python, you'd probably prefer f a b c to f(a)(b)(c) as well. -- http://mail.python.org/mailman/listinfo/python-list
Re: Python and Ruby
Nobody nob...@nowhere.com writes:
Configurable tab stops in a text editor is one of those features that
differentiates a coder from a software engineer. A coder implements it
because it's easy to implement, without giving a moment's thought to the
wider context (such as: how to communicate the non-standard tab stops to
any other program which needs to read the file).
[..]
if(x) {
if(y)
foo();
else
bar();
}
See the problem?
Nope, because a good editor will format this correctly. One written by
software engineers ;-)
Given that any sane program uses indentation to reflect the program's
structure, braces (or begin, or end (or endif/endwhile/etc)) are
redundant.
An editor can correct the indenting of the braces example but can't with
this one.
if x:
if y:
foo()
else:
bar()
While braces might be considered redundant they are not when for one
reason or another formatting is lost or done incorrectly.
FWIW: I have no problem with how Python doesn't use braces nor on how
other languages do insist on braces or other structure markers.
--
John Bokma j3b
Hacking Hiking in Mexico - http://johnbokma.com/
http://castleamber.com/ - Perl Python Development
--
http://mail.python.org/mailman/listinfo/python-list
Re: Python and Ruby
On Sun, 31 Jan 2010 04:28:41 -0800, Ed Keith wrote: In most functional languages you just name a function to access it and you do it ALL the time. for example, in if you have a function 'f' which takes two parameters to call the function and get the result you use: f 2 3 If you want the function itself you use: f How do you call a function of no arguments? -- Steven -- http://mail.python.org/mailman/listinfo/python-list
Re: Python and Ruby
On Sun, 31 Jan 2010 14:47:08 -0600, John Bokma wrote: An editor can correct the indenting of the braces example but can't with this one. if x: if y: foo() else: bar() While braces might be considered redundant they are not when for one reason or another formatting is lost or done incorrectly. I've heard this argument before, and I don't buy it. Why should we expect the editor to correct malformed code? Would you expect your editor to correct this malformed code? result = sin(x+)y Why should broken indentation be held to a higher standard than any other breakage in code? -- Steven -- http://mail.python.org/mailman/listinfo/python-list
Re: Python and Ruby
On Sun, Jan 31, 2010 at 2:36 PM, Steven D'Aprano st...@remove-this-cybersource.com.au wrote: On Sun, 31 Jan 2010 04:28:41 -0800, Ed Keith wrote: In most functional languages you just name a function to access it and you do it ALL the time. for example, in if you have a function 'f' which takes two parameters to call the function and get the result you use: f 2 3 If you want the function itself you use: f How do you call a function of no arguments? It's not really a function in that case, it's just a named constant. (Recall that functions don't/can't have side-effects.) Cheers, Chris -- http://blog.rebertia.com -- http://mail.python.org/mailman/listinfo/python-list
Re: Python and Ruby
Steven D'Aprano st...@remove-this-cybersource.com.au writes: On Sun, 31 Jan 2010 04:28:41 -0800, Ed Keith wrote: In most functional languages you just name a function to access it and you do it ALL the time. for example, in if you have a function 'f' which takes two parameters to call the function and get the result you use: f 2 3 If you want the function itself you use: f How do you call a function of no arguments? In a functional language, a function of no arguments will always return the same value. So, from a non-functional point of vue, f is both the function and its value. -- Arnaud -- http://mail.python.org/mailman/listinfo/python-list
Re: Python and Ruby
--- On Sun, 1/31/10, Steven D'Aprano st...@remove-this-cybersource.com.au wrote: From: Steven D'Aprano st...@remove-this-cybersource.com.au Subject: Re: Python and Ruby To: python-list@python.org Date: Sunday, January 31, 2010, 5:36 PM On Sun, 31 Jan 2010 04:28:41 -0800, Ed Keith wrote: In most functional languages you just name a function to access it and you do it ALL the time. for example, in if you have a function 'f' which takes two parameters to call the function and get the result you use: f 2 3 If you want the function itself you use: f How do you call a function of no arguments? In a 'pure' functional language a function with no arguments is, by definition, a constant. This is because a 'pure' function will always return the same result whenever given the same arguments. so if it has no argument it always returns a constant value. -EdK Ed Keith e_...@yahoo.com Blog: edkeith.blogspot.com -- http://mail.python.org/mailman/listinfo/python-list
Re: Python and Ruby
On Sun, 31 Jan 2010 15:40:36 -0800, Chris Rebert wrote: On Sun, Jan 31, 2010 at 2:36 PM, Steven D'Aprano st...@remove-this-cybersource.com.au wrote: On Sun, 31 Jan 2010 04:28:41 -0800, Ed Keith wrote: In most functional languages you just name a function to access it and you do it ALL the time. for example, in if you have a function 'f' which takes two parameters to call the function and get the result you use: f 2 3 If you want the function itself you use: f How do you call a function of no arguments? It's not really a function in that case, it's just a named constant. (Recall that functions don't/can't have side-effects.) time.time(), random.random() (1264983502.7505889, 0.29974255140479633) time.time(), random.random() (1264983505.9283719, 0.74207867411026329) They don't look terribly constant to me. There is a difference between a function that does give me whatever value is specified by a fixed description and a function that does give me a fixed value. -- Steven -- http://mail.python.org/mailman/listinfo/python-list
Re: Python and Ruby
Steven D'Aprano st...@remove-this-cybersource.com.au writes:
On Sun, 31 Jan 2010 14:47:08 -0600, John Bokma wrote:
An editor can correct the indenting of the braces example but can't with
this one.
if x:
if y:
foo()
else:
bar()
While braces might be considered redundant they are not when for one
reason or another formatting is lost or done incorrectly.
I've heard this argument before, and I don't buy it. Why should we expect
the editor to correct malformed code?
Or a prettyfier. It doesn't matter. The point is that with braces there
*is* redundancy that be used to fix the code.
Would you expect your editor to correct this malformed code?
result = sin(x+)y
Nice straw man.
Let me repeat again: I am ok with how Python works. To be honest I think
it's cleaner compared to using {}. But in there are real life examples
in which Python code will break where code with braces will survive.
--
John Bokma j3b
Hacking Hiking in Mexico - http://johnbokma.com/
http://castleamber.com/ - Perl Python Development
--
http://mail.python.org/mailman/listinfo/python-list
Re: Python and Ruby
On Sun, Jan 31, 2010 at 4:25 PM, Steven D'Aprano ste...@remove.this.cybersource.com.au wrote: On Sun, 31 Jan 2010 15:40:36 -0800, Chris Rebert wrote: On Sun, Jan 31, 2010 at 2:36 PM, Steven D'Aprano st...@remove-this-cybersource.com.au wrote: On Sun, 31 Jan 2010 04:28:41 -0800, Ed Keith wrote: In most functional languages you just name a function to access it and you do it ALL the time. for example, in if you have a function 'f' which takes two parameters to call the function and get the result you use: f 2 3 If you want the function itself you use: f How do you call a function of no arguments? It's not really a function in that case, it's just a named constant. (Recall that functions don't/can't have side-effects.) time.time(), random.random() (1264983502.7505889, 0.29974255140479633) time.time(), random.random() (1264983505.9283719, 0.74207867411026329) They don't look terribly constant to me. Those aren't functions in the pure functional programming sense; which is unsurprising since Python isn't a [pure] functional language. They both involve side-effects. time() does I/O to the clock chip to see what time it is, and random() uses and changes a global seed value variable (which, in a double-whammy, takes its initial value from time()). Pure functions must be referentially transparent [http://en.wikipedia.org/wiki/Referential_transparency_(computer_science)], and as you've demonstrated, neither of those Python functions qualify. Cheers, Chris -- http://blog.rebertia.com -- http://mail.python.org/mailman/listinfo/python-list
Re: Python and Ruby
Steven D'Aprano st...@remove-this-cybersource.com.au writes: On Sun, 31 Jan 2010 14:47:08 -0600, John Bokma wrote: An editor can correct the indenting of the braces example but can't with this one. if x: if y: foo() else: bar() While braces might be considered redundant they are not when for one reason or another formatting is lost or done incorrectly. I've heard this argument before, and I don't buy it. Why should we expect the editor to correct malformed code? I do expect my editor to assist me in coding. In Emacs I have to do some effort to enter the broken C code in the earlier post, and when I reformat the code, it will be lined out correctly. I can't do that with the above example, because it's correctly formatted. You don't have to buy my argument, I am not selling it. While in the past I wrote that an editor can't make you that more productive I want to take that back, on the record. Since I've switched to Emacs the editor has saved me several times from minor issues. Either because it refused to indent correctly thanks to a missing closing }, ), ] or other error. With the correct mode in Emacs one gets, in my experience, immediate feedback when making mistakes one otherwise find during the run/compiling phase. Note that I am also not selling Emacs. It's free after all. -- John Bokma j3b Hacking Hiking in Mexico - http://johnbokma.com/ http://castleamber.com/ - Perl Python Development -- http://mail.python.org/mailman/listinfo/python-list
Re: Python and Ruby
On Sun, 31 Jan 2010 16:50:50 -0800, Chris Rebert wrote: How do you call a function of no arguments? It's not really a function in that case, it's just a named constant. (Recall that functions don't/can't have side-effects.) time.time(), random.random() (1264983502.7505889, 0.29974255140479633) time.time(), random.random() (1264983505.9283719, 0.74207867411026329) They don't look terribly constant to me. Those aren't functions in the pure functional programming sense; which is unsurprising since Python isn't a [pure] functional language. They both involve side-effects. time() does I/O to the clock chip to see what time it is, and random() uses and changes a global seed value variable (which, in a double-whammy, takes its initial value from time()). Yes, but these tasks -- get the time, get a (pseudo) random number -- are not unique to Python. Surely even Lisp and Haskell code will sometimes need to know the time. Whether they are pure functions (functions in the mathematical sense) or impure, they're still functions in some sense. How do you deal with such impure functions? -- Steven -- http://mail.python.org/mailman/listinfo/python-list
Re: Python and Ruby
--- On Sun, 1/31/10, Steven D'Aprano ste...@remove.this.cybersource.com.au wrote: From: Steven D'Aprano ste...@remove.this.cybersource.com.au Subject: Re: Python and Ruby To: python-list@python.org Date: Sunday, January 31, 2010, 8:22 PM On Sun, 31 Jan 2010 16:50:50 -0800, Chris Rebert wrote: How do you call a function of no arguments? It's not really a function in that case, it's just a named constant. (Recall that functions don't/can't have side-effects.) time.time(), random.random() (1264983502.7505889, 0.29974255140479633) time.time(), random.random() (1264983505.9283719, 0.74207867411026329) They don't look terribly constant to me. Those aren't functions in the pure functional programming sense; which is unsurprising since Python isn't a [pure] functional language. They both involve side-effects. time() does I/O to the clock chip to see what time it is, and random() uses and changes a global seed value variable (which, in a double-whammy, takes its initial value from time()). Yes, but these tasks -- get the time, get a (pseudo) random number -- are not unique to Python. Surely even Lisp and Haskell code will sometimes need to know the time. Whether they are pure functions (functions in the mathematical sense) or impure, they're still functions in some sense. How do you deal with such impure functions? You pass it a monad (http://en.wikipedia.org/wiki/Monad_(functional_programming)). -EdK Ed Keith e_...@yahoo.com Blog: edkeith.blogspot.com -- http://mail.python.org/mailman/listinfo/python-list
Re: Python and Ruby
On Sun, Jan 31, 2010 at 5:22 PM, Steven D'Aprano ste...@remove.this.cybersource.com.au wrote: On Sun, 31 Jan 2010 16:50:50 -0800, Chris Rebert wrote: How do you call a function of no arguments? It's not really a function in that case, it's just a named constant. (Recall that functions don't/can't have side-effects.) time.time(), random.random() (1264983502.7505889, 0.29974255140479633) time.time(), random.random() (1264983505.9283719, 0.74207867411026329) They don't look terribly constant to me. Those aren't functions in the pure functional programming sense; which is unsurprising since Python isn't a [pure] functional language. They both involve side-effects. time() does I/O to the clock chip to see what time it is, and random() uses and changes a global seed value variable (which, in a double-whammy, takes its initial value from time()). Yes, but these tasks -- get the time, get a (pseudo) random number -- are not unique to Python. Surely even Lisp and Haskell code will sometimes need to know the time. Whether they are pure functions (functions in the mathematical sense) or impure, they're still functions in some sense. How do you deal with such impure functions? Make the state explicit, i.e. monads or uniqueness typing. In the case of random(), you have it take the seed explicitly as an argument and have it return a new seed along with the randomly generated number. In the case of time(), you pass around an argument to represent the state of the outside world. I don't quite grok monads, but http://en.wikipedia.org/wiki/Uniqueness_type has a decent example of the general uniqueness type approach. Cheers, Chris -- http://blog.rebertia.com -- http://mail.python.org/mailman/listinfo/python-list
Re: Python and Ruby
On Sun, 31 Jan 2010 18:47:42 -0600, John Bokma wrote:
Steven D'Aprano st...@remove-this-cybersource.com.au writes:
On Sun, 31 Jan 2010 14:47:08 -0600, John Bokma wrote:
An editor can correct the indenting of the braces example but can't
with this one.
if x:
if y:
foo()
else:
bar()
While braces might be considered redundant they are not when for one
reason or another formatting is lost or done incorrectly.
I've heard this argument before, and I don't buy it. Why should we
expect the editor to correct malformed code?
Or a prettyfier. It doesn't matter. The point is that with braces there
*is* redundancy that be used to fix the code.
Prettyfiers are significant in languages that allow braces (or begin/end
tokens) and indentation to go out of sync. Since that can't happen with
Python, it's not a problem that needs solving. Prettyfiers exist to work
around a limitation of languages where indentation is not significant.
Arguing that an advantage of braces is that prettyfiers can work with
them easily is a silly argument. That's like saying an advantage of horse-
drawn buggies over cars is that it will go faster when you hit the horse
with a whip. That's true, but you only need the whip because of the lack
of accelerator pedal.
A much better argument would be that an advantage of significant
indentation is that you no longer need a prettyfier, and a second
advantage is a major reduction in flame wars over coding styles.
Would you expect your editor to correct this malformed code?
result = sin(x+)y
Nice straw man.
It's not a straw man. It's a serious argument. There is an infinite
number of problems with malformed code that your editor can't fix, and
your prettifier can't deal with. Why should we care if indentation is one
more?
There are tools out there (such as some web forum software) that corrupt
whitespace. Those tools are broken, and if you (generic you), as a
developer, are relying on those tools to code with, then shame on you.
And if you're the creator of such broken tools, then shame on you more.
You wouldn't arbitrarily decide to remove leading Es from the user's
text, or trailing full stops, so why do you arbitrarily remove whitespace?
Let me repeat again: I am ok with how Python works. To be honest I think
it's cleaner compared to using {}. But in there are real life examples
in which Python code will break where code with braces will survive.
Yes. So what? They are rare and insignificant in practice. For every line
of code that you get via a webforum that mangles indentation, you get ten
thousand lines of code from some place that doesn't.
So long as code is written by and for human beings, the benefit of
significant indentation is 100% practical, and the practical benefit of
braces will remain insignificant.
--
Steven
--
http://mail.python.org/mailman/listinfo/python-list
Re: Python and Ruby
Steven D'Aprano ste...@remove.this.cybersource.com.au writes: On Sun, 31 Jan 2010 18:47:42 -0600, John Bokma wrote: Steven D'Aprano st...@remove-this-cybersource.com.au writes: On Sun, 31 Jan 2010 14:47:08 -0600, John Bokma wrote: An editor can correct the indenting of the braces example but can't with this one. if x: if y: foo() else: bar() While braces might be considered redundant they are not when for one reason or another formatting is lost or done incorrectly. I've heard this argument before, and I don't buy it. Why should we expect the editor to correct malformed code? Or a prettyfier. It doesn't matter. The point is that with braces there *is* redundancy that be used to fix the code. Prettyfiers are significant in languages that allow braces (or begin/end tokens) and indentation to go out of sync. Since that can't happen with Python, Yes it can. I *have* seen Python with broken indentation on web pages, and good luck sorting it out. Blaming it on broken tools is just another straw man. It happens, and if you're learning Python and interested in that code you have a problem. Snipped the rest, because you start to sound like a zealot. I should've know better. -- John Bokma j3b Hacking Hiking in Mexico - http://johnbokma.com/ http://castleamber.com/ - Perl Python Development -- http://mail.python.org/mailman/listinfo/python-list
Re: Python and Ruby
On 1/31/2010 7:25 PM, Steven D'Aprano wrote: On Sun, 31 Jan 2010 15:40:36 -0800, Chris Rebert wrote: On Sun, Jan 31, 2010 at 2:36 PM, Steven D'Aprano st...@remove-this-cybersource.com.au wrote: On Sun, 31 Jan 2010 04:28:41 -0800, Ed Keith wrote: In most functional languages you just name a function to access it and you do it ALL the time. for example, in if you have a function 'f' which takes two parameters to call the function and get the result you use: f 2 3 If you want the function itself you use: f How do you call a function of no arguments? It's not really a function in that case, it's just a named constant. (Recall that functions don't/can't have side-effects.) Three of you gave essentially identical answers, but I still do not see how given something like def f(): return 1 I differentiate between 'function object at address xxx' and 'int 1' objects. time.time(), random.random() (1264983502.7505889, 0.29974255140479633) time.time(), random.random() (1264983505.9283719, 0.74207867411026329) They don't look terribly constant to me. I believe these are not functions in a functional language sense. Neither are input and output 'functions'. So all of these are either missing or some sort of special function-like something. I personally take a broader view of functions and include the relevant environment in their input and output, so that there are no 'side effects'. The concept of 'side-effect' is somewhat arbitrary. In fields other than computing, like pharmacology and politics, its meaning is somewhat different and a bit corrupt. There is a difference between a function that does give me whatever value is specified by a fixed description and a function that does give me a fixed value. Terry Jan Reedy -- http://mail.python.org/mailman/listinfo/python-list
Re: Python and Ruby
Terry Reedy tjre...@udel.edu writes: Three of you gave essentially identical answers, but I still do not see how given something like def f(): return 1 I differentiate between 'function object at address xxx' and 'int 1' objects. In the languages they are talking about, there is no such thing as a function with no args. A function is closer to a mathematical function, i.e. a mapping from one type to another, so every function has an arg. Haskell and ML do have a Unit type, written (), which is something like Python's None. So in Haskell you could write f () = 1 which means the function f, applied to the Unit value (), results in the value 1. The parens are not function-calling syntax. () is simply a value. For example, you could say y = () z = f y which would mean that z = 1. -- http://mail.python.org/mailman/listinfo/python-list
Re: Python and Ruby
On Sun, 31 Jan 2010 20:22:36 -0800, Paul Rubin wrote: Terry Reedy tjre...@udel.edu writes: Three of you gave essentially identical answers, but I still do not see how given something like def f(): return 1 I differentiate between 'function object at address xxx' and 'int 1' objects. In the languages they are talking about, there is no such thing as a function with no args. A function is closer to a mathematical function, i.e. a mapping from one type to another, so every function has an arg. Suppose I have a function that queries a website http://guessmyname.com for a list of popular names and returns the most popular name on the list. Obviously this name will change from time to time, so I can't just get it once and treat the result as a constant. In a non-functional language, I'd write it something like this: def get_popular_name(): URL = 'http://guessmyname.com' data = fetch(URL) names = parse(data) name = choose(names, 1) return name name = get_popular_name() # call the function with no argument f = decorate(get_popular_name) # treat the function as a 1st class object How would Haskell coders write it? Something like this? def get_popular_name(url): data = fetch url names = parse data name = choose name 1 return name name = get_popular_name 'http://guessmyname.com' # call the function f = decorate get_popular_name # treat the function as a 1st class object But now you're needlessly having the caller, rather than the function, remember an implementation detail of the get_popular_name function. Since the argument couldn't be anything different, I'd immediately think of applying partial: get_popular_name = partial get_popular_name 'http://guessmyname.com' but now how do I call the new function? Is this where you say Monads and everyone's eyes glaze over? -- Steven -- http://mail.python.org/mailman/listinfo/python-list
Re: Python and Ruby
On Sun, 31 Jan 2010 18:53:16 -0600, John Bokma wrote: You don't have to buy my argument, I am not selling it. It's a figure of speech. You are making an argument others have made before, and I don't accept the validity of the argument. -- Steven -- http://mail.python.org/mailman/listinfo/python-list
Re: Python and Ruby
Steven D'Aprano ste...@remove.this.cybersource.com.au writes: How would Haskell coders write it? Something like this? def get_popular_name(url): data = fetch url names = parse data name = choose name 1 return name The syntax and types would be different, but ok, something like that. name = get_popular_name 'http://guessmyname.com' # call the function f = decorate get_popular_name # treat the function as a 1st class object You wouldn't need decorate. You'd just say f = get_popular_name http://guessmyname.com; f is now an I/O action which when executed queries the guessmyname site. but now how do I call the new function? Is this where you say Monads and everyone's eyes glaze over? You'd say something like most_popular_name - f to invoke the action. Yes, explaining the difference between - and = involves monads. You might like the Haskell tutorial http://learnyouahaskell.com . -- http://mail.python.org/mailman/listinfo/python-list
Re: Python and Ruby
On Sun, 31 Jan 2010 21:30:15 -0600, John Bokma wrote: While braces might be considered redundant they are not when for one reason or another formatting is lost or done incorrectly. I've heard this argument before, and I don't buy it. Why should we expect the editor to correct malformed code? Or a prettyfier. It doesn't matter. The point is that with braces there *is* redundancy that be used to fix the code. Prettyfiers are significant in languages that allow braces (or begin/end tokens) and indentation to go out of sync. Since that can't happen with Python, Yes it can. I *have* seen Python with broken indentation on web pages, and good luck sorting it out. Blaming it on broken tools is just another straw man. You're using that term wrong. It looks to me that you don't actually know what a straw man argument is. A straw man argument is when somebody responds to a deliberately weakened or invalid argument as if it had been made by their opponent. You raised the issue that the redundancy which prettyfiers exploit are a good reason for preferring braces, so it's not a straw man argument. It's not a straw man to say that you don't need a code prettyfier if indentation is significant when you raised the issue of prettyfiers in the first place. I certainly accept that braces + indentation do provide redundancy, and if the norm was noisy channels, that redundancy would be valuable. But that's not the norm. Most channels don't delete leading whitespace, and those noisy channels we do deal with (like web forms) tend to introduce far more noise than merely deleting leading whitespace, e.g. word- wrapping long lines. The argument that web pages break indentation, therefore braces are better is a real argument that some people make, but it is very weak. Suppose there was a web page that arbitrarily deleted braces out of some misplaced sense of security. Would anyone argue that this proves that indentation was better and braces were bad? No, of course not -- they would say That website is broken. It happens, and if you're learning Python and interested in that code you have a problem. Yes you do. If you're trying to learn carpentry, and somebody gives you a blunt saw that causes the wood to break rather than cut cleanly, you have a problem. If you're learning to cook, and they give you a put with a hole in it and tell you to make soup in it, you have a problem. Broken tools lead to problems. Snipped the rest, because you start to sound like a zealot. I should've know better. Yeah, whatever. -- Steven -- http://mail.python.org/mailman/listinfo/python-list
Re: Python and Ruby
Steven D'Aprano ste...@remove.this.cybersource.com.au wrote: You're using that term wrong. It looks to me that you don't actually know what a straw man argument is. A straw man argument is when somebody responds to a deliberately weakened or invalid argument as if it had been made by their opponent. Jeez, Steve, you're beginning to sound like some kind of fallacy zealot... ;) -- http://mail.python.org/mailman/listinfo/python-list
Re: Python and Ruby
On Sun, Jan 31, 2010 at 10:05 PM, Steven D'Aprano ste...@remove.this.cybersource.com.au wrote: On Sun, 31 Jan 2010 20:22:36 -0800, Paul Rubin wrote: Terry Reedy tjre...@udel.edu writes: Three of you gave essentially identical answers, but I still do not see how given something like def f(): return 1 I differentiate between 'function object at address xxx' and 'int 1' objects. In the languages they are talking about, there is no such thing as a function with no args. A function is closer to a mathematical function, i.e. a mapping from one type to another, so every function has an arg. Suppose I have a function that queries a website http://guessmyname.com for a list of popular names and returns the most popular name on the list. Obviously this name will change from time to time, so I can't just get it once and treat the result as a constant. In a non-functional language, I'd write it something like this: def get_popular_name(): URL = 'http://guessmyname.com' data = fetch(URL) names = parse(data) name = choose(names, 1) return name name = get_popular_name() # call the function with no argument f = decorate(get_popular_name) # treat the function as a 1st class object How would Haskell coders write it? snip Is this where you say Monads and everyone's eyes glaze over? Yeah, basically. Your function has side-effects (i.e. it does I/O over the network), and thus some extra hoops need to be jumped through to reconcile that with the functional purity of the language. Assuming my understanding of monads is somewhat correct: get_popular_name would have the type: IO () - IO String i.e. it takes no real parameters but does I/O, and returns a String. IO is a generic type, thus IO () is like IOvoid, and IO String is IOString (using Java/C#-like generics syntax). Wrapping things in IOs (the IO monad) is how the type system models that I/O side effects are involved. So, get_popular_name would end up taking one argument, IO (). Now where does the caller get an IO () ? Well, the toplevel (i.e. the main function) is allowed to do IO (otherwise, we couldn't write very interesting programs), and thus is provided with an IO by the environment (through some sort of magic). Using this, it passes an IO () to get_popular_name (or it gets passed down the call stack and eventually winds up at get_popular_name) and we get back an IO String. And through some further monad trickery, we make sure that lazy evaluation is effectively bypassed for the I/O and we are able to rip the String out of its IO container and pass it to pure functions. And using the dark magic of do-notation, we write the parts involving IO in pseudo-imperative style (the - operator Paul mentioned is part of that). And there you have it (I think/hope). Supposedly, in practice, you don't need to know the monad guts of how the I/O system works in order to use it, you just need to be able to write do-notation. Cheers, Chris -- I really should read the monad chapters of my copy of Real World Haskell. http://blog.rebertia.com -- http://mail.python.org/mailman/listinfo/python-list
Re: Python and Ruby
On Sun, 31 Jan 2010 22:43:56 -0800, alex23 wrote: Steven D'Aprano ste...@remove.this.cybersource.com.au wrote: You're using that term wrong. It looks to me that you don't actually know what a straw man argument is. A straw man argument is when somebody responds to a deliberately weakened or invalid argument as if it had been made by their opponent. Jeez, Steve, you're beginning to sound like some kind of fallacy zealot... ;) Death to all those who confuse agumentum ad populum with argumentum ad verecundiam!!! -- Steven -- http://mail.python.org/mailman/listinfo/python-list
Re: Python and Ruby
Chris Rebert c...@rebertia.com writes: get_popular_name would have the type: IO () - IO String I don't know if it makes the explanation any clearer, but I think that isn't quite right. The Python version would have type String - IO String. The parameterless Haskell version would just be an I/O action, with type IO String. IO () is not really involved. -- http://mail.python.org/mailman/listinfo/python-list
Re: Python and Ruby
On Wed, 27 Jan 2010 15:29:05 -0800, Jonathan Gardner wrote: There's a lot of magic in Ruby as well. For instance, function calls are made without parentheses. That's also true for most functional languages, e.g. Haskell and ML, as well as e.g. Tcl and most shells. Why require f(x) or (f x) if f x will suffice? Python is much, much cleaner. I don't know how anyone can honestly say Ruby is cleaner than Python. I'm not familiar with Ruby, but most languages are cleaner than Python once you get beyond the 10-minute introduction stage. -- http://mail.python.org/mailman/listinfo/python-list
Re: Python and Ruby
In article pan.2010.01.30.16.43.18.172...@nowhere.com, Nobody nob...@nowhere.com wrote: On Wed, 27 Jan 2010 15:29:05 -0800, Jonathan Gardner wrote: There's a lot of magic in Ruby as well. For instance, function calls are made without parentheses. That's also true for most functional languages, e.g. Haskell and ML, as well as e.g. Tcl and most shells. Why require f(x) or (f x) if f x will suffice? Python is much, much cleaner. I don't know how anyone can honestly say Ruby is cleaner than Python. I'm not familiar with Ruby, but most languages are cleaner than Python once you get beyond the 10-minute introduction stage. I'd have to agree. The only ones that beat Python in that department are Javascript and PHP. Plus CSS and HTML if you can call those languages. The very idea of using a number of blanks to identify your block level is as insane as it gets. First of all, combinations of blanks and tabs, depending on how your ide is setup to expand tabs, may get you bugs, you'd never imagine in your wild dreams. Braces is the most reliable way to identify blocks. Sane compilers ignore blanks altogether. -- Programmer's Goldmine collections: http://preciseinfo.org Tens of thousands of code examples and expert discussions on C++, MFC, VC, ATL, STL, templates, Java, Python, Javascript, PHP, organized by major topics of language, tools, methods, techniques. All collections are fully searchable down to specific chapter. -- http://mail.python.org/mailman/listinfo/python-list
Re: Python and Ruby
--- On Sat, 1/30/10, Nobody nob...@nowhere.com wrote: From: Nobody nob...@nowhere.com Python is much, much cleaner. I don't know how anyone can honestly say Ruby is cleaner than Python. I'm not familiar with Ruby, but most languages are cleaner than Python once you get beyond the 10-minute introduction stage. You need to be clear about what you mean by clean. Is Python scoping clean? I suspect lots of people would argue either side. -EdK Ed Keith e_...@yahoo.com Blog: edkeith.blogspot.com -- http://mail.python.org/mailman/listinfo/python-list
