Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.python > #24643 > unrolled thread
| Started by | "Littlefield, Tyler" <tyler@tysdomain.com> |
|---|---|
| First post | 2012-06-28 20:57 -0600 |
| Last post | 2012-07-06 10:37 +0100 |
| Articles | 20 on this page of 134 — 34 participants |
Back to article view | Back to comp.lang.python
code review "Littlefield, Tyler" <tyler@tysdomain.com> - 2012-06-28 20:57 -0600
Re: code review alex23 <wuwei23@gmail.com> - 2012-06-28 20:58 -0700
Re: code review Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2012-06-29 07:31 +0000
Re: code review Chris Angelico <rosuav@gmail.com> - 2012-06-29 17:42 +1000
Re: code review "Littlefield, Tyler" <tyler@tysdomain.com> - 2012-06-29 09:03 -0600
Re: code review Alister <alister.ware@ntlworld.com> - 2012-06-29 19:41 +0000
Re: code review MRAB <python@mrabarnett.plus.com> - 2012-06-29 21:09 +0100
Re: code review "Martin P. Hellwig" <martin.hellwig@gmail.com> - 2012-06-29 13:27 -0700
Re: code review Alister <alister.ware@ntlworld.com> - 2012-06-29 20:43 +0000
Re: code review Dennis Lee Bieber <wlfraed@ix.netcom.com> - 2012-06-29 19:02 -0400
Re: code review Terry Reedy <tjreedy@udel.edu> - 2012-06-29 23:02 -0400
Re: code review "Littlefield, Tyler" <tyler@tysdomain.com> - 2012-06-29 14:49 -0600
Re: code review Alister <alister.ware@ntlworld.com> - 2012-06-30 09:31 +0000
Re: code review Alister <alister.ware@ntlworld.com> - 2012-06-30 09:36 +0000
Re: code review Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2012-06-30 02:28 +0000
Re: code review Alister <alister.ware@ntlworld.com> - 2012-06-30 09:22 +0000
Re: code review Terry Reedy <tjreedy@udel.edu> - 2012-06-29 23:00 -0400
Re: code review Alister <alister.ware@ntlworld.com> - 2012-06-30 10:04 +0000
Re: code review Peter Otten <__peter__@web.de> - 2012-06-30 12:29 +0200
Re: code review Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2012-06-30 20:39 +0200
Re: code review Thomas Jollans <t@jollybox.de> - 2012-06-30 21:38 +0200
Re: code review Alister <alister.ware@ntlworld.com> - 2012-06-30 20:30 +0000
Re: code review Thomas Jollans <t@jollybox.de> - 2012-06-30 22:50 +0200
Re: code review Alain Ketterlin <alain@dpt-info.u-strasbg.fr> - 2012-06-30 23:07 +0200
Re: code review Thomas Jollans <t@jollybox.de> - 2012-06-30 23:35 +0200
Re: code review Terry Reedy <tjreedy@udel.edu> - 2012-06-30 17:47 -0400
Re: code review Thomas Jollans <t@jollybox.de> - 2012-07-01 00:05 +0200
Re: code review Alain Ketterlin <alain@dpt-info.u-strasbg.fr> - 2012-07-01 01:03 +0200
Re: code review Ben Finney <ben+python@benfinney.id.au> - 2012-07-01 10:08 +1000
Re: code review Chris Angelico <rosuav@gmail.com> - 2012-07-01 10:37 +1000
Re: code review Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2012-07-01 03:23 +0000
Re: code review Chris Angelico <rosuav@gmail.com> - 2012-07-01 13:48 +1000
Re: code review Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2012-07-01 06:54 +0000
Re: code review Chris Angelico <rosuav@gmail.com> - 2012-07-01 16:59 +1000
Re: code review Terry Reedy <tjreedy@udel.edu> - 2012-07-01 05:55 -0400
Re: code review Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2012-07-02 01:26 +0000
Re: code review Albert van der Horst <albert@spenarnc.xs4all.nl> - 2012-07-13 12:30 +0000
Re: code review Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2012-07-13 15:04 +0000
Re: code review Chris Angelico <rosuav@gmail.com> - 2012-07-14 01:36 +1000
Re: code review rusi <rustompmody@gmail.com> - 2012-07-13 09:24 -0700
Re: code review Dennis Lee Bieber <wlfraed@ix.netcom.com> - 2012-07-13 16:39 -0400
Re: code review Duncan Booth <duncan.booth@invalid.invalid> - 2012-07-16 10:43 +0000
Re: code review Ben Finney <ben+python@benfinney.id.au> - 2012-07-16 21:34 +1000
Re: code review Albert van der Horst <albert@spenarnc.xs4all.nl> - 2012-07-17 10:54 +0000
Re: code review Terry Reedy <tjreedy@udel.edu> - 2012-07-13 19:09 -0400
Re: code review Ian Kelly <ian.g.kelly@gmail.com> - 2012-07-14 03:26 -0600
Re: code review Terry Reedy <tjreedy@udel.edu> - 2012-07-14 16:42 -0400
Re: code review rusi <rustompmody@gmail.com> - 2012-06-30 21:07 -0700
Re: code review Chris Angelico <rosuav@gmail.com> - 2012-07-01 14:20 +1000
Re: code review Ben Finney <ben+python@benfinney.id.au> - 2012-07-01 17:28 +1000
Re: code review Thomas Jollans <t@jollybox.de> - 2012-07-01 09:46 +0200
Re: code review HoneyMonster <nobody@someplace.invalid> - 2012-07-01 20:53 +0000
Re: code review Devin Jeanpierre <jeanpierreda@gmail.com> - 2012-07-01 05:18 -0400
Re: code review Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2012-07-02 00:41 +0000
Re: code review Devin Jeanpierre <jeanpierreda@gmail.com> - 2012-07-01 21:40 -0400
Re: code review Dennis Lee Bieber <wlfraed@ix.netcom.com> - 2012-07-01 13:41 -0400
Re: code review John O'Hagan <research@johnohagan.com> - 2012-07-02 14:43 +1000
Re: Re: code review Evan Driscoll <driscoll@cs.wisc.edu> - 2012-06-30 23:45 -0500
Re: Re: code review Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2012-07-01 08:57 +0200
Re: code review Alister <alister.ware@ntlworld.com> - 2012-07-01 09:54 +0000
Re: Re: code review Evan Driscoll <driscoll@cs.wisc.edu> - 2012-07-01 10:48 -0500
Re: Re: code review lars van gemerden <lars@rational-it.com> - 2012-07-06 04:22 -0700
Re: Re: code review lars van gemerden <lars@rational-it.com> - 2012-07-06 04:22 -0700
Re: code review Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2012-07-06 13:58 +0000
Re: code review Roy Smith <roy@panix.com> - 2012-07-13 08:32 -0700
Re: code review Evan Driscoll <driscoll@cs.wisc.edu> - 2012-06-30 23:57 -0500
Re: code review Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2012-07-01 09:04 +0200
Re: code review Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2012-07-01 02:06 +0000
Re: code review Chris Angelico <rosuav@gmail.com> - 2012-07-01 12:20 +1000
Re: code review Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2012-07-01 04:17 +0000
Re: code review Chris Angelico <rosuav@gmail.com> - 2012-07-01 14:23 +1000
Re: code review Steven D'Aprano <steve+usenet@pearwood.info> - 2012-07-01 06:27 +0000
Re: code review Chris Angelico <rosuav@gmail.com> - 2012-07-01 16:33 +1000
Re: code review Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2012-07-02 01:28 +0000
Re: code review Devin Jeanpierre <jeanpierreda@gmail.com> - 2012-07-01 21:50 -0400
Re: code review Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2012-07-02 07:29 +0000
Re: code review Chris Angelico <rosuav@gmail.com> - 2012-07-02 12:04 +1000
Re: code review Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2012-07-02 08:11 +0000
Re: code review Chris Angelico <rosuav@gmail.com> - 2012-07-02 18:20 +1000
Re: code review Rick Johnson <rantingrickjohnson@gmail.com> - 2012-07-02 08:57 -0700
Re: code review Chris Angelico <rosuav@gmail.com> - 2012-07-03 02:42 +1000
Re: code review Rick Johnson <rantingrickjohnson@gmail.com> - 2012-07-02 11:22 -0700
Re: code review Thomas Jollans <t@jollybox.de> - 2012-07-02 21:06 +0200
Re: code review Rick Johnson <rantingrickjohnson@gmail.com> - 2012-07-02 12:35 -0700
Re: code review Chris Angelico <rosuav@gmail.com> - 2012-07-03 07:57 +1000
Re: code review Neil Cerutti <neilc@norwich.edu> - 2012-07-03 12:19 +0000
Re: code review Dennis Lee Bieber <wlfraed@ix.netcom.com> - 2012-07-02 01:20 -0400
Re: code review Thomas Jollans <t@jollybox.de> - 2012-07-02 16:41 +0200
Re: code review Terry Reedy <tjreedy@udel.edu> - 2012-07-02 11:33 -0400
Re: code review Thomas Jollans <t@jollybox.de> - 2012-07-01 09:35 +0200
Re: code review Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2012-07-02 00:43 +0000
Re: code review Thomas Jollans <t@jollybox.de> - 2012-07-02 16:26 +0200
Re: code review Rick Johnson <rantingrickjohnson@gmail.com> - 2012-07-02 08:16 -0700
Re: code review Chris Angelico <rosuav@gmail.com> - 2012-07-03 02:55 +1000
Re: code review Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2012-07-03 00:57 +0000
Re: code review Chris Angelico <rosuav@gmail.com> - 2012-07-03 11:22 +1000
Re: code review John O'Hagan <research@johnohagan.com> - 2012-07-03 12:25 +1000
Re: code review Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2012-07-03 04:11 +0000
Re: code review Dennis Lee Bieber <wlfraed@ix.netcom.com> - 2012-07-03 02:09 -0400
Re: code review Roy Smith <roy@panix.com> - 2012-07-03 08:33 -0400
Re: code review Mark Lawrence <breamoreboy@yahoo.co.uk> - 2012-07-03 16:53 +0100
Re: code review Dennis Lee Bieber <wlfraed@ix.netcom.com> - 2012-07-03 17:32 -0400
Re: code review rusi <rustompmody@gmail.com> - 2012-07-02 22:10 -0700
Re: code review Ben Finney <ben+python@benfinney.id.au> - 2012-07-03 15:46 +1000
Re: code review John O'Hagan <research@johnohagan.com> - 2012-07-04 00:59 +1000
Re: code review Mark Lawrence <breamoreboy@yahoo.co.uk> - 2012-07-03 16:50 +0100
Re: code review Paul Rudin <paul.nospam@rudin.co.uk> - 2012-07-04 10:29 +0100
Re: code review Mark Lawrence <breamoreboy@yahoo.co.uk> - 2012-07-04 17:25 +0100
Re: code review Chris Angelico <rosuav@gmail.com> - 2012-07-04 01:53 +1000
Re: code review Mark Lawrence <breamoreboy@yahoo.co.uk> - 2012-07-03 17:05 +0100
Re: code review Dave Angel <d@davea.name> - 2012-07-03 16:13 -0400
Re: code review Chris Angelico <rosuav@gmail.com> - 2012-07-04 07:54 +1000
Re: code review Mark Lawrence <breamoreboy@yahoo.co.uk> - 2012-07-04 09:28 +0100
Re: code review rusi <rustompmody@gmail.com> - 2012-06-30 19:37 -0700
Re: code review Chris Angelico <rosuav@gmail.com> - 2012-07-01 09:25 +1000
Re: code review Thomas Jollans <t@jollybox.de> - 2012-07-01 01:50 +0200
Re: code review "Martin P. Hellwig" <martin.hellwig@gmail.com> - 2012-06-30 14:48 -0700
Re: code review Ian Kelly <ian.g.kelly@gmail.com> - 2012-07-02 13:16 -0600
Re: code review Alister <alister.ware@ntlworld.com> - 2012-06-30 20:25 +0000
Re: code review Kushal Kumaran <kushal.kumaran+python@gmail.com> - 2012-07-03 23:23 +0530
Re: code review John Gordon <gordon@panix.com> - 2012-07-03 18:18 +0000
Re: code review Ian Kelly <ian.g.kelly@gmail.com> - 2012-07-03 12:27 -0600
Re: code review Chris Angelico <rosuav@gmail.com> - 2012-07-04 07:51 +1000
Re: code review Ian Kelly <ian.g.kelly@gmail.com> - 2012-07-03 12:19 -0600
Re: code review kushal.kumaran+python@gmail.com - 2012-07-04 08:27 +0530
Re: code review Chris Angelico <rosuav@gmail.com> - 2012-07-04 13:53 +1000
Re: code review Simon Cropper <simoncropper@fossworkflowguides.com> - 2012-07-04 14:55 +1000
Re: code review "Littlefield, Tyler" <tyler@tysdomain.com> - 2012-07-03 23:39 -0600
Re: code review alex23 <wuwei23@gmail.com> - 2012-07-03 23:17 -0700
Re: code review rusi <rustompmody@gmail.com> - 2012-07-04 00:05 -0700
Apology for OT posts (was: code review) John O'Hagan <research@johnohagan.com> - 2012-07-06 12:06 +1000
Re: Apology for OT posts Simon Cropper <simoncropper@fossworkflowguides.com> - 2012-07-06 15:30 +1000
Re: Apology for OT posts Chris Angelico <rosuav@gmail.com> - 2012-07-06 17:45 +1000
Re: Apology for OT posts Mark Lawrence <breamoreboy@yahoo.co.uk> - 2012-07-06 10:37 +0100
Page 5 of 7 — ← Prev page 1 2 3 4 [5] 6 7 Next page →
| From | Chris Angelico <rosuav@gmail.com> |
|---|---|
| Date | 2012-07-03 02:42 +1000 |
| Message-ID | <mailman.1713.1341247372.4697.python-list@python.org> |
| In reply to | #24778 |
On Tue, Jul 3, 2012 at 1:57 AM, Rick Johnson <rantingrickjohnson@gmail.com> wrote: > Poor Chris. That's because you've been brainwashed into believing you > must spoon feed your interpreter to get your code working correctly. > Stop applying these naive assumptions to Python code. Python knows > when you reach the end of a statement, no need for redundant > semicolons! Python knows when its reached the end of block and needs > to drop back one level, no need for redundant road signs. Python > knows Chris; Python KNOWS! Why "poor", Ralph? I am poor in the essence of ignorance's bliss, rich only in the never-ending thirst for knowledge and more languages. In me there meet a combination of antithetical elements which are at eternal war with one another... I hope I make myself clear, lady? Oops, wrong mailing list. Near enough. Python is not magic. It's not that it "knows" when I reach the end of a statement; it simply rules that line ends correspond to statement ends unless ordered otherwise. It has been told that the reduction of indentation level is a lexer token. Rick, do you realize that you have to spoon-feed the interpreter with spaces/tabs when other interpreters just KNOW to drop back an indentation level when you close a brace? </troll> I simply need to make sure that the interpreter and I have the same understanding of the code. It will then work correctly. There's nothing special about one syntax or another, they're all just communication from my brain to a CPU, and different syntaxes are suited to different tasks. There's nothing inherently wrong with: right_length = len(x) > 5, < 20 being a valid way of expressing a double condition. It puts the query first and the bounds after it, so hey, it's justifiably sane. (No, I'm not advocating adding this. It's just for argument's sake.) Whatever you're writing with, you need to have the same rules in your head as the compiler/interpreter uses; beyond that there's a huge amount of personal preference (I quite like braces, myself, but many others don't) and only a relatively small amount of actual logic (use ASCII mathematical symbols to represent mathematical operations). ChrisA
[toc] | [prev] | [next] | [standalone]
| From | Rick Johnson <rantingrickjohnson@gmail.com> |
|---|---|
| Date | 2012-07-02 11:22 -0700 |
| Message-ID | <f18a74cc-86bc-4fb2-8df8-587051a62883@x39g2000yqx.googlegroups.com> |
| In reply to | #24780 |
On Jul 2, 11:42 am, Chris Angelico <ros...@gmail.com> wrote: > Rick, do you realize that you have > to spoon-feed the interpreter with spaces/tabs when other interpreters > just KNOW to drop back an indentation level when you close a brace? Yes. And significant white space is my favorite attribute of Python source code. But the difference here is like night and day. While your getting bogged down playing "match-the-brackets", i'm writing code and being productive. I don't need to put any mental effort into pressing the Enter+Tab keys. On the contrary, you must constantly break your mental focus to "corral" the braces, and the sad part is, you're still formatting your code like mine (with tabs and newlines!) however your simultaneously juggling superfluously archaic syntax! Why Chris? WHY? > I simply need to make sure that the interpreter and I have the same > understanding of the code. It will then work correctly. There's > nothing special about one syntax or another, I agree in the sense of: "to each his own". However. There are methods of writing code that are more productive, and methods that are less productive, and your emotive agenda of defending such nostalgic pedantry is quite self-defeating. > they're all just > communication from my brain to a CPU, and different syntaxes are > suited to different tasks. There's nothing inherently wrong with: > > right_length = len(x) > 5, < 20 Agreed. I wish we had one language. One which had syntactical directives for scoping, blocks, assignments, etc, etc... BLOCK_INDENT_MARKER -> \t BLOCK_DEDENT_MARKER -> \n STATEMENT_TERMINATOR -> \n ASSIGNMENT_OPERATOR -> := CONDITIONAL_IF_SPELLING -> IF CONDITIONAL_ELSE_SPELLING -> EL ... > (I quite like braces, myself, [...] and only a relatively small > amount of actual logic. So you have a penchant for confinement and an aversion to logic? Hmm, interesting!
[toc] | [prev] | [next] | [standalone]
| From | Thomas Jollans <t@jollybox.de> |
|---|---|
| Date | 2012-07-02 21:06 +0200 |
| Message-ID | <mailman.1716.1341256009.4697.python-list@python.org> |
| In reply to | #24783 |
On 07/02/2012 08:22 PM, Rick Johnson wrote:
> Agreed. I wish we had one language. One which had syntactical
> directives for scoping, blocks, assignments, etc, etc...
>
> BLOCK_INDENT_MARKER -> \t
> BLOCK_DEDENT_MARKER -> \n
> STATEMENT_TERMINATOR -> \n
> ASSIGNMENT_OPERATOR -> :=
> CONDITIONAL_IF_SPELLING -> IF
> CONDITIONAL_ELSE_SPELLING -> EL
> ...
You must be joking.
In C, for example, it is possible to "create your own language" by going
#define IF(cond) if (cond) {
#define ELSE } else {
#define ELIF(cond) } else if (cond) {
#define ENDIF }
and so on. There's a reason nobody does it.
[toc] | [prev] | [next] | [standalone]
| From | Rick Johnson <rantingrickjohnson@gmail.com> |
|---|---|
| Date | 2012-07-02 12:35 -0700 |
| Message-ID | <5940a10f-b19c-4936-b41f-e4a03c42560a@l32g2000yqb.googlegroups.com> |
| In reply to | #24785 |
On Jul 2, 2:06 pm, Thomas Jollans <t...@jollybox.de> wrote: > On 07/02/2012 08:22 PM, Rick Johnson wrote: > > > Agreed. I wish we had one language. One which had syntactical > > directives for scoping, blocks, assignments, etc, etc... > > > BLOCK_INDENT_MARKER -> \t > > BLOCK_DEDENT_MARKER -> \n > > STATEMENT_TERMINATOR -> \n > > ASSIGNMENT_OPERATOR -> := > > CONDITIONAL_IF_SPELLING -> IF > > CONDITIONAL_ELSE_SPELLING -> EL > > ... > > You must be joking. Well i was slightly serious, but mostly sarcastic. Whist customizable syntax would be a great benefit to the individual, it would be a nightmare to the community -- the real solution lies in assimilation! I am reminded of a story: A few years back a very nice old woman offered to give me her typewriter. She said: "i might need to type a letter one day and it would good to have around". It was a nice typewriter for 1956, but she had no idea her little "machine" was reduced to no less than a paper weight thanks to something called the PC. Her machine had been extinct for decades. Effectually, SHE had been extinct for decades. When i hear people like Chris evangelizing about slavish syntax, i am reminded of the nice old lady. Her intentions where virtuous, however her logic was flawed. She is still clinging to old technology. Like the Luddites she refuses to see the importance technological advancements. And by harboring this nostalgia she is actually undermining the future evolution of an entire species. Lifespans are limited for a very important evolutionary reason!
[toc] | [prev] | [next] | [standalone]
| From | Chris Angelico <rosuav@gmail.com> |
|---|---|
| Date | 2012-07-03 07:57 +1000 |
| Message-ID | <mailman.1720.1341266273.4697.python-list@python.org> |
| In reply to | #24783 |
On Tue, Jul 3, 2012 at 5:06 AM, Thomas Jollans <t@jollybox.de> wrote:
> On 07/02/2012 08:22 PM, Rick Johnson wrote:
>> Agreed. I wish we had one language. One which had syntactical
>> directives for scoping, blocks, assignments, etc, etc...
>>
>> BLOCK_INDENT_MARKER -> \t
>> BLOCK_DEDENT_MARKER -> \n
>> STATEMENT_TERMINATOR -> \n
>> ASSIGNMENT_OPERATOR -> :=
>> CONDITIONAL_IF_SPELLING -> IF
>> CONDITIONAL_ELSE_SPELLING -> EL
>> ...
>
> You must be joking.
>
> In C, for example, it is possible to "create your own language" by going
>
> #define IF(cond) if (cond) {
> #define ELSE } else {
> #define ELIF(cond) } else if (cond) {
> #define ENDIF }
>
>
> and so on. There's a reason nobody does it.
I'll go one further. The "create your own language" is just a plain
text file, is in fact is NO LANGUAGE. If it's that flexible, what's
the use of calling it the same language?
Actually there is a lot of use in having that sort of commonality, but
at a different level: source control. Tools like git are
language-agnostic; I can have a repository with Javascript, PHP (ugh),
Pike (that atones), Python, C++, etc source files, a single makefile
that in the darkness binds them, and so on. But they're still all
different languages.
Oh and Rick? Nice troll there with the ellipsis. You fail grammar
forever, but hey, at least you win at trolling.
ChrisA
[toc] | [prev] | [next] | [standalone]
| From | Neil Cerutti <neilc@norwich.edu> |
|---|---|
| Date | 2012-07-03 12:19 +0000 |
| Message-ID | <a5g6b5FlnuU1@mid.individual.net> |
| In reply to | #24780 |
On 2012-07-02, Chris Angelico <rosuav@gmail.com> wrote: > On Tue, Jul 3, 2012 at 1:57 AM, Rick Johnson ><rantingrickjohnson@gmail.com> wrote: >> Poor Chris. That's because you've been brainwashed into believing you >> must spoon feed your interpreter to get your code working correctly. >> Stop applying these naive assumptions to Python code. Python knows >> when you reach the end of a statement, no need for redundant >> semicolons! Python knows when its reached the end of block and needs >> to drop back one level, no need for redundant road signs. Python >> knows Chris; Python KNOWS! > > Why "poor", Ralph? > > I am poor in the essence of ignorance's bliss, rich only in the > never-ending thirst for knowledge and more languages. In me there meet > a combination of antithetical elements which are at eternal war with > one another... I hope I make myself clear, lady? His simple eloquence goes to my very heart! -- Neil Cerutti
[toc] | [prev] | [next] | [standalone]
| From | Dennis Lee Bieber <wlfraed@ix.netcom.com> |
|---|---|
| Date | 2012-07-02 01:20 -0400 |
| Message-ID | <mailman.1698.1341206422.4697.python-list@python.org> |
| In reply to | #24757 |
On 02 Jul 2012 01:28:25 GMT, Steven D'Aprano
<steve+comp.lang.python@pearwood.info> declaimed the following in
gmane.comp.python.general:
>
> When you make unsafe assumptions about an operator, and get bitten by it,
> the *correct* conclusion should be that the assumption was wrong, not
> that the language is wrong.
>
Well, to be fair, the assumption is not about "an operator" but
about a sequence of operators. I don't think there was any question that
"<" was not a "less than comparison" operator.
OTOH: consider
>>> 5 ^ 2
7
>>> 1 < 3 < 5
True
>>> 3 < 5 < 1
False
>>> True < 1
False
>>>
vs
> 5 ^ 2
[1] 25
> 1 < 3 < 5
Error: unexpected '<' in "1 < 3 <"
> TRUE < 1
[1] FALSE
>
vs
? 5 ^ 2
25
? 1 < 3 < 5
True
? 3 < 5 < 1
True
? True < 1
True
vs
PS E:\UserData\Wulfraed\My Documents> 5 ^ 2
Unexpected token '^' in expression or statement.
At line:1 char:3
Unexpected token '2' in expression or statement.
At line:1 char:5
PS E:\UserData\Wulfraed\My Documents> 1 -lt 3 -lt 5
False
PS E:\UserData\Wulfraed\My Documents> 1 -lt 5 -lt 3
False
PS E:\UserData\Wulfraed\My Documents> 1 -lt 5
True
PS E:\UserData\Wulfraed\My Documents> True -lt 1
The term 'True' is not recognized as the name of a cmdlet, function,
script file, or operable program. Check the spelling of the name, or if
a path was included, verify that the path is correct and try again.
At line:1 char:5
+ True <<<< -lt 1
+ CategoryInfo : ObjectNotFound: (True:String) [],
CommandNotFoundException
+ FullyQualifiedErrorId : CommandNotFoundException
PS E:\UserData\Wulfraed\My Documents> 'True' -lt 1
False
PS E:\UserData\Wulfraed\My Documents> 1 -lt 'True'
Bad argument to operator '-lt': Could not compare "1" to "True". Error:
"Cannot convert value "True" to type "System.Int32". Error: "Input
string was not in a correct format."".
At line:1 char:6
+ 1 -lt <<<< 'True'
+ CategoryInfo : InvalidOperation: (:) [], RuntimeException
+ FullyQualifiedErrorId : BadOperatorArgument
PS E:\UserData\Wulfraed\My Documents> $True -lt 1
False
PS E:\UserData\Wulfraed\My Documents> $True -eq 1
True
Python, R, Visual Basic 6, PowerShell 2, respectively.
Obviously, someone coming over from VB or R who hasn't read the
Python reference is going to wonder why they are getting incorrect
results when doing exponentiation (Isn't there an interface from Python
to R? Now there is confusion in the making!)
{Hmmm... R accepts BOTH 5 ** 2 and 5 ^ 2 for exponentiation}
--
Wulfraed Dennis Lee Bieber AF6VN
wlfraed@ix.netcom.com HTTP://wlfraed.home.netcom.com/
[toc] | [prev] | [next] | [standalone]
| From | Thomas Jollans <t@jollybox.de> |
|---|---|
| Date | 2012-07-02 16:41 +0200 |
| Message-ID | <mailman.1710.1341240114.4697.python-list@python.org> |
| In reply to | #24757 |
On 07/02/2012 03:28 AM, Steven D'Aprano wrote: > We *really did have* somebody arguing that chained comparisons are Bad > because you can't stick parentheses around bits of it without changing > the semantics. That was an actual argument, not a straw-man. Ahem. It may have been sub-optimally phrased in a way that opened itself up to attack, but I was arguing that Python comparisons operators are anomalous because they're not associative. (and, going back to the root of the argument, this makes them Bad because "Special cases aren't special enough to break the rules.") On Sun, 01 Jul 2012 21:50:29 -0400, Devin Jeanpierre wrote: > On Sun, Jul 1, 2012 at 9:28 PM, Steven D'Aprano > <steve+comp.lang.python@pearwood.info> wrote: >> Technically, < in Python is left-associative: a < b < c first evaluates >> a, not b or c. But it is left-associative under the rules of comparison >> operator chaining, not arithmetic operator chaining. > > Left-associativity is when a < b < c is equivalent to (a < b) < c.
[toc] | [prev] | [next] | [standalone]
| From | Terry Reedy <tjreedy@udel.edu> |
|---|---|
| Date | 2012-07-02 11:33 -0400 |
| Message-ID | <mailman.1711.1341243222.4697.python-list@python.org> |
| In reply to | #24757 |
On 7/2/2012 1:20 AM, Dennis Lee Bieber wrote: > Obviously, someone coming over from VB or R or any other single language x > who hasn't read the Python reference is going to be surprised as something or other. So what. The manuals, including the tutorial, are there for a reason. The main points of the language take just a few hours to review. Perhaps my advantage learning Python was that I had written code in over 10 other languages and dialects and so had few expectations and made few assumptions. -- Terry Jan Reedy
[toc] | [prev] | [next] | [standalone]
| From | Thomas Jollans <t@jollybox.de> |
|---|---|
| Date | 2012-07-01 09:35 +0200 |
| Message-ID | <mailman.1677.1341128143.4697.python-list@python.org> |
| In reply to | #24714 |
On 07/01/2012 04:06 AM, Steven D'Aprano wrote: > On Sun, 01 Jul 2012 00:05:26 +0200, Thomas Jollans wrote: > >> As soon as you read it as a ternary operator, > > Well that's your problem. Why are you reading it as a ternary operator? > It isn't one. It is a pair of chained binary operator. > > How can you tell that it is a pair of binary operators, rather than a > single ternary operator? > > 1) There are TWO operators, hence a pair, not a single ternary operator; > > 2) each operator takes TWO arguments, not three. This is simply wrong. The comparisons are not acting as binary operators. > You can't just arbitrarily stick parentheses around parts of expressions > and expect the result to remain unchanged. Order of evaluation matters: > > 2**3**4 != (2**3)**4 > > Comparisons are no different. You can't just toss in some arbitrary > brackets and expect the result to be the same. In the second case, the > parentheses explicitly turn the comparison into the equivalent of this: As Chris points out, 2**3**4 == 2**(3**4) For any chain of actual binary operators, it is possible to place brackets around binary sub-expressions such that the meaning of the total expression stays the same. This is true of ALL infix-notated strictly binary operators. This is not true of Python comparison operators. If you're inclined to look at operators in terms of how many arguments they take, then the inescapable conclusion is that a chain of N comparison operators forms one single (N+1)-term operator because it cannot be grouped into binary expressions without rephrasing the expression using "and".
[toc] | [prev] | [next] | [standalone]
| From | Steven D'Aprano <steve+comp.lang.python@pearwood.info> |
|---|---|
| Date | 2012-07-02 00:43 +0000 |
| Message-ID | <4ff0eebf$0$29988$c3e8da3$5496439d@news.astraweb.com> |
| In reply to | #24733 |
On Sun, 01 Jul 2012 09:35:40 +0200, Thomas Jollans wrote:
> On 07/01/2012 04:06 AM, Steven D'Aprano wrote:
>> On Sun, 01 Jul 2012 00:05:26 +0200, Thomas Jollans wrote:
>>
>>> As soon as you read it as a ternary operator,
>>
>> Well that's your problem. Why are you reading it as a ternary operator?
>> It isn't one. It is a pair of chained binary operator.
>>
>> How can you tell that it is a pair of binary operators, rather than a
>> single ternary operator?
>>
>> 1) There are TWO operators, hence a pair, not a single ternary
>> operator;
>>
>> 2) each operator takes TWO arguments, not three.
>
> This is simply wrong. The comparisons are not acting as binary
> operators.
Of course they are. Take this chained comparison:
a < b == c
There are exactly TWO operators. Each one takes TWO arguments.
The < operator takes a and b as arguments. That's TWO, not three.
The == operator takes b and c arguments. Again, that's TWO, not three.
If you want to claim that this is a ternary operator, you need to explain:
1) What is the operator in this expression? Is it < or == or something
else?
2) What double-underscore special method does it call? Where is this
mysterious, secret, undocumented method implemented?
3) Why do the Python docs lie that a < b == c is exactly equivalent to
the short-circuit expression (a < b) and (b == c) with b evaluated once?
4) And how do you explain that the compiled byte code actually calls the
regular two-argument binary operators instead of your imaginary three-
argument ternary operator?
py> from dis import dis
py> dis(compile("a < b == c", "", "single"))
1 0 LOAD_NAME 0 (a)
3 LOAD_NAME 1 (b)
6 DUP_TOP
7 ROT_THREE
8 COMPARE_OP 0 (<)
11 JUMP_IF_FALSE_OR_POP 23
14 LOAD_NAME 2 (c)
17 COMPARE_OP 2 (==)
20 JUMP_FORWARD 2 (to 25)
>> 23 ROT_TWO
24 POP_TOP
>> 25 PRINT_EXPR
26 LOAD_CONST 0 (None)
29 RETURN_VALUE
--
Steven
[toc] | [prev] | [next] | [standalone]
| From | Thomas Jollans <t@jollybox.de> |
|---|---|
| Date | 2012-07-02 16:26 +0200 |
| Message-ID | <mailman.1709.1341239173.4697.python-list@python.org> |
| In reply to | #24754 |
On 07/02/2012 02:43 AM, Steven D'Aprano wrote: > On Sun, 01 Jul 2012 09:35:40 +0200, Thomas Jollans wrote: >> This is simply wrong. The comparisons are not acting as binary >> operators. > > Of course they are. Take this chained comparison: Technically, yes - two-input operations are happening. Syntactically, no. Read my post. > 1) What is the operator in this expression? Is it < or == or something > else? I think I've answered this - it's the combination. > 2) What double-underscore special method does it call? Where is this > mysterious, secret, undocumented method implemented? > > 3) Why do the Python docs lie that a < b == c is exactly equivalent to > the short-circuit expression (a < b) and (b == c) with b evaluated once? > > 4) And how do you explain that the compiled byte code actually calls the > regular two-argument binary operators instead of your imaginary three- > argument ternary operator? In this context, I don't care what actually happens. I'm talking about how the code can be parsed (by the generic reader, not necessarily the python interpreter).
[toc] | [prev] | [next] | [standalone]
| From | Rick Johnson <rantingrickjohnson@gmail.com> |
|---|---|
| Date | 2012-07-02 08:16 -0700 |
| Message-ID | <43f27741-bd1b-4c15-9822-c196b8b0396e@x39g2000yqx.googlegroups.com> |
| In reply to | #24714 |
On Jun 30, 9:06 pm, Steven D'Aprano <steve +comp.lang.pyt...@pearwood.info> wrote: > On Sun, 01 Jul 2012 00:05:26 +0200, Thomas Jollans wrote: > > Yes. My sole point, really, is that "normally", one would expect these > > two expressions to be equivalent: > > > a < b < c > > (a < b) < c > > Good grief. Why would you expect that? > > You can't just arbitrarily stick parentheses around parts of expressions > and expect the result to remain unchanged. Order of evaluation matters: > > 2**3**4 != (2**3)**4 Yes but as Chris points out in the next message, you can inject the following parenthesis without changing a thing!: py> 1 + 3 * 4 13 py> 1 + (3 * 4) 13 Of course i understand the rules of operator precedence, however i have never liked them AND i continue to believe that such functionality breeds bugs and is in fact bad language design. I believe all evaluations should be cumulative: py> 1 + 3 * 4 should ALWAYS equal 16! With parenthesis only used for grouping: py> a + (b*c) + d Which seems like the most consistent approach to me.
[toc] | [prev] | [next] | [standalone]
| From | Chris Angelico <rosuav@gmail.com> |
|---|---|
| Date | 2012-07-03 02:55 +1000 |
| Message-ID | <mailman.1714.1341248151.4697.python-list@python.org> |
| In reply to | #24779 |
On Tue, Jul 3, 2012 at 1:16 AM, Rick Johnson <rantingrickjohnson@gmail.com> wrote: > py> 1 + 3 * 4 > should ALWAYS equal 16! > > With parenthesis only used for grouping: > py> a + (b*c) + d > > Which seems like the most consistent approach to me. Oh yes, absolutely consistent. Consistency. It's a CR 1/2 monster found on page 153 of the 3.5th Edition Monster Manual. Let's see. By your principle, we should evaluate the ** before the - in: 2**-1 Have fun. ChrisA
[toc] | [prev] | [next] | [standalone]
| From | Steven D'Aprano <steve+comp.lang.python@pearwood.info> |
|---|---|
| Date | 2012-07-03 00:57 +0000 |
| Message-ID | <4ff24384$0$29988$c3e8da3$5496439d@news.astraweb.com> |
| In reply to | #24781 |
On Tue, 03 Jul 2012 02:55:48 +1000, Chris Angelico wrote: > On Tue, Jul 3, 2012 at 1:16 AM, Rick Johnson > <rantingrickjohnson@gmail.com> wrote: >> py> 1 + 3 * 4 >> should ALWAYS equal 16! >> >> With parenthesis only used for grouping: py> a + (b*c) + d >> >> Which seems like the most consistent approach to me. > > Oh yes, absolutely consistent. Consistency. It's a CR 1/2 monster found > on page 153 of the 3.5th Edition Monster Manual. GvR is fond of quoting Ralph Waldo Emerson: "A foolish consistency is the hobgoblin of little minds." Perhaps the world would be better off if mathematicians threw out the existing precedence rules and replaced them with a strict left-to-right precedence. (Personally, I doubt it.) But until they do, consistency with mathematics is far more important than the foolish consistency of left-to-right precedence. -- Steven
[toc] | [prev] | [next] | [standalone]
| From | Chris Angelico <rosuav@gmail.com> |
|---|---|
| Date | 2012-07-03 11:22 +1000 |
| Message-ID | <mailman.1725.1341278577.4697.python-list@python.org> |
| In reply to | #24794 |
On Tue, Jul 3, 2012 at 10:57 AM, Steven D'Aprano <steve+comp.lang.python@pearwood.info> wrote: > On Tue, 03 Jul 2012 02:55:48 +1000, Chris Angelico wrote: >> Oh yes, absolutely consistent. Consistency. It's a CR 1/2 monster found >> on page 153 of the 3.5th Edition Monster Manual. > > GvR is fond of quoting Ralph Waldo Emerson: > > "A foolish consistency is the hobgoblin of little minds." Yeah, that's what I was referring to. Dungeons and Dragons has specs for a hobgoblin warrior :) > Perhaps the world would be better off if mathematicians threw out the > existing precedence rules and replaced them with a strict left-to-right > precedence. (Personally, I doubt it.) > > But until they do, consistency with mathematics is far more important > than the foolish consistency of left-to-right precedence. And if they ever do, it'll break consistency with past centuries of mathematical writing. Imagine (taking this to another realm) that it's decided that since Wolfram is now called Tungsten, it should have the chemical symbol 'T' instead of 'W'. This is far more consistent, right? And Iron should be I, not Fe. We'll move Iodine to Io (and Europium to Europa and Gallium to Ganymede?), and tritium (the isotope of hydrogen) can become H3. It'd make today's chemistry notes look as archaic and unreadable as those using alchemical symbols, only the actual symbols are the same, making it ambiguous. Nope. Better to stick with what's standardized. ChrisA
[toc] | [prev] | [next] | [standalone]
| From | John O'Hagan <research@johnohagan.com> |
|---|---|
| Date | 2012-07-03 12:25 +1000 |
| Message-ID | <mailman.1728.1341282369.4697.python-list@python.org> |
| In reply to | #24794 |
On Tue, 3 Jul 2012 11:22:55 +1000 Chris Angelico <rosuav@gmail.com> wrote: > On Tue, Jul 3, 2012 at 10:57 AM, Steven D'Aprano > <steve+comp.lang.python@pearwood.info> wrote: > > > Perhaps the world would be better off if mathematicians threw out the > > existing precedence rules and replaced them with a strict left-to-right > > precedence. (Personally, I doubt it.) > > > > But until they do, consistency with mathematics is far more important > > than the foolish consistency of left-to-right precedence. > > And if they ever do, it'll break consistency with past centuries of > mathematical writing. Imagine (taking this to another realm) that it's > decided that since Wolfram is now called Tungsten, it should have the > chemical symbol 'T' instead of 'W'. This is far more consistent, > right? And Iron should be I, not Fe. We'll move Iodine to Io (and > Europium to Europa and Gallium to Ganymede?), and tritium (the isotope > of hydrogen) can become H3. It'd make today's chemistry notes look as > archaic and unreadable as those using alchemical symbols, only the > actual symbols are the same, making it ambiguous. Nope. Better to > stick with what's standardized. > I agree to some extent, but as a counter-example, when I was a child there a subject called "Weights and Measures" which is now redundant because of the Metric system. I don't miss hogsheads and fathoms at all. Music is another field which could do with a "metrification": I get tired of explaining to beginners why there's no B#, except when it's C. Check out http://musicnotation.org If legacy systems get too far out of sync with current practice, they become an unnecessary layer of complexity and a hurdle to understanding, and at some point you have to take the plunge, old books be damned. -- John
[toc] | [prev] | [next] | [standalone]
| From | Steven D'Aprano <steve+comp.lang.python@pearwood.info> |
|---|---|
| Date | 2012-07-03 04:11 +0000 |
| Message-ID | <4ff270ea$0$11103$c3e8da3@news.astraweb.com> |
| In reply to | #24801 |
On Tue, 03 Jul 2012 12:25:59 +1000, John O'Hagan wrote: > On Tue, 3 Jul 2012 11:22:55 +1000 > Chris Angelico <rosuav@gmail.com> wrote: > >> On Tue, Jul 3, 2012 at 10:57 AM, Steven D'Aprano >> <steve+comp.lang.python@pearwood.info> wrote: >> >> > Perhaps the world would be better off if mathematicians threw out the >> > existing precedence rules and replaced them with a strict >> > left-to-right precedence. (Personally, I doubt it.) >> > >> > But until they do, consistency with mathematics is far more important >> > than the foolish consistency of left-to-right precedence. >> >> And if they ever do, it'll break consistency with past centuries of >> mathematical writing. Imagine (taking this to another realm) that it's >> decided that since Wolfram is now called Tungsten, it should have the >> chemical symbol 'T' instead of 'W'. This is far more consistent, right? >> And Iron should be I, not Fe. We'll move Iodine to Io (and Europium to >> Europa and Gallium to Ganymede?), and tritium (the isotope of hydrogen) >> can become H3. It'd make today's chemistry notes look as archaic and >> unreadable as those using alchemical symbols, only the actual symbols >> are the same, making it ambiguous. Nope. Better to stick with what's >> standardized. >> >> > I agree to some extent, but as a counter-example, when I was a child > there a subject called "Weights and Measures" which is now redundant > because of the Metric system. I don't miss hogsheads and fathoms at all. Don't mistake tradition for consistency. There's little consistency in the legacy weights and measures used before the metric system. The introduction of the Imperial system in 1824 at least got rid of *some* of the more wacky measures, and standardised the rest, but there was still damn little consistency: e.g. a finger was 7/8 of an inch, and an ell was 45 inches, meaning an ell is 39 and 3/8th fingers. One of my favourites is the league, which in the Middle Ages was actually defined as the distance that a man, or a horse, could walk in an hour. -- Steven
[toc] | [prev] | [next] | [standalone]
| From | Dennis Lee Bieber <wlfraed@ix.netcom.com> |
|---|---|
| Date | 2012-07-03 02:09 -0400 |
| Message-ID | <mailman.1734.1341295784.4697.python-list@python.org> |
| In reply to | #24803 |
On 03 Jul 2012 04:11:22 GMT, Steven D'Aprano
<steve+comp.lang.python@pearwood.info> declaimed the following in
gmane.comp.python.general:
> One of my favourites is the league, which in the Middle Ages was actually
> defined as the distance that a man, or a horse, could walk in an hour.
From the "Explanatory Supplement to the Astronomical Almanac" [1992
University Science Books], Table 15.15, the speed of light is
1.80261750E12 furlongs/fortnight
--
Wulfraed Dennis Lee Bieber AF6VN
wlfraed@ix.netcom.com HTTP://wlfraed.home.netcom.com/
[toc] | [prev] | [next] | [standalone]
| From | Roy Smith <roy@panix.com> |
|---|---|
| Date | 2012-07-03 08:33 -0400 |
| Message-ID | <roy-63C064.08333803072012@news.panix.com> |
| In reply to | #24808 |
In article <mailman.1734.1341295784.4697.python-list@python.org>, Dennis Lee Bieber <wlfraed@ix.netcom.com> wrote: > On 03 Jul 2012 04:11:22 GMT, Steven D'Aprano > <steve+comp.lang.python@pearwood.info> declaimed the following in > gmane.comp.python.general: > > > > One of my favourites is the league, which in the Middle Ages was actually > > defined as the distance that a man, or a horse, could walk in an hour. > > From the "Explanatory Supplement to the Astronomical Almanac" [1992 > University Science Books], Table 15.15, the speed of light is > > 1.80261750E12 furlongs/fortnight And sure enough, that's what units says: $ units 500 units, 54 prefixes You have: c You want: furlongs/fortnight * 1.8026175e+12 / 5.5474886e-13
[toc] | [prev] | [next] | [standalone]
Page 5 of 7 — ← Prev page 1 2 3 4 [5] 6 7 Next page →
Back to top | Article view | comp.lang.python
csiph-web