Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.python > #57940 > unrolled thread
| Started by | jonas.thornvall@gmail.com |
|---|---|
| First post | 2013-10-29 10:40 -0700 |
| Last post | 2013-10-30 10:02 -0700 |
| Articles | 10 on this page of 90 — 17 participants |
Back to article view | Back to comp.lang.python
First day beginner to python, add to counter after nested loop jonas.thornvall@gmail.com - 2013-10-29 10:40 -0700
Re: First day beginner to python, add to counter after nested loop Neil Cerutti <neilc@norwich.edu> - 2013-10-29 18:09 +0000
Re: First day beginner to python, add to counter after nested loop jonas.thornvall@gmail.com - 2013-10-29 11:23 -0700
Re: First day beginner to python, add to counter after nested loop jonas.thornvall@gmail.com - 2013-10-29 11:35 -0700
Re: First day beginner to python, add to counter after nested loop Dave Angel <davea@davea.name> - 2013-10-29 19:24 +0000
Re: First day beginner to python, add to counter after nested loop jonas.thornvall@gmail.com - 2013-10-29 13:08 -0700
Re: First day beginner to python, add to counter after nested loop jonas.thornvall@gmail.com - 2013-10-29 13:11 -0700
Re: First day beginner to python, add to counter after nested loop Mark Lawrence <breamoreboy@yahoo.co.uk> - 2013-10-29 20:37 +0000
Re: First day beginner to python, add to counter after nested loop Dave Angel <davea@davea.name> - 2013-10-30 01:44 +0000
Re: First day beginner to python, add to counter after nested loop Ned Batchelder <ned@nedbatchelder.com> - 2013-10-29 16:30 -0400
Re: First day beginner to python, add to counter after nested loop Neil Cerutti <neilc@norwich.edu> - 2013-10-29 20:32 +0000
Re: First day beginner to python, add to counter after nested loop Gregory Ewing <greg.ewing@canterbury.ac.nz> - 2013-10-30 11:53 +1300
Re: First day beginner to python, add to counter after nested loop Tim Roberts <timr@probo.com> - 2013-10-30 00:07 -0700
Re: First day beginner to python, add to counter after nested loop jonas.thornvall@gmail.com - 2013-10-30 01:52 -0700
Re: First day beginner to python, add to counter after nested loop jonas.thornvall@gmail.com - 2013-10-30 02:48 -0700
Re: First day beginner to python, add to counter after nested loop jonas.thornvall@gmail.com - 2013-10-30 02:52 -0700
Re: First day beginner to python, add to counter after nested loop Mark Lawrence <breamoreboy@yahoo.co.uk> - 2013-10-30 10:00 +0000
Re: First day beginner to python, add to counter after nested loop jonas.thornvall@gmail.com - 2013-10-30 03:13 -0700
Re: First day beginner to python, add to counter after nested loop rusi <rustompmody@gmail.com> - 2013-10-30 05:08 -0700
Re: First day beginner to python, add to counter after nested loop Ned Batchelder <ned@nedbatchelder.com> - 2013-10-30 08:51 -0400
Re: First day beginner to python, add to counter after nested loop jonas.thornvall@gmail.com - 2013-10-30 03:42 -0700
Re: First day beginner to python, add to counter after nested loop jonas.thornvall@gmail.com - 2013-10-30 03:08 -0700
Re: First day beginner to python, add to counter after nested loop jonas.thornvall@gmail.com - 2013-10-30 03:11 -0700
Re: First day beginner to python, add to counter after nested loop jonas.thornvall@gmail.com - 2013-10-30 03:19 -0700
Re: First day beginner to python, add to counter after nested loop alex23 <wuwei23@gmail.com> - 2013-11-01 11:05 +1000
Re: First day beginner to python, add to counter after nested loop jonas.thornvall@gmail.com - 2013-10-30 07:24 -0700
Re: First day beginner to python, add to counter after nested loop Chris Angelico <rosuav@gmail.com> - 2013-10-30 21:42 +1100
Re: First day beginner to python, add to counter after nested loop Alister <alister.ware@ntlworld.com> - 2013-10-30 14:07 +0000
Re: First day beginner to python, add to counter after nested loop Tim Roberts <timr@probo.com> - 2013-11-02 13:19 -0700
Re: First day beginner to python, add to counter after nested loop Antoon Pardon <antoon.pardon@rece.vub.ac.be> - 2013-11-03 12:33 +0100
Re: First day beginner to python, add to counter after nested loop jonas.thornvall@gmail.com - 2013-11-03 04:54 -0800
Re: First day beginner to python, add to counter after nested loop jonas.thornvall@gmail.com - 2013-11-03 04:55 -0800
Re: First day beginner to python, add to counter after nested loop Antoon Pardon <antoon.pardon@rece.vub.ac.be> - 2013-10-30 13:01 +0100
Re: First day beginner to python, add to counter after nested loop Grant Edwards <invalid@invalid.invalid> - 2013-10-30 15:50 +0000
Re: First day beginner to python, add to counter after nested loop jonas.thornvall@gmail.com - 2013-10-30 08:54 -0700
Re: First day beginner to python, add to counter after nested loop Antoon Pardon <antoon.pardon@rece.vub.ac.be> - 2013-10-30 19:59 +0100
Re: First day beginner to python, add to counter after nested loop Chris Angelico <rosuav@gmail.com> - 2013-10-30 23:17 +1100
Re: First day beginner to python, add to counter after nested loop Antoon Pardon <antoon.pardon@rece.vub.ac.be> - 2013-10-30 13:42 +0100
Re: First day beginner to python, add to counter after nested loop Alister <alister.ware@ntlworld.com> - 2013-10-30 14:22 +0000
Re: First day beginner to python, add to counter after nested loop jonas.thornvall@gmail.com - 2013-10-30 07:31 -0700
Re: First day beginner to python, add to counter after nested loop Mark Lawrence <breamoreboy@yahoo.co.uk> - 2013-10-30 15:09 +0000
Re: First day beginner to python, add to counter after nested loop jonas.thornvall@gmail.com - 2013-10-30 08:35 -0700
Re: First day beginner to python, add to counter after nested loop jonas.thornvall@gmail.com - 2013-10-30 08:51 -0700
Re: First day beginner to python, add to counter after nested loop Alister <alister.ware@ntlworld.com> - 2013-10-30 15:51 +0000
Re: First day beginner to python, add to counter after nested loop jonas.thornvall@gmail.com - 2013-10-30 09:14 -0700
Re: First day beginner to python, add to counter after nested loop Dennis Lee Bieber <wlfraed@ix.netcom.com> - 2013-10-30 16:47 -0400
Re: First day beginner to python, add to counter after nested loop alex23 <wuwei23@gmail.com> - 2013-11-01 11:07 +1000
Re: First day beginner to python, add to counter after nested loop rusi <rustompmody@gmail.com> - 2013-10-30 08:53 -0700
Re: First day beginner to python, add to counter after nested loop Kushal Kumaran <kushal.kumaran+python@gmail.com> - 2013-10-30 22:00 +0530
Re: First day beginner to python, add to counter after nested loop rusi <rustompmody@gmail.com> - 2013-10-30 09:45 -0700
Re: First day beginner to python, add to counter after nested loop Mark Lawrence <breamoreboy@yahoo.co.uk> - 2013-10-30 15:54 +0000
Re: First day beginner to python, add to counter after nested loop jonas.thornvall@gmail.com - 2013-10-30 08:57 -0700
Re: First day beginner to python, add to counter after nested loop Alister <alister.ware@ntlworld.com> - 2013-10-30 16:13 +0000
Re: First day beginner to python, add to counter after nested loop rusi <rustompmody@gmail.com> - 2013-10-30 09:16 -0700
Re: First day beginner to python, add to counter after nested loop Mark Lawrence <breamoreboy@yahoo.co.uk> - 2013-10-30 16:38 +0000
Re: First day beginner to python, add to counter after nested loop Mark Lawrence <breamoreboy@yahoo.co.uk> - 2013-10-30 16:22 +0000
Re: First day beginner to python, add to counter after nested loop jonas.thornvall@gmail.com - 2013-10-30 09:31 -0700
Re: First day beginner to python, add to counter after nested loop MRAB <python@mrabarnett.plus.com> - 2013-10-30 17:44 +0000
Re: First day beginner to python, add to counter after nested loop jonas.thornvall@gmail.com - 2013-10-30 10:55 -0700
Re: First day beginner to python, add to counter after nested loop jonas.thornvall@gmail.com - 2013-10-30 11:02 -0700
Re: First day beginner to python, add to counter after nested loop Antoon Pardon <antoon.pardon@rece.vub.ac.be> - 2013-10-30 20:09 +0100
Re: First day beginner to python, add to counter after nested loop jonas.thornvall@gmail.com - 2013-10-30 12:16 -0700
Re: First day beginner to python, add to counter after nested loop Antoon Pardon <antoon.pardon@rece.vub.ac.be> - 2013-10-30 19:01 +0100
Re: First day beginner to python, add to counter after nested loop jonas.thornvall@gmail.com - 2013-10-30 11:43 -0700
Re: First day beginner to python, add to counter after nested loop Mark Lawrence <breamoreboy@yahoo.co.uk> - 2013-10-30 19:05 +0000
Re: First day beginner to python, add to counter after nested loop jonas.thornvall@gmail.com - 2013-10-30 12:13 -0700
Re: First day beginner to python, add to counter after nested loop Antoon Pardon <antoon.pardon@rece.vub.ac.be> - 2013-10-30 20:59 +0100
Re: First day beginner to python, add to counter after nested loop Ned Batchelder <ned@nedbatchelder.com> - 2013-10-30 16:52 -0400
Re: First day beginner to python, add to counter after nested loop Antoon Pardon <antoon.pardon@rece.vub.ac.be> - 2013-10-30 22:07 +0100
Re: First day beginner to python, add to counter after nested loop rusi <rustompmody@gmail.com> - 2013-10-31 00:37 -0700
Re: First day beginner to python, add to counter after nested loop Mark Lawrence <breamoreboy@yahoo.co.uk> - 2013-10-31 10:11 +0000
Re: First day beginner to python, add to counter after nested loop rusi <rustompmody@gmail.com> - 2013-10-31 04:07 -0700
Re: First day beginner to python, add to counter after nested loop Alister <alister.ware@ntlworld.com> - 2013-11-01 11:17 +0000
Re: First day beginner to python, add to counter after nested loop rusi <rustompmody@gmail.com> - 2013-11-01 09:52 -0700
Re: First day beginner to python, add to counter after nested loop Antoon Pardon <antoon.pardon@rece.vub.ac.be> - 2013-10-31 12:12 +0100
Re: First day beginner to python, add to counter after nested loop rusi <rustompmody@gmail.com> - 2013-10-31 04:40 -0700
Re: First day beginner to python, add to counter after nested loop Mark Lawrence <breamoreboy@yahoo.co.uk> - 2013-10-31 14:01 +0000
Re: First day beginner to python, add to counter after nested loop rusi <rustompmody@gmail.com> - 2013-10-31 08:30 -0700
Re: First day beginner to python, add to counter after nested loop jonas.thornvall@gmail.com - 2013-10-30 11:55 -0700
Re: First day beginner to python, add to counter after nested loop Mark Lawrence <breamoreboy@yahoo.co.uk> - 2013-10-30 19:26 +0000
Re: First day beginner to python, add to counter after nested loop jonas.thornvall@gmail.com - 2013-10-30 12:38 -0700
Re: First day beginner to python, add to counter after nested loop jonas.thornvall@gmail.com - 2013-10-30 12:41 -0700
Re: First day beginner to python, add to counter after nested loop Dave Angel <davea@davea.name> - 2013-10-31 03:02 +0000
Re: First day beginner to python, add to counter after nested loop Dennis Lee Bieber <wlfraed@ix.netcom.com> - 2013-10-30 16:50 -0400
Re: First day beginner to python, add to counter after nested loop jonas.thornvall@gmail.com - 2013-10-30 09:19 -0700
Re: First day beginner to python, add to counter after nested loop Alister <alister.ware@ntlworld.com> - 2013-10-30 15:15 +0000
Re: First day beginner to python, add to counter after nested loop Antoon Pardon <antoon.pardon@rece.vub.ac.be> - 2013-10-30 15:56 +0100
Re: First day beginner to python, add to counter after nested loop Alister <alister.ware@ntlworld.com> - 2013-10-30 16:07 +0000
Re: First day beginner to python, add to counter after nested loop Alister <alister.ware@ntlworld.com> - 2013-10-30 16:14 +0000
Re: First day beginner to python, add to counter after nested loop rurpy@yahoo.com - 2013-10-30 10:02 -0700
Page 5 of 5 — ← Prev page 1 2 3 4 [5]
| From | jonas.thornvall@gmail.com |
|---|---|
| Date | 2013-10-30 12:38 -0700 |
| Message-ID | <6f80a371-b7f2-48ee-bc9f-a33e0bea8617@googlegroups.com> |
| In reply to | #58094 |
Den onsdagen den 30:e oktober 2013 kl. 20:26:06 UTC+1 skrev Mark Lawrence: > On 30/10/2013 18:55, jonas.thornvall@gmail.com wrote: > > > > > > And it is certainly no problem to me it just means 10 more minutes now and then, the first week or two looking it up myself. But it adds up and the introduction to a programming language is always the hardest part, and finding out that the monkeys that implemented python can not follow directions, was the hardest part. The fuckers turned to go anal, and i do not like it. No more then i like the anal fuckers in any programming language. There seem to be these people around on every usenet programming group, so i wonder is this a programmer feature to go anal? > > > > > > I consider myself a sloppy but intelligent person. So who are these anal monkeys that seem to pop up in every NG dealing with programming i want to do a Myer-Briggs on the fuckers and make them conform to intelligence not anal behaviour but is it even possible? > > > > > > > Thank you for being honest enough to tell us what you're really like. > > I've certainly known a few people shoot themselves in the foot over the > > years, but I never thought I'd come across a Black Knight who could chop > > off his own arms and legs. > > > > -- > > Python is the second best programming language in the world. > > But the best has yet to be invented. Christian Tismer > > > > Mark Lawrence So you think there is a certain grandeur around being anal, i do not think so anal people very good can analyse and remove obstructs, even analyse code that they previously learned howto code. Myself think that is better done by automation... i am not into put down people that hold up the current status quo by going anal, no not a bit. What i am against is the anal people, becoming condescending towards people that may have good ideas, and sometimes being smarter and have a more plasticity favoured thought pattern then simple parroting...
[toc] | [prev] | [next] | [standalone]
| From | jonas.thornvall@gmail.com |
|---|---|
| Date | 2013-10-30 12:41 -0700 |
| Message-ID | <1e44b949-1ba4-4bee-9700-77b884da167f@googlegroups.com> |
| In reply to | #58094 |
Den onsdagen den 30:e oktober 2013 kl. 20:26:06 UTC+1 skrev Mark Lawrence: > On 30/10/2013 18:55, jonas.thornvall@gmail.com wrote: > > > > > > And it is certainly no problem to me it just means 10 more minutes now and then, the first week or two looking it up myself. But it adds up and the introduction to a programming language is always the hardest part, and finding out that the monkeys that implemented python can not follow directions, was the hardest part. The fuckers turned to go anal, and i do not like it. No more then i like the anal fuckers in any programming language. There seem to be these people around on every usenet programming group, so i wonder is this a programmer feature to go anal? > > > > > > I consider myself a sloppy but intelligent person. So who are these anal monkeys that seem to pop up in every NG dealing with programming i want to do a Myer-Briggs on the fuckers and make them conform to intelligence not anal behaviour but is it even possible? > > > > > > > Thank you for being honest enough to tell us what you're really like. > > I've certainly known a few people shoot themselves in the foot over the > > years, but I never thought I'd come across a Black Knight who could chop > > off his own arms and legs. > > > > -- > > Python is the second best programming language in the world. > > But the best has yet to be invented. Christian Tismer > > > > Mark Lawrence So i guess you do not like either Myer Briggs or IQ tests...
[toc] | [prev] | [next] | [standalone]
| From | Dave Angel <davea@davea.name> |
|---|---|
| Date | 2013-10-31 03:02 +0000 |
| Message-ID | <mailman.1864.1383188571.18130.python-list@python.org> |
| In reply to | #58066 |
On 30/10/2013 12:31, jonas.thornvall@gmail.com wrote: > > No that is not my problem, apparently so it is that the newsreader constructors do not like the competition of Google groups otherwise they would had written the five lines of codes necessary to remove the empty linebreaks. > I like web based features, and i will use them until "they get it right, understood?" > End of story They are not empty linebreaks, they're lines with one or more > symbols at the beginning and nothing following. And if all of them get deleted by some 5 line script, it would change many valid quotations. If you had actually looked at any of the links various people had sent you, you might understand how stupid you sound. (Note I'm not saying you're stupid, just ignorant) Googlegroups has the bug, and they're not likely to change it, as they've been asked many times. So if you continue to use gg, without compensating, then I and many like me will stop reading. It could have been nice. -- DaveA
[toc] | [prev] | [next] | [standalone]
| From | Dennis Lee Bieber <wlfraed@ix.netcom.com> |
|---|---|
| Date | 2013-10-30 16:50 -0400 |
| Message-ID | <mailman.1846.1383166506.18130.python-list@python.org> |
| In reply to | #58056 |
On Wed, 30 Oct 2013 08:57:08 -0700 (PDT), jonas.thornvall@gmail.com
declaimed the following:
>
>Bug of anal monkey either solve your own problems, or implement your own newsreader.
Really -- because ONE client (Google) makes a mess on all standards
conforming news clients, you suggest everyone else should implement new
clients?
I'd been holding on on the basis there might be something in your posts
worthy of responding to, but the last few tell me... No...
Goodbye.
--
Wulfraed Dennis Lee Bieber AF6VN
wlfraed@ix.netcom.com HTTP://wlfraed.home.netcom.com/
[toc] | [prev] | [next] | [standalone]
| From | jonas.thornvall@gmail.com |
|---|---|
| Date | 2013-10-30 09:19 -0700 |
| Message-ID | <8fb1e509-96c5-46eb-8cd2-9f972d457d35@googlegroups.com> |
| In reply to | #58054 |
Den onsdagen den 30:e oktober 2013 kl. 16:54:19 UTC+1 skrev Mark Lawrence: > On 30/10/2013 15:35, jonas.thornvall@gmail.com wrote: > > > Den onsdagen den 30:e oktober 2013 kl. 16:09:25 UTC+1 skrev Mark Lawrence: > > >> On 30/10/2013 14:31, jonas.thornvall@gmail.com wrote: > > >> > > >> > > >> > > >> Would you please be kind enough to read, digest and action this > > >> > > >> https://wiki.python.org/moin/GoogleGroupsPython > > >> > > >> > > >> > > >> TIA. > > >> > > >> > > >> > > >> -- > > >> > > >> Python is the second best programming language in the world. > > >> > > >> But the best has yet to be invented. Christian Tismer > > >> > > >> > > >> > > >> Mark Lawrence > > > > > > I am all for automatiation to be honest i rather go in change the code for google than do it manual. Maybe those who complain should adress Google? There must be a simple solution or? > > > > > > > The simplest solution is that you stop posting, as you've been spewing > > this double spaced crap all day and show no inclination to do anything > > about it. I assume that google won't fix their problem as there's not > > enough profit in it. > > > > -- > > Python is the second best programming language in the world. > > But the best has yet to be invented. Christian Tismer > > > > Mark Lawrence For what *they* actually have done is replacing the curl paragraph slavery with indentation slavery. And looking at the other features of python i easily can tell that was not the intention of the creator, it was to remove the anal code monkey stuff and replace it with simplicity and automation.
[toc] | [prev] | [next] | [standalone]
| From | Alister <alister.ware@ntlworld.com> |
|---|---|
| Date | 2013-10-30 15:15 +0000 |
| Message-ID | <Ao9cu.52339$gs7.15084@fx16.am4> |
| In reply to | #58042 |
On Wed, 30 Oct 2013 07:31:04 -0700, jonas.thornvall wrote: > Den onsdagen den 30:e oktober 2013 kl. 15:22:50 UTC+1 skrev Alister: >> On Wed, 30 Oct 2013 13:42:37 +0100, Antoon Pardon wrote: >> >> >> >> > Op 30-10-13 13:17, Chris Angelico schreef: >> >> >> On Wed, Oct 30, 2013 at 11:01 PM, Antoon Pardon >> >> >> <antoon.pardon@rece.vub.ac.be> wrote: >> >> >> I broadly agree with your post (I'm of the school of thought that >> >> >> braces are better than indentation for delimiting blocks), but I >> >> don't >> >> >> think this argument holds water. All you need to do is be consistent >> >> >> about tabs OR spaces (and I'd recommend tabs, since they're simpler >> >> and >> >> >> safer), and you'll never have this trouble. >> >> >> > >> > Easier said than done. First of all I can be as consistent as >> > possible, >> >> > I can't just take code from someone else and insert it because that >> >> > other person may be consistenly doing it different from me. >> >> >> >> I disagree it is very easy. >> >> >> >> 1) make sure you editor is set to inset 4 spaces rather than tab when >> >> pressing the tab key. consistency in your own code is now not an issue. >> >> >> >> 2) when importing code from someone else a simple search & replace of >> tab >> >> with 4 spaces will instantly correct the formatting on code using tab >> >> without breaking code that doesn't. >> >> >> >> >> >> >> > >> > Then if you are working on different machines, the settings of your >> >> > editor may not always be the same so that you have tabs on one >> > machine >> >> > and spaces on an other, which causes problem when you move the code. >> >> >> > >> that is fixed by setting your environment consistantly but step 2 above >> >> will fix it if you forget. >> >> >> >> > Also when you have an xterm, selecting a tab and pasting it into >> > another >> >> > it will turn the tab into spaces. >> >> >> >> Read pep 11 & always use 4 spaces for indentation not tab. >> >> >> >> >> > >> > All these things usually can be ignored, they typically only show up >> >> > when you print something and things aren't aligned as you expect but >> >> > with python you are forced to correct those things immediately, >> > forcing >> >> > you to focus on white space layout issues instead of on the logic of >> > the >> >> > code. >> >> >> > >> >> Also, the parser should tell you if you mix tabs and spaces, so that >> >> >> won't trip anything either. >> >> >> > >> > Maybe you mean something different than I understand but a program >> >> > throwing a syntax error because there is a tab instead of a number of >> >> > spaces or vice versa, is something I would understand as tripping. >> >> >> >> no more than failing to close a brace in a C like language >> >> indentation is the syntax of python you will grow to love it, like most >> >> people I found it distracting at first even though i tended to indent >> >> other code (inconsistently)to make it readable. >> >> >> >> >> >> >> >> >> >> -- >> >> I am what you will be; I was what you are. > > Alister i do not ask for changing the actual implementation with indents > that the compiler/interpretator work with. What i ask for is some > courtesy relative the programmers using IDLE, to incorporate a simple > automatic parser that let them who like to write slopy formatted with > end instead to do so. And the parser in editor automaticly go in and > autoindent *function, loops, if and allow end that the editor autoindent > to end of loop. It can not be that hard i have implemented my own python > using this... In that case I think you have found yourself a project ;-) I believe Idle is itself written in python so adding a clean-up function that meets your requirements should be feasible. you may even find others who find it useful. Personally I would recommend finding a better environment than Idle -- Your love life will be... interesting.
[toc] | [prev] | [next] | [standalone]
| From | Antoon Pardon <antoon.pardon@rece.vub.ac.be> |
|---|---|
| Date | 2013-10-30 15:56 +0100 |
| Message-ID | <mailman.1809.1383144994.18130.python-list@python.org> |
| In reply to | #58040 |
Op 30-10-13 15:22, Alister schreef: > On Wed, 30 Oct 2013 13:42:37 +0100, Antoon Pardon wrote: > >> Op 30-10-13 13:17, Chris Angelico schreef: >>> On Wed, Oct 30, 2013 at 11:01 PM, Antoon Pardon >>> <antoon.pardon@rece.vub.ac.be> wrote: >>> I broadly agree with your post (I'm of the school of thought that >>> braces are better than indentation for delimiting blocks), but I don't >>> think this argument holds water. All you need to do is be consistent >>> about tabs OR spaces (and I'd recommend tabs, since they're simpler and >>> safer), and you'll never have this trouble. >> >> Easier said than done. First of all I can be as consistent as possible, >> I can't just take code from someone else and insert it because that >> other person may be consistenly doing it different from me. > > I disagree it is very easy. You can disagree, as much as you want. You don't get to define my experience. Maybe all those things you enumerate are all easy, all taken together they can makes it cumbersome at times. > 1) make sure you editor is set to inset 4 spaces rather than tab when > pressing the tab key. consistency in your own code is now not an issue. > > 2) when importing code from someone else a simple search & replace of tab > with 4 spaces will instantly correct the formatting on code using tab > without breaking code that doesn't. But why should I have to do all that. When I write other code I just don't have to bother and it is all indented as desired too. >> Then if you are working on different machines, the settings of your >> editor may not always be the same so that you have tabs on one machine >> and spaces on an other, which causes problem when you move the code. >> > that is fixed by setting your environment consistantly but step 2 above > will fix it if you forget. Again why should I have to bother. Why does python force me to go through all this trouble when other languages allow themselves to be happily edited without all this. >> Also when you have an xterm, selecting a tab and pasting it into another >> it will turn the tab into spaces. > > Read pep 11 & always use 4 spaces for indentation not tab. I'll decide how to layout my code. >> All these things usually can be ignored, they typically only show up >> when you print something and things aren't aligned as you expect but >> with python you are forced to correct those things immediately, forcing >> you to focus on white space layout issues instead of on the logic of the >> code. >> >>> Also, the parser should tell you if you mix tabs and spaces, so that >>> won't trip anything either. >> >> Maybe you mean something different than I understand but a program >> throwing a syntax error because there is a tab instead of a number of >> spaces or vice versa, is something I would understand as tripping. > > no more than failing to close a brace in a C like language > indentation is the syntax of python you will grow to love it, like most > people I found it distracting at first even though i tended to indent > other code (inconsistently)to make it readable. I didn't like it at first, accustomed to it a bit and then disliked it again. So no I don't think I will grow to love it. Python is a tool, not a religion, so I can live with it if the tool I use has some featurese I dislike about it. As long as I evaluate the usefulness of the tool as positive I can live with the peeves. What is more annoying are the people with some kind of need to reason your peeves away, as if it is sacriledge daring to dislike something about the language. -- Antoon Pardon
[toc] | [prev] | [next] | [standalone]
| From | Alister <alister.ware@ntlworld.com> |
|---|---|
| Date | 2013-10-30 16:07 +0000 |
| Message-ID | <n9acu.52341$gs7.24809@fx16.am4> |
| In reply to | #58043 |
On Wed, 30 Oct 2013 15:56:32 +0100, Antoon Pardon wrote:
> Op 30-10-13 15:22, Alister schreef:
>> On Wed, 30 Oct 2013 13:42:37 +0100, Antoon Pardon wrote:
>>
>>> Op 30-10-13 13:17, Chris Angelico schreef:
>>>> On Wed, Oct 30, 2013 at 11:01 PM, Antoon Pardon
>>>> <antoon.pardon@rece.vub.ac.be> wrote:
>>>> I broadly agree with your post (I'm of the school of thought that
>>>> braces are better than indentation for delimiting blocks), but I
>>>> don't think this argument holds water. All you need to do is be
>>>> consistent about tabs OR spaces (and I'd recommend tabs, since
>>>> they're simpler and safer), and you'll never have this trouble.
>>>
>>> Easier said than done. First of all I can be as consistent as
>>> possible, I can't just take code from someone else and insert it
>>> because that other person may be consistenly doing it different from
>>> me.
>>
>> I disagree it is very easy.
>
> You can disagree, as much as you want. You don't get to define my
> experience. Maybe all those things you enumerate are all easy, all taken
> together they can makes it cumbersome at times.
>
>> 1) make sure you editor is set to inset 4 spaces rather than tab when
>> pressing the tab key. consistency in your own code is now not an issue.
>>
>> 2) when importing code from someone else a simple search & replace of
>> tab with 4 spaces will instantly correct the formatting on code using
>> tab without breaking code that doesn't.
>
> But why should I have to do all that. When I write other code I just
> don't have to bother and it is all indented as desired too.
>
>>> Then if you are working on different machines, the settings of your
>>> editor may not always be the same so that you have tabs on one machine
>>> and spaces on an other, which causes problem when you move the code.
>>>
>> that is fixed by setting your environment consistantly but step 2 above
>> will fix it if you forget.
>
> Again why should I have to bother. Why does python force me to go
> through all this trouble when other languages allow themselves to be
> happily edited without all this.
>
>>> Also when you have an xterm, selecting a tab and pasting it into
>>> another it will turn the tab into spaces.
>>
>> Read pep 11 & always use 4 spaces for indentation not tab.
>
> I'll decide how to layout my code.
>
>>> All these things usually can be ignored, they typically only show up
>>> when you print something and things aren't aligned as you expect but
>>> with python you are forced to correct those things immediately,
>>> forcing you to focus on white space layout issues instead of on the
>>> logic of the code.
>>>
>>>> Also, the parser should tell you if you mix tabs and spaces, so that
>>>> won't trip anything either.
>>>
>>> Maybe you mean something different than I understand but a program
>>> throwing a syntax error because there is a tab instead of a number of
>>> spaces or vice versa, is something I would understand as tripping.
>>
>> no more than failing to close a brace in a C like language indentation
>> is the syntax of python you will grow to love it, like most people I
>> found it distracting at first even though i tended to indent other code
>> (inconsistently)to make it readable.
>
> I didn't like it at first, accustomed to it a bit and then disliked it
> again. So no I don't think I will grow to love it. Python is a tool, not
> a religion, so I can live with it if the tool I use has some featurese I
> dislike about it. As long as I evaluate the usefulness of the tool as
> positive I can live with the peeves.
>
> What is more annoying are the people with some kind of need to reason
> your peeves away, as if it is sacriledge daring to dislike something
> about the language.
I guess your experience & mine differ, that is personal taste
I am certainly not trying to "reason your peeves away" just presenting an
alternate view.
Just for fun I knocked up a quick function to parse a poorly writen
program as described by the OP (with end as a block terminator) and came
up with the following
def fixfile(i,o):
infile=open(i,'r')
outfile=open(o,'w')
indent=0
for line in infile:
text=line.strip()
if text[-3:]=='end':
indent=indent -1
continue
outfile.write("%s%s\r\n"%(" "*(indent*4),text))
if text[-1]==":":
indent=indent+1
obviously this is just proof of concept with no error checking vbut it
did convert this:-
def function():
print "this should be indented but isnt"
print "indented with tab"
print "too many spaces"
for x in range(10):
print "this should be indented twice!"
end
print "should be indented once"
end
print "this should not be indented at all!"
into this:-
def function():
print "this should be indented but isnt"
print "indented with tab"
print "too many spaces"
for x in range(10):
print "this should be indented twice!"
print "should be indented once"
print "this should not be indented at all!"
--
If you're right 90% of the time, why quibble about the remaining 3%?
[toc] | [prev] | [next] | [standalone]
| From | Alister <alister.ware@ntlworld.com> |
|---|---|
| Date | 2013-10-30 16:14 +0000 |
| Message-ID | <1gacu.52343$gs7.42832@fx16.am4> |
| In reply to | #58057 |
On Wed, 30 Oct 2013 16:07:47 +0000, Alister wrote:
> On Wed, 30 Oct 2013 15:56:32 +0100, Antoon Pardon wrote:
>
>> Op 30-10-13 15:22, Alister schreef:
>>> On Wed, 30 Oct 2013 13:42:37 +0100, Antoon Pardon wrote:
>>>
>>>> Op 30-10-13 13:17, Chris Angelico schreef:
>>>>> On Wed, Oct 30, 2013 at 11:01 PM, Antoon Pardon
>>>>> <antoon.pardon@rece.vub.ac.be> wrote:
>>>>> I broadly agree with your post (I'm of the school of thought that
>>>>> braces are better than indentation for delimiting blocks), but I
>>>>> don't think this argument holds water. All you need to do is be
>>>>> consistent about tabs OR spaces (and I'd recommend tabs, since
>>>>> they're simpler and safer), and you'll never have this trouble.
>>>>
>>>> Easier said than done. First of all I can be as consistent as
>>>> possible, I can't just take code from someone else and insert it
>>>> because that other person may be consistenly doing it different from
>>>> me.
>>>
>>> I disagree it is very easy.
>>
>> You can disagree, as much as you want. You don't get to define my
>> experience. Maybe all those things you enumerate are all easy, all
>> taken together they can makes it cumbersome at times.
>>
>>> 1) make sure you editor is set to inset 4 spaces rather than tab when
>>> pressing the tab key. consistency in your own code is now not an
>>> issue.
>>>
>>> 2) when importing code from someone else a simple search & replace of
>>> tab with 4 spaces will instantly correct the formatting on code using
>>> tab without breaking code that doesn't.
>>
>> But why should I have to do all that. When I write other code I just
>> don't have to bother and it is all indented as desired too.
>>
>>>> Then if you are working on different machines, the settings of your
>>>> editor may not always be the same so that you have tabs on one
>>>> machine and spaces on an other, which causes problem when you move
>>>> the code.
>>>>
>>> that is fixed by setting your environment consistantly but step 2
>>> above will fix it if you forget.
>>
>> Again why should I have to bother. Why does python force me to go
>> through all this trouble when other languages allow themselves to be
>> happily edited without all this.
>>
>>>> Also when you have an xterm, selecting a tab and pasting it into
>>>> another it will turn the tab into spaces.
>>>
>>> Read pep 11 & always use 4 spaces for indentation not tab.
>>
>> I'll decide how to layout my code.
>>
>>>> All these things usually can be ignored, they typically only show up
>>>> when you print something and things aren't aligned as you expect but
>>>> with python you are forced to correct those things immediately,
>>>> forcing you to focus on white space layout issues instead of on the
>>>> logic of the code.
>>>>
>>>>> Also, the parser should tell you if you mix tabs and spaces, so that
>>>>> won't trip anything either.
>>>>
>>>> Maybe you mean something different than I understand but a program
>>>> throwing a syntax error because there is a tab instead of a number of
>>>> spaces or vice versa, is something I would understand as tripping.
>>>
>>> no more than failing to close a brace in a C like language indentation
>>> is the syntax of python you will grow to love it, like most people I
>>> found it distracting at first even though i tended to indent other
>>> code (inconsistently)to make it readable.
>>
>> I didn't like it at first, accustomed to it a bit and then disliked it
>> again. So no I don't think I will grow to love it. Python is a tool,
>> not a religion, so I can live with it if the tool I use has some
>> featurese I dislike about it. As long as I evaluate the usefulness of
>> the tool as positive I can live with the peeves.
>>
>> What is more annoying are the people with some kind of need to reason
>> your peeves away, as if it is sacriledge daring to dislike something
>> about the language.
>
> I guess your experience & mine differ, that is personal taste I am
> certainly not trying to "reason your peeves away" just presenting an
> alternate view.
>
> Just for fun I knocked up a quick function to parse a poorly writen
> program as described by the OP (with end as a block terminator) and came
> up with the following
>
> def fixfile(i,o):
> infile=open(i,'r')
> outfile=open(o,'w')
> indent=0 for line in infile:
> text=line.strip()
> if text[-3:]=='end':
> indent=indent -1 continue
> outfile.write("%s%s\r\n"%(" "*(indent*4),text))
> if text[-1]==":":
> indent=indent+1
>
> obviously this is just proof of concept with no error checking vbut it
> did convert this:-
>
> def function():
> print "this should be indented but isnt"
> print "indented with tab"
> print "too many spaces"
> for x in range(10):
> print "this should be indented twice!"
> end print "should be indented once"
> end
> print "this should not be indented at all!"
>
>
> into this:-
>
> def function():
> print "this should be indented but isnt"
> print "indented with tab"
> print "too many spaces"
> for x in range(10):
> print "this should be indented twice!"
> print "should be indented once"
> print "this should not be indented at all!"
there is a slight typo in my example input file with a missing line break.
--
Very few things happen at the right time, and the rest do not happen
at all. The conscientious historian will correct these defects.
-- Herodotus
[toc] | [prev] | [next] | [standalone]
| From | rurpy@yahoo.com |
|---|---|
| Date | 2013-10-30 10:02 -0700 |
| Message-ID | <5edf16e9-ff19-406b-9d28-477710e010ad@googlegroups.com> |
| In reply to | #58040 |
On 10/30/2013 08:22 AM, Alister wrote:
> On Wed, 30 Oct 2013 13:42:37 +0100, Antoon Pardon wrote:
>> Op 30-10-13 13:17, Chris Angelico schreef:
>>> On Wed, Oct 30, 2013 at 11:01 PM, Antoon Pardon
>>> <antoon.pardon@rece.vub.ac.be> wrote:
>>> I broadly agree with your post (I'm of the school of thought that
>>> braces are better than indentation for delimiting blocks), but I don't
>>> think this argument holds water. All you need to do is be consistent
>>> about tabs OR spaces (and I'd recommend tabs, since they're simpler and
>>> safer), and you'll never have this trouble.
>>
>> Easier said than done. First of all I can be as consistent as possible,
>> I can't just take code from someone else and insert it because that
>> other person may be consistenly doing it different from me.
>
> I disagree it is very easy.
>[...]
> 2) when importing code from someone else a simple search & replace of tab
> with 4 spaces will instantly correct the formatting on code using tab
> without breaking code that doesn't.
Tabs can occur in strings as well as tokens in Python
code and such code will be broken by a global search and
replace:
print (" %s" % message)
^^^^^^--- This is a literal tab.
Or:
CSVDATA = '''
item qty cost
44522 100 30.25
44107 55 15.50
45229 1007 77.20
'''
where the spaces between the columns above need to be
tabs to be correctly processed as csv text.
Your "easy fix" will break code like the above.
(And please note that because you can write the above
using "\t" or avoid literal tabs in other ways, that:
1) Does not negate the fact that the above code is
legal python code that is broken by your suggestion.
2) Alternatives such as using '\t' have their own
downsides such as readability or lack of compatibility
with other parts of a larger system.
Note too that even replacing only leading tabs is not
safe since the cvs data above could have leading tabs.
[toc] | [prev] | [standalone]
Page 5 of 5 — ← Prev page 1 2 3 4 [5]
Back to top | Article view | comp.lang.python
csiph-web