These were useful primarily for the Python 2 to 3 transition. Python 2
is no longer supported so these are no longer necessary.

Differential Revision: https://reviews.llvm.org/D157759

This is an ongoing series of commits that are reformatting our Python
code. Reformatting is done with `black` (23.1.0).

If you end up having problems merging this commit because you have made
changes to a python file, the best way to handle that is to run `git
checkout --ours <yourfile>` and then reformat it with black.

RFC: https://discourse.llvm.org/t/rfc-document-and-standardize-python-code-style

Differential revision: https://reviews.llvm.org/D151460

With lldb (& llvm) requiring Python 3.6+, use of the `six` module can be removed.

Differential Revision: https://reviews.llvm.org/D131304

This patch replaces getargspec with getfullargspec in funcutils.py.
getargspec has been deprecated by python 11x release. This is
important to run LLDB testsuite in Windows/Arm64 platform
where Python native will be available from python release onwards.

Note: getfullargspec is not available in python 2

Reviewed By: labath

Differential Revision: https://reviews.llvm.org/D121786

join is only available since python-3.8, but the all the interesting
magic happens in shlex.quote, which has been around since 3.3.

Use shlex.quote, and instead provide a home-grown helper function to
handle the joining.

Differential Revision: https://reviews.llvm.org/D112802

To the best of my understanding these files or their content is nowhere
referenced.

Tests that check the output of `memory find` may trip over
unreadable characters, and in Python 3 this is an error.

llvm-svn: 355612

Summary:
This patch finishes the python3-ification of the lldb-server test suite.
It reverts the partial attempt in r352709 to encode/decode the string
via utf8 before writing to the socket. This wasn't enough because the
gdb-remote protocol can sometimes (but not very often) carry binary
data, and the utf8 codec chokes on that. Instead I add utility functions
to the "seven" module for performing "identity" transformations on the
byte data. This basically drills back the hole in the python type system
that the string/bytes distinction was supposed to plug. That is not
ideal, but was the best solution of the alternatives I could come up
with. The options I considered were:
- make use of the type system to add type safety to the test suite: This
  required making a lot of changes to the test suite, since most of the
  strings would now become byte objects instead, and it was not even
  fully clear to me where to draw the line. One extreme solution would
  be to just use byte objects everywhere, as the protocol doesn't
  support non-ascii characters anyway. However, this appeared to be:
  a) weird, because most of the protocol actually deals with strings,
     but we would have to prefix everything with 'b'
  b) clunky, because the handling of the bytes objects is sufficiently
     different in PY2 and PY3 (e.g. b'a'[0] is a string in PY2, but an
     int in PY3).
- using the latin1 codec (which gives an identity transformation for the
  first 256 code points of unicode) instead of the custom
  bytes_to_string functions. This almost could work, but it was still
  slightly different between python 2 and 3, because in PY2 in would
  return a unicode object, which would then cause problems when
  combined with regular strings if it contained 8-bit chars.

With this in mind, I think the best solution for the time being is to
just coerce everything into the string type as early as possible, and
have things proceed indentically on both python versions. Once we stop
supporting python3, we can revisit the idea of using bytes objects more
prevasively.

Reviewers: davide, zturner, serge-sans-paille

Subscribers: lldb-commits

Differential Revision: https://reviews.llvm.org/D58177

llvm-svn: 354106