Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.python > #89005 > unrolled thread
| Started by | Blake McBride <blake1024@gmail.com> |
|---|---|
| First post | 2015-04-15 21:07 -0700 |
| Last post | 2015-04-16 18:45 +0000 |
| Articles | 20 on this page of 119 — 32 participants |
Back to article view | Back to comp.lang.python
New to Python - block grouping (spaces) Blake McBride <blake1024@gmail.com> - 2015-04-15 21:07 -0700
Re: New to Python - block grouping (spaces) Paul Rubin <no.email@nospam.invalid> - 2015-04-15 21:48 -0700
Re: New to Python - block grouping (spaces) Chris Angelico <rosuav@gmail.com> - 2015-04-16 14:51 +1000
Re: New to Python - block grouping (spaces) Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2015-04-16 15:49 +1000
Re: New to Python - block grouping (spaces) Paul Rubin <no.email@nospam.invalid> - 2015-04-15 23:11 -0700
Re: New to Python - block grouping (spaces) William Ray Wing <wrw@mac.com> - 2015-04-16 09:00 -0400
Re: New to Python - block grouping (spaces) BartC <bc@freeuk.com> - 2015-04-16 11:51 +0100
Re: New to Python - block grouping (spaces) Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2015-04-17 03:10 +1000
Re: New to Python - block grouping (spaces) Tim Chase <python.list@tim.thechases.com> - 2015-04-16 12:49 -0500
Re: New to Python - block grouping (spaces) BartC <bc@freeuk.com> - 2015-04-16 22:04 +0100
Re: New to Python - block grouping (spaces) Antoon Pardon <antoon.pardon@rece.vub.ac.be> - 2015-04-17 11:37 +0200
Re: New to Python - block grouping (spaces) Serhiy Storchaka <storchaka@gmail.com> - 2015-04-16 22:14 +0300
Re: New to Python - block grouping (spaces) alister <alister.nospam.ware@ntlworld.com> - 2015-04-16 07:46 +0000
Re: New to Python - block grouping (spaces) Antoon Pardon <antoon.pardon@rece.vub.ac.be> - 2015-04-16 10:47 +0200
Re: New to Python - block grouping (spaces) Chris Angelico <rosuav@gmail.com> - 2015-04-16 19:34 +1000
Re: New to Python - block grouping (spaces) Antoon Pardon <antoon.pardon@rece.vub.ac.be> - 2015-04-16 12:09 +0200
Re: New to Python - block grouping (spaces) Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2015-04-16 20:43 +1000
Re: New to Python - block grouping (spaces) Antoon Pardon <antoon.pardon@rece.vub.ac.be> - 2015-04-16 13:07 +0200
Re: New to Python - block grouping (spaces)yhoni alister <alister.nospam.ware@ntlworld.com> - 2015-04-16 13:18 +0000
Re: New to Python - block grouping (spaces)yhoni BartC <bc@freeuk.com> - 2015-04-16 14:44 +0100
Re: New to Python - block grouping (spaces)yhoni Mark Lawrence <breamoreboy@yahoo.co.uk> - 2015-04-16 18:46 +0100
Re: New to Python - block grouping (spaces)yhoni alister <alister.nospam.ware@ntlworld.com> - 2015-04-16 18:03 +0000
Re: New to Python - block grouping (spaces)yhoni Chris Angelico <rosuav@gmail.com> - 2015-04-16 23:50 +1000
Re: New to Python - block grouping (spaces)yhoni Antoon Pardon <antoon.pardon@rece.vub.ac.be> - 2015-04-16 16:09 +0200
Re: New to Python - block grouping (spaces)yhoni alister <alister.nospam.ware@ntlworld.com> - 2015-04-16 18:04 +0000
Re: New to Python - block grouping (spaces) Chris Angelico <rosuav@gmail.com> - 2015-04-16 23:41 +1000
Re: New to Python - block grouping (spaces) Antoon Pardon <antoon.pardon@rece.vub.ac.be> - 2015-04-16 15:57 +0200
Re: New to Python - block grouping (spaces) Mark Lawrence <breamoreboy@yahoo.co.uk> - 2015-04-16 13:17 +0100
Re: New to Python - block grouping (spaces) Antoon Pardon <antoon.pardon@rece.vub.ac.be> - 2015-04-16 14:48 +0200
Re: New to Python - block grouping (spaces) Simmo <square.steve@gmail.com> - 2015-04-16 14:37 +0100
Re: New to Python - block grouping (spaces) Blake McBride <blake1024@gmail.com> - 2015-04-16 07:52 -0700
Re: New to Python - block grouping (spaces) Blake McBride <blake1024@gmail.com> - 2015-04-16 08:01 -0700
Re: New to Python - block grouping (spaces) alister <alister.nospam.ware@ntlworld.com> - 2015-04-16 18:08 +0000
Re: New to Python - block grouping (spaces) memilanuk <memilanuk@gmail.com> - 2015-04-16 11:28 -0700
Re: New to Python - block grouping (spaces) Jon Ribbens <jon+usenet@unequivocal.co.uk> - 2015-04-16 15:05 +0000
Re: New to Python - block grouping (spaces) edmondo.giovannozzi@gmail.com - 2015-04-20 03:00 -0700
Re: New to Python - block grouping (spaces) memilanuk <memilanuk@gmail.com> - 2015-04-16 08:05 -0700
Re: New to Python - block grouping (spaces) Mark Lawrence <breamoreboy@yahoo.co.uk> - 2015-04-16 16:05 +0100
Re: New to Python - block grouping (spaces) CHIN Dihedral <dihedral88888@gmail.com> - 2015-04-19 11:46 -0700
Re: New to Python - block grouping (spaces) Chris Angelico <rosuav@gmail.com> - 2015-04-17 01:03 +1000
Re: New to Python - block grouping (spaces) Grant Edwards <invalid@invalid.invalid> - 2015-04-16 15:21 +0000
Re: New to Python - block grouping (spaces) Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2015-04-17 03:41 +1000
Re: New to Python - block grouping (spaces) Ron Adam <ron3200@gmail.com> - 2015-04-16 14:54 -0400
EditorConfig for cross-editor consistent code style (was: New to Python - block grouping (spaces)) Ben Finney <ben+python@benfinney.id.au> - 2015-04-17 06:10 +1000
Re: New to Python - block grouping (spaces) Michael Torrie <torriem@gmail.com> - 2015-04-17 09:44 -0600
Re: New to Python - block grouping (spaces) Grant Edwards <invalid@invalid.invalid> - 2015-04-17 16:28 +0000
Re: New to Python - block grouping (spaces) BartC <bc@freeuk.com> - 2015-04-17 18:05 +0100
Re: New to Python - block grouping (spaces) Rustom Mody <rustompmody@gmail.com> - 2015-04-17 10:13 -0700
Re: New to Python - block grouping (spaces) sohcahtoa82@gmail.com - 2015-04-17 11:13 -0700
Re: New to Python - block grouping (spaces) Marko Rauhamaa <marko@pacujo.net> - 2015-04-17 23:28 +0300
Re: New to Python - block grouping (spaces) Chris Angelico <rosuav@gmail.com> - 2015-04-18 07:10 +1000
Re: New to Python - block grouping (spaces) Dan Sommers <dan@tombstonezero.net> - 2015-04-18 01:18 +0000
Re: New to Python - block grouping (spaces) Rustom Mody <rustompmody@gmail.com> - 2015-04-17 19:22 -0700
Re: New to Python - block grouping (spaces) BartC <bc@freeuk.com> - 2015-04-19 12:44 +0100
Re: New to Python - block grouping (spaces) Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2015-04-19 23:23 +1000
Re: New to Python - block grouping (spaces) wxjmfauth@gmail.com - 2015-04-19 07:22 -0700
Re: New to Python - block grouping (spaces) Rustom Mody <rustompmody@gmail.com> - 2015-04-19 07:01 -0700
Re: New to Python - block grouping (spaces) Michael Torrie <torriem@gmail.com> - 2015-04-17 20:14 -0600
Re: New to Python - block grouping (spaces) Marko Rauhamaa <marko@pacujo.net> - 2015-04-18 09:53 +0300
Re: New to Python - block grouping (spaces) Ben Finney <ben+python@benfinney.id.au> - 2015-04-18 12:22 +1000
Re: New to Python - block grouping (spaces) Larry Hudson <orgnut@yahoo.com> - 2015-04-17 22:28 -0700
Re: New to Python - block grouping (spaces) Marko Rauhamaa <marko@pacujo.net> - 2015-04-18 10:00 +0300
Re: New to Python - block grouping (spaces) Rustom Mody <rustompmody@gmail.com> - 2015-04-18 00:13 -0700
Re: New to Python - block grouping (spaces) Marko Rauhamaa <marko@pacujo.net> - 2015-04-18 10:42 +0300
Re: New to Python - block grouping (spaces) Michael Torrie <torriem@gmail.com> - 2015-04-19 11:15 -0600
Re: New to Python - block grouping (spaces) Marko Rauhamaa <marko@pacujo.net> - 2015-04-19 23:41 +0300
Re: New to Python - block grouping (spaces) Rustom Mody <rustompmody@gmail.com> - 2015-04-19 19:00 -0700
Re: New to Python - block grouping (spaces) Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2015-04-20 12:54 +1000
Re: New to Python - block grouping (spaces) Chris Angelico <rosuav@gmail.com> - 2015-04-20 13:05 +1000
Re: New to Python - block grouping (spaces) Marko Rauhamaa <marko@pacujo.net> - 2015-04-20 08:09 +0300
Re: New to Python - block grouping (spaces) BartC <bc@freeuk.com> - 2015-04-19 12:38 +0100
Re: New to Python - block grouping (spaces) Ben Finney <ben+python@benfinney.id.au> - 2015-04-19 22:59 +1000
Re: New to Python - block grouping (spaces) BartC <bc@freeuk.com> - 2015-04-19 22:42 +0100
Re: New to Python - block grouping (spaces) Ron Adam <ron3200@gmail.com> - 2015-04-19 19:28 -0400
Re: New to Python - block grouping (spaces) Ben Finney <ben+python@benfinney.id.au> - 2015-04-20 09:59 +1000
Re: New to Python - block grouping (spaces) BartC <bc@freeuk.com> - 2015-04-20 01:30 +0100
Re: New to Python - block grouping (spaces) Dave Angel <davea@davea.name> - 2015-04-19 09:18 -0400
Re: New to Python - block grouping (spaces) Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2015-04-19 23:22 +1000
Re: New to Python - block grouping (spaces) Mark Lawrence <breamoreboy@yahoo.co.uk> - 2015-04-19 14:30 +0100
Re: New to Python - block grouping (spaces) Chris Angelico <rosuav@gmail.com> - 2015-04-20 01:15 +1000
Re: New to Python - block grouping (spaces) Rustom Mody <rustompmody@gmail.com> - 2015-04-19 09:03 -0700
Re: New to Python - block grouping (spaces) Mel Wilson <mwilson@the-wire.com> - 2015-04-19 17:38 +0000
Re: New to Python - block grouping (spaces) Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2015-04-20 03:53 +1000
Re: New to Python - block grouping (spaces) Mel Wilson <mwilson@the-wire.com> - 2015-04-19 18:25 +0000
Re: New to Python - block grouping (spaces) Rustom Mody <rustompmody@gmail.com> - 2015-04-19 19:08 -0700
Re: New to Python - block grouping (spaces) Chris Angelico <rosuav@gmail.com> - 2015-04-20 12:24 +1000
Re: New to Python - block grouping (spaces) Rustom Mody <rustompmody@gmail.com> - 2015-04-19 19:43 -0700
Re: New to Python - block grouping (spaces) Chris Angelico <rosuav@gmail.com> - 2015-04-20 13:03 +1000
Re: New to Python - block grouping (spaces) Rustom Mody <rustompmody@gmail.com> - 2015-04-19 20:28 -0700
Re: New to Python - block grouping (spaces) Chris Angelico <rosuav@gmail.com> - 2015-04-20 13:44 +1000
Re: New to Python - block grouping (spaces) Rustom Mody <rustompmody@gmail.com> - 2015-04-20 19:18 -0700
Re: New to Python - block grouping (spaces) Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2015-04-20 20:30 +1000
Re: New to Python - block grouping (spaces) Rustom Mody <rustompmody@gmail.com> - 2015-04-20 04:51 -0700
Re: New to Python - block grouping (spaces) albert@spenarnc.xs4all.nl (Albert van der Horst) - 2015-04-25 17:42 +0000
Re: New to Python - block grouping (spaces) BartC <bc@freeuk.com> - 2015-04-20 13:05 +0100
Re: New to Python - block grouping (spaces) wxjmfauth@gmail.com - 2015-04-24 01:50 -0700
Re: New to Python - block grouping (spaces) Mark Lawrence <breamoreboy@yahoo.co.uk> - 2015-04-20 03:38 +0100
Re: New to Python - block grouping (spaces) llanitedave <llanitedave@birdandflower.com> - 2015-04-21 08:29 -0700
Re: New to Python - block grouping (spaces) Rustom Mody <rustompmody@gmail.com> - 2015-04-21 10:49 -0700
Re: New to Python - block grouping (spaces) llanitedave <llanitedave@birdandflower.com> - 2015-04-21 14:35 -0700
Re: New to Python - block grouping (spaces) Rustom Mody <rustompmody@gmail.com> - 2015-04-21 20:11 -0700
Re: New to Python - block grouping (spaces) llanitedave <llanitedave@birdandflower.com> - 2015-04-21 21:05 -0700
Re: New to Python - block grouping (spaces) Rustom Mody <rustompmody@gmail.com> - 2015-04-22 04:37 -0700
Re: New to Python - block grouping (spaces) Mark Lawrence <breamoreboy@yahoo.co.uk> - 2015-04-22 13:05 +0100
Re: New to Python - block grouping (spaces) Gregory Ewing <greg.ewing@canterbury.ac.nz> - 2015-04-20 20:38 +1200
Re: New to Python - block grouping (spaces) Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2015-04-20 20:15 +1000
Re: New to Python - block grouping (spaces) Dan Sommers <dan@tombstonezero.net> - 2015-04-19 18:07 +0000
Re: New to Python - block grouping (spaces) Chris Angelico <rosuav@gmail.com> - 2015-04-20 06:03 +1000
Re: New to Python - block grouping (spaces) Rustom Mody <rustompmody@gmail.com> - 2015-04-19 18:46 -0700
Re: New to Python - block grouping (spaces) Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2015-04-20 12:42 +1000
Re: New to Python - block grouping (spaces) Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2015-04-20 03:46 +1000
Re: New to Python - block grouping (spaces) Paul Rubin <no.email@nospam.invalid> - 2015-04-19 13:36 -0700
Re: New to Python - block grouping (spaces) Rustom Mody <rustompmody@gmail.com> - 2015-04-24 22:06 -0700
Re: New to Python - block grouping (spaces) Marko Rauhamaa <marko@pacujo.net> - 2015-04-25 10:27 +0300
Re: New to Python - block grouping (spaces) Rustom Mody <rustompmody@gmail.com> - 2015-04-25 09:52 -0700
Re: New to Python - block grouping (spaces) Mark Lawrence <breamoreboy@yahoo.co.uk> - 2015-04-24 08:31 +0100
Re: New to Python - block grouping (spaces) Michael Torrie <torriem@gmail.com> - 2015-04-24 08:03 -0600
Re: New to Python - block grouping (spaces) Rustom Mody <rustompmody@gmail.com> - 2015-04-16 10:59 -0700
Re: New to Python - block grouping (spaces) Rob Gaddi <rgaddi@technologyhighland.invalid> - 2015-04-16 18:45 +0000
Page 5 of 6 — ← Prev page 1 2 3 4 [5] 6 Next page →
| From | Rustom Mody <rustompmody@gmail.com> |
|---|---|
| Date | 2015-04-19 09:03 -0700 |
| Message-ID | <7413a8e7-b580-4b2f-84bc-dd13da2d36ba@googlegroups.com> |
| In reply to | #89157 |
On Sunday, April 19, 2015 at 8:45:27 PM UTC+5:30, Chris Angelico wrote: <Description of the task of first-classing syntax snipped> > I suspect you'll find the task fundamentally hard. How hard? Lets see. Two guys wanted to write an OS. Seeing current languages not upto their standard they first made themselves a suitable language. Would you call their project hard ridiculous and misguided? Well evidently some people did but fortunately their managers did not interfere. OTOH some others liked the ideas/outlook enough that they jumped on the bandwagon and in short order there were - a heavy duty compilation system -- parser generators to librarians etc - editor(s) - source code systems - text tools (grep sed) - shell In short a 'Programmer's Work Bench' http://www.ics.uci.edu/~andre/ics228s2006/dolottamashey.pdf Now if Thomson and Ritchie (yeah thems the guys) could do it in 1970, why cant we revamp this 45-year old archaic program=textfile system today?
[toc] | [prev] | [next] | [standalone]
| From | Mel Wilson <mwilson@the-wire.com> |
|---|---|
| Date | 2015-04-19 17:38 +0000 |
| Message-ID | <mh0p79$ebb$1@dont-email.me> |
| In reply to | #89161 |
On Sun, 19 Apr 2015 09:03:23 -0700, Rustom Mody wrote: > Now if Thomson and Ritchie (yeah thems the guys) could do it in 1970, > why cant we revamp this 45-year old archaic program=textfile system > today? Dunno. Why not? There's half of you right there.
[toc] | [prev] | [next] | [standalone]
| From | Steven D'Aprano <steve+comp.lang.python@pearwood.info> |
|---|---|
| Date | 2015-04-20 03:53 +1000 |
| Message-ID | <5533eb85$0$12992$c3e8da3$5496439d@news.astraweb.com> |
| In reply to | #89161 |
On Mon, 20 Apr 2015 02:03 am, Rustom Mody wrote: > On Sunday, April 19, 2015 at 8:45:27 PM UTC+5:30, Chris Angelico wrote: > > <Description of the task of first-classing syntax snipped> > >> I suspect you'll find the task fundamentally hard. > > How hard? > Lets see. > Two guys wanted to write an OS. > Seeing current languages not upto their standard they first made > themselves a suitable language. > Would you call their project hard ridiculous and misguided? No, I would call it easy and sensible. University undergraduates write their own compilers and operating systems. Admittedly only toy ones, but Thomson and Ritchie weren't undergraduates. What does this have to do with creating a language with configurable syntax? Just because C/Unix was a good idea doesn't mean every idea related to programming language design is also a good idea. > Well evidently some people did but fortunately their managers did not > interfere. You are assuming they had managers. University life isn't exactly the same as corporate culture. > OTOH some others liked the ideas/outlook enough that they jumped on the > bandwagon and in short order there were - a heavy duty compilation system > -- parser generators to librarians etc - editor(s) > - source code systems > - text tools (grep sed) > - shell > > In short a 'Programmer's Work Bench' > http://www.ics.uci.edu/~andre/ics228s2006/dolottamashey.pdf > > Now if Thomson and Ritchie (yeah thems the guys) could do it in 1970, > why cant we revamp this 45-year old archaic program=textfile system today? Programmers use source code as text for the same reason that wheels are still round. Wheels have been round for thousands of years! Why can't we try something modern, like triangular wheels? Or something fractal in three-dimensions... maybe cauliflower shaped? -- Steven
[toc] | [prev] | [next] | [standalone]
| From | Mel Wilson <mwilson@the-wire.com> |
|---|---|
| Date | 2015-04-19 18:25 +0000 |
| Message-ID | <mh0rvm$ou2$1@dont-email.me> |
| In reply to | #89164 |
On Mon, 20 Apr 2015 03:53:08 +1000, Steven D'Aprano wrote: > On Mon, 20 Apr 2015 02:03 am, Rustom Mody wrote: >> Well evidently some people did but fortunately their managers did not >> interfere. > > You are assuming they had managers. University life isn't exactly the > same as corporate culture. IIRC Thompson, Ritchie, et al. were working at Bell Labs. Legend has it that management would not buy them a Multics, so they were forced to write their own using the hardware they had. Mel.
[toc] | [prev] | [next] | [standalone]
| From | Rustom Mody <rustompmody@gmail.com> |
|---|---|
| Date | 2015-04-19 19:08 -0700 |
| Message-ID | <16d59891-6e28-4256-870a-903bb75aa953@googlegroups.com> |
| In reply to | #89164 |
On Sunday, April 19, 2015 at 11:23:20 PM UTC+5:30, Steven D'Aprano wrote: > Programmers use source code as text for the same reason that wheels are > still round. Wheels have been round for thousands of years! Why can't we > try something modern, like triangular wheels? Or something fractal in > three-dimensions... maybe cauliflower shaped? So also did people believe for a good 2000 years that acceleration due to gravity is proportional to mass until Galileo climbed up the tower of Pisa and dropped 2 different weight objects http://en.wikipedia.org/wiki/Galileo%27s_Leaning_Tower_of_Pisa_experiment Analogies can work both ways And before you ask something like | What does this have to do with creating a language with configurable syntax? | Just because C/Unix was a good idea doesn't mean every idea related to | programming language design is also a good idea. let me spell it out: Prestige of Aristotle stymies progress of physics of 2 millennia likewise Prestige of Unix development environment keeps us stuck with text files when the world has moved on
[toc] | [prev] | [next] | [standalone]
| From | Chris Angelico <rosuav@gmail.com> |
|---|---|
| Date | 2015-04-20 12:24 +1000 |
| Message-ID | <mailman.3.1429496666.31470.python-list@python.org> |
| In reply to | #89186 |
On Mon, Apr 20, 2015 at 12:08 PM, Rustom Mody <rustompmody@gmail.com> wrote: > Prestige of Unix development environment keeps us stuck with text files when > the world has moved on And what, pray, would we gain by using non-text source code? Aside from binding ourselves to a set of tools, which would create an even worse lock-in? ChrisA
[toc] | [prev] | [next] | [standalone]
| From | Rustom Mody <rustompmody@gmail.com> |
|---|---|
| Date | 2015-04-19 19:43 -0700 |
| Message-ID | <a745d401-190d-4e7b-bc90-85f7e2cd6504@googlegroups.com> |
| In reply to | #89187 |
On Monday, April 20, 2015 at 7:54:37 AM UTC+5:30, Chris Angelico wrote: > On Mon, Apr 20, 2015 at 12:08 PM, Rustom Mody wrote: > > Prestige of Unix development environment keeps us stuck with text files when > > the world has moved on > > And what, pray, would we gain by using non-text source code? Aside > from binding ourselves to a set of tools, which would create an even > worse lock-in? Threads like this one would become passé. In html for example there's things like fluid-layout. So also if indentation was strictly delimited by tabs then whether you like to see your tabs as 4 spaces and I like to see them as 2 would be as relevant to our discussing shared code as the fact that I wearing pyjamas and you are in a 3 piece suit. The key thing to make this work is that the tab needs to be a reasonably solid non-leaky abstraction for denoting an indent. As soon as you allow both tabs and spaces all the interminable bikeshedding starts In many ways this is like the browser wars. If browsers had been made like half-decent compilers then non-compliant html wouldn't render and would get corrected on short order. Instead browsers overreach themselves to be nice (to users) and end up being horrible to web-developers who now need to maintain 1 dozen browsers × 2 dozen versions. Likewise all the overreaching to be allow 'free-form' layout puts paid to all attempts at richer structure comprehending tools. As a quick example try this: You've a 10-file python project in which you want to replace function 'f' by function 'longname' How easy is it? I am ready to bet that if you use IE-ish its easy if you use classic editors not so. This unfortunate choice between sophistication+lockin vs uncivilization+freedom is unnecessary
[toc] | [prev] | [next] | [standalone]
| From | Chris Angelico <rosuav@gmail.com> |
|---|---|
| Date | 2015-04-20 13:03 +1000 |
| Message-ID | <mailman.5.1429499040.31470.python-list@python.org> |
| In reply to | #89190 |
On Mon, Apr 20, 2015 at 12:43 PM, Rustom Mody <rustompmody@gmail.com> wrote: > The key thing to make this work is that the tab needs to be a reasonably solid > non-leaky abstraction for denoting an indent. > As soon as you allow both tabs and spaces all the interminable bikeshedding starts > Whatever you change, there will be stuff for people to argue about. Trust me, that's nothing to do with the nature of programming languages... it's about the nature of people. > In many ways this is like the browser wars. > If browsers had been made like half-decent compilers then non-compliant html > wouldn't render and would get corrected on short order. > Instead browsers overreach themselves to be nice (to users) and end up being > horrible to web-developers who now need to maintain 1 dozen browsers × 2 dozen versions. > > Likewise all the overreaching to be allow 'free-form' layout puts paid to all > attempts at richer structure comprehending tools. > As a quick example try this: > You've a 10-file python project in which you want to replace function 'f' > by function 'longname' > How easy is it? > > I am ready to bet that if you use IE-ish its easy if you use classic editors > not so. If you have a ten-file project that's identifying a key function globally as 'f', then you already have a problem. If your names are more useful and informative, a global search-and-replace will do the job. What's your point, though? Somewhere along the way, you need to have identifiers, and those identifiers need to explain *to the human* what code you're referring to. Whether they're line labels in assembly language, memory locations in machine code, linker relocation table entries, fully-qualified module/class/method names, or simple flat identifiers, they exist as much for the humans as for the compiler. If you change the basic syscall from INT 21 to CALL __SYSTEM, everyone who uses your code needs to change his/her *head* to cope with your change. There is fundamentally no tool which can do this for you. You can add a level of indirection to program loading by having the function name turn into some sort of internal identifier when you save the source file, and then you can rename the function in one place. Great! But somehow you still need to have humans recognize which functions they want to call. Do they have to point-and-click to pick a function? I've used IDEs like that, and they are a pain. ChrisA
[toc] | [prev] | [next] | [standalone]
| From | Rustom Mody <rustompmody@gmail.com> |
|---|---|
| Date | 2015-04-19 20:28 -0700 |
| Message-ID | <17ed0132-89d5-4b45-81b5-b61328a21198@googlegroups.com> |
| In reply to | #89194 |
On Monday, April 20, 2015 at 8:34:12 AM UTC+5:30, Chris Angelico wrote: > On Mon, Apr 20, 2015 at 12:43 PM, Rustom Mody wrote: > > The key thing to make this work is that the tab needs to be a reasonably solid > > non-leaky abstraction for denoting an indent. > > As soon as you allow both tabs and spaces all the interminable bikeshedding starts > > > > Whatever you change, there will be stuff for people to argue about. > Trust me, that's nothing to do with the nature of programming > languages... it's about the nature of people. > > > In many ways this is like the browser wars. > > If browsers had been made like half-decent compilers then non-compliant html > > wouldn't render and would get corrected on short order. > > Instead browsers overreach themselves to be nice (to users) and end up being > > horrible to web-developers who now need to maintain 1 dozen browsers × 2 dozen versions. > > > > Likewise all the overreaching to be allow 'free-form' layout puts paid to all > > attempts at richer structure comprehending tools. > > As a quick example try this: > > You've a 10-file python project in which you want to replace function 'f' > > by function 'longname' > > How easy is it? > > > > I am ready to bet that if you use IE-ish its easy if you use classic editors > > not so. > > If you have a ten-file project that's identifying a key function > globally as 'f', then you already have a problem. If your names are > more useful and informative, a global search-and-replace will do the > job. Are you sure your global search-and-replace will do a proper job inside strings and comments? > > What's your point, though? Point? Nnotions like identifier (and dozens of others) are straightforwardly present and available inside the python implementation. However the language implementation is a hard-n-high silo For the programmer accessing the language through an editor these notions are not available unless hi-power explosives are used to punch holes in the silo -- eg open Cpython sources. The Smalltalks and Lisps organized the world differently -- the programmer was inside the silo with the corresponding advantages of power and disadvantages of imprisonment. I (and I guess BartC) like to dream of a Utopia that is powerful and free
[toc] | [prev] | [next] | [standalone]
| From | Chris Angelico <rosuav@gmail.com> |
|---|---|
| Date | 2015-04-20 13:44 +1000 |
| Message-ID | <mailman.7.1429501451.31470.python-list@python.org> |
| In reply to | #89195 |
On Mon, Apr 20, 2015 at 1:28 PM, Rustom Mody <rustompmody@gmail.com> wrote:
>> If you have a ten-file project that's identifying a key function
>> globally as 'f', then you already have a problem. If your names are
>> more useful and informative, a global search-and-replace will do the
>> job.
>
> Are you sure your global search-and-replace will do a proper job inside
> strings and comments?
Yep! Any occurrence inside a string literal or comment is generally
going to be referring to the same function, and thus should be
renamed. Can your system handle _that_? Example:
def add_grab(widget):
"""Add a widget to the grabbed widgets"""
def remove_grab(widget):
"""Undo the effect of add_grab() on a given widget"""
# Note that multiple add_grab() calls will add multiple instances,
# so we remove only the first.
Every occurrence of add_grab here is referring to the function. If you
do a global search-and-replace, they'll be caught automatically. With
your non-text magic, you'd need to explicitly implement this as a
feature. Text files make life easier!
>> What's your point, though?
>
> Point?
>
> Nnotions like identifier (and dozens of others) are straightforwardly
> present and available inside the python implementation.
> However the language implementation is a hard-n-high silo
> For the programmer accessing the language through an editor these notions are
> not available unless hi-power explosives are used to punch holes in the silo
> -- eg open Cpython sources.
Would it help if Python grew a function like Pike's
Function.defined(), which tells you exactly where, even in C source,
something was defined? I don't honestly see that looking in the
CPython source is such a common need that it begs for assistance, and
I definitely don't see how a non-text source code format would improve
on it. Feel like elaborating?
ChrisA
[toc] | [prev] | [next] | [standalone]
| From | Rustom Mody <rustompmody@gmail.com> |
|---|---|
| Date | 2015-04-20 19:18 -0700 |
| Message-ID | <bee34853-fb27-40ee-b64b-bfa33bc0ebe1@googlegroups.com> |
| In reply to | #89197 |
On Monday, April 20, 2015 at 9:14:23 AM UTC+5:30, Chris Angelico wrote: > I definitely don't see how a non-text source code format would improve > on it. Feel like elaborating? You are putting emphasis on the 'non'. This puts you into an oscillatory system between tautology and contradiction: How can something which is NOT be something? -- contradiction It is something else -- tautology If you dont put the emphasis on the not but on 'structured text' it may be more meaningful; eg html html is not 'not-text' -- you can edit it in a text editor alright. However if you edit it in a html-editor -- mozilla composer, seamonkey, or any of zillion web versions -- you get (at least) two views -- text vs structured In the text (ironically also called html) view it behaves like a half-assed text-editor In the structured view it renders the html structure (somewhat) So a table does not show as <table></table> <tr><td> etc but actually as cells. This prevents trivial counting/off-by-one errors. After the gross-layout is taken care of you can switch to text mode and add fancy html attributes if needed. Likewise having ready access to the AST of a program would be neat So for example when I used to do a lot of lisp, my editor was set up so that - cursor arrows behaved like normal cursor arrows - keypad arrows moved up/down/along S-exp ie they were tree movements
[toc] | [prev] | [next] | [standalone]
| From | Steven D'Aprano <steve+comp.lang.python@pearwood.info> |
|---|---|
| Date | 2015-04-20 20:30 +1000 |
| Message-ID | <5534d52d$0$2915$c3e8da3$76491128@news.astraweb.com> |
| In reply to | #89190 |
On Monday 20 April 2015 12:43, Rustom Mody wrote: > You've a 10-file python project in which you want to replace function 'f' > by function 'longname' > How easy is it? About a thousand times easier than the corresponding situation: You have ten PDF files in which you want to replace the word "f" with the word "longname". You have identified a weakness in the current Python ecosystem. Our automated refactoring tools are currently quite weak and primitive. I'm only aware of one, Bicycle Repair Man, which as far as I know is no longer under active development. But I think the reason for that is not because Python is text based. Java is also text based and it has powerful refactoring tools. In Python's case: - Python projects tend to be smaller and less enterprisey than Java projects; - Python syntax is easier to read (less cruft) and therefore manual refactoring is simpler, compared to Java. -- Steve
[toc] | [prev] | [next] | [standalone]
| From | Rustom Mody <rustompmody@gmail.com> |
|---|---|
| Date | 2015-04-20 04:51 -0700 |
| Message-ID | <d7f4c401-253a-4826-b018-7e84abb0838c@googlegroups.com> |
| In reply to | #89215 |
On Monday, April 20, 2015 at 4:00:16 PM UTC+5:30, Steven D'Aprano wrote: > On Monday 20 April 2015 12:43, Rustom Mody wrote: > > > You've a 10-file python project in which you want to replace function 'f' > > by function 'longname' > > How easy is it? > > About a thousand times easier than the corresponding situation: > > You have ten PDF files in which you want to replace the word "f" with the > word "longname". > To paraphrase Pauli's "This is not even wrong" this is not even a strawman If you want a realistic example its something like castXML or its more well-known predecessor gccXML https://github.com/CastXML/CastXML/blob/master/doc/manual/castxml.1.rst [With some hesitation because I dont like XML but anyway in the abstract thats my point] > > You have identified a weakness in the current Python ecosystem. Our > automated refactoring tools are currently quite weak and primitive. I'm only > aware of one, Bicycle Repair Man, which as far as I know is no longer under > active development. Well there is rope if thats what you want. > But I think the reason for that is not because Python is > text based. Java is also text based and it has powerful refactoring tools. > In Python's case: > > - Python projects tend to be smaller and less enterprisey than Java > projects; > > - Python syntax is easier to read (less cruft) and therefore manual > refactoring is simpler, compared to Java. All this is true but a bit far afield from what I am saying: These examples are about how to keep going with these silos as they are I am talking of how the silos can be less impenetrable
[toc] | [prev] | [next] | [standalone]
| From | albert@spenarnc.xs4all.nl (Albert van der Horst) |
|---|---|
| Date | 2015-04-25 17:42 +0000 |
| Message-ID | <553bd214$0$23196$e4fe514c@dreader34.news.xs4all.nl> |
| In reply to | #89216 |
In article <d7f4c401-253a-4826-b018-7e84abb0838c@googlegroups.com>, Rustom Mody <rustompmody@gmail.com> wrote: >On Monday, April 20, 2015 at 4:00:16 PM UTC+5:30, Steven D'Aprano wrote: >> On Monday 20 April 2015 12:43, Rustom Mody wrote: >> >> > You've a 10-file python project in which you want to replace function 'f' >> > by function 'longname' >> > How easy is it? >> >> About a thousand times easier than the corresponding situation: >> >> You have ten PDF files in which you want to replace the word "f" with the >> word "longname". >> > >To paraphrase Pauli's "This is not even wrong" >this is not even a strawman On the contrary it is the last word in this discussion. At least the last word I need or will read. Groetjes Albert -- Albert van der Horst, UTRECHT,THE NETHERLANDS Economic growth -- being exponential -- ultimately falters. albert@spe&ar&c.xs4all.nl &=n http://home.hccnet.nl/a.w.m.van.der.horst
[toc] | [prev] | [next] | [standalone]
| From | BartC <bc@freeuk.com> |
|---|---|
| Date | 2015-04-20 13:05 +0100 |
| Message-ID | <wY5Zw.267025$9%6.140183@fx01.am4> |
| In reply to | #89215 |
On 20/04/2015 11:30, Steven D'Aprano wrote:
> On Monday 20 April 2015 12:43, Rustom Mody wrote:
>
>> You've a 10-file python project in which you want to replace function 'f'
>> by function 'longname'
>> How easy is it?
>
> About a thousand times easier than the corresponding situation:
>
> You have ten PDF files in which you want to replace the word "f" with the
> word "longname".
Why would the PDF example be particularly difficult? (I assume they can
simply be processed individually.)
Some tool would be used to edit the textual contents of the files, and,
in the absence of any more specific instructions (there being embedded
code examples for instance, or some literal uses of "f", or it's verse
that still needs to rhyme), then you just replace each whole-word "f"
with "longname".
(It might well be 1000 times harder if the PDFs contained full-featured
Postscript where all the "f"s are generated at runtime, or their glyphs
are formed with highly elaborate graphics.)
> You have identified a weakness in the current Python ecosystem. Our
> automated refactoring tools are currently quite weak and primitive.
I'm sure everyone is already aware of the difficulties with doing this
with Python code, but apart from comments and strings, there are
examples such as this:
if cond:
def f():
print ("This is F")
else:
f=3.142
x=f
In this last line, it's not possible to tell whether f refers to the
function, or the number. (I assume the requirement is to change calls to
f(), or any references to the name, to longname(), as well as the defs.)
Even harder is:
eval(s)
where the string s may also contain references to f.
There is also code that may be commented out temporarily that you want
to change, and other comments that you don't want to change. Etc.
With some languages the task is simpler, as what is or isn't a valid
reference to "f" can be determined by examining the source code.
(Although C gives Python a run for its money by being able to use its
macro system to make certain code impossible to analyse from the static
sources.)
--
Bartc
[toc] | [prev] | [next] | [standalone]
| From | wxjmfauth@gmail.com |
|---|---|
| Date | 2015-04-24 01:50 -0700 |
| Message-ID | <789c7b7e-a54d-46b7-8f33-0aa304482234@googlegroups.com> |
| In reply to | #89215 |
Le lundi 20 avril 2015 12:30:16 UTC+2, Steven D'Aprano a écrit : > > You have ten PDF files in which you want to replace the word "f" with the > word "longname". > > Come on. This denotes a non undestanding of "pdf". Your "pdf" may not even contains a "char id" / "glyph", your replacement string may need. Unicode and related stuff. Serious users can be happy, all this is not working à la Python. What a disaster it would be. jmf
[toc] | [prev] | [next] | [standalone]
| From | Mark Lawrence <breamoreboy@yahoo.co.uk> |
|---|---|
| Date | 2015-04-20 03:38 +0100 |
| Message-ID | <mailman.4.1429497531.31470.python-list@python.org> |
| In reply to | #89186 |
On 20/04/2015 03:08, Rustom Mody wrote: > Prestige of Unix development environment keeps us stuck with text files when > the world has moved on > If it ain't broke, don't fix it. -- My fellow Pythonistas, ask not what our language can do for you, ask what you can do for our language. Mark Lawrence
[toc] | [prev] | [next] | [standalone]
| From | llanitedave <llanitedave@birdandflower.com> |
|---|---|
| Date | 2015-04-21 08:29 -0700 |
| Message-ID | <09bdfda4-9154-460b-bc54-f227f1c1fd90@googlegroups.com> |
| In reply to | #89186 |
On Sunday, April 19, 2015 at 7:09:02 PM UTC-7, Rustom Mody wrote: > > > let me spell it out: > Prestige of Aristotle stymies progress of physics of 2 millennia > likewise > Prestige of Unix development environment keeps us stuck with text files when > the world has moved on Difference is, Aristotle was flat-out, objectively wrong. Unix with text files, not so much.
[toc] | [prev] | [next] | [standalone]
| From | Rustom Mody <rustompmody@gmail.com> |
|---|---|
| Date | 2015-04-21 10:49 -0700 |
| Message-ID | <80574d29-7db6-4f67-b667-6cdc980b77e5@googlegroups.com> |
| In reply to | #89254 |
On Tuesday, April 21, 2015 at 9:01:08 PM UTC+5:30, llanitedave wrote: > On Sunday, April 19, 2015 at 7:09:02 PM UTC-7, Rustom Mody wrote: > > > > > > let me spell it out: > > Prestige of Aristotle stymies progress of physics of 2 millennia > > likewise > > Prestige of Unix development environment keeps us stuck with text files when > > the world has moved on > > Difference is, Aristotle was flat-out, objectively wrong. > > Unix with text files, not so much. If only Galileo had had you as lawyer...
[toc] | [prev] | [next] | [standalone]
| From | llanitedave <llanitedave@birdandflower.com> |
|---|---|
| Date | 2015-04-21 14:35 -0700 |
| Message-ID | <56e8beb8-88e3-4664-b95a-2875fa831bff@googlegroups.com> |
| In reply to | #89261 |
On Tuesday, April 21, 2015 at 10:49:34 AM UTC-7, Rustom Mody wrote: > On Tuesday, April 21, 2015 at 9:01:08 PM UTC+5:30, llanitedave wrote: > > On Sunday, April 19, 2015 at 7:09:02 PM UTC-7, Rustom Mody wrote: > > > > > > > > > let me spell it out: > > > Prestige of Aristotle stymies progress of physics of 2 millennia > > > likewise > > > Prestige of Unix development environment keeps us stuck with text files when > > > the world has moved on > > > > Difference is, Aristotle was flat-out, objectively wrong. > > > > Unix with text files, not so much. > > If only Galileo had had you as lawyer... Well, I'd asked Giordano Bruno for a positive recommendation. For some inexplicable reason, he declined.
[toc] | [prev] | [next] | [standalone]
Page 5 of 6 — ← Prev page 1 2 3 4 [5] 6 Next page →
Back to top | Article view | comp.lang.python
csiph-web