Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.python > #11094 > unrolled thread
| Started by | Yingjie Lan <lanyjie@yahoo.com> |
|---|---|
| First post | 2011-08-09 23:05 -0700 |
| Last post | 2011-08-11 00:55 +0100 |
| Articles | 20 on this page of 159 — 34 participants |
Back to article view | Back to comp.lang.python
This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by
below is the oldest one visible, not the original post.
Re: allow line break at operators Yingjie Lan <lanyjie@yahoo.com> - 2011-08-09 23:05 -0700
Re: allow line break at operators Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2011-08-10 18:32 +1000
Re: allow line break at operators Chris Angelico <rosuav@gmail.com> - 2011-08-10 09:39 +0100
Re: allow line break at operators Dan Sommers <dan@tombstonezero.net> - 2011-08-10 09:56 +0000
Re: allow line break at operators Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2011-08-11 00:44 +1000
Re: allow line break at operators Chris Angelico <rosuav@gmail.com> - 2011-08-10 11:26 +0100
Re: allow line break at operators Duncan Booth <duncan.booth@invalid.invalid> - 2011-08-10 12:25 +0000
Re: allow line break at operators Chris Angelico <rosuav@gmail.com> - 2011-08-10 13:42 +0100
Re: allow line break at operators Yingjie Lan <lanyjie@yahoo.com> - 2011-08-10 05:58 -0700
Re: allow line break at operators Chris Angelico <rosuav@gmail.com> - 2011-08-10 15:45 +0100
Re: allow line break at operators Yingjie Lan <lanyjie@yahoo.com> - 2011-08-10 06:19 -0700
Re: allow line break at operators Chris Angelico <rosuav@gmail.com> - 2011-08-10 16:56 +0100
Re: allow line break at operators Seebs <usenet-nospam@seebs.net> - 2011-08-10 17:55 +0000
Re: allow line break at operators Ben Finney <ben+python@benfinney.id.au> - 2011-08-11 07:51 +1000
Re: allow line break at operators Chris Angelico <rosuav@gmail.com> - 2011-08-10 23:42 +0100
Re: allow line break at operators Neil Cerutti <neilc@norwich.edu> - 2011-08-11 14:40 +0000
Re: Python & Sullivan Tim Chase <python.list@tim.thechases.com> - 2011-08-10 18:26 -0500
Re: Python & Sullivan Ben Finney <ben+python@benfinney.id.au> - 2011-08-11 10:57 +1000
Re: Python & Sullivan Chris Angelico <rosuav@gmail.com> - 2011-08-11 00:54 +0100
Re: allow line break at operators Seebs <usenet-nospam@seebs.net> - 2011-08-11 04:59 +0000
Re: allow line break at operators Ben Finney <ben+python@benfinney.id.au> - 2011-08-11 15:56 +1000
Re: allow line break at operators Seebs <usenet-nospam@seebs.net> - 2011-08-11 21:19 +0000
Re: allow line break at operators Chris Angelico <rosuav@gmail.com> - 2011-08-12 00:58 +0100
Re: allow line break at operators Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2011-08-12 11:40 +1000
Re: allow line break at operators Chris Angelico <rosuav@gmail.com> - 2011-08-12 08:09 +0100
Re: allow line break at operators Neil Cerutti <neilc@norwich.edu> - 2011-08-12 12:57 +0000
Re: allow line break at operators Thomas Rachel <nutznetz-0c1b6768-bfa9-48d5-a470-7603bd3aa915@spamschutz.glglgl.de> - 2011-08-12 14:54 +0200
Re: allow line break at operators Tim Roberts <timr@probo.com> - 2011-08-14 22:22 -0700
Re: allow line break at operators Ben Finney <ben+python@benfinney.id.au> - 2011-08-12 18:59 +1000
Re: allow line break at operators Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2011-08-12 20:40 +1000
Re: allow line break at operators Ben Finney <ben+python@benfinney.id.au> - 2011-08-12 21:16 +1000
Re: allow line break at operators Seebs <usenet-nospam@seebs.net> - 2011-08-12 16:33 +0000
Re: allow line break at operators Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2011-08-11 22:29 +1000
Re: allow line break at operators Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2011-08-11 22:40 +1000
Re: allow line break at operators Seebs <usenet-nospam@seebs.net> - 2011-08-11 21:19 +0000
Re: allow line break at operators Seebs <usenet-nospam@seebs.net> - 2011-08-11 21:19 +0000
Re: allow line break at operators Ethan Furman <ethan@stoneleaf.us> - 2011-08-11 15:43 -0700
Re: allow line break at operators Seebs <usenet-nospam@seebs.net> - 2011-08-12 06:34 +0000
Re: allow line break at operators Chris Angelico <rosuav@gmail.com> - 2011-08-12 08:20 +0100
Re: allow line break at operators rantingrick <rantingrick@gmail.com> - 2011-08-12 08:33 -0700
Re: allow line break at operators Chris Angelico <rosuav@gmail.com> - 2011-08-12 20:52 +0100
Re: allow line break at operators Seebs <usenet-nospam@seebs.net> - 2011-08-12 16:33 +0000
Re: allow line break at operators Ben Finney <ben+python@benfinney.id.au> - 2011-08-12 20:39 +1000
Re: allow line break at operators Chris Rebert <clp2@rebertia.com> - 2011-08-12 10:03 -0700
Re: allow line break at operators Seebs <usenet-nospam@seebs.net> - 2011-08-12 18:37 +0000
Re: allow line break at operators Seebs <usenet-nospam@seebs.net> - 2011-08-12 16:33 +0000
Re: allow line break at operators Chris Angelico <rosuav@gmail.com> - 2011-08-12 21:01 +0100
Re: allow line break at operators Seebs <usenet-nospam@seebs.net> - 2011-08-12 21:06 +0000
Re: allow line break at operators rantingrick <rantingrick@gmail.com> - 2011-08-12 08:26 -0700
Re: allow line break at operators Seebs <usenet-nospam@seebs.net> - 2011-08-12 16:33 +0000
Re: allow line break at operators rantingrick <rantingrick@gmail.com> - 2011-08-12 10:57 -0700
Re: allow line break at operators Chris Angelico <rosuav@gmail.com> - 2011-08-12 21:09 +0100
Re: allow line break at operators Seebs <usenet-nospam@seebs.net> - 2011-08-12 21:06 +0000
Re: allow line break at operators Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2011-08-13 08:39 +1000
Re: allow line break at operators Chris Angelico <rosuav@gmail.com> - 2011-08-12 23:50 +0100
Re: allow line break at operators Ben Finney <ben+python@benfinney.id.au> - 2011-08-13 09:19 +1000
Re: allow line break at operators Tim Chase <python.list@tim.thechases.com> - 2011-08-12 18:53 -0500
Re: allow line break at operators Seebs <usenet-nospam@seebs.net> - 2011-08-13 00:39 +0000
Re: allow line break at operators Ben Finney <ben+python@benfinney.id.au> - 2011-08-13 10:57 +1000
Re: allow line break at operators Seebs <usenet-nospam@seebs.net> - 2011-08-13 02:34 +0000
Re: allow line break at operators rantingrick <rantingrick@gmail.com> - 2011-08-13 18:50 -0700
Re: allow line break at operators rantingrick <rantingrick@gmail.com> - 2011-08-13 19:07 -0700
Re: allow line break at operators rantingrick <rantingrick@gmail.com> - 2011-08-13 18:59 -0700
Re: allow line break at operators Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2011-08-14 17:10 +1000
Re: allow line break at operators Seebs <usenet-nospam@seebs.net> - 2011-08-14 08:07 +0000
Re: allow line break at operators Ben Finney <ben+python@benfinney.id.au> - 2011-08-14 19:25 +1000
Re: allow line break at operators Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2011-08-15 00:26 +1000
Re: allow line break at operators Roy Smith <roy@panix.com> - 2011-08-14 11:35 -0400
Re: allow line break at operators Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2011-08-15 03:24 +1000
Re: Re: allow line break at operators Dave Angel <davea@ieee.org> - 2011-08-14 17:46 -0400
Re: allow line break at operators Roy Smith <roy@panix.com> - 2011-08-14 18:46 -0400
Re: allow line break at operators Chris Angelico <rosuav@gmail.com> - 2011-08-15 00:02 +0100
Re: allow line break at operators Chris Angelico <rosuav@gmail.com> - 2011-08-14 16:39 +0100
Re: allow line break at operators Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2011-08-15 03:26 +1000
Re: allow line break at operators Seebs <usenet-nospam@seebs.net> - 2011-08-14 19:01 +0000
Re: allow line break at operators Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2011-08-15 11:54 +1000
Re: allow line break at operators Chris Rebert <clp2@rebertia.com> - 2011-08-14 19:10 -0700
Re: allow line break at operators Seebs <usenet-nospam@seebs.net> - 2011-08-15 04:28 +0000
Re: allow line break at operators Tim Chase <python.list@tim.thechases.com> - 2011-08-15 06:40 -0500
Re: allow line break at operators Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2011-08-15 23:30 +1000
Re: allow line break at operators Seebs <usenet-nospam@seebs.net> - 2011-08-15 16:32 +0000
Re: allow line break at operators alex23 <wuwei23@gmail.com> - 2011-08-15 21:13 -0700
Re: allow line break at operators rantingrick <rantingrick@gmail.com> - 2011-08-15 21:37 -0700
Re: allow line break at operators alex23 <wuwei23@gmail.com> - 2011-08-15 23:49 -0700
Re: allow line break at operators rantingrick <rantingrick@gmail.com> - 2011-08-16 11:56 -0700
Re: allow line break at operators Seebs <usenet-nospam@seebs.net> - 2011-08-15 04:28 +0000
Re: allow line break at operators Terry Reedy <tjreedy@udel.edu> - 2011-08-15 03:31 -0400
Re: allow line break at operators rantingrick <rantingrick@gmail.com> - 2011-08-15 14:21 -0700
Re: allow line break at operators Chris Angelico <rosuav@gmail.com> - 2011-08-15 09:27 +0100
Re: allow line break at operators Chris Angelico <rosuav@gmail.com> - 2011-08-14 09:34 +0100
Re: allow line break at operators Ben Finney <ben+python@benfinney.id.au> - 2011-08-14 19:27 +1000
Re: allow line break at operators Ethan Furman <ethan@stoneleaf.us> - 2011-08-14 03:51 -0700
Re: allow line break at operators Chris Angelico <rosuav@gmail.com> - 2011-08-14 12:59 +0100
Re: allow line break at operators Teemu Likonen <tlikonen@iki.fi> - 2011-08-14 12:46 +0300
Re: allow line break at operators Seebs <usenet-nospam@seebs.net> - 2011-08-14 19:01 +0000
Re: allow line break at operators Seebs <usenet-nospam@seebs.net> - 2011-08-14 19:01 +0000
Re: allow line break at operators Chris Rebert <clp2@rebertia.com> - 2011-08-14 01:44 -0700
Re: allow line break at operators Teemu Likonen <tlikonen@iki.fi> - 2011-08-16 07:04 +0300
Re: allow line break at operators rantingrick <rantingrick@gmail.com> - 2011-08-13 19:18 -0700
Re: allow line break at operators Gregory Ewing <greg.ewing@canterbury.ac.nz> - 2011-08-13 13:19 +1200
Re: allow line break at operators Johann Hibschman <jhibschman+usenet@gmail.com> - 2011-08-15 08:27 -0500
Re: allow line break at operators Roy Smith <roy@panix.com> - 2011-08-15 09:41 -0400
Re: allow line break at operators Chris Angelico <rosuav@gmail.com> - 2011-08-15 15:16 +0100
Re: allow line break at operators Roy Smith <roy@panix.com> - 2011-08-15 20:34 -0400
Re: allow line break at operators Chris Angelico <rosuav@gmail.com> - 2011-08-16 01:37 +0100
Re: allow line break at operators Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2011-08-16 00:28 +1000
Re: allow line break at operators Chris Angelico <rosuav@gmail.com> - 2011-08-15 15:42 +0100
Re: allow line break at operators Roy Smith <roy@panix.com> - 2011-08-15 20:30 -0400
Re: allow line break at operators Seebs <usenet-nospam@seebs.net> - 2011-08-16 00:39 +0000
Re: allow line break at operators Gregory Ewing <greg.ewing@canterbury.ac.nz> - 2011-08-16 12:43 +1200
Re: allow line break at operators Seebs <usenet-nospam@seebs.net> - 2011-08-15 16:32 +0000
Re: allow line break at operators Ethan Furman <ethan@stoneleaf.us> - 2011-08-12 13:35 -0700
Re: allow line break at operators Seebs <usenet-nospam@seebs.net> - 2011-08-12 21:06 +0000
Re: allow line break at operators Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2011-08-13 08:03 +1000
Re: allow line break at operators Seebs <usenet-nospam@seebs.net> - 2011-08-12 22:14 +0000
Re: allow line break at operators Ben Finney <ben+python@benfinney.id.au> - 2011-08-13 08:36 +1000
Re: allow line break at operators Terry Reedy <tjreedy@udel.edu> - 2011-08-12 20:15 -0400
Re: allow line break at operators Seebs <usenet-nospam@seebs.net> - 2011-08-13 00:44 +0000
Re: allow line break at operators rantingrick <rantingrick@gmail.com> - 2011-08-13 18:25 -0700
Re: allow line break at operators Ben Finney <ben+python@benfinney.id.au> - 2011-08-13 08:12 +1000
RE: allow line break at operators "Prasad, Ramit" <ramit.prasad@jpmorgan.com> - 2011-08-16 15:51 -0400
RE: allow line break at operators "Prasad, Ramit" <ramit.prasad@jpmorgan.com> - 2011-08-16 15:26 -0400
Re: allow line break at operators Seebs <usenet-nospam@seebs.net> - 2011-08-16 20:19 +0000
Re: allow line break at operators Chris Angelico <rosuav@gmail.com> - 2011-08-16 21:05 +0100
Re: allow line break at operators Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2011-08-11 10:32 +1000
Re: allow line break at operators Chris Angelico <rosuav@gmail.com> - 2011-08-11 01:47 +0100
Re: allow line break at operators Seebs <usenet-nospam@seebs.net> - 2011-08-11 04:59 +0000
Re: allow line break at operators Yingjie Lan <lanyjie@yahoo.com> - 2011-08-10 19:52 -0700
Re: allow line break at operators Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2011-08-11 14:18 +1000
Re: allow line break at operators Chris Rebert <clp2@rebertia.com> - 2011-08-11 00:50 -0700
Re: allow line break at operators Vito 'ZeD' De Tullio <zak.mc.kraken@libero.it> - 2011-08-11 12:21 +0200
Re: allow line break at operators Yingjie Lan <lanyjie@yahoo.com> - 2011-08-10 19:58 -0700
Re: allow line break at operators Chris Rebert <clp2@rebertia.com> - 2011-08-10 21:16 -0700
Re: allow line break at operators Chris Rebert <clp2@rebertia.com> - 2011-08-10 22:07 -0700
Re: allow line break at operators Chris Angelico <rosuav@gmail.com> - 2011-08-11 09:24 +0100
Re: allow line break at operators MRAB <python@mrabarnett.plus.com> - 2011-08-11 14:03 +0100
Re: [Python-ideas] allow line break at operators Matt Joiner <anacrolix@gmail.com> - 2011-08-12 00:28 +1000
Re: [Python-ideas] allow line break at operators Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2011-08-12 12:32 +1000
Re: [Python-ideas] allow line break at operators Jakob Bowyer <jkbbwr@gmail.com> - 2011-08-11 16:42 +0100
Re: [Python-ideas] allow line break at operators Daniel Greenfeld <pydanny@gmail.com> - 2011-08-11 10:04 -0700
Re: [Python-ideas] allow line break at operators Paul Colomiets <paul@colomiets.name> - 2011-08-11 22:17 +0300
Re: [Python-ideas] allow line break at operators Devin Jeanpierre <jeanpierreda@gmail.com> - 2011-08-11 17:06 -0400
Re: [Python-ideas] allow line break at operators Devin Jeanpierre <jeanpierreda@gmail.com> - 2011-08-11 17:29 -0400
Re: [Python-ideas] allow line break at operators Jim Jewett <jimjjewett@gmail.com> - 2011-08-11 17:39 -0400
Re: [Python-ideas] allow line break at operators Devin Jeanpierre <jeanpierreda@gmail.com> - 2011-08-11 18:29 -0400
Re: [Python-ideas] allow line break at operators Matt Joiner <anacrolix@gmail.com> - 2011-09-02 15:33 +1000
Re: [Python-ideas] allow line break at operators Roy Smith <roy@panix.com> - 2011-09-03 12:59 -0400
Re: [Python-ideas] allow line break at operators "Stephen J. Turnbull" <stephen@xemacs.org> - 2011-09-02 16:28 +0900
Re: [Python-ideas] allow line break at operators Guido van Rossum <guido@python.org> - 2011-09-02 12:30 -0700
Re: [Python-ideas] allow line break at operators "Stephen J. Turnbull" <stephen@xemacs.org> - 2011-09-03 13:38 +0900
Re: [Python-ideas] allow line break at operators "Stephen J. Turnbull" <stephen@xemacs.org> - 2011-09-03 15:10 +0900
Re: [Python-ideas] allow line break at operators Terry Reedy <tjreedy@udel.edu> - 2011-09-03 15:01 -0400
Re: [Python-ideas] allow line break at operators ron3200 <ron3200@gmail.com> - 2011-09-04 10:22 -0500
Re: allow line break at operators rantingrick <rantingrick@gmail.com> - 2011-09-04 11:08 -0700
Re: allow line break at operators Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2011-08-11 00:37 +1000
Re: allow line break at operators Chris Angelico <rosuav@gmail.com> - 2011-08-10 16:13 +0100
Re: allow line break at operators Ian Kelly <ian.g.kelly@gmail.com> - 2011-08-10 09:16 -0600
Re: allow line break at operators Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2011-08-11 09:32 +1000
Re: allow line break at operators Chris Angelico <rosuav@gmail.com> - 2011-08-11 00:55 +0100
Page 7 of 8 — ← Prev page 1 2 3 4 5 6 [7] 8 Next page →
| From | "Prasad, Ramit" <ramit.prasad@jpmorgan.com> |
|---|---|
| Date | 2011-08-16 15:51 -0400 |
| Message-ID | <mailman.99.1313524310.27778.python-list@python.org> |
| In reply to | #11291 |
>> PS: I will admit that a few of our community members can be rather >> acerbic at times. >Yeah. And the thing is... This can't possibly lead to convincing people of >your position, so presumably the purpose is that you don't want anyone who >didn't start out agreeing with you to ever come to agree with you? Why's >that? Rantingrick: Do answer his question, please. Ramit Ramit Prasad | JPMorgan Chase Investment Bank | Currencies Technology 712 Main Street | Houston, TX 77002 work phone: 713 - 216 - 5423 This email is confidential and subject to important disclaimers and conditions including on offers for the purchase or sale of securities, accuracy and completeness of information, viruses, confidentiality, legal privilege, and legal entity disclaimers, available at http://www.jpmorgan.com/pages/disclosures/email.
[toc] | [prev] | [next] | [standalone]
| From | "Prasad, Ramit" <ramit.prasad@jpmorgan.com> |
|---|---|
| Date | 2011-08-16 15:26 -0400 |
| Message-ID | <mailman.98.1313523921.27778.python-list@python.org> |
| In reply to | #11184 |
>1. Indentation as flow control was a bad idea. >2. People are subconsciously aware of this. >3. There is a HUGE degree of emotional investment in defending it. > >The responses I have seen on this issue are highly emotional, full of insults, >full of blame-throwing, and utterly contrary to the basic engineering spirit >I usually see in programming communities. In other languages, and even in >Python on any issue but this one, I regularly see people acknowledge >shortcomings and explain either why they think the tradeoffs are good, or why >they are willing to put up with it anyway. > >The characteristic vehemence and hostility this issue produces are the surest >sign of people who have a desperate need not to acknowledge the elephant in >the room. What exactly is the downside to indentation as flow control? I am a fairly new programmer to Python, but the more I use it, the more I think it has the Right idea (for me at least). I find braces in Java/c[#,++] to be less than helpful in comparison to how people rave over. It allows for free form code sure, but half the time I was using indentation to figure out where conditional branching/loops started and stopped anyway! I will admit it was super useful in helping Eclipse to reformat with a more "readable" indentation. The only difference is that now it forces me to make more readable code instead of allowing me the freedom to make hard to read code. I suppose as an American I should be insulted at the lack of freedom. Hell, I own Apple products; I must be getting indoctrinated into a lack of freedom. :-P I am not being vehement or hostile. At least I am attempting to be neither. I do not really feel emotionally invested in either because honestly, I will do whatever I have to for what I am trying to get done. If that requires me coding while only wearing hot pink or using braces I will do it. I am far more concerned with ease of coding, ability to do what I want, and occasionally (fairly rarely) if the running code will be "fast enough". I am not sure why people are so stuck on braces. I figured other people would be like me and tired of having to do things like figuring out where I missed an end brace. Ramit Ramit Prasad | JPMorgan Chase Investment Bank | Currencies Technology 712 Main Street | Houston, TX 77002 work phone: 713 - 216 - 5423 This email is confidential and subject to important disclaimers and conditions including on offers for the purchase or sale of securities, accuracy and completeness of information, viruses, confidentiality, legal privilege, and legal entity disclaimers, available at http://www.jpmorgan.com/pages/disclosures/email.
[toc] | [prev] | [next] | [standalone]
| From | Seebs <usenet-nospam@seebs.net> |
|---|---|
| Date | 2011-08-16 20:19 +0000 |
| Message-ID | <slrnj4lk66.21d2.usenet-nospam@guild.seebs.net> |
| In reply to | #11606 |
On 2011-08-16, Prasad, Ramit <ramit.prasad@jpmorgan.com> wrote: >What exactly is the downside to indentation as flow control? I think a lot of it is personal taste or differences in how peoples' brains work. I don't want "free form code", I don't want to write stuff that isn't correctly indented. I want a visual cue I can match up with the start of a loop so I know for sure what I meant, and a way to recover code in the event of Something Going Wrong. >I am not sure why people are so stuck on braces. I figured other >people would be like me and tired of having to do things like >figuring out where I missed an end brace. For me, if I've made an error of that category, the options are: 1. In C, finding out where I missed an end brace, because the compiler warned me, so I go look for an outdent without a brace. 2. In Python, having no clue at all what's wrong or why the program isn't running, and having no cue I can look to to see where the error occurred. Basically, it's parity bits. I love me some parity bits. :) I also recognize that this is a matter of taste; there are sound reasons for other people to have different preferences. -s -- Copyright 2011, all wrongs reversed. Peter Seebach / usenet-nospam@seebs.net http://www.seebs.net/log/ <-- lawsuits, religion, and funny pictures http://en.wikipedia.org/wiki/Fair_Game_(Scientology) <-- get educated! I am not speaking for my employer, although they do rent some of my opinions.
[toc] | [prev] | [next] | [standalone]
| From | Chris Angelico <rosuav@gmail.com> |
|---|---|
| Date | 2011-08-16 21:05 +0100 |
| Message-ID | <mailman.100.1313525160.27778.python-list@python.org> |
| In reply to | #11184 |
On Tue, Aug 16, 2011 at 8:26 PM, Prasad, Ramit
<ramit.prasad@jpmorgan.com> wrote:
> I am not sure why people are so stuck on braces. I figured other people would be like me and tired of having to do things like figuring out where I missed an end brace.
>
I'm one of the fans of braces, but search the list archives and you'll
find plenty of arguments on both sides. I like braces because they
allow me to separate the syntax from the layout; I can choose to
indent things based on logical structure, even when that doesn't
correspond to the compiler's notion of the structure. Here's an
example from C++:
struct _blah
{
int x;
int y;
char **z;
//etc etc etc
}; struct blah: public _blah {
char padding[1024-sizeof(_blah)];
};
The inheritance isn't significant to the overall concept of the object
(the idea was that it should have a size of exactly 1024, as this had
to interface with some lower-level systems), but it's significant to
the compiler's understanding of the object. The braces, therefore,
follow the compiler's requirements, but the indentation follows the
programmer's. (And yes, there were comments explaining things, and
much better element names.)
Another idiom I often use in C or C++ is the "conditional for loop":
for (x=getfirst();x;x=getnext()) if (x%3)
{
blah
blah
}
The equivalent in Python:
for x in blah: if x%3:
blah
blah
is not legal, and must be written with an extra indentation:
for x in blah:
if x%3:
blah
blah
I'm sure I could sort something out with a filtering generator, but it
seems ridiculous to write:
def condition(gen,func):
for elem in gen:
if func(elem): yield elem
for x in condition(blah,lambda x: x%3):
blah
blah
There are very good reasons for Python's system, and I don't object to
it *in Python*. But I do not see indentation-as-structure as the
ultimate and perfect system, and I desire and intend to preserve the
freedom to choose languages with different systems.
Chris Angelico
[toc] | [prev] | [next] | [standalone]
| From | Steven D'Aprano <steve+comp.lang.python@pearwood.info> |
|---|---|
| Date | 2011-08-11 10:32 +1000 |
| Message-ID | <4e432323$0$29983$c3e8da3$5496439d@news.astraweb.com> |
| In reply to | #11145 |
Seebs wrote:
> On 2011-08-10, Chris Angelico <rosuav@gmail.com> wrote:
>> And if we require {} then truly free indentation should be OK too! But
>> it wouldn't be Python any more.
>
> Would it really not be Python at all?
Of course it wouldn't be. Every function, class, if, while, for,
try...except block etc. in existing Python code would be illegal if {} were
required. This would be an order of magnitude bigger change than going from
Python 2 to 3, where the biggest syntax change is that print is no longer a
statement.
Even more so if ; were to become required, as suggested by the Original
Poster.
> I've seen bits of code in preprocessing-based "Python with {}" type
> things, and they still look like Python to me, only they favor explicit
> over implicit a little more strongly.
"Looks like" Python does not equal "is Python". Cobra looks like Python, as
do Boo, Groovy and Ruby, or OCaml with "twt" turned on ("the whitespace
thing"). The similarities are especially strong for Boo and Cobra, but
there is no doubt that they are different languages.
In general, languages that aim to look like executable pseudo-code will
converge on a similar look, because executable pseudo-code tends to be
based on natural language (usually English) and mathematics syntax.
--
Steven
[toc] | [prev] | [next] | [standalone]
| From | Chris Angelico <rosuav@gmail.com> |
|---|---|
| Date | 2011-08-11 01:47 +0100 |
| Message-ID | <mailman.2135.1313023672.1164.python-list@python.org> |
| In reply to | #11159 |
On Thu, Aug 11, 2011 at 1:32 AM, Steven D'Aprano
<steve+comp.lang.python@pearwood.info> wrote:
>> I've seen bits of code in preprocessing-based "Python with {}" type
>> things, and they still look like Python to me, only they favor explicit
>> over implicit a little more strongly.
>
> "Looks like" Python does not equal "is Python". Cobra looks like Python, as
> do Boo, Groovy and Ruby, or OCaml with "twt" turned on ("the whitespace
> thing"). The similarities are especially strong for Boo and Cobra, but
> there is no doubt that they are different languages.
>
> In general, languages that aim to look like executable pseudo-code will
> converge on a similar look, because executable pseudo-code tends to be
> based on natural language (usually English) and mathematics syntax.
"Looks like" is a poor indication of anything much; "feels like" is a
bit vague, but may be more useful. If you can manipulate objects and
references to objects, if you can use Python's rich object set and
standard library, if you can use Python-like features using reasonably
readable syntax, then it feels like Python. Little things don't matter
(eg whether 'print' is a keyword or a function). Big things do (eg
having to explicitly deallocate objects).
Lots of languages "look like" C. Some of them function like C (eg
C++), and most definitely "feel like" C. Others don't.
ChrisA
[toc] | [prev] | [next] | [standalone]
| From | Seebs <usenet-nospam@seebs.net> |
|---|---|
| Date | 2011-08-11 04:59 +0000 |
| Message-ID | <slrnj46o83.1rv9.usenet-nospam@guild.seebs.net> |
| In reply to | #11159 |
On 2011-08-11, Steven D'Aprano <steve+comp.lang.python@pearwood.info> wrote:
> Seebs wrote:
>> On 2011-08-10, Chris Angelico <rosuav@gmail.com> wrote:
>>> And if we require {} then truly free indentation should be OK too! But
>>> it wouldn't be Python any more.
>> Would it really not be Python at all?
> Of course it wouldn't be. Every function, class, if, while, for,
> try...except block etc. in existing Python code would be illegal if {} were
> required.
So?
Since there has never been an indentation-related problem in the history
of human endeavors, automatically adding the braces would be completely
trivial.
How much of the language *specification* would change?
> In general, languages that aim to look like executable pseudo-code will
> converge on a similar look, because executable pseudo-code tends to be
> based on natural language (usually English) and mathematics syntax.
This is an interesting point. I guess I meant "look like" in a more abstract
sense; the basic idea of what it's like to read the code, and what you have
to keep in mind while doing so.
-s
--
Copyright 2011, all wrongs reversed. Peter Seebach / usenet-nospam@seebs.net
http://www.seebs.net/log/ <-- lawsuits, religion, and funny pictures
http://en.wikipedia.org/wiki/Fair_Game_(Scientology) <-- get educated!
I am not speaking for my employer, although they do rent some of my opinions.
[toc] | [prev] | [next] | [standalone]
| From | Yingjie Lan <lanyjie@yahoo.com> |
|---|---|
| Date | 2011-08-10 19:52 -0700 |
| Message-ID | <mailman.2141.1313031310.1164.python-list@python.org> |
| In reply to | #11113 |
:And if we require {} then truly free indentation should be OK too! But
:it wouldn't be Python any more.
Of course, but not the case with ';'. Currently ';' is optional in Python,
But '{' is used for dicts. Clearly, ';' and '{' are different in magnitude.
So the decision is: shall we change ';' from optional to mandatory
to allow free line splitting?
Yingjie
[toc] | [prev] | [next] | [standalone]
| From | Steven D'Aprano <steve+comp.lang.python@pearwood.info> |
|---|---|
| Date | 2011-08-11 14:18 +1000 |
| Message-ID | <4e43582e$0$29969$c3e8da3$5496439d@news.astraweb.com> |
| In reply to | #11170 |
On Thu, 11 Aug 2011 12:52 pm Yingjie Lan wrote:
> :And if we require {} then truly free indentation should be OK too! But
>
> :it wouldn't be Python any more.
>
> Of course, but not the case with ';'. Currently ';' is optional in Python,
> But '{' is used for dicts. Clearly, ';' and '{' are different in
> magnitude.
>
> So the decision is: shall we change ';' from optional to mandatory
> to allow free line splitting?
Why on earth would you want to break backwards compatibility of millions of
Python scripts and programs, and require extra, unnecessary line-noise on
every single line of Python code, just so that you can occasionally avoid a
writing a pair of parentheses?
This will never happen. Forget it. Python is more likely to get static types
than compulsory semi-colons.
--
Steven
[toc] | [prev] | [next] | [standalone]
| From | Chris Rebert <clp2@rebertia.com> |
|---|---|
| Date | 2011-08-11 00:50 -0700 |
| Message-ID | <mailman.2159.1313049029.1164.python-list@python.org> |
| In reply to | #11179 |
On Thu, Aug 11, 2011 at 12:24 AM, Yingjie Lan <lanyjie@yahoo.com> wrote:
> From: Steven D'Aprano <steve+comp.lang.python@pearwood.info>
> On Thu, 11 Aug 2011 12:52 pm Yingjie Lan wrote:
>
>> :And if we require {} then truly free indentation should be OK too! But
>>
>> :it wouldn't be Python any more.
>>
>> Of course, but not the case with ';'. Currently ';' is optional in Python,
>> But '{' is used for dicts. Clearly, ';' and '{' are different in
>> magnitude.
>>
>> So the decision is: shall we change ';' from optional to mandatory
>> to allow free line splitting?
>
> :Why on earth would you want to break backwards compatibility of millions of
> :Python scripts and programs, and require extra, unnecessary line-noise on
> :every single line of Python code, just so that you can occasionally avoid a
> :writing a pair of parentheses?
>
> I think allowing free line splitting (without parentheses -- that's
> artifitial and
> requires the coder to serve the machine rather than the other way around)
> with proper indentation will produce truely ergonomic code layout (well,
> assuming you also like properly indented code).
>
> And this can be done almost hassle-free for the coder.
<snip>
> The trouble of adding a ';' to most of the lines can also be
> avoided by a smart editor (see my other reply).
The trouble of dealing with long lines can be avoided by a smart
editor. It's called line wrap.
Cheers,
Chris
[toc] | [prev] | [next] | [standalone]
| From | Vito 'ZeD' De Tullio <zak.mc.kraken@libero.it> |
|---|---|
| Date | 2011-08-11 12:21 +0200 |
| Message-ID | <mailman.2168.1313058119.1164.python-list@python.org> |
| In reply to | #11179 |
Yingjie Lan wrote: > :The trouble of dealing with long lines can be avoided by a smart > :editor. It's called line wrap. > > Yeah, usually they just wrap it pretty arbitrarily, > and you don't have any control, isn't it? umm... besides "notepad" pretty much any other serious "programmer editor" program try to do its best to deal with line wrap: the minimal I found is the wrapped line is "indented" at the same level of the flow, but I found editors where you can specify what to do (generally something like "indent the wrapped part 2 levels" or something like that) -- By ZeD
[toc] | [prev] | [next] | [standalone]
| From | Yingjie Lan <lanyjie@yahoo.com> |
|---|---|
| Date | 2011-08-10 19:58 -0700 |
| Message-ID | <mailman.2142.1313031655.1164.python-list@python.org> |
| In reply to | #11113 |
On Wed, Aug 10, 2011 at 1:58 PM, Yingjie Lan <lanyjie@yahoo.com> wrote: > Is it possible for python to allow free splitting of single-line statements > without the backslashes, if we impose that expressions can only be split > when it is not yet a finished expression? :The trouble is that in a lot of cases, the next statement after an :unfinished expression could conceivably be a continuation of it. If :this were permitted, it would have to also require that the :continuation lines be indented, to avoid the problem described above. :It'd still have the potential to mis-diagnose errors, though. Indentation is a good idea to reduce the likelihood of such troubles. and also produce code that is easier to read. Yingjie
[toc] | [prev] | [next] | [standalone]
| From | Chris Rebert <clp2@rebertia.com> |
|---|---|
| Date | 2011-08-10 21:16 -0700 |
| Message-ID | <mailman.2147.1313036218.1164.python-list@python.org> |
| In reply to | #11113 |
On Wed, Aug 10, 2011 at 7:52 PM, Yingjie Lan <lanyjie@yahoo.com> wrote:
> :And if we require {} then truly free indentation should be OK too! But
>
> :it wouldn't be Python any more.
>
> Of course, but not the case with ';'. Currently ';' is optional in Python,
I think of it more as that Python deigns to permit semicolons.
> But '{' is used for dicts. Clearly, ';' and '{' are different in magnitude.
>
> So the decision is: shall we change ';' from optional to mandatory
> to allow free line splitting?
Hell no, considering that the sizable majority of lines *aren't*
split, which makes those semicolons completely redundant to their
accompanying newlines. We'd be practicing poor Huffman coding by
optimizing for the *un*common case. It would also add punctuational
noise to what is otherwise an amazingly clean and readable syntax.
Accidental semicolon omission is (IMO) the most irritating source of
syntax (and, inadvertently, sometimes other more serious) errors in
curly-braced programming languages.
Such a core syntax feature is not going to be changed lightly (or likely ever).
Cheers,
Chris
[toc] | [prev] | [next] | [standalone]
| From | Chris Rebert <clp2@rebertia.com> |
|---|---|
| Date | 2011-08-10 22:07 -0700 |
| Message-ID | <mailman.2150.1313039266.1164.python-list@python.org> |
| In reply to | #11113 |
> On Aug 10, 2011 10:57 PM, "Yingjie Lan" <lanyjie@yahoo.com> wrote:
>> :And if we require {} then truly free indentation should be OK too! But
>>
>> :it wouldn't be Python any more.
>>
>> Of course, but not the case with ';'. Currently ';' is optional in Python,
>> But '{' is used for dicts. Clearly, ';' and '{' are different in
>> magnitude.
>>
>> So the decision is: shall we change ';' from optional to mandatory
>> to allow free line splitting?
On Wed, Aug 10, 2011 at 9:51 PM, Michael Trausch <fd0man@gmail.com> wrote:
> Perhaps it could be made an optional thing to enable; for example, some
> languages by default do dynamic typing, but with an option contained as the
> first statement of the file can enforce static typing.
I am intrigued. What languages(s) have the feature you refer to?
Cheers,
Chris
[toc] | [prev] | [next] | [standalone]
| From | Chris Angelico <rosuav@gmail.com> |
|---|---|
| Date | 2011-08-11 09:24 +0100 |
| Message-ID | <mailman.2162.1313051047.1164.python-list@python.org> |
| In reply to | #11113 |
On Thu, Aug 11, 2011 at 6:17 AM, Michael Trausch <fd0man@gmail.com> wrote: > Somthing like an "option" keyword (which would only be a keyword until the > first executable statement, e.g., would have to be before even imports) > could enable things like "semicolon" or "explicit", or whatever really, and > only affect those who opt in. If no code is ever seen using the option, it > can even be removed. Wouldn't be a bad way to test changes that would impact > the syntax of the language, actually... Python already has a syntax like this: from __future__ import statictyping Although I'm not sure how you'd go about implementing it plausibly. It'd be a fairly backward-incompatible change; what would happen to the modules you import? Either you would have to have a duplicate set (one that uses statictyping and one that doesn't), or you'd have to have statictyping somehow work on a per-module basis. As far as I know, most of the other future statements are per-module (with the possible exception of barry_as_FLUFL, which until today I was not aware of). Would static typing then apply only to module-level variables and function-local variables, with the values in lists/tuples/dicts/objects/etc/etc/etc still being dynamically typed? I think it'd be easier to fork Python and give it a new name. ChrisA
[toc] | [prev] | [next] | [standalone]
| From | MRAB <python@mrabarnett.plus.com> |
|---|---|
| Date | 2011-08-11 14:03 +0100 |
| Message-ID | <mailman.2176.1313067800.1164.python-list@python.org> |
| In reply to | #11113 |
On 11/08/2011 05:16, Chris Rebert wrote:
> On Wed, Aug 10, 2011 at 7:52 PM, Yingjie Lan<lanyjie@yahoo.com> wrote:
>> :And if we require {} then truly free indentation should be OK too! But
>>
>> :it wouldn't be Python any more.
>>
>> Of course, but not the case with ';'. Currently ';' is optional in Python,
>
> I think of it more as that Python deigns to permit semicolons.
>
>> But '{' is used for dicts. Clearly, ';' and '{' are different in magnitude.
>>
>> So the decision is: shall we change ';' from optional to mandatory
>> to allow free line splitting?
>
> Hell no, considering that the sizable majority of lines *aren't*
> split, which makes those semicolons completely redundant to their
> accompanying newlines. We'd be practicing poor Huffman coding by
> optimizing for the *un*common case. It would also add punctuational
> noise to what is otherwise an amazingly clean and readable syntax.
> Accidental semicolon omission is (IMO) the most irritating source of
> syntax (and, inadvertently, sometimes other more serious) errors in
> curly-braced programming languages.
>
+1
> Such a core syntax feature is not going to be changed lightly (or likely ever).
>
I'm glad to hear that. :-)
Although Python's use of indentation has its downside, we gain much
more then we lose, IMHO.
[toc] | [prev] | [next] | [standalone]
| From | Matt Joiner <anacrolix@gmail.com> |
|---|---|
| Date | 2011-08-12 00:28 +1000 |
| Subject | Re: [Python-ideas] allow line break at operators |
| Message-ID | <mailman.2183.1313072908.1164.python-list@python.org> |
| In reply to | #11113 |
+0.5
The "trailing \" workaround is nonobvious. Wrapping in () is noisy and
already heavily used by other syntactical structures. Since a final
':' is needed anyway, i think this would be great.
if a
and b
or c:
do stuff()
On Thu, Aug 11, 2011 at 11:02 PM, MRAB <python@mrabarnett.plus.com> wrote:
> On 11/08/2011 05:16, Chris Rebert wrote:
>>
>> On Wed, Aug 10, 2011 at 7:52 PM, Yingjie Lan<lanyjie@yahoo.com> wrote:
>>>
>>> :And if we require {} then truly free indentation should be OK too! But
>>>
>>> :it wouldn't be Python any more.
>>>
>>> Of course, but not the case with ';'. Currently ';' is optional in
>>> Python,
>>
>> I think of it more as that Python deigns to permit semicolons.
>>
>>> But '{' is used for dicts. Clearly, ';' and '{' are different in
>>> magnitude.
>>>
>>> So the decision is: shall we change ';' from optional to mandatory
>>> to allow free line splitting?
>>
>> Hell no, considering that the sizable majority of lines *aren't*
>> split, which makes those semicolons completely redundant to their
>> accompanying newlines. We'd be practicing poor Huffman coding by
>> optimizing for the *un*common case. It would also add punctuational
>> noise to what is otherwise an amazingly clean and readable syntax.
>> Accidental semicolon omission is (IMO) the most irritating source of
>> syntax (and, inadvertently, sometimes other more serious) errors in
>> curly-braced programming languages.
>>
> +1
>>
>> Such a core syntax feature is not going to be changed lightly (or likely
>> ever).
>>
> I'm glad to hear that. :-)
>
> Although Python's use of indentation has its downside, we gain much
> more then we lose, IMHO.
> _______________________________________________
> Python-ideas mailing list
> Python-ideas@python.org
> http://mail.python.org/mailman/listinfo/python-ideas
>
[toc] | [prev] | [next] | [standalone]
| From | Steven D'Aprano <steve+comp.lang.python@pearwood.info> |
|---|---|
| Date | 2011-08-12 12:32 +1000 |
| Subject | Re: [Python-ideas] allow line break at operators |
| Message-ID | <4e4490c9$0$29975$c3e8da3$5496439d@news.astraweb.com> |
| In reply to | #11218 |
Matt Joiner wrote:
> +0.5
>
> The "trailing \" workaround is nonobvious. Wrapping in () is noisy and
> already heavily used by other syntactical structures.
"Noisy"? Compare:
# Best viewed with a fixed-width font
if a if (a
and b and b
or c: or c):
do stuff() do stuff()
That is not my idea of "noise". The brackets have a clear and obvious
meaning: they group the condition.
> Since a final
> ':' is needed anyway, i think this would be great.
A final : is not needed for arbitrary expressions.
flag = (a
and b
or c)
--
Steven
[toc] | [prev] | [next] | [standalone]
| From | Jakob Bowyer <jkbbwr@gmail.com> |
|---|---|
| Date | 2011-08-11 16:42 +0100 |
| Subject | Re: [Python-ideas] allow line break at operators |
| Message-ID | <mailman.2184.1313077366.1164.python-list@python.org> |
| In reply to | #11113 |
-1 This idea seems like it would remove the true readability of
python. Personally it would create more confusion than it would
remove.
On Thu, Aug 11, 2011 at 3:28 PM, Matt Joiner <anacrolix@gmail.com> wrote:
> +0.5
>
> The "trailing \" workaround is nonobvious. Wrapping in () is noisy and
> already heavily used by other syntactical structures. Since a final
> ':' is needed anyway, i think this would be great.
>
> if a
> and b
> or c:
> do stuff()
>
> On Thu, Aug 11, 2011 at 11:02 PM, MRAB <python@mrabarnett.plus.com> wrote:
>> On 11/08/2011 05:16, Chris Rebert wrote:
>>>
>>> On Wed, Aug 10, 2011 at 7:52 PM, Yingjie Lan<lanyjie@yahoo.com> wrote:
>>>>
>>>> :And if we require {} then truly free indentation should be OK too! But
>>>>
>>>> :it wouldn't be Python any more.
>>>>
>>>> Of course, but not the case with ';'. Currently ';' is optional in
>>>> Python,
>>>
>>> I think of it more as that Python deigns to permit semicolons.
>>>
>>>> But '{' is used for dicts. Clearly, ';' and '{' are different in
>>>> magnitude.
>>>>
>>>> So the decision is: shall we change ';' from optional to mandatory
>>>> to allow free line splitting?
>>>
>>> Hell no, considering that the sizable majority of lines *aren't*
>>> split, which makes those semicolons completely redundant to their
>>> accompanying newlines. We'd be practicing poor Huffman coding by
>>> optimizing for the *un*common case. It would also add punctuational
>>> noise to what is otherwise an amazingly clean and readable syntax.
>>> Accidental semicolon omission is (IMO) the most irritating source of
>>> syntax (and, inadvertently, sometimes other more serious) errors in
>>> curly-braced programming languages.
>>>
>> +1
>>>
>>> Such a core syntax feature is not going to be changed lightly (or likely
>>> ever).
>>>
>> I'm glad to hear that. :-)
>>
>> Although Python's use of indentation has its downside, we gain much
>> more then we lose, IMHO.
>> _______________________________________________
>> Python-ideas mailing list
>> Python-ideas@python.org
>> http://mail.python.org/mailman/listinfo/python-ideas
>>
> _______________________________________________
> Python-ideas mailing list
> Python-ideas@python.org
> http://mail.python.org/mailman/listinfo/python-ideas
>
[toc] | [prev] | [next] | [standalone]
| From | Daniel Greenfeld <pydanny@gmail.com> |
|---|---|
| Date | 2011-08-11 10:04 -0700 |
| Subject | Re: [Python-ideas] allow line break at operators |
| Message-ID | <mailman.2185.1313082268.1164.python-list@python.org> |
| In reply to | #11113 |
Something like this already exists:
a = 0
b = 1
if (True == True
and False == False
and a + 1 == b
and b - 1 == a):
print 'meh'
So I've got no idea what this proposal is about except for the
dropping of readability of Python.
-1
Daniel Greenfeld
On Thu, Aug 11, 2011 at 8:42 AM, Jakob Bowyer <jkbbwr@gmail.com> wrote:
> -1 This idea seems like it would remove the true readability of
> python. Personally it would create more confusion than it would
> remove.
>
> On Thu, Aug 11, 2011 at 3:28 PM, Matt Joiner <anacrolix@gmail.com> wrote:
>> +0.5
>>
>> The "trailing \" workaround is nonobvious. Wrapping in () is noisy and
>> already heavily used by other syntactical structures. Since a final
>> ':' is needed anyway, i think this would be great.
>>
>> if a
>> and b
>> or c:
>> do stuff()
>>
>> On Thu, Aug 11, 2011 at 11:02 PM, MRAB <python@mrabarnett.plus.com> wrote:
>>> On 11/08/2011 05:16, Chris Rebert wrote:
>>>>
>>>> On Wed, Aug 10, 2011 at 7:52 PM, Yingjie Lan<lanyjie@yahoo.com> wrote:
>>>>>
>>>>> :And if we require {} then truly free indentation should be OK too! But
>>>>>
>>>>> :it wouldn't be Python any more.
>>>>>
>>>>> Of course, but not the case with ';'. Currently ';' is optional in
>>>>> Python,
>>>>
>>>> I think of it more as that Python deigns to permit semicolons.
>>>>
>>>>> But '{' is used for dicts. Clearly, ';' and '{' are different in
>>>>> magnitude.
>>>>>
>>>>> So the decision is: shall we change ';' from optional to mandatory
>>>>> to allow free line splitting?
>>>>
>>>> Hell no, considering that the sizable majority of lines *aren't*
>>>> split, which makes those semicolons completely redundant to their
>>>> accompanying newlines. We'd be practicing poor Huffman coding by
>>>> optimizing for the *un*common case. It would also add punctuational
>>>> noise to what is otherwise an amazingly clean and readable syntax.
>>>> Accidental semicolon omission is (IMO) the most irritating source of
>>>> syntax (and, inadvertently, sometimes other more serious) errors in
>>>> curly-braced programming languages.
>>>>
>>> +1
>>>>
>>>> Such a core syntax feature is not going to be changed lightly (or likely
>>>> ever).
>>>>
>>> I'm glad to hear that. :-)
>>>
>>> Although Python's use of indentation has its downside, we gain much
>>> more then we lose, IMHO.
>>> _______________________________________________
>>> Python-ideas mailing list
>>> Python-ideas@python.org
>>> http://mail.python.org/mailman/listinfo/python-ideas
>>>
>> _______________________________________________
>> Python-ideas mailing list
>> Python-ideas@python.org
>> http://mail.python.org/mailman/listinfo/python-ideas
>>
> _______________________________________________
> Python-ideas mailing list
> Python-ideas@python.org
> http://mail.python.org/mailman/listinfo/python-ideas
>
[toc] | [prev] | [next] | [standalone]
Page 7 of 8 — ← Prev page 1 2 3 4 5 6 [7] 8 Next page →
Back to top | Article view | comp.lang.python
csiph-web