[gardening] Python tidies in cmpcodesize.main

What's in this pull request?
Some Python tidies:

Those .sorts weren't actually doing anything -- you need to call the methods for them to take effect.
Use zip(), and drop the idx variable. We know that old_files and new_files are the same length -- there's a check on the lines above -- so we don't need to worry about missing elements.

Resolved bug number: (SR-)
None.

Before merging this pull request to apple/swift repository:

[ ] Test pull request on Swift continuous integration.

Triggering Swift CI
The swift-ci is triggered by writing a comment on this PR addressed to the GitHub user @swift-ci. Different tests will run depending on the specific comment that you use. The currently available comments are:
Smoke Testing
    Platform     | Comment
    ------------ | -------------
    All supported platforms     | @swift-ci Please smoke test
    All supported platforms     | @swift-ci Please smoke test and merge
    OS X platform               | @swift-ci Please smoke test OS X platform
    Linux platform              | @swift-ci Please smoke test Linux platform

A smoke test on macOS does the following:

Builds the compiler incrementally.
Builds the standard library only for macOS. Simulator standard libraries and
device standard libraries are not built.
lldb is not built.
The test and validation-test targets are run only for macOS. The optimized
version of these tests are not run.

A smoke test on Linux does the following:

Builds the compiler incrementally.
Builds the standard library incrementally.
lldb is built incrementally.
The swift test and validation-test targets are run. The optimized version of these
tests are not run.
lldb is tested.

Validation Testing
    Platform     | Comment
    ------------ | -------------
    All supported platforms     | @swift-ci Please test
    All supported platforms     | @swift-ci Please test and merge
    OS X platform               | @swift-ci Please test OS X platform
    OS X platform               | @swift-ci Please benchmark
    Linux platform              | @swift-ci Please test Linux platform

Lint Testing
    Language     | Comment
    ------------ | -------------
    Python       | @swift-ci Please Python lint

Note: Only members of the Apple organization can trigger swift-ci.

Actually call the sort() method.
Cut out an unnecessary idx variable.

@swift-ci please Python lint.

CC @eeckstein for review.

@swift-ci Please smoke test


brew plugin: brew upgrade require --all

brew upgrade will require soon --all

Warning: brew upgrade with no arguments will change behaviour soon!
It currently upgrades all formula but this will soon change to require '--all'.
Please update any workflows, documentation and scripts!

Should be the alias definition of the brew.plugin updated to?
alias bubu="brew update && brew upgrade --all && brew cleanup"
https://github.com/robbyrussell/oh-my-zsh/blob/master/plugins/brew/brew.plugin.zsh#L2

Hello,
Patch #3816 is the patch to fix this that will be merged.

This will be fixed when #3809, which will be imminent. I'm adding it to #3651.

Forget what I said, the homebrew team backtracked on the --all parameter decision: https://github.com/Homebrew/homebrew/commit/a45a34db0b2c66f626f3724ae9a52563b4aa94b5


Inheritance from geometries does not work on Shapely 2.0 any more

Expected behavior and actual behavior
Expected: Inheriting from geometry objects works like on any other objects
Actual: Starting with 2.0 (as currently developed on the main branch), this does not seem to be possible
I am aware that this is only a development "snapshot", but I think this will become a problem. If it is intended to work, I can of course contribute the problematic code as a regression test. However, I do not know of a solution to the actual problem right now.
Steps to reproduce the problem.
This is a boiled-down example. The multiple inheritance probably isn't really the problem here, it's inheritance in general.
On Shapely 1.7.1 and before, this worked fine
from abc import ABC
from typing import Any

from shapely.geometry import Polygon

from our_lib import compat_transform

class PrintingMixin(ABC):
    """In reality, this contains common and custom logic for geometries."""

    def __init__(self, name: str) -> None:
        self.name = name

    def print_the_name(self) -> None:
        print(self.name)

class FancyPolygon(PrintingMixin, Polygon):
    """This contains custom attributes and methods, like projection information."""

    def __init__(self, points: Any, name: str = "Name", projection: str = "Projection") -> None:
        PrintingMixin.__init__(self, name)
        Polygon.__init__(self, compat_transform(points))
        self.projection = projection

    def print_the_projection(self) -> None:
        print(self.projection)

points = [(0, 1), (1, 2), (2, 3)]
poly = FancyPolygon(points)
poly.print_the_name()
poly.print_the_projection()

On Shapely 1.8.0
We got the ShapelyDeprecationWarning: Setting custom attributes on geometry objects is deprecated, and will raise an AttributeError in Shapely 2.0, as intended. We were confident that we would only need to add slots, which is fairly easy even with multiple inheritance (just the two lines with __slots__ where changed):
# In PrintingMixin:
__slots__ = ()  # Must be set in subclasses https://docs.python.org/3/reference/datamodel.html#object.__slots__

# In FancyPolygon:
__slots__ = ["name", "projection"]  # Will be merged with Polygon.__slots__

This should  work once shapely.Polygon also has a __slots__ attribute.
It also works functionally on this version, although it does not suppress the ShapelyDeprecationWarning.
On the way to shapely 2.0 (at commit b47dab627f796e3a89e340a6e533504037535e88)
... we realized, that this might be more complicated than that, since by now, shapely.Polygon has a __new__ class method. This means that FancyPolygon.__init__(...) will never actually be called. The implications of that:

We cannot apply compat_transform(...)
Custom attributes are not initialized
One gets an AttributeError: 'Polygon' object has no attribute 'print_the_name', since all out custom methods are not callable (since FancyPolygon(...) does not return a FancyPolygon)

I tried to hack it by adding a custom __new__() to FancyPolygon, but to no avail (TypeError: __class__ assignment: 'FancyPolygon' object layout differs from 'Polygon':
    def __new__(cls, points, *args, **kwargs):
        import shapely
        poly = shapely.polygons(compat_transform(points))  # This approach also has poor maintainability
        poly.__class__ = FancyPolygon  # <-- error in this line
        return poly

Operating system
Ubuntu 20.04, Python 3.8. Probably a universal problem.
Shapely version and provenance
Various, see above. Installed with pip, the last one with  python -m pip install git+https://github.com/shapely/shapely@b47dab627f796e3a89e340a6e533504037535e88.

Yes, see some related discussion in https://github.com/shapely/shapely/issues/1233. We didn't really consider the subclassing topic upfront, but is certainly is a consequence of the refactor in shapely 2.0.
A general solution could be to use composition instead of inheritance, but in the last comment at https://github.com/shapely/shapely/issues/1233#issuecomment-977837620 it seems @Jeremiah-England found a way to get the subclass working.

Thank you @jorisvandenbossche, that thread looks great!

I think we can close this as it's a known issue and intentional, yes?

Yes, and also as a duplicate of #1233