[TUHS] python

[Ed Bradford]

Very nice serman, Norman. I moved from (cb unix) BTL C (1976) to C++ to
Java to PHP and JavaScript to Python. I never went for the object oriented
view but loved C++'s strict type checking.

I got very frustrated with the active support for Python2 and Python3
versions and vacationed
for several years. Then Python went out of the Python 2 support
business and I started using
Python again. Over the span of all those languages Python 3 has supported
almost anything
I could think of with free downloadable modules. That has happened nowhere
I have ever seen.

I also struggled with writing and supporting print functions where the
variables were
in one place and the formats for them were in another place.
Python3's f-strings reduced
my strings substantially. Now the format and variable can be defined in one
place and used in lots of places.

That is a huge help to me for documentation and support.

That's my two cents.

Thanks for your thoughts

Ed Bradford
Pflugerville, TX
egbegb2 at gmail.com

PS: Has anyone else but me on this list tried chatGPT generated python
programs? We should
move such a conversation elsewhere, but I simply don't know where. Email me
if you
want to start a discussion on this topic in a more appropriate place.



On Sun, Aug 6, 2023 at 2:46 PM Norman Wilson <norman at oclsc.org> wrote:

> At the risk of releasing more heat than light (so if you feel
> compelled to flame by this message, please reply just to me
> or to COFF, not to TUHS):
>
> The fussing here over Python reminds me very much of Unix in
> the 1980s.  Specifically wars over editors, and over BSD vs
> System V vs Research systems, and over classic vs ISO C, and
> over embracing vendor-specific features (CSRG and USG counting
> as vendors as well as Digital, SGI, Sun, et al) vs sticking
> to the common core.  And more generally whether any of the
> fussing is worth it, and whether adding stuff to Unix is
> progress or just pointless complication.
>
> Speaking as an old fart who no longer gets excited about this
> stuff except where it directly intersects something I want to
> do, I have concluded that nobody is entirely right and nobody
> is entirely wrong.  Fancy new features that are there just to
> be fancy are usually a bad idea, especially when they just copy
> something from one system to a completely different one, but
> sometimes they actually add something.  Sometimes something
> brand new is a useful addition, especially when its supplier
> takes the time and thought to fit cleanly into the existing
> ecosystem, but sometimes it turns out to be a dead end.
>
> Personal taste counts, but never as much as those of us
> brandishing it like to think.
>
> To take Python as an example: I started using it about fifteen
> years ago, mostly out of curiousity.  It grew on me, and these
> days I use it a lot.  It's the nearest thing to an object-
> oriented language that I have ever found to be usable (but I
> never used the original Smalltalk and suspect I'd have liked
> that too).  It's not what I'd use to write an OS, nor to do
> any sort of performance-limited program, but computers and
> storage are so fast these days that that rarely matters to me.
>
> Using white space to denote blocks took a little getting used
> to, but only a little; no more than getting used to typing
> if ...: instead of if (...).  The lack of a C-style for loop
> occasionally bothers me, but iterating over lists and sets
> handles most of the cases that matter, and is far less cumbersome.
> It's a higher-level language than C, which means it gets in the
> way of some things but makes a lot of other things easier.  It
> turns out the latter is more significant than the former for
> the things I do with it.
>
> The claim that Python doesn't have printf (at least since ca. 2.5,
> when I started using it) is just wrong:
>         print 'pick %d pecks of %s' % (n, fruit)
> is just a different spelling of
>         printf("pick %d pecks of %s\n", n, fruit)
> except that sprintf is no longer a special case (and snprintf
> becomes completely needless).  I like the modern
>         print(f'pick {n} pecks of {fruit}')
> even better; f strings are what pushed me from Python 2 to
> Python 3.
>
> I really like the way modules work in Python, except the dumbass
> ways you're expected to distribute a program that is broken into
> modules of its own.  As a low-level hacker I came up with my own
> way to do that (assembling them all into a single Python source
> file in which each module is placed as a string, evaled and
> inserted into the module table, and then the starting point
> called at the end; all using documented, stable interfaces,
> though they changed from 2 to 3; program actually written as
> a collection of individual source files, with a tool of my
> own--written in Python, of course--to create the single file
> which I can then install where I need it).
>
> I have for some years had my own hand-crafted idiosyncratic
> program for reading mail.  (As someone I know once said,
> everybody writes a mailer; it's simple and easy and makes
> them feel important.  But in this case I was doing it just
> for myself and for the fun of it.)  The first edition was
> written 20 years ago in C.  I rewrote it about a decade ago
> in Python.  It works fine; can now easily deal with on-disk
> or IMAP4 or POP3 mailboxes, thanks both to modules as a
> concept and to convenient library modules to do the hard work;
> and updating in the several different work and home environments
> where I use it no longer requires recompiling (and the source
> code need no longer worry about the quirks of different
> compilers and libraries); I just copy the single executable
> source-code file to the different places it needs to run.
>
> For me, Python fits into the space between shell scripts and
> awk on one hand, and C on the other, overlapping some of the
> space of each.
>
> But personal taste is relevant too.  I didn't know whether I'd
> like Python until I'd tried it for a few real programs (and
> even then it took a couple of years before I felt like I'd
> really figured out out to use it).  Just as I recall, about
> 45 years ago, moving from TECO (in which I had been quite
> expert) to ed and later the U of T qed and quickly feeling
> that ed was better in nearly every way; a year or so later,
> trying vi for a week and giving up in disgust because it just
> didn't fit my idea of how screen editors should work; falling
> in love with jim and later sam (though not exclusively, I still
> use ed/qed daily) because they got the screen part just right
> even if their command languages weren't quite such a good match
> for me.
>
> And I have never cottoned on to Perl for, I suspect, the same
> reason I'd be really unhappy to go back to TECO.  Tastes
> evolve.  I bet there's a lot of stuff I did in the 1980s that
> I'd do differently could I have another go at it.
>
> The important thing is to try new stuff.  I haven't tried Go
> or Rust yet, and I should.  If you haven't given Python or
> Perl a good look, you should.  Sometimes new tools are
> useless or cumbersome, sometimes they are no better than
> what you've got now, but sometimes they make things easier.
> You won't know until you try.
>
> Here endeth today's sermon from the messy office, which I ought
> to be cleaning up, but preaching is more fun.
>
> Norman Wilson
> Toronto ON
>


-- 
Advice is judged by results, not by intentions.
  Cicero
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.tuhs.org/pipermail/tuhs/attachments/20230807/bd929ac4/attachment.htm>