On Tue, 24 Dec 2019 at 19:05, Avi Gross via Python-list
wrote:
> There are some lint programs that check your code and supply warnings and I
> see some languages have the option to generate warnings when the two strings
> are on the same line. I wonder if a Python lint does that. It may at least
>
On 12/24/2019 10:02 AM, Avi Gross via Python-list wrote:
This being Python (which lies about how there should be one unique way to
logically do something)
The koan is:
There should be one-- and preferably only one --obvious way to do it.
It is not:
- only one way
- one unique way
- the on
-Original Message-
From: Python-list On
Behalf Of Tim Daneliuk
Sent: Monday, December 23, 2019 11:22 PM
To: python-list@python.org
Subject: Re: Lists And Missing Commas
On 12/23/19 8:35 PM, Chris Angelico wrote:
> On Tue, Dec 24, 2019 at 12:56 PM DL Neil via Python-list
> wrote:
>>
On 12/24/19 10:45 AM, Tim Daneliuk wrote:
On 12/24/19 6:37 AM, Stefan Ram wrote:
And you all are aware that this kind of string concatenation
happens in C and C++, too, aren't you?
main.c
#include
int main( void ){ puts( "a" "b" ); }
transcript
ab
Noting that it has been a long
On 12/24/19 6:37 AM, Stefan Ram wrote:
> And you all are aware that this kind of string concatenation
> happens in C and C++, too, aren't you?
>
> main.c
>
> #include
> int main( void ){ puts( "a" "b" ); }
>
> transcript
>
> ab
Noting that it has been a long time since I looked at the
On 24/12/19 5:20 PM, Tim Daneliuk wrote:
On 12/23/19 7:52 PM, DL Neil wrote:
WebRef: https://docs.python.org/3/reference/lexical_analysis.html
Yep, that explains it, but it still feels non-regular to me. From a pointy
headed academic
POV, I'd like to see behavior consistent across types. A
On 2019-12-24 6:20 AM, Tim Daneliuk wrote:
On 12/23/19 7:52 PM, DL Neil wrote:
WebRef: https://docs.python.org/3/reference/lexical_analysis.html
Yep, that explains it, but it still feels non-regular to me. From a pointy
headed academic
POV, I'd like to see behavior consistent across types.
On 12/23/19 8:35 PM, Chris Angelico wrote:
> On Tue, Dec 24, 2019 at 12:56 PM DL Neil via Python-list
> wrote:
>> However, your point involves the fact that whereas:
>>
>> 1 + 2 # 3 is *clearly* addition, and
>> "a" + "b" # "ab" is *clearly* concatenation
>>
>> "a" "b" # al
On 12/23/19 7:52 PM, DL Neil wrote:
>
> WebRef: https://docs.python.org/3/reference/lexical_analysis.html
Yep, that explains it, but it still feels non-regular to me. From a pointy
headed academic
POV, I'd like to see behavior consistent across types. Again ... what do I know?
--
https://mai
On 24/12/19 3:35 PM, Chris Angelico wrote:
On Tue, Dec 24, 2019 at 12:56 PM DL Neil via Python-list
wrote:
However, your point involves the fact that whereas:
1 + 2 # 3 is *clearly* addition, and
"a" + "b" # "ab" is *clearly* concatenation
"a" "b" # also evaluates to "
On Tue, Dec 24, 2019 at 12:56 PM DL Neil via Python-list
wrote:
> However, your point involves the fact that whereas:
>
> 1 + 2 # 3 is *clearly* addition, and
> "a" + "b" # "ab" is *clearly* concatenation
>
> "a" "b" # also evaluates to "ab"
>
> and is thus, concatenation w
On 24/12/19 1:48 PM, Tim Daneliuk wrote:
If I do this:
foo = [ "bar", "baz" "slop", "crud" ]
Python silently accepts that and makes the middle term "bazslop".
BUT, if I do this:
foo = [ "bar", "baz" 1, "crud" ]
or this:
foo = [ "bar", 2 1, "crud" ]
The interpreter throws a s
On Tuesday, 24 December 2019, Tim Daneliuk wrote:
> If I do this:
>
> foo = [ "bar", "baz" "slop", "crud" ]
>
> Python silently accepts that and makes the middle term "bazslop".
Strings concatinate over line endings so this case is only sensible really.
>
> BUT, if I do this:
>
> foo
If I do this:
foo = [ "bar", "baz" "slop", "crud" ]
Python silently accepts that and makes the middle term "bazslop".
BUT, if I do this:
foo = [ "bar", "baz" 1, "crud" ]
or this:
foo = [ "bar", 2 1, "crud" ]
The interpreter throws a syntax error.
This is more of an intellectual
14 matches
Mail list logo
