Thanks for the thoughtful reply, Steve...
...in-line replies as per my usu:
On Sun, 30 Aug 2026, Stephen J. Turnbull wrote:
Richard writes:
> my big issue about moving on is the apparent necessity of
> otherwise, for me, COMPLETELY unnecessary use of containerization
Do you mean Python virtual environments?
[...snip...]
Honestly it's been a while, so I'm not 100% sure memory serves but I think
on my distribution they were pushing the dockerized version and I was
pressed for time and didn't realize that was just my distribution's
default package and not the preferred way, which is what you seem to be
saying.
I'm glad you responded, Steve because I appreciate the potential benefits.
It looks like I have to give this another look-see, probably over this
coming holiday season...
As for Python I've always felt it's a snake alright, and a real python
that will strangle you to death if you let it wrap its insidious self
around your computing... a view I developed after more than once someone
with privs inadvertently installed some package for themselves and it
devastated the whole system. ... I generally support performant and not
otherwise resource consuming methods of keeping the damned thing
contained. ... Not entirely disconnected from Mailman, a mini-rant:
In my view Python and a good handful of other systems in (too-)
wide-spread use were foisted on us by young programmers who chose their
own personal expediency over the huge burden their code places on others
when put into production use on server-systems, primarily because they've
never run a production server - a REAL production server - and so have
zero idea what the requirements are and therefore have zero appreciation
for just how bad a choice they made in using whatever it was. I don't care
their age; there's immaturity in the curable but profound ignorance of the
choice... Developers claim it's easy to maintain meaning “easy to modify
and extend.” But they choose to not even consider the burdens their
choices place on people who have to deal with dependency control,
patching, reproducible deployment, startup behavior, memory use,
observability, failure recovery, incident response, and long-term upgrade
work. Those are very different meanings of maintainability and the hours
spent on keeping the software up and running dwarf the delta of time saved
in creation and extending the applications versus using better tools by
orders of magnitude.
In that sense, Python (especially pip install), and key parts of Ruby and
Perl are terrible choices for those who have to bear the burden of
maintenance, uptime, etc., and are fundamentally borne of the same
mentality of the original Windows systems - that is, treating the host
system as if it's single-user or single-application. ... And NOW we have
another problem borne of the first: there are FAR too many independent
Python "packaging" solutions that have HAD to be created to keep track of
them all. ...
I KNOW it's like trying to hold back the ocean with a broom but I beg ALL
developers everywhere to learn about and consider the down-stream effects,
and abandon Python and and ANY and EVERY anti-social programming
environment that doesn't have reasonable ecosystem considerations built
right in - there ARE other ways to write your code that aren't unfriendly
to those who would like to host it!
> (Note to newbies;
Not a lot of newbies here. The newbies are running Discord and Zulip,
rather than mailing lists.
Noted!
> ... One day (Turing Award winner) Michael Stonebraker came into my
> lab (380 Soda Hall, UC Berkeley - before it was reconfigured) with
> Sergey Brin and Larry Page in tow,
Great story!
TY... Having started in computing just before my 14th birthday, getting
paid for my skills within a year, and having a full time job programming
within two years while attending Tulane (usu. half-days) ... bookended by
two Turing Award Winners, I've been told a few times I really need to
write a book or three. But I know I can be just some opinionated asshat,
who just happens to have seen a lot and not been abjectly stupid. So I
appreciate your positive comment.
> Later many "AI" researchers came to our lab for a similar
> dog-and-poney-show dialogue asking if we'd created a "neural net,"
> as many "AI" research teams did at the time. Instead I cited our
> R-tree adaptation and said point blank that when you have a data
> processing need for some form of index, a pointer, to what's needed
> that doesn't already exist you invent the pointer for the type of
> data you have.
This drives me nuts, too. "Bright! New! Shiny! Nonfunctional and
pessimized!"
Yup!
New doesn't necessarily mean better and too often means worse!
Have you read Jamie Zawinski's screed about the advantage of Netscape
2's flat-file approach over formal databases for mail reader message
summaries?
Um... Probably not. But I can easily identify with the choice.... While I
was a top person at Ingres (before Postgres) and worked with Stonebraker
and team during Postgres' development at Berkeley - and have done a lot of
internals coding myself - I have oft chosen "flat file" solutions for
their durability, simplicity, "packaging", and many times superior
performance. But DO send me a link if you have one!
Thanks again for the reply, Steve,
Richard
--
Richard Troy
510-717-6942, Pacific time
[email protected]
------------------------------------------------------
Mailman-Users mailing list -- [email protected]
To unsubscribe send an email to [email protected]
https://mail.python.org/mailman3/lists/mailman-users.python.org/
Mailman FAQ: http://wiki.list.org/x/AgA3
Security Policy: http://wiki.list.org/x/QIA9
Searchable Archives: https://www.mail-archive.com/[email protected]/
https://mail.python.org/archives/list/[email protected]/
Member address: [email protected]
