[TUHS] python

[Larry McVoy]

I agree with Rob.  I get why Guido did it, he wanted some sane style.  Any 
of us who were kernel engineers and saw a sane C style, then you see GNU
C style and you recoil in horror.  I don't know if that was his path but
I get that you would like some sanity in the formatting.

That said, as a person who thinks of himself as a professional, when I go
in to someone else's code, I adopt their style.  It's really rude to not
do so.  I've written code in GNU C style.

On Thu, Aug 03, 2023 at 11:29:18PM +1000, Rob Pike wrote:
> The idea of indentation defining structure seemed really cool when it
> arose. I first saw it in a toy language called Henry, back in the early
> 1980s.
> 
> But over time the notion that invisible characters define program execution
> created so many problems that in retrospect it is ill advised despite its
> prevalence. In fact its prevalence makes it even less advisable, as it
> creates yet more areas for trouble.
> 
> -rob
> 
> 
> On Thu, Aug 3, 2023 at 10:36???PM Mike Markowski <mike.ab3ap at gmail.com> wrote:
> 
> > Clem and all,
> >
> > I find python string format syntax to be close enough to printf. E.g.,
> >
> >    print('%.4f ns, (%.4f, %.4fj)' % (tap[0], tap[1].real, tap[1].imag))
> >
> > However, the example highlights a shortcoming.  While complex numbers
> > are supported by the language, there is no formatting support like
> > '%.5j' ('j' is my made up format char) to directly format a complex number.
> >
> > I work in an RF lab focused on work with hardware and lab gear. Some
> > points in favor of python are (1) lab gear is controlled by SCPI, (2)
> > DSP relies on complex math, and (3) RF propagation modeling is
> > computationally intense.
> >
> > Item (1) is easily performed with python, (2) with python or
> > Matlab/octave, and (3) is 'it depends.'  An engineer's friend went from
> > slide rule, to calculator, fortran/c (fortran for numbers, c for
> > hardware), and now python. A laptop with python or matlab is the new
> > 'calculator.'  As to (3), if you will use the program for large
> > scenarios, use c or fortran. For small runs or to dovetail results with
> > control of lab gear python fills the bill.  (I even went to the slightly
> > insane length of converting a classic prop model from fortran to python
> > for that reason: https://udel.edu/~mm/itm/ )
> >
> > I agree 110% that python white space formatting is horrible.  I can't
> > say many times I took someone else's program, made a quick change, to
> > discover one of us used tabs and the other spaces.
> >
> > Mike Markowski
> >
> > On 8/2/23 10:07 PM, Clem Cole wrote:
> > > IMO (Like Larry) no printf stinks.  But the real killer for my sustain
> > > for Python is the use white space and being typeless.   My daughter
> > > loves it for her cloud development and we argue a bit.  But it was the
> > > first language she really mastered in college and she never took a
> > > competitive languages course so I???m not so sure really had experienced
> > > much beyond it for real programs.   Maybe I???m just an old fart but
> > > between C, Go and Rust I???m pretty good.  I do write scripts in Bourne
> > > shell and or awk truth be known.
> > >
> >

-- 
---
Larry McVoy           Retired to fishing          http://www.mcvoy.com/lm/boat