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

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

Language design

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

Contents

  Language design Steven D'Aprano <steve@pearwood.info> - 2013-09-10 06:09 +0000
    Re: Language design diverman <pavel@schon.cz> - 2013-09-09 23:59 -0700
    Re: Language design Ben Finney <ben+python@benfinney.id.au> - 2013-09-10 17:07 +1000
      Re: Language design Nobody <nobody@nowhere.com> - 2013-09-11 01:03 +0100
        Re: Language design Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2013-09-11 00:53 +0000
          Re: Language design Nobody <nobody@nowhere.com> - 2013-09-12 18:23 +0100
    Re: Language design Antoon Pardon <antoon.pardon@rece.vub.ac.be> - 2013-09-10 09:58 +0200
    Re: Language design Chris Angelico <rosuav@gmail.com> - 2013-09-10 20:20 +1000
    Re: Language design Chris Rebert <clp2@rebertia.com> - 2013-09-10 18:46 -0700
    Re: Language design Chris Angelico <rosuav@gmail.com> - 2013-09-11 14:21 +1000
    Re: Language design Burak Arslan <burak.arslan@arskom.com.tr> - 2013-09-11 13:38 +0300
      Re: Language design Neil Cerutti <neilc@norwich.edu> - 2013-09-11 14:32 +0000
        Re: Language design Chris Angelico <rosuav@gmail.com> - 2013-09-12 00:46 +1000
    Re: Language design Wayne Werner <wayne@waynewerner.com> - 2013-09-11 06:42 -0500
    Re: Language design Dave Angel <davea@davea.name> - 2013-09-11 12:05 +0000
    Re: Language design Ethan Furman <ethan@stoneleaf.us> - 2013-09-11 07:52 -0700
    Re: Language design Burak Arslan <burak.arslan@arskom.com.tr> - 2013-09-11 18:41 +0300
    Re: Language design Markus Rother <python@markusrother.de> - 2013-09-11 22:41 +0200
      Re: Language design Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2013-09-11 23:40 +0000
    Re: Language design Mark Janssen <dreamingforward@gmail.com> - 2013-09-11 14:22 -0700
    Re: Language design Mark Janssen <dreamingforward@gmail.com> - 2013-09-11 14:30 -0700
      Re: Language design Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2013-09-11 23:40 +0000
        Re: Language design Mark Janssen <dreamingforward@gmail.com> - 2013-09-11 17:49 -0700
          Re: Language design Steven D'Aprano <steve@pearwood.info> - 2013-09-12 05:33 +0000
            Re: Language design Mark Janssen <dreamingforward@gmail.com> - 2013-09-12 20:23 -0700
              Re: Language design Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2013-09-13 05:08 +0000
                Re: Language design Chris Angelico <rosuav@gmail.com> - 2013-09-13 17:39 +1000
                Re: Language design Mark Janssen <dreamingforward@gmail.com> - 2013-09-14 19:37 -0700
                Re: Language design Antoon Pardon <antoon.pardon@rece.vub.ac.be> - 2013-09-15 09:57 +0200
        Re: Language design Terry Reedy <tjreedy@udel.edu> - 2013-09-11 21:40 -0400
        Re: Language design Chris Angelico <rosuav@gmail.com> - 2013-09-12 11:41 +1000
    Re: Language design Ethan Furman <ethan@stoneleaf.us> - 2013-09-11 14:15 -0700
    RE: Language design "Prasad, Ramit" <ramit.prasad@jpmorgan.com.dmarc.invalid> - 2013-09-11 21:56 +0000
    Re: Language design Ben Finney <ben+python@benfinney.id.au> - 2013-09-12 09:16 +1000
    Please omit false legalese footers (was: Language design) Ben Finney <ben+python@benfinney.id.au> - 2013-09-12 09:22 +1000
      Re: Please omit false legalese footers (was: Language design) Grant Edwards <invalid@invalid.invalid> - 2013-09-12 20:12 +0000
    Re: Language design Chris Angelico <rosuav@gmail.com> - 2013-09-12 09:27 +1000
    Re: Language design Ben Finney <ben+python@benfinney.id.au> - 2013-09-12 09:19 +1000
    Re: Language design Terry Reedy <tjreedy@udel.edu> - 2013-09-11 19:51 -0400
    Re: Language design Mark Janssen <dreamingforward@gmail.com> - 2013-09-11 17:25 -0700
    Re: Language design Chris Angelico <rosuav@gmail.com> - 2013-09-12 10:31 +1000
      Re: Language design Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2013-09-12 02:33 +0000
        Re: Language design Roy Smith <roy@panix.com> - 2013-09-11 22:43 -0400
          Re: Language design Chris Angelico <rosuav@gmail.com> - 2013-09-12 12:58 +1000
          Re: Language design Steven D'Aprano <steve@pearwood.info> - 2013-09-12 05:08 +0000
    Re: Language design Mark Janssen <dreamingforward@gmail.com> - 2013-09-11 17:34 -0700
    Re: Language design Mark Janssen <dreamingforward@gmail.com> - 2013-09-11 17:37 -0700
    Re: Language design Chris Angelico <rosuav@gmail.com> - 2013-09-12 10:40 +1000
    Re: Language design Benjamin Kaplan <benjamin.kaplan@case.edu> - 2013-09-11 17:54 -0700
    Re: Language design Ben Finney <ben+python@benfinney.id.au> - 2013-09-12 10:57 +1000
    Re: Language design Joshua Landau <joshua@landau.ws> - 2013-09-12 05:17 +0100
    Re: Please omit false legalese footers (was: Language design) Skip Montanaro <skip@pobox.com> - 2013-09-12 04:27 -0500
    Re: Please omit false legalese footers (was: Language design) Oscar Benjamin <oscar.j.benjamin@gmail.com> - 2013-09-12 10:44 +0100
    Re: Language design Markus Rother <python@markusrother.de> - 2013-09-12 19:51 +0200
      Re: Language design Neil Cerutti <neilc@norwich.edu> - 2013-09-12 18:06 +0000
    Re: Language design Markus Rother <python@markusrother.de> - 2013-09-12 20:13 +0200
    Re: Language design Markus Rother <python@markusrother.de> - 2013-09-12 20:24 +0200
      Re: Language design Neil Cerutti <neilc@norwich.edu> - 2013-09-12 19:18 +0000
    Re: Language design Ethan Furman <ethan@stoneleaf.us> - 2013-09-12 11:05 -0700
    Re: Language design Ned Batchelder <ned@nedbatchelder.com> - 2013-09-12 14:37 -0400
    Re: Language design Terry Reedy <tjreedy@udel.edu> - 2013-09-12 14:46 -0400
    Re: Language design Chris Angelico <rosuav@gmail.com> - 2013-09-13 07:53 +1000
    Re: Language design Antoon Pardon <antoon.pardon@rece.vub.ac.be> - 2013-09-13 09:04 +0200
      Re: Language design Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2013-09-13 10:13 +0000
        Re: Language design Chris Angelico <rosuav@gmail.com> - 2013-09-13 21:16 +1000
        Re: Language design Antoon Pardon <antoon.pardon@rece.vub.ac.be> - 2013-09-13 13:28 +0200
        Re: Language design Terry Reedy <tjreedy@udel.edu> - 2013-09-13 15:32 -0400
        Re: Language design Chris Angelico <rosuav@gmail.com> - 2013-09-14 09:57 +1000
          Re: Language design Neil Cerutti <neilc@norwich.edu> - 2013-09-18 14:57 +0000
            Re: Language design Chris Angelico <rosuav@gmail.com> - 2013-09-19 01:02 +1000
              Re: Language design Neil Cerutti <neilc@norwich.edu> - 2013-09-18 15:08 +0000
                Re: Language design Chris Angelico <rosuav@gmail.com> - 2013-09-19 01:12 +1000
                Re: Language design William Ray Wing <wrw@mac.com> - 2013-09-18 12:58 -0400
                  Re: Language design wxjmfauth@gmail.com - 2013-09-18 10:45 -0700
                    Re: Language design Neil Cerutti <neilc@norwich.edu> - 2013-09-18 17:55 +0000
        Re: Language design Mark Janssen <dreamingforward@gmail.com> - 2013-09-13 17:28 -0700
        Re: Language design Vito De Tullio <vito.detullio@gmail.com> - 2013-09-14 07:25 +0200

