[lug] Running a mixed Python environment

[Steve Litt]

On Tue, 15 Sep 2020 07:57:23 -0600
Rob Nagler <nagler at bivio.biz> wrote:

> On Tue, Sep 15, 2020 at 2:17 AM Steve Litt wrote loads of flamebait:
> > Some projects are huge, but the Python folks announced in 2008 that
> > they'd sunset in 2015, and eventually moved that out to 2020.  
> 
> Can you explain why Dropbox, a company founded in 2007, who hired
> Guido van Rossum in 2012, still was migrating the code base in 2020?
> (Dropbox may still be using py2. There hasn't been a "we're done"
> blog post afaict.)

I'm not privy to Dropbox' code, so I can't answer the preceding
question.

I will, however, state a principle I believe in: With large code (50K
or more lines), maintenance requires one of the following two:

1) Throw lots of time and money at maintenance

2) Be very, very stringent about modularity, encapsulation, and thin
   interfaces.


> 
> Flame: I have heard that the Python folks have learned their lesson,
> but they are still breaking APIs on every minor release and sometimes
> on patch releases. Every time we upgrade Python versions or use PIP,
> it's a crapshoot of whether we lose hours or days fixing things.

Breaking API interfaces is a crime against the entire software sphere.
Applications use libraries that use libraries that use libraries, such
that one bad actor who changes an API interface can bug up lots of
applications.

I completely understand why once every five years or so, a new version
of a library or dependency needs to wholesale dispense with the old and
bring in the new (after a suitable deprecation period). But constant
changes of API interfaces is horrible.

I personally have never been bitten by my Python code breaking with
minor version Python upgrades. One reason is I never write big
software. Even my UMENU2 program, written in Python, is only 0.5MB of
source, which if you divide that by 50 characters per line (guess), is
only 10K lines of code. Another reason is probably because I move
heaven and earth not to use anything not in the Python standard
library. I'd rather write a few hundred lines to implement a behavior
than incorporate a huge library, possibly written partially in C. I
don't want to tell users of my software to pip this and install that and
flatpack whatever. I prefer my softwares' sole dependency to be the
standard Python3 distribution.

And I take a lot of grief for my position. The talking heads all tell
me "don't reinvent the wheel", as if that advice is universally true in
every situation. To continue the wheel metaphor, unfortunately all too
many developers shoehorn in a whole wheel when all they needed was one
spoke nipple. No wonder software gets so big, slow, bulky and buggy.

One time I asked on #python or ##python or whatever on Freenode how to
code a very specific action that would probably have been 50 lines of
code if I knew how to do it. They answered that I should include
library z. A minute web-searching library z showed it to be immense,
with a zillion features. I wrote them back saying I didn't need all
that, and I didn't want to require my users to install library z, and
that I didn't want to install a wheel when all I needed was a spoke
nipple. They wrote me back, and I kid you not, that I should *always*
incorporate big libraries in order to learn them, and I could put my
app in a flatpack (or something like that) to distribute a Python
specific to my application. I'm not kidding, that's what they said.

I'm a big believer in minimal dependencies.
 
SteveT

Steve Litt 
Autumn 2020 featured book: Thriving in Tough Times
http://www.troubleshooters.com/thrive