Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.python > #89005 > unrolled thread

New to Python - block grouping (spaces)

Back to article view | Back to comp.lang.python

Contents

  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 →

#89161

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]

#89163

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]

#89164

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]

#89167

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]

#89186

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]

#89187

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]

#89190

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]

#89194

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]

#89195

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]

#89197

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]

#89231

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]

#89215

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]

#89216

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]

#89395

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]

#89218

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]

#89361

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]

#89188

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]

#89254

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]

#89261

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]

#89273

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