Page 4 of 4 — ← Prev page 1 2 3 [4]

#54078

On 9/12/2013 2:24 PM, Markus Rother wrote:

> Dictionaries should iterate over their items instead of their keys.

Dictionaries *can* iterate by keys, values, or items. You would prefer 
that the default iteration be by items rather than keys.

> Looking forward to contrary opinions.

When the issue was discussed and decided, a majority of developers 
preferred keys. A large factor was experience and expectation that 
iterating by keys is more common than than iterating by items, coupled 
with the idea that the most common usage should be the default.

-- 
Terry Jan Reedy

[toc] | [prev] | [next] | [standalone]

#54086

On Fri, Sep 13, 2013 at 4:13 AM, Markus Rother <python@markusrother.de> wrote:
> On 12.09.2013 01:27, Chris Angelico wrote:
>> On Thu, Sep 12, 2013 at 6:41 AM, Markus Rother <python@markusrother.de> wrote:
>>>     3. The default return value of methods is None instead of self.
>>>     If it was self, it would be possible to chain method calls (which
>>>     is called a cascade in smalltalk).
>>
>> That's a policy decision: a method (or function) will *EITHER* return
>> a value, *OR* mutate its primary argument (in the case of a method,
>> that's self).
>
> You are stating: "All getters must be free of side effects".
> That is not the case.  Furthermore, the demand for getters with hidden
> side effects is the reasoning behind properties.

This isn't a language feature here, just a stdlib policy. It's more
akin to Ruby's habit of adorning the mutating methods with an
exclamation mark - it's a way of stopping you from accidentally doing
what you didn't mean to do. There's a sharp distinction between
list.sort(), which mutates in place and returns None, and sorted(),
which doesn't touch its argument and returns a new list.

ChrisA

[toc] | [prev] | [next] | [standalone]

#54105

Op 10-09-13 12:20, Chris Angelico schreef:
> On Tue, Sep 10, 2013 at 4:09 PM, Steven D'Aprano <steve@pearwood.info> wrote:
>> What design mistakes, traps or gotchas do you think Python has? Gotchas
>> are not necessarily a bad thing, there may be good reasons for it, but
>> they're surprising.
> 
> Significant indentation. It gets someone every day, it seems.
> 

Not only that. There are a lot of python code snippets on the net
that for whatever reason lost their indentation. There is no
algorithm that can restore the lost structure.

-- 
Antoon Pardon

[toc] | [prev] | [next] | [standalone]

#54107

On Fri, 13 Sep 2013 09:04:06 +0200, Antoon Pardon wrote:

> Op 10-09-13 12:20, Chris Angelico schreef:
>> On Tue, Sep 10, 2013 at 4:09 PM, Steven D'Aprano <steve@pearwood.info>
>> wrote:
>>> What design mistakes, traps or gotchas do you think Python has?
>>> Gotchas are not necessarily a bad thing, there may be good reasons for
>>> it, but they're surprising.
>> 
>> Significant indentation. It gets someone every day, it seems.
>> 
>> 
> Not only that. There are a lot of python code snippets on the net that
> for whatever reason lost their indentation. There is no algorithm that
> can restore the lost structure.

Is there an algorithm that will restore the lost structure if you delete 
all the braces from C source code?

Perhaps if web sites and mail clients routinely deleted braces, we'd see 
the broken-by-design software being fixed instead of blaming the language.



-- 
Steven

[toc] | [prev] | [next] | [standalone]

#54110

On Fri, Sep 13, 2013 at 8:13 PM, Steven D'Aprano
<steve+comp.lang.python@pearwood.info> wrote:
> On Fri, 13 Sep 2013 09:04:06 +0200, Antoon Pardon wrote:
>
>> Op 10-09-13 12:20, Chris Angelico schreef:
>>> On Tue, Sep 10, 2013 at 4:09 PM, Steven D'Aprano <steve@pearwood.info>
>>> wrote:
>>>> What design mistakes, traps or gotchas do you think Python has?
>>>> Gotchas are not necessarily a bad thing, there may be good reasons for
>>>> it, but they're surprising.
>>>
>>> Significant indentation. It gets someone every day, it seems.
>>>
>>>
>> Not only that. There are a lot of python code snippets on the net that
>> for whatever reason lost their indentation. There is no algorithm that
>> can restore the lost structure.
>
> Is there an algorithm that will restore the lost structure if you delete
> all the braces from C source code?
>
> Perhaps if web sites and mail clients routinely deleted braces, we'd see
> the broken-by-design software being fixed instead of blaming the language.

While I don't deny your statement, I'd like to point out that English
usually isn't overly concerned with formatting. You can take this
paragraph of text, unwrap it, and then reflow it to any width you
like, without materially changing my points. C follows a rule of
English which Python breaks, ergo software designed to cope only with
English can better cope with C code than with Python code. Removing
all braces would be like removing all punctuation - very like, in fact
- a very real change to the content, and destruction of important
information. Python is extremely unusual in making indentation
important information, thus running afoul of systems that aren't meant
for any code.

But if you look at the quoted text above, I specifically retained your
declaration that "Gotchas are not necessarily a bad thing" when citing
significant indentation. I'm not here to argue that Python made the
wrong choice; I'm only arguing that it frequently confuses people.

ChrisA

[toc] | [prev] | [next] | [standalone]

#54111

Op 13-09-13 12:13, Steven D'Aprano schreef:
> On Fri, 13 Sep 2013 09:04:06 +0200, Antoon Pardon wrote:
> 
>> Op 10-09-13 12:20, Chris Angelico schreef:
>>> On Tue, Sep 10, 2013 at 4:09 PM, Steven D'Aprano <steve@pearwood.info>
>>> wrote:
>>>> What design mistakes, traps or gotchas do you think Python has?
>>>> Gotchas are not necessarily a bad thing, there may be good reasons for
>>>> it, but they're surprising.
>>>
>>> Significant indentation. It gets someone every day, it seems.
>>>
>>>
>> Not only that. There are a lot of python code snippets on the net that
>> for whatever reason lost their indentation. There is no algorithm that
>> can restore the lost structure.
> 
> Is there an algorithm that will restore the lost structure if you delete 
> all the braces from C source code?

Yes, almost. Just look at the indentation of the program and you will
probably be able to restore the braces in 99% of the programs.

> Perhaps if web sites and mail clients routinely deleted braces, we'd see 
> the broken-by-design software being fixed instead of blaming the language.

The world is not perfect. If products in your design are hard to repair
after some kind of hiccup, then I think the design can be blamed for
that. Good design is more than being ok when nothing goes wrong. Good
design is also about being recoverable when things do go wrong.

-- 
Antoon Pardon

[toc] | [prev] | [next] | [standalone]

#54132

On 9/13/2013 7:16 AM, Chris Angelico wrote:
> On Fri, Sep 13, 2013 at 8:13 PM, Steven D'Aprano
> <steve+comp.lang.python@pearwood.info> wrote:
>> On Fri, 13 Sep 2013 09:04:06 +0200, Antoon Pardon wrote:
>>> Not only that. There are a lot of python code snippets on the net that
>>> for whatever reason lost their indentation. There is no algorithm that
>>> can restore the lost structure.

I believe tabs are worse than spaces with respect to getting lost.

>> Is there an algorithm that will restore the lost structure if you delete
>> all the braces from C source code?
>>
>> Perhaps if web sites and mail clients routinely deleted braces, we'd see
>> the broken-by-design software being fixed instead of blaming the language.
>
> While I don't deny your statement, I'd like to point out that English
> usually isn't overly concerned with formatting.

Poetry, including that in English, often *is* concerned with formatting. 
Code is more like poetry than prose.

> You can take this
> paragraph of text, unwrap it, and then reflow it to any width you
> like, without materially changing my points.

But you cannot do that with poetry! Or mathematical formulas. Or tables. 
Or text with headers and paragraphs and indented quotations. Etc. What 
percentage of published books on your bookshelf have NO significant 
indentation? As far as I know for mine, it is 0.

> C follows a rule of English

which you just made up, and which is drastically wrong,

> which Python breaks,
> ergo software designed to cope only with English

impoverished plain unformatted prose

> can better cope with C code than with Python code.

Software that removes formatting info is broken for English as well as 
Python.

> Python is extremely unusual in making indentation
> important information

You have it backwards. Significant indentation is *normal* in English. C 
in unusual is being able to write a whole text on a single line.

When I was a child, paragraphs were marked by tab indents. The change to 
new-fangled double spacing with no indent seems to have come along with 
computer text processing. Perhaps this is because software is more prone 
to dropping tabs that return characters.

-- 
Terry Jan Reedy

[toc] | [prev] | [next] | [standalone]

#54145

On Sat, Sep 14, 2013 at 5:32 AM, Terry Reedy <tjreedy@udel.edu> wrote:
> Poetry, including that in English, often *is* concerned with formatting.
> Code is more like poetry than prose.
>
>
>> You can take this
>> paragraph of text, unwrap it, and then reflow it to any width you
>> like, without materially changing my points.
>
>
> But you cannot do that with poetry!

Evangelical vicar in want of a portable second-hand font. Would
dispose, for the same, of a portrait, in frame, of the Bishop-elect of
Vermont.

I think you could quite easily reconstruct the formatting of that,
based on its internal structure. Even in poetry, English doesn't
depend on its formatting nearly as much as Python does; and even
there, it's line breaks, not indentation - so we're talking more like
REXX than Python. In fact, it's not uncommon for poetry to be laid out
on a single line with slashes to divide lines:

A boat beneath a sunny sky / Lingering onward dreamily / In an evening
of July / Children three that nestle near, / Eager eye and willing ear
/ Pleased a simple tale to hear...

in the same way that I might write:

call sqlexec "connect to words"; call sqlexec "create table dict (word
varchar(20) not null)"; call sqlexec "insert into dict values
('spam')"; call sqlexec "insert into dict values ('ham')"

