Sorry stupid Mail program sent it before I finished. Keyboard seems to
be having a bad day.

On 03/02/2015 11:05 AM, Steve Litt wrote:


>
> Because here's the thing. We all say we're great programmers, but
> somehow, on lots of software, buffers get overrun. Pointers go errant.
> Programs proceed after failed mallocs. Malloc/free loops somehow start
> to accumulate more allocation than freeing. None of this is an issue in
> Python. In Python, programmer mistakes tend to affect the data, not the
> system. Python long ago solved the vast majority of security problems:
> It's secure, and when it's not, because of its millions of users, you
> find out fast.

Let's just say that I EMPHATICALLY disagree with you on the subject of Python and leave it at that. I'm afraid I come from a part of the universe where Python is not embraced, but utterly despised for syntax reasons.



>
> Yes, I know that Python's got that 2.x vs 3.x problem. Yes, I know that
> a lot of people hate Python's significant whitespace. Yes, I know that
> a Python import is a dependency, just as sure as
> libarbitraryfunctionality.so.

Those are annoyances, I agree.

>
> You might wonder why I picked Python over Perl, Ruby and Lua. After
> all, most of the "interpreter" benefits I stated are equally applicable
> to all four. Here's why. So far, only Perl and Python are truely
> intertwined with Linux. I'd like to keep that number to a minimum.

On that, we definitely agree!

I'd prefer less, but if we have to have at least one, I'd rather pick one and stick with it consistently - even if in the end that happened to be Python, and that all the interpreted scripting in a distribution be done in one and only one language, rather than a handful.


> Throughout the past two decades, Perl's "many ways" philosophy has
> fallen into disfavor, as more and more shaky, indeterminant and
> unreadable code gets written in "many ways".

Forcing the "one way" using Python hardly leads to efficient code either, IMHO.


> And CPAN's a menace, and
> its tendancy to compile C code is failure waiting to happen.

On that we also agree: CPAN is a menace. Just to be clear, I don't blame C for that. At least not any more than I blame Python for using C code itself. I blame CPAN for crappy test modules and poor version control.

> Lastly, as
> far as I know, among the four "interpreters" I mentioned, only Perl and
> Python have a stable of known good, well known and capable add-ons to
> assure one that any project you start in the language you can finish in
> the language.

On that we can agree somewhat. I'll be honest in saying that Python would gain much more respect from me if it were formally standardized. I'd prefer that every certified version was guaranteed to run a certain level of compatible code.
I'm not a fan of "de-facto" languages.

t.j