Warning: mysqli::__construct(): (HY000/1203): User howardkn already has more than 'max_user_connections' active connections in D:\Inetpub\vhosts\howardknight.net\al.howardknight.net\includes\artfuncs.php on line 21
Failed to connect to MySQL: (1203) User howardkn already has more than 'max_user_connections' active connections
Warning: mysqli::query(): Couldn't fetch mysqli in D:\Inetpub\vhosts\howardknight.net\al.howardknight.net\index.php on line 66
Article <va74vk$dfb0$1@dont-email.me>
Deutsch   English   Français   Italiano  
<va74vk$dfb0$1@dont-email.me>

View for Bookmarking (what is this?)
Look up another Usenet article

Path: ...!news.mixmin.net!eternal-september.org!feeder3.eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail
From: David Brown <david.brown@hesbynett.no>
Newsgroups: comp.unix.shell,comp.unix.programmer,comp.lang.misc
Subject: Re: Python (was Re: I did not inhale)
Date: Thu, 22 Aug 2024 12:47:16 +0200
Organization: A noiseless patient Spider
Lines: 43
Message-ID: <va74vk$dfb0$1@dont-email.me>
References: <uu54la$3su5b$6@dont-email.me> <uvbfii$3mom0$1@news.xmission.com>
 <20240412094809.811@kylheku.com> <87il0mm94y.fsf@tudado.org>
 <way-20240413091747@ram.dialup.fu-berlin.de> <87il0lldf8.fsf@tudado.org>
 <choices-20240413123957@ram.dialup.fu-berlin.de>
 <v9lm2k$12qhv$1@dont-email.me> <v9m4gd$14scu$1@dont-email.me>
 <20240815182717.189@kylheku.com> <v9npls$1fjus$1@dont-email.me>
 <v9t204$2dofg$1@dont-email.me> <va28pi$3dldm$1@dont-email.me>
 <va2ro9$3gd7v$1@dont-email.me> <va2vt0$3h3gj$1@dont-email.me>
 <va44rh$3p1l6$1@dont-email.me> <va45eq$3pkt9$1@dont-email.me>
 <va4aut$3q4g0$1@dont-email.me> <va4fbr$3qvij$1@dont-email.me>
 <va5108$3tmmd$1@dont-email.me> <va51ok$3tqr9$1@dont-email.me>
 <va5ec2$3vluh$1@dont-email.me> <va6q4g$c1a7$1@dont-email.me>
 <va6rpa$c6bg$1@dont-email.me> <va6uqg$clga$1@dont-email.me>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Injection-Date: Thu, 22 Aug 2024 12:47:16 +0200 (CEST)
Injection-Info: dont-email.me; posting-host="e19e10a6f493b0642935e2bdebcb364b";
	logging-data="441696"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX1+8dK8pgJ8SZQz+ITTJBZ2xpuOZQ7ST2+0="
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101
 Thunderbird/102.11.0
Cancel-Lock: sha1:560TjJDXlkCdG9ER/vMGLkoFi0M=
Content-Language: en-GB
In-Reply-To: <va6uqg$clga$1@dont-email.me>
Bytes: 3959

On 22/08/2024 11:02, Lawrence D'Oliveiro wrote:
> On Thu, 22 Aug 2024 10:10:18 +0200, David Brown wrote:
> 
>> I am a big fan of clear and consistent layout and indentation, which is
>> forced on you by Python (and Occam), but I too prefer explicit blocking.
>>    It's harder to get things wrong with explicit blocking, and you are
>> never faced with space vs. tab conflicts causing semantic changes to the
>> code.
> 
> Python prohibits those space/tab inconsistencies.
> 

No, it does not.  Python treats tabs (at the start of lines, which is 
the only relevant point here) as 8 spaces by default.  You can change 
that with command-line flags if you want.  But it is quite happy with 
mixtures of tabs and spaces as long as the result after tab-to-space 
conversion is consistent with Python syntax.

So if you have an editor set to 8-space tabs, you can mix spaces and 
tabs freely, and Python will treat your code exactly as it appears.  If, 
as many people do, you have an editor with 4-space tabs then mixing tabs 
and spaces will risk strange effects.  In some cases, Python can see it 
as inconsistent indentation.  In other cases, you might get indentation 
that is valid Python syntax but not what the programmer saw in the editor:

    if cond :
         doThis()	# 8 spaces
    doThat()		# One tab

An editor that sees the tab as 4 spaces will show a very different 
picture from Python that treats it as 8 spaces.

> Nevertheless, I don’t like the loss of redundancy in the way code
> structure is expressed, which is why I like to put in “#end” comments.

I would not recommend that.  But I think it makes sense to add a 
"return" at the end of functions if they otherwise end in indentations, 
to give a clear ending to the function definition.  That is vastly 
better than an "# end" comment because it is checked for Python syntax 
and correct (or at least plausible) indentation.  If you need an end 
marker for other blocks, "pass" is your friend - again it is better than 
a comment.