To be sure, it looks nicer laid out with line breaks; but it's
possible to replace them with other markers. And indentation still is
completely insignificant. The only case I can think of in English of
indentation mattering is the one you mentioned of first line of
subsequent paragraphs, not by any means a universal convention and
definitely not the primary structure of the entire document.

Making line breaks significant usually throws people. It took my
players a lot of time and hints to figure this out:
http://rosuav.com/1/?id=969

ChrisA

[toc] | [prev] | [next] | [standalone]

#54384

On 2013-09-13, Chris Angelico <rosuav@gmail.com> wrote:
> On Sat, Sep 14, 2013 at 5:32 AM, Terry Reedy <tjreedy@udel.edu> wrote:
>> Poetry, including that in English, often *is* concerned with formatting.
>> Code is more like poetry than prose.
>>
>>
>>> You can take this
>>> paragraph of text, unwrap it, and then reflow it to any width you
>>> like, without materially changing my points.
>>
>>
>> But you cannot do that with poetry!
>
> Evangelical vicar in want of a portable second-hand font. Would
> dispose, for the same, of a portrait, in frame, of the Bishop-elect of
> Vermont.
>
> I think you could quite easily reconstruct the formatting of
> that, based on its internal structure. Even in poetry, English
> doesn't depend on its formatting nearly as much as Python does;
> and even there, it's line breaks, not indentation - so we're
> talking more like REXX than Python. In fact, it's not uncommon
> for poetry to be laid out on a single line with slashes to
> divide lines:

