Path: csiph.com!news.nrbbs.org!border-3.nntp.ord.giganews.com!nntp.giganews.com!Xl.tags.giganews.com!local-4.nntp.ord.giganews.com!news.giganews.com.POSTED!not-for-mail NNTP-Posting-Date: Wed, 05 Aug 2026 03:05:53 +0000 From: steve g Newsgroups: comp.lang.lisp Subject: Re: Python blanks References: <111sa8t$3ua8h$3@dont-email.me> <1124bls$2879p$3@dont-email.me> <11254iv$2e16l$1@dont-email.me> <1126k40$2ucc5$3@dont-email.me> <1126sie$30tde$1@dont-email.me> <87v7awl1fb.fsf@dear-messner.dont-email.me> <87a4s7ylb5.fsf@nightsong.com> <112o0vr$bouu$1@dont-email.me> <112o9kb$3cs6m$1@paganini.bofh.team> <112obr1$f7en$1@dont-email.me> <112p2a4$3eqo2$1@paganini.bofh.team> Date: Tue, 04 Aug 2026 23:05:53 -0400 Message-ID: <87ldaltgfi.fsf@gmail.com> User-Agent: Gnus/5.13 (Gnus v5.13) Cancel-Lock: sha1:M+0qEdR7xlB/i2GZd/zOYLiGsWY= MIME-Version: 1.0 Content-Type: text/plain Lines: 62 X-Usenet-Provider: http://www.giganews.com X-Trace: sv3-V5j9ILwgzd0JRbsTkvA4GNZxo+ah+ya4G6UJG0yo1y7NqtLuNu0y0c2mCdapGMbAFOdPKNuWvqhDYlP!cCO9fdsm0VFt4M3XS+mQofLE8zEcscfDf0SABaTDBVDRuRE= X-Complaints-To: abuse@giganews.com X-DMCA-Notifications: http://www.giganews.com/info/dmca.html X-Abuse-and-DMCA-Info: Please be sure to forward a copy of ALL headers X-Abuse-and-DMCA-Info: Otherwise we will be unable to process your complaint properly X-Postfilter: 1.3.40 Xref: csiph.com comp.lang.lisp:61294 antispam@fricas.org (Waldek Hebisch) writes: > tfb wrote: >> Waldek Hebisch wrote: >>> >>> >>> Consider: >>> >>> (defun c_args_as_string (arguments) >>> (cond >>> ((null arguments) "") >>> (t (let ((res (c_type_as_string (nth 1 (car arguments))))) >>> (dolist (el (rest arguments)) >>> (setf res (concatenate 'string res ", " >>> (c_type_as_string (nth 1 el))))) >>> res))) >>> ) >>> >>> I do not say it is great code, but I find it easier to handle than >>> more traditional Lisp style. >>> >> >> OK, that's just weird. Everything is fine and you've got lots of close >> parens at the ends of lines in the standard way, but then something breaks >> and you have the final close paren on its own at the left margin. I can't >> even begin to understand what motivates that. > > If you look at rational factors: I need to see where given piece of > code ends. In bigger function with multiple blocks inside I would > put some parentheses in separate lines to signal ends of blocks. > There is also issue of seeing what is changed. Code frequently > gets added at end of existing functions. Separate "end" > parenthesis means that in such case old lines are unchanged and > only new lines get added. Version with parentheses at end of > line needs to move closing parentheses from old line to new > one. Hear Hear! IMHO python looks like pascal. Pascal is a great language but do not mess up the begin/end statements! The semicolons should be standard. I have the same issue with GO. This is starting to remind me of sendmail.cf :) > I trying to be conservative with putting end parentheses on > separate lines. One, doing this on too many constructs would > add too many extra lines. Second, putting such parentheses > in too many places would limit their value, they would be no > longer good cue. Third, really small pieces of code are > managable without extra cues, it is bigger pieces when it > matters. Fourh, I want to limit dissatisfaction of Lispers > used to traditional style in case they need to work on code > that I write. > >> But the same question: if you wrote it in Python, would you leave an extra >> little blank line for that weird closing paren? [ ... ] > "no trailing white space". Hear hear!