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 4 of 6 — ← Prev page 1 2 3 [4] 5 6 Next page →
| From | Larry Hudson <orgnut@yahoo.com> |
|---|---|
| Date | 2015-04-17 22:28 -0700 |
| Message-ID | <8emdnR6R2KAVdqzInZ2dnUU7-KudnZ2d@giganews.com> |
| In reply to | #89104 |
On 04/17/2015 07:22 PM, Ben Finney wrote:
> BartC <bc@freeuk.com> writes:
>
>> (Actually *I* would quite like to know why languages don't have
>> switchable syntax anyway to allow for people's personal preferences.)
>
> Which people's personal preferences? Are these the same people who have
> such passionate disagreement about tabs versus spaces?
>
> If you only write programs that will only ever be read by you and no-one
> else, feel free to maintain a fork of Python (or any other language)
> that suits your personal preferences.
>
> Too much effort? Or maybe you sometimes want others, whose preferences
> may not exactly match yours, to collaborate on programs you write? Then
> I think you have your answer of why such personal perferences are not
> switchable in the languages we actually use.
>
I always find discussions like these rather amusing.
From a practical standpoint, no matter now passionately someone feels about this sort of thing,
it is ultimately totally irrelevant. The language (whatever language or subject it is) is
already defined. You either use it as it exists or go on to something else. EOD!
(End-of-discussion).
The exception, of course, is if you are actively involved in the defining and creating something
new. But otherwise, take it or leave it.
Naturally you are permitted to have your own opinions, whether passionate or otherwise, but it's
not worth arguing about.
-=- Larry -=-
[toc] | [prev] | [next] | [standalone]
| From | Marko Rauhamaa <marko@pacujo.net> |
|---|---|
| Date | 2015-04-18 10:00 +0300 |
| Message-ID | <87k2x9yl7w.fsf@elektro.pacujo.net> |
| In reply to | #89104 |
Ben Finney <ben+python@benfinney.id.au>: > If you only write programs that will only ever be read by you and > no-one else, feel free to maintain a fork of Python (or any other > language) that suits your personal preferences. It would be possible to define a canonical AST storage format. Then, your editor could "incarnate" the AST in the syntax of your choosing. A Python source file is an AST storage format, only it's not canonical. IOW, more than one Python source file can produce identical AST's. That isn't a problem for the specialized editors but it can be a problem for text editors, source code control etc. Marko
[toc] | [prev] | [next] | [standalone]
| From | Rustom Mody <rustompmody@gmail.com> |
|---|---|
| Date | 2015-04-18 00:13 -0700 |
| Message-ID | <6fc75a64-5c38-4dfa-b45b-7576b454dfab@googlegroups.com> |
| In reply to | #89113 |
On Saturday, April 18, 2015 at 12:30:49 PM UTC+5:30, Marko Rauhamaa wrote: > Ben Finney : > > > If you only write programs that will only ever be read by you and > > no-one else, feel free to maintain a fork of Python (or any other > > language) that suits your personal preferences. > > It would be possible to define a canonical AST storage format. Then, > your editor could "incarnate" the AST in the syntax of your choosing. > > A Python source file is an AST storage format, only it's not canonical. > IOW, more than one Python source file can produce identical AST's. That > isn't a problem for the specialized editors but it can be a problem for > text editors, source code control etc. Things like comments are a headache -- they have to be shoved into the AST rather artificially
[toc] | [prev] | [next] | [standalone]
| From | Marko Rauhamaa <marko@pacujo.net> |
|---|---|
| Date | 2015-04-18 10:42 +0300 |
| Message-ID | <87bnilyjao.fsf@elektro.pacujo.net> |
| In reply to | #89115 |
Rustom Mody <rustompmody@gmail.com>:
>> It would be possible to define a canonical AST storage format. Then,
>> your editor could "incarnate" the AST in the syntax of your choosing.
>>
>> [...]
>
> Things like comments are a headache -- they have to be shoved into the
> AST rather artificially
I don't think comments would be so bad assuming you don't write comments
like this:
result = principal * (1 + interest_rate / 100)
# expressed as percentage ^^^^^^^^^^^^^
I know, I know -- that's a lot to assume.
Marko
[toc] | [prev] | [next] | [standalone]
| From | Michael Torrie <torriem@gmail.com> |
|---|---|
| Date | 2015-04-19 11:15 -0600 |
| Message-ID | <mailman.409.1429463769.12925.python-list@python.org> |
| In reply to | #89113 |
On 04/18/2015 01:00 AM, Marko Rauhamaa wrote: > Ben Finney <ben+python@benfinney.id.au>: > >> If you only write programs that will only ever be read by you and >> no-one else, feel free to maintain a fork of Python (or any other >> language) that suits your personal preferences. > > It would be possible to define a canonical AST storage format. Then, > your editor could "incarnate" the AST in the syntax of your choosing. As was just mentioned in another part of the thread, what you're describing is essentially LISP.
[toc] | [prev] | [next] | [standalone]
| From | Marko Rauhamaa <marko@pacujo.net> |
|---|---|
| Date | 2015-04-19 23:41 +0300 |
| Message-ID | <87383vx34w.fsf@elektro.pacujo.net> |
| In reply to | #89162 |
Michael Torrie <torriem@gmail.com>: > On 04/18/2015 01:00 AM, Marko Rauhamaa wrote: >> It would be possible to define a canonical AST storage format. Then, >> your editor could "incarnate" the AST in the syntax of your choosing. > > As was just mentioned in another part of the thread, what you're > describing is essentially LISP. I don't see how that is more essentially Lisp than Python. Lisp has a noncanonical textual representation just like Python. Marko
[toc] | [prev] | [next] | [standalone]
| From | Rustom Mody <rustompmody@gmail.com> |
|---|---|
| Date | 2015-04-19 19:00 -0700 |
| Message-ID | <ac62e96e-4b60-498f-bdf4-52d4457e4f14@googlegroups.com> |
| In reply to | #89173 |
On Monday, April 20, 2015 at 2:11:13 AM UTC+5:30, Marko Rauhamaa wrote: > Michael Torrie: > > > On 04/18/2015 01:00 AM, Marko Rauhamaa wrote: > >> It would be possible to define a canonical AST storage format. Then, > >> your editor could "incarnate" the AST in the syntax of your choosing. > > > > As was just mentioned in another part of the thread, what you're > > describing is essentially LISP. > > I don't see how that is more essentially Lisp than Python. > > Lisp has a noncanonical textual representation just like Python. > > > Marko Technically correct Pragmatically: its like saying a meal that costs a penny, 100 EURO and 10K EURO are all the same. In C, access to parsing /unparsing is one of open up gcc/use lex/yacc In python, it is use the introspective module(s) In lisp its one call (read)/(print) -- at most; none if the REPL is used effectively
[toc] | [prev] | [next] | [standalone]
| From | Steven D'Aprano <steve+comp.lang.python@pearwood.info> |
|---|---|
| Date | 2015-04-20 12:54 +1000 |
| Message-ID | <55346a6a$0$12981$c3e8da3$5496439d@news.astraweb.com> |
| In reply to | #89173 |
On Mon, 20 Apr 2015 06:41 am, Marko Rauhamaa wrote: > Lisp has a noncanonical textual representation just like Python. Python has a noncanonical textual representation? What is a noncanonical textual representation, and where can I see some? -- Steven
[toc] | [prev] | [next] | [standalone]
| From | Chris Angelico <rosuav@gmail.com> |
|---|---|
| Date | 2015-04-20 13:05 +1000 |
| Message-ID | <mailman.6.1429499133.31470.python-list@python.org> |
| In reply to | #89192 |
On Mon, Apr 20, 2015 at 12:54 PM, Steven D'Aprano <steve+comp.lang.python@pearwood.info> wrote: > On Mon, 20 Apr 2015 06:41 am, Marko Rauhamaa wrote: > >> Lisp has a noncanonical textual representation just like Python. > > Python has a noncanonical textual representation? > > What is a noncanonical textual representation, and where can I see some? I think what Marko means is that there is a textual way to represent Python source code, and there are multiple files that represent identical Python programs, hence "noncanonical". If you have two UTF-8 encoded files that contain the same text, they will have the exact same bytes in them, because UTF-8 defines a canonical byte representation for text. You can't say that about Python source. ChrisA
[toc] | [prev] | [next] | [standalone]
| From | Marko Rauhamaa <marko@pacujo.net> |
|---|---|
| Date | 2015-04-20 08:09 +0300 |
| Message-ID | <87mw23v10w.fsf@elektro.pacujo.net> |
| In reply to | #89193 |
Chris Angelico <rosuav@gmail.com>: > On Mon, Apr 20, 2015 at 12:54 PM, Steven D'Aprano > <steve+comp.lang.python@pearwood.info> wrote: >> On Mon, 20 Apr 2015 06:41 am, Marko Rauhamaa wrote: >> Python has a noncanonical textual representation? >> >> What is a noncanonical textual representation, and where can I see >> some? > > I think what Marko means is that there is a textual way to represent > Python source code, and there are multiple files that represent > identical Python programs, hence "noncanonical". If you have two UTF-8 > encoded files that contain the same text, they will have the exact > same bytes in them, because UTF-8 defines a canonical byte > representation for text. You can't say that about Python source. Yes, more than one Python source file produces an identical AST, and none of them is obviously the "normal form." Marko
[toc] | [prev] | [next] | [standalone]
| From | BartC <bc@freeuk.com> |
|---|---|
| Date | 2015-04-19 12:38 +0100 |
| Message-ID | <7tMYw.252071$SO1.39320@fx43.am4> |
| In reply to | #89104 |
On 18/04/2015 03:22, Ben Finney wrote: > BartC <bc@freeuk.com> writes: > >> (Actually *I* would quite like to know why languages don't have >> switchable syntax anyway to allow for people's personal preferences.) > > Which people's personal preferences? Are these the same people who have > such passionate disagreement about tabs versus spaces? > > If you only write programs that will only ever be read by you and no-one > else, feel free to maintain a fork of Python (or any other language) > that suits your personal preferences. > > Too much effort? Or maybe you sometimes want others, whose preferences > may not exactly match yours, to collaborate on programs you write? Then > I think you have your answer of why such personal perferences are not > switchable in the languages we actually use. Perhaps you don't understand what I'm getting at. Suppose there were just two syntaxes: C-like and Python-like (we'll put aside for a minute the question of what format is used to store Python source code). Why shouldn't A configure his editor to display a Python program in C-like syntax, and B configure their editor to use Python-like tabbed syntax? A can write code in the preferred syntax, and B can view/modify exactly the same code in /their/ preferred syntax. What would be the problem? (The actual stored representation of the program would be in one of those two styles, or something else entirely; Lisp-like syntax for example. It doesn't matter because no-one would care. (I think much of the problem that most languages are intimately associated with their specific syntax, so that people can't see past it to what the code is actually saying. a=b, a:=b, b=>a, (setf a b), whatever the syntax is, who cares? We just want to do an assignment!) -- Bartc
[toc] | [prev] | [next] | [standalone]
| From | Ben Finney <ben+python@benfinney.id.au> |
|---|---|
| Date | 2015-04-19 22:59 +1000 |
| Message-ID | <mailman.402.1429448364.12925.python-list@python.org> |
| In reply to | #89145 |
BartC <bc@freeuk.com> writes: > Why shouldn't A configure his editor to display a Python program in > C-like syntax, and B configure their editor to use Python-like tabbed > syntax? I don't recall anyone saying that *shouldn't* be done. Feel free to make, and maintain and support and propagate and keep pace with changes in everything Python interacts with, a full Python stack that supports such flexibility. > A can write code in the preferred syntax, and B can view/modify > exactly the same code in /their/ preferred syntax. What would be the > problem? I can only invite you to embark on the project of a Python compiler which accepts such a switchable syntax, maintain it consistently over the lifetime of a project with significant numbers of people collaborating using different switch settings for that syntax, and working on the same code with different editor settings. Once you've done that, report back to us about the problems encountered. > (The actual stored representation of the program would be in one of > those two styles, or something else entirely; Lisp-like syntax for > example. It doesn't matter because no-one would care. No-one except the people who have to maintain and debug and continue developing a Python that supports multiple radically-different syntaxes. I suspect the efforts of those people is being discounted in your vision. -- \ “To have the choice between proprietary software packages, is | `\ being able to choose your master. Freedom means not having a | _o__) master.” —Richard M. Stallman, 2007-05-16 | Ben Finney
[toc] | [prev] | [next] | [standalone]
| From | BartC <bc@freeuk.com> |
|---|---|
| Date | 2015-04-19 22:42 +0100 |
| Message-ID | <zjVYw.278475$kA6.39572@fx46.am4> |
| In reply to | #89147 |
On 19/04/2015 13:59, Ben Finney wrote: > BartC <bc@freeuk.com> writes: > >> Why shouldn't A configure his editor to display a Python program in >> C-like syntax, and B configure their editor to use Python-like tabbed >> syntax? > > I don't recall anyone saying that *shouldn't* be done. Feel free to > make, and maintain and support and propagate and keep pace with changes > in everything Python interacts with, a full Python stack that supports > such flexibility. > >> A can write code in the preferred syntax, and B can view/modify >> exactly the same code in /their/ preferred syntax. What would be the >> problem? > > I can only invite you to embark on the project of a Python compiler > which accepts such a switchable syntax, maintain it consistently over > the lifetime of a project with significant numbers of people > collaborating using different switch settings for that syntax, and > working on the same code with different editor settings. > > Once you've done that, report back to us about the problems encountered. > >> (The actual stored representation of the program would be in one of >> those two styles, or something else entirely; Lisp-like syntax for >> example. It doesn't matter because no-one would care. > > No-one except the people who have to maintain and debug and continue > developing a Python that supports multiple radically-different syntaxes. > I suspect the efforts of those people is being discounted in your vision. I used actual languages Python and C in my example, I should have used A and B or something. If this was actually Python, then clearly source must be stored in Python syntax, to get around some of the objections that have been raised. Then all existing tools will work as before. But it means an editor would need to understand Python extremely well in order to do the 2-way transformation I was suggesting. And while that would need maintaining, I don't think it's impossible (don't smart editors already understand a lot of the syntax? And if I was doing this, I would use a conventional editor, and an separate translator). But it would all be optional; everything would then still work as before. However, I have played around with an actual project along these lines, but with some differences. Let's call actual Python source ".PY", and my preferred syntax ".JPY" (since those were the file extensions I used; "J" was the name I used to designate my syntax - syntax, not language, as the language must still be Python). Here, the intention was to store source code in .JPY files, with .PY used as an intermediate form when I need to use an existing Python tool. So the translation was one-way (which suited me because I tend to do my own thing). There are a few issues: I can still import .PY files created by others, but if it's one of mine created as .JPY, it just means it needs translating before running Python. Things such as eval() that have been mentioned, I haven't attempted. (Probably, it would be written as jeval() and would need to invoke the translator on the string, the results of which are passed to eval(). You can get around most such problems.) So I'm aware of some of the things that are involved. (BTW that project worked reasonably well, but I decided to go in a different direction: turning "J" from a mere syntax into an actual language of its own.) -- Bartc
[toc] | [prev] | [next] | [standalone]
| From | Ron Adam <ron3200@gmail.com> |
|---|---|
| Date | 2015-04-19 19:28 -0400 |
| Message-ID | <mailman.413.1429486094.12925.python-list@python.org> |
| In reply to | #89176 |
On 04/19/2015 05:42 PM, BartC wrote: > > So I'm aware of some of the things that are involved. > > (BTW that project worked reasonably well, but I decided to go in a > different direction: turning "J" from a mere syntax into an actual language > of its own.) Something you might try with your new language is to have an editor that can parse the source text to a tokenised "text" data file. It should be a fairly direct text to text translation, so putting it into the editor should be doable. Once you get that far, you can add pluggable token parsers to the editor that can unparse the token files to a specific user format for editing, and reparse it back to the standardised token file for storage. Now the users can choose a customised dialect of your language. And the compiler will work on a single token file type. This will also remove the need for pretty printers and formatters as they will be built into the editors pluggable token parser. Just have the editor tokenise and then immediately untokenise and you just checked for syntax errors and reformatted the program. The highlighter could also work with the token parser as well. The only catch is how to handle compile and run time errors. The editor will need to read an error file and translate it back to the source. I think it's doable but it will be tricky to get it to work well. The reason to make the split at tokens is, it's at a stage that most of what is needed is already in a text editor. The token file format becomes the bridge that spans the gap between the user/editor and the compiler/interpreter. Then your compiler/interpreter is all implementation details that work on a single standardised token file format rather than unformatted text files. Ron
[toc] | [prev] | [next] | [standalone]
| From | Ben Finney <ben+python@benfinney.id.au> |
|---|---|
| Date | 2015-04-20 09:59 +1000 |
| Message-ID | <mailman.0.1429487973.31470.python-list@python.org> |
| In reply to | #89176 |
BartC <bc@freeuk.com> writes: > I used actual languages Python and C in my example, I should have used > A and B or something. If you had, then the topic drifts so far from being relevant to a Python programming forum that I'd ask you to stop. Perhaps that should have happened much sooner. -- \ “If we have to give up either religion or education, we should | `\ give up education.” —William Jennings Bryan, 1923-01 | _o__) | Ben Finney
[toc] | [prev] | [next] | [standalone]
| From | BartC <bc@freeuk.com> |
|---|---|
| Date | 2015-04-20 01:30 +0100 |
| Message-ID | <VMXYw.239296$nQ7.235123@fx42.am4> |
| In reply to | #89179 |
On 20/04/2015 00:59, Ben Finney wrote: > BartC <bc@freeuk.com> writes: > >> I used actual languages Python and C in my example, I should have used >> A and B or something. > > If you had, then the topic drifts so far from being relevant to a Python > programming forum that I'd ask you to stop. > > Perhaps that should have happened much sooner. Maybe it should have. This sub-thread started by you replying to this parenthesised comment of mine: "(Actually *I* would quite like to know why languages don't have switchable syntax anyway to allow for people's personal preferences.)" I didn't mention any language by name at all! -- Bartc
[toc] | [prev] | [next] | [standalone]
| From | Dave Angel <davea@davea.name> |
|---|---|
| Date | 2015-04-19 09:18 -0400 |
| Message-ID | <mailman.403.1429449493.12925.python-list@python.org> |
| In reply to | #89145 |
On 04/19/2015 07:38 AM, BartC wrote: .... > Perhaps you don't understand what I'm getting at. > > Suppose there were just two syntaxes: C-like and Python-like (we'll put > aside for a minute the question of what format is used to store Python > source code). > > Why shouldn't A configure his editor to display a Python program in > C-like syntax, and B configure their editor to use Python-like tabbed > syntax? > > A can write code in the preferred syntax, and B can view/modify exactly > the same code in /their/ preferred syntax. What would be the problem? > (The actual stored representation of the program would be in one of > those two styles, or something else entirely; Lisp-like syntax for > example. It doesn't matter because no-one would care. > > (I think much of the problem that most languages are intimately > associated with their specific syntax, so that people can't see past it > to what the code is actually saying. a=b, a:=b, b=>a, (setf a b), > whatever the syntax is, who cares? We just want to do an assignment!) > If you make enough simplifying assumptions, of course it's easy and natural. Assume that a text editor is the only way you'll be viewing the source code. You and your coworkers are willing to each use a prescribed text editor, rather than your previous favorite one that doesn't happen to support the customization you're suggesting here. You're not going to use a version control system, nor diff programs. You're not going to post your code in messages on the internet. You're not going to display error messages showing source code, from a running system. You're not going to use the interactive debugger. You're not going to copy code from one place to another without copying sufficient context to be able to reconstruct the funny syntax. You're going to permit only one such variation, and it's just big enough that it's always obvious which version of the code is being examined (by programs or by humans) [1] You're not going to use eval() [good]. You're not going to examine source code that comes from 3rd party or the standard library. The changes you want are all completely reversible, regardless of interspersed comments, and when reversed, preserve spacing and characters completely in the way that each user expects to see the code. And they are reversible even if you only have a small fragment of the code. I implemented something analogous to such a system 40 years ago. But on that system, nearly all of the restrictions above applied. There was no clipboard, no version control, no internet. Programs had to fit in 64k. Each line stood completely on its own, so context was not a problem. i wrote the text editor, much of the interactive debugger, the listing utility, the pretty printer, the cross reference program, etc. So they were consistent. Further, we had a captive audience -- if they didn't like it, they could buy the competitor's product, which had similar constraints. Would I do things differently now? You bet I would. At least if I could upgrade the memory addressability to a few megs. For the purposes you've described so far, I'd suggest just writing two translators, one a mirror image of the other. Invoke them automatically on load and save in your personal editor And learn to live with both syntaxes, because it will leak. And if it's really not reversible, don't use them when you're editing somebody else's code. And even if it is reversible, don't use them when you edit code you plan to post on the internet. [1] So for example a=b can not mean assignment in one version, and a comparison in the other. Because then you'd need to either discover that it's a line by itself, or within an if expression, or ... But you could arrange two disjoint sets of symbols readily enough. In your version, require either := or ==, and make = just plain illegal. PS. I haven't examined the costs in tool development to support this. Just whether it's practical. You can easily discount any one of these constraints, but taken as a whole, they very much limit what you can do. -- DaveA
[toc] | [prev] | [next] | [standalone]
| From | Steven D'Aprano <steve+comp.lang.python@pearwood.info> |
|---|---|
| Date | 2015-04-19 23:22 +1000 |
| Message-ID | <5533ac30$0$13003$c3e8da3$5496439d@news.astraweb.com> |
| In reply to | #89145 |
On Sun, 19 Apr 2015 09:38 pm, BartC wrote:
> Suppose there were just two syntaxes: C-like and Python-like (we'll put
> aside for a minute the question of what format is used to store Python
> source code).
>
> Why shouldn't A configure his editor to display a Python program in
> C-like syntax, and B configure their editor to use Python-like tabbed
> syntax?
>
> A can write code in the preferred syntax, and B can view/modify exactly
> the same code in their preferred syntax. What would be the problem?
> (The actual stored representation of the program would be in one of
> those two styles, or something else entirely; Lisp-like syntax for
> example. It doesn't matter because no-one would care.
The only people who would not care are those alone in a bubble who never
share or discuss code with anyone else. Everyone else will care a great
deal.
How could A and B talk about the code to each other? A says "line 56 is
buggy, you need to replace foo{^bar} with foo@bar" and B replies "what are
you talking about? line 56 says foo.bar and foo@bar is a syntax error".
--
Steven
[toc] | [prev] | [next] | [standalone]
| From | Mark Lawrence <breamoreboy@yahoo.co.uk> |
|---|---|
| Date | 2015-04-19 14:30 +0100 |
| Message-ID | <mailman.404.1429450280.12925.python-list@python.org> |
| In reply to | #89145 |
On 19/04/2015 13:59, Ben Finney wrote: > BartC <bc@freeuk.com> writes: > >> Why shouldn't A configure his editor to display a Python program in >> C-like syntax, and B configure their editor to use Python-like tabbed >> syntax? > > I don't recall anyone saying that *shouldn't* be done. Feel free to > make, and maintain and support and propagate and keep pace with changes > in everything Python interacts with, a full Python stack that supports > such flexibility. > Presumably we just add BartCPython to the list containing those like Python 2.8 and RickedPython. -- 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 | Chris Angelico <rosuav@gmail.com> |
|---|---|
| Date | 2015-04-20 01:15 +1000 |
| Message-ID | <mailman.405.1429456511.12925.python-list@python.org> |
| In reply to | #89145 |
On Sun, Apr 19, 2015 at 9:38 PM, BartC <bc@freeuk.com> wrote: > Suppose there were just two syntaxes: C-like and Python-like (we'll put > aside for a minute the question of what format is used to store Python > source code). > > Why shouldn't A configure his editor to display a Python program in C-like > syntax, and B configure their editor to use Python-like tabbed syntax? You still haven't addressed the question of the extent of "C-like syntax" for Python. It's not simply a matter of block delimiters. With git (and I believe similarly with hg, but I'm not sure about smaller and/or proprietary source control systems), you can define a pair of filters which transform a file between the actual source control system and your checked-out version, so (for instance) you could have source control work with four-space indents where you work with tab indents. That one's dead easy. With a little more work, you could probably rig something up to use keywords or symbols to delimit blocks of code; braces would be harder, because Python uses them for dicts and sets, so you'd need some sort of context-aware parsing. But the biggest problem is that you wouldn't actually be changing anything else. You'd end up with a bizarre hybrid that uses a tiny bit of C-like syntax, but entirely Python-like syntax everywhere else. For example, Python doesn't allow this: if condition: for i in range(3): do_stuff() So you'd never truly be able to take advantage of the braces. In fact, all you'd _really_ have would be a way to key in some braces, commit to source control, check out again, and have your indentation auto-fixed for you... and if that's all you want, I think there are editors which make the reindenting of code a ton easier than that! As Dave suggests, make yourself a parser which turns *any* legal[1] Python code into your preferred "C-like" syntax, and another which performs a perfect reverse transformation. I suspect you'll find the task fundamentally hard. ChrisA [1] Coping with broken Python code is going to be important later on, but ignore it for now. It's a ton harder to ensure that you can do a reversible syntactic change on something with syntax errors!
[toc] | [prev] | [next] | [standalone]
Page 4 of 6 — ← Prev page 1 2 3 [4] 5 6 Next page →
Back to top | Article view | comp.lang.python
csiph-web