There's lots of poetry with significant indentation, though.
Imbuing the shape of the text on the page with significance is a
thing.

-- 
Neil Cerutti

[toc] | [prev] | [next] | [standalone]

#54385

On Thu, Sep 19, 2013 at 12:57 AM, Neil Cerutti <neilc@norwich.edu> wrote:
> There's lots of poetry with significant indentation, though.
> Imbuing the shape of the text on the page with significance is a
> thing.

And you can do that with C code, too. Doesn't mean that indentation is
important to C; it means that you're layering different types of
information into a single piece of work. It's like Perl code drawn in
the shape of a camel - a beautiful hack.

ChrisA

[toc] | [prev] | [next] | [standalone]

#54386

On 2013-09-18, Chris Angelico <rosuav@gmail.com> wrote:
> On Thu, Sep 19, 2013 at 12:57 AM, Neil Cerutti <neilc@norwich.edu> wrote:
>> There's lots of poetry with significant indentation, though.
>> Imbuing the shape of the text on the page with significance is a
>> thing.
>
> And you can do that with C code, too. Doesn't mean that
> indentation is important to C; it means that you're layering
> different types of information into a single piece of work.
> It's like Perl code drawn in the shape of a camel - a beautiful
> hack.

I just meant you can't condense whitespace in a poem and retain
all its meaning. It will break certain kinds of quotation styles
in publications, as well.

