> A little bit of a primer one of  the biggest motivation of the original writer of Python was he hated how sloppy Perl programmers  were and wanted to create a language that enforced what he thought were good coding practices.

And then they invented pypi, and "pip install" where the same package
of the same name and version on Tuesday has a different checksum,
different content, and different dependencies than the same package
which pypi allowed the developer to replace without renumbering, and
instead invented an unreliable and unpredicatable checksum based
indexing to segregate between the different versions.

Python, and pypi, and busilly rediscovering many of the same sloppy
sins of Perl and CPAN is not a good use of engineering time. Neither
is burning hundreds or thousands of man-hours to write complex tools
like the "awscli", and getting basic features wrong through complete
failure to document, like whether the "sync" command overwrites or
makes a local copy and then replaces local files, or misreports
"/dir1/dir2/filename" as "../../dir1/dir2/filename" because the author
doesn't understand what an absolute directory path means or realize
just how badly direcotory symlinks can screw up relative paths.

I'm not finding myself impressed with Python development. Spending so
much time to rewrite tools that already exist, work better, and have
defined interfaces does not seem to me be useful engineering.

> As for Python it's become popular and definitely Red Hat's favorite scripting language. It's got a great following and is used for many things.
>
> As for modules Perl 5 still has more but many of the are dated, Python is catching up and it has the benefit of youth and popularity.

As a sys-admin over 50 years old, I'm not over enchanted with youth
and popularity.

> For example Amazon AWS has a Python API, but not a Perl API. I've been debating about writing one my self and in the Perl tradition there are 2 ways I can do it build on LWP (lib WWW Perl) to create a native Perl module, or take the lazy route by create an "XS" module which wraps the C API. The advantage of the XS method is I can run a script and have a clumsy but working module in seconds, then spend a couple of hours to make it easy to use.

See above. The awscli and the Python API it partially defines, and is
the reference implementation for, are *horrible*. Even such ISO
standards as regular expression matching for file and directory names,
and ISO standards for dates, are casually ignored without warning. One
of the very reasons it's very exciting and "new" is because many of
its authors are simply ignoring standards, implicitly and explicitly,
and not realizing that they have to deal with even the simplest
standards as command line options and error reporting. Code gets more
complex and harder to write when you have to handle errors, and it's
*very* common for new languages to be faster until actually tested
with real uses.

> What you will here is Perl is dead, but the truth is most people use it on a daily basis and don't know it. Perl is still the swiss army chainsaw of scripting languages.

Hear, hear. (And that is how it is spelled, by the way.)

> Honestly for support on learning Python is easier.
> With Perl if you can get to the point where you really understand the power of anonymous references, it's still a very fast and flexible language.
>
> In conclusion
> Either one is good. Learn them both at least superficially. Tinker and play with them and see which one is right for you.

I'd suggest learning bash first. Many complex perl, python, php, etc.
tools are actually wrappers for a few lines of shell.