Re: [Python-ideas] A suggestion for Python 3 vs Python 2
>An interesting methodology; however, I think PERL already has
>conquered this corner of the language world.
I think Perl has much lower efficiency than python, especially you need to
type a $ before every variable. The input effort of $ is very high because
you need to press shift.
Also, you need to type {} for every function/for/while structure.
In terms of language efficiency, I think Perl is no comparison to Python.
We can roughly estimate the input effort of every key in the following way:
Normal alphabet keys: effort=1
Numbers 0~9: effort=1.2
Shift/Tab: effort=0.6
Ctrl/Alt: effort=0.8
{}[];'\,./-=: effort=1.2
(effort measures how difficult it is to press the key)
Therefore, any composed keys like shift+9='(', the input effort is
0.6+1.2=1.8
that's why we should try to avoid composed keys if it's not necessary.
>>"Advantages of print being a function:
* You can override it. Can't do that with a special language element.
* It can be used in map, lambda, and other expression contexts.
* Precedence etc follows the normal rules of functions - the arguments
are all tidily enclosed.
* Keyword arguments, rather than magical syntax, handle the oddities
like end=" ".
* You can easily alias it: "p = print; p('Hello, world!')"
I do agree that print should remain as a function logically. But is there a
way to make it as simple as in python 2, or even simpler, for example:
pr >>sys.stderr, 'hello world'
xuancong
On Tue, Nov 12, 2013 at 11:56 AM, Mark Janssen <dreamingforward@gmail.com>wrote:
> On Mon, Nov 11, 2013 at 7:45 PM, Xuancong Wang <xuancong84@gmail.com>
> wrote:
> > As you know, reading from and writing to IO is a high frequency
> operation.
> > By entropy coding theorem (e.g. Huffman coding), an efficient language
> > should assign shorter language code to more frequent tasks. Typing a '('
> > requires holding SHIFT and pressing 9, the input effort is much higher
> than
> > that in Python 2. Also, specifying IO has changed from >>* to file=*,
> which
> > also becomes more inconvenient.
>
> An interesting methodology; however, I think PERL already has
> conquered this corner of the language world.
> --
> MarkJ
> Tacoma, Washington
>
On Mon, Nov 11, 2013 at 11:03 PM, Xuancong Wang <xuancong84@gmail.com> wrote:
I do agree that print should remain as a function logically. But is there a way to make it as simple as in python 2, or even simpler, for example: pr >>sys.stderr, 'hello world'
It cannot get any more simple than doing what it is named to do. print prints. Anything else is not readable.
On Tue, Nov 12, 2013 at 4:23 PM, Brian Curtin <brian@python.org> wrote:
On Mon, Nov 11, 2013 at 11:03 PM, Xuancong Wang <xuancong84@gmail.com> wrote:
I do agree that print should remain as a function logically. But is there a way to make it as simple as in python 2, or even simpler, for example: pr >>sys.stderr, 'hello world'
It cannot get any more simple than doing what it is named to do. print prints. Anything else is not readable.
It's funny how many words we have that all quite validly describe the concept of producing console output. C calls it "print" (printf), or "write"; Python calls it "print"; REXX opts for "say"; C++ goes for "cout" (console output)... yet all of them are very clear, in their own way, and nobody expects Python to create hard copies or REXX to use the speaker :) ChrisA
On Tue, Nov 12, 2013 at 04:31:56PM +1100, Chris Angelico wrote:
It's funny how many words we have that all quite validly describe the concept of producing console output. C calls it "print" (printf), or "write"; Python calls it "print"; REXX opts for "say"; C++ goes for "cout" (console output)... yet all of them are very clear, in their own way, and nobody expects Python to create hard copies or REXX to use the speaker :)
I don't know about that. Expecting print to generate hardcopy output is something which beginners to programming often need to unlearn. If print doesn't print, which command do you use to actually print? As for REXX, I expected "say" to use the speaker. That's what the "say" command does in Applescript, for example. -- Steven
On Tue, Nov 12, 2013 at 6:14 PM, Steven D'Aprano <steve@pearwood.info> wrote:
I don't know about that. Expecting print to generate hardcopy output is something which beginners to programming often need to unlearn. If print doesn't print, which command do you use to actually print?
Why, LPRINT of course! Yes, I was tainted by BASIC in my early days. ChrisA
On 12/11/2013 07:14, Steven D'Aprano wrote:
On Tue, Nov 12, 2013 at 04:31:56PM +1100, Chris Angelico wrote:
It's funny how many words we have that all quite validly describe the concept of producing console output. C calls it "print" (printf), or "write"; Python calls it "print"; REXX opts for "say"; C++ goes for "cout" (console output)... yet all of them are very clear, in their own way, and nobody expects Python to create hard copies or REXX to use the speaker :)
I don't know about that. Expecting print to generate hardcopy output is something which beginners to programming often need to unlearn. If print doesn't print, which command do you use to actually print?
As for REXX, I expected "say" to use the speaker. That's what the "say" command does in Applescript, for example.
I remember a review of a micro (Sharp?) many years ago. The reviewer tried of its version of Basic, using the PRINT command, and was surprised when the printer sprang into life. It turned out that the command for printing to the screen was DISPLAY.
You probably ought to weigh the ease of typing against readability. Which
is more important? By how much? If 10% more effort typing makes for 5%
better readability, but the code is read 5 times as often as it is edited,
is that then worth it?
Separately, have you measured typing speed rigorously?
On Monday, November 11, 2013, Xuancong Wang wrote:
> >An interesting methodology; however, I think PERL already has
> >conquered this corner of the language world.
>
> I think Perl has much lower efficiency than python, especially you need to
> type a $ before every variable. The input effort of $ is very high because
> you need to press shift.
>
> Also, you need to type {} for every function/for/while structure.
>
> In terms of language efficiency, I think Perl is no comparison to Python.
>
> We can roughly estimate the input effort of every key in the following way:
> Normal alphabet keys: effort=1
> Numbers 0~9: effort=1.2
> Shift/Tab: effort=0.6
> Ctrl/Alt: effort=0.8
> {}[];'\,./-=: effort=1.2
> (effort measures how difficult it is to press the key)
> Therefore, any composed keys like shift+9='(', the input effort is
> 0.6+1.2=1.8
> that's why we should try to avoid composed keys if it's not necessary.
>
> >>"Advantages of print being a function:
> * You can override it. Can't do that with a special language element.
> * It can be used in map, lambda, and other expression contexts.
> * Precedence etc follows the normal rules of functions - the arguments
> are all tidily enclosed.
> * Keyword arguments, rather than magical syntax, handle the oddities
> like end=" ".
> * You can easily alias it: "p = print; p('Hello, world!')"
>
> I do agree that print should remain as a function logically. But is there
> a way to make it as simple as in python 2, or even simpler, for example:
> pr >>sys.stderr, 'hello world'
>
> xuancong
>
>
> On Tue, Nov 12, 2013 at 11:56 AM, Mark Janssen <dreamingforward@gmail.com<javascript:_e({}, 'cvml', 'dreamingforward@gmail.com');>
> > wrote:
>
>> On Mon, Nov 11, 2013 at 7:45 PM, Xuancong Wang <xuancong84@gmail.com<javascript:_e({}, 'cvml', 'xuancong84@gmail.com');>>
>> wrote:
>> > As you know, reading from and writing to IO is a high frequency
>> operation.
>> > By entropy coding theorem (e.g. Huffman coding), an efficient language
>> > should assign shorter language code to more frequent tasks. Typing a '('
>> > requires holding SHIFT and pressing 9, the input effort is much higher
>> than
>> > that in Python 2. Also, specifying IO has changed from >>* to file=*,
>> which
>> > also becomes more inconvenient.
>>
>> An interesting methodology; however, I think PERL already has
>> conquered this corner of the language world.
>> --
>> MarkJ
>> Tacoma, Washington
>>
>
>
--
--Guido van Rossum (on iPad)
On Tue, Nov 12, 2013 at 8:03 AM, Xuancong Wang <xuancong84@gmail.com> wrote:
I think Perl has much lower efficiency than python, especially you need to type a $ before every variable. The input effort of $ is very high because you need to press shift.
Also, you need to type {} for every function/for/while structure.
In terms of language efficiency, I think Perl is no comparison to Python.
And even in Python you can write inefficient. One of the reasons Mercurial got awesome without all the community support that Git had, is efficient coding style that enables typing at the speed of thought. Quoting http://mercurial.selenic.com/wiki/CodingStyle?action=recall&rev=17 "in general, don't make mpm use his shift key any more than he has to" I really like the hack with applying Huffman code to human brain behavior. Speaking of Mercurial vs Git, I hate Git in command line, because of notoriously long subcommand syntax, where HG uses adaptive shortcuts.
We can roughly estimate the input effort of every key in the following way: Normal alphabet keys: effort=1 Numbers 0~9: effort=1.2 Shift/Tab: effort=0.6 Ctrl/Alt: effort=0.8 {}[];'\,./-=: effort=1.2 (effort measures how difficult it is to press the key) Therefore, any composed keys like shift+9='(', the input effort is 0.6+1.2=1.8 that's why we should try to avoid composed keys if it's not necessary.
The methodology metrics rocks! =) But for me it would be differently: Numbers 0~9: effort=1 Left Shift/Ctrl: effort=0.8 Alt: effort=0.5 Tab: effort=0.5 Right Shift: effort=1.2 Right Ctrl: effort=0.6 And in terms of print frequency occurrences it needs to be applied to interaction Python sessions, editor commands, not just to final source code.
participants (7)
-
anatoly techtonik -
Brian Curtin -
Chris Angelico -
Guido van Rossum -
MRAB -
Steven D'Aprano -
Xuancong Wang