-- 
Neil Cerutti

[toc] | [prev] | [next] | [standalone]

#54387

On Thu, Sep 19, 2013 at 1:08 AM, Neil Cerutti <neilc@norwich.edu> wrote:
> On 2013-09-18, Chris Angelico <rosuav@gmail.com> wrote:
>> On Thu, Sep 19, 2013 at 12:57 AM, Neil Cerutti <neilc@norwich.edu> wrote:
>>> There's lots of poetry with significant indentation, though.
>>> Imbuing the shape of the text on the page with significance is a
>>> thing.
>>
>> And you can do that with C code, too. Doesn't mean that
>> indentation is important to C; it means that you're layering
>> different types of information into a single piece of work.
>> It's like Perl code drawn in the shape of a camel - a beautiful
>> hack.
>
> I just meant you can't condense whitespace in a poem and retain
> all its meaning. It will break certain kinds of quotation styles
> in publications, as well.

Sure. I'm still trying to work out if it's possible to deliver a
verbal speech with fancy information in its written version... English
is a fun language to tinker with!

ChrisA

[toc] | [prev] | [next] | [standalone]

#54389

On Sep 18, 2013, at 11:12 AM, Chris Angelico <rosuav@gmail.com> wrote:

> On Thu, Sep 19, 2013 at 1:08 AM, Neil Cerutti <neilc@norwich.edu> wrote:
>> On 2013-09-18, Chris Angelico <rosuav@gmail.com> wrote:
>>> On Thu, Sep 19, 2013 at 12:57 AM, Neil Cerutti <neilc@norwich.edu> wrote:
>>>> There's lots of poetry with significant indentation, though.
>>>> Imbuing the shape of the text on the page with significance is a
>>>> thing.
>>> 
>>> And you can do that with C code, too. Doesn't mean that
>>> indentation is important to C; it means that you're layering
>>> different types of information into a single piece of work.
>>> It's like Perl code drawn in the shape of a camel - a beautiful
>>> hack.
>> 
>> I just meant you can't condense whitespace in a poem and retain
>> all its meaning. It will break certain kinds of quotation styles
>> in publications, as well.
> 
> Sure. I'm still trying to work out if it's possible to deliver a
> verbal speech with fancy information in its written version... English
> is a fun language to tinker with!
> 
> ChrisA
> -- 
> 

