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

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

Re: n00b question on spacing

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

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  Re: n00b question on spacing Mark Janssen <dreamingforward@gmail.com> - 2013-06-22 10:43 -0700
    Re: n00b question on spacing alex23 <wuwei23@gmail.com> - 2013-06-25 09:48 +1000
      Re: n00b question on spacing Mark Janssen <dreamingforward@gmail.com> - 2013-06-24 17:22 -0700
      Re: n00b question on spacing Robert Kern <robert.kern@gmail.com> - 2013-06-25 12:19 +0100
      Re: n00b question on spacing Chris Angelico <rosuav@gmail.com> - 2013-06-25 21:48 +1000
      Re: n00b question on spacing Robert Kern <robert.kern@gmail.com> - 2013-06-25 12:59 +0100
      Re: n00b question on spacing Chris Angelico <rosuav@gmail.com> - 2013-06-25 22:07 +1000

#48938 — Re: n00b question on spacing

> Also remember when entering long lines of text that strings concatenate
> within parenthesis.
> So,
> ("a, b, c"
> "d, e, f"
> "g, h, i")
>
> Is the same as ("a, b, cd, e, fg, h, i")

There was a recent discussion about this (under "implicit string
concatenation").  It seems this is a part of the python language
specification that was simply undefined.   (A rule probably should be
added to the lexer to make this explicit.)

-- 
MarkJ
Tacoma, Washington

[toc] | [next] | [standalone]

#49110

On 23/06/2013 3:43 AM, Mark Janssen wrote:
> There was a recent discussion about this (under "implicit string
> concatenation").  It seems this is a part of the python language
> specification that was simply undefined.

It's part of the language reference, not an accidental artifact:
http://docs.python.org/2/reference/lexical_analysis.html#string-literal-concatenation

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

#49113

On Mon, Jun 24, 2013 at 4:48 PM, alex23 <wuwei23@gmail.com> wrote:
> On 23/06/2013 3:43 AM, Mark Janssen wrote:
>>
>> There was a recent discussion about this (under "implicit string
>> concatenation").  It seems this is a part of the python language
>> specification that was simply undefined.
>
>
> It's part of the language reference, not an accidental artifact:
> http://docs.python.org/2/reference/lexical_analysis.html#string-literal-concatenation

When I say "specification", I mean "specified in the formal notation"
(BNF, etc).  "whitespace" is not defined (otherwise there would be a
line in the token list for "linefeed" and "carriagereturn".

-- 
MarkJ
Tacoma, Washington

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

#49145

On 2013-06-25 01:22, Mark Janssen wrote:
> On Mon, Jun 24, 2013 at 4:48 PM, alex23 <wuwei23@gmail.com> wrote:
>> On 23/06/2013 3:43 AM, Mark Janssen wrote:
>>>
>>> There was a recent discussion about this (under "implicit string
>>> concatenation").  It seems this is a part of the python language
>>> specification that was simply undefined.
>>
>>
>> It's part of the language reference, not an accidental artifact:
>> http://docs.python.org/2/reference/lexical_analysis.html#string-literal-concatenation
>
> When I say "specification", I mean "specified in the formal notation"
> (BNF, etc).

There is quite a bit of Python's lexical analysis that is specified in places 
other than the formal notation. That does not mean it is undefined. It is well 
defined in the lexer code and the documentation. You suggest that a "rule 
probably should be added to the lexer to make this explicit." That is not 
necessary. The rule is already there.

-- 
Robert Kern

"I have come to believe that the whole world is an enigma, a harmless enigma
  that is made terrible by our own mad attempt to interpret it as though it had
  an underlying truth."
   -- Umberto Eco

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

#49147

On Tue, Jun 25, 2013 at 9:19 PM, Robert Kern <robert.kern@gmail.com> wrote:
> There is quite a bit of Python's lexical analysis that is specified in
> places other than the formal notation. That does not mean it is undefined.
> It is well defined in the lexer code and the documentation. You suggest that
> a "rule probably should be added to the lexer to make this explicit." That
> is not necessary. The rule is already there.

Be careful; Python is not an implementation-defined language. Python
has no "lexer code" - CPython does, and is probably what you're
thinking of. (There are other languages that *are*
implementation-defined, meaning that it *is* correct to talk about
features in that way. Python just isn't one of them.) Sometimes a rule
needs to be clarified to mandate something that was previously left up
to the implementation; however, if that's the case, the rule would not
be added to the lexer, but to the documentation.

ChrisA

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

#49149

On 2013-06-25 12:48, Chris Angelico wrote:
> On Tue, Jun 25, 2013 at 9:19 PM, Robert Kern <robert.kern@gmail.com> wrote:
>> There is quite a bit of Python's lexical analysis that is specified in
>> places other than the formal notation. That does not mean it is undefined.
>> It is well defined in the lexer code and the documentation. You suggest that
>> a "rule probably should be added to the lexer to make this explicit." That
>> is not necessary. The rule is already there.
>
> Be careful; Python is not an implementation-defined language. Python
> has no "lexer code" - CPython does, and is probably what you're
> thinking of.

No, that's not what I am thinking of. I said that the rule is defined in both 
code and the documentation. Mark did suggest adding the rule to the lexer (for 
which he may have been thinking of just CPython, but you can take that up with 
him), but of course it is already there. I did not suggest that its presence in 
the lexer code (of any or all implementations) is sufficient, but the point is 
moot because it is already both explicitly implemented (several times) and 
clearly documented in the Python language reference.

-- 
Robert Kern

"I have come to believe that the whole world is an enigma, a harmless enigma
  that is made terrible by our own mad attempt to interpret it as though it had
  an underlying truth."
   -- Umberto Eco

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

#49150

On Tue, Jun 25, 2013 at 9:59 PM, Robert Kern <robert.kern@gmail.com> wrote:
> On 2013-06-25 12:48, Chris Angelico wrote:
>>
>> On Tue, Jun 25, 2013 at 9:19 PM, Robert Kern <robert.kern@gmail.com>
>> wrote:
>>>
>>> There is quite a bit of Python's lexical analysis that is specified in
>>> places other than the formal notation. That does not mean it is
>>> undefined.
>>> It is well defined in the lexer code and the documentation. You suggest
>>> that
>>> a "rule probably should be added to the lexer to make this explicit."
>>> That
>>> is not necessary. The rule is already there.
>>
>>
>> Be careful; Python is not an implementation-defined language. Python
>> has no "lexer code" - CPython does, and is probably what you're
>> thinking of.
>
>
> No, that's not what I am thinking of. I said that the rule is defined in
> both code and the documentation. Mark did suggest adding the rule to the
> lexer (for which he may have been thinking of just CPython, but you can take
> that up with him), but of course it is already there. I did not suggest that
> its presence in the lexer code (of any or all implementations) is
> sufficient, but the point is moot because it is already both explicitly
> implemented (several times) and clearly documented in the Python language
> reference.

Sure, fair enough. I've just been skimming this thread, lately, so
please don't take my post as implying that you're wrong-wrong-wrong...
it's just something that seemed to want clarifying :)

ChrisA

[toc] | [prev] | [standalone]

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

csiph-web