Just to add a data point on the importance of formatting in language.  New Testament Greek is/was written with no punctuation, no spaces between words, and no distinction between upper and lower case.  This frequently results in the Greek equivalent of the follow English:  "iamnowhereiameverywhere"  which can be "translated" as either "I am now here, I am everywhere."  _or_ "I am nowhere, I am everywhere."  In other words, two very different meanings.  So, without context or further information, the intent of the original writer can't be inferred.

-Bill

[toc] | [prev] | [next] | [standalone]

#54390

>>> 1and 0
0
>>> 'a'or 1
'a'
>>> 5if True else 999
5


jmf

[toc] | [prev] | [next] | [standalone]

#54391

On 2013-09-18, wxjmfauth@gmail.com <wxjmfauth@gmail.com> wrote:
>>>> 1and 0
> 0
>>>> 'a'or 1
> 'a'
>>>> 5if True else 999
> 5

Curse you, FSR!

Oh, wait...

-- 
Neil Cerutti

[toc] | [prev] | [next] | [standalone]

#54147

On Fri, Sep 13, 2013 at 4:57 PM, Chris Angelico <rosuav@gmail.com> wrote:
> Evangelical vicar in want of a portable second-hand font. Would
> dispose, for the same, of a portrait, in frame, of the Bishop-elect of
> Vermont.
>
> I think you could quite easily reconstruct the formatting of that,
> based on its internal structure. Even in poetry, English doesn't
> depend on its formatting nearly as much as Python does;

(Just to dispose of this old argument:)  Both Python and English
depend on both syntactical, material delimiters and whitespace.  While
it may seem that Python depends more on whitespace than English, that
is highly contentious, poetry or not.  Take some literature, remove
all the tabs at paragraph start and CRs at paragraph-end so that it
all runs together and you'll find that it impossible to read -- you
just won't be able to enter into the universe that the author is
attempting to build.

-- 
MarkJ
Tacoma, Washington

[toc] | [prev] | [next] | [standalone]

#54153

Chris Angelico wrote:

> Making line breaks significant usually throws people. It took my
> players a lot of time and hints to figure this out:
> http://rosuav.com/1/?id=969

fukin' Gaston!

-- 
By ZeD

[toc] | [prev] | [standalone]

Page 4 of 4 — ← Prev page 1 2 3 [4]

Back to top | Article view | comp.lang.python

csiph-web