What exactly to do with this CoordinateSequence class is something still to be discussed, and I opened #984 for that

I have been reading up on #984 and I tend to go with this implementation for this PR (making self._coords a ndarray directly)

However I think that sticking a full duplicate of coords to the object by default is a bit too much. Also _coords won't be initialized properly in all construction paths.

Within this approach (I actually like the lazy CoordinateSequency object approach better) I think it is best to use a pattern like this:

@property
def coords(self):
    try:
        coords = getattr(self, "_coords")
    except AttributeError:
        coords = pygeos.get_coordinates(self)
        coords.flags.writeable = False
        self._coords = coords
    return coords

However I think that sticking a full duplicate of coords to the object by default is a bit too much.

Note that this CoordinateSequence is not constructed by default when creating a geometry object. It will only be created once a user accesses the geom.coords attribute.

Now, with the current code, each time the user does geom.coords, it will create a new CoordinateSequence object containing a new array, so making this "cached" is certainly a good idea (as well as making the array not writable)

For all those constructors, I now use WKT to create an empty geometry, but see pygeos/pygeos#149 to discuss if we need to have a better way for this

pygeos.geometrycollections([]) gives you the empty geometry collection also

We get different error message in several places (we should see to what extent we want to preserve them, sometimes they are more informative though)

This is something we need to check in pygeos how this can be possible, if it's a feature we want to preserve

I'd say all error messages from GEOS (like the one below) should be converted to exception messages, similar to #991 (comment) . I'd assume it would be difficult to capture an error message in pygeos, but also emit the same error message to the logger handler below. I wouldn't expect many other folks to be relying on these log capture methods.

Opened #998 for a discussion on logging.

In pygeos right now we didn't implement this keyword, but have a byte_order keyword instead (matches more closely the terminology of GEOS). The default is to use the machine's endianness, and one can use the keyword to override this.

We were just discussing this in PyGEOS as well -> pygeos/pygeos#190

There we thought that it might be OK enough to get a LineString back from pickling a LinearRing. However, having the pickling on the python side (still using WKB), we could more easily track the original class as well and ensure it is correctly preserved.
However, having it in python compared to in the base C extension type has a performance penalty.

This is tracked by #988

Currently, shapely has a bunch of custom error classes in https://github.com/Toblerity/Shapely/blob/master/shapely/errors.py. But in PYGEOS, for now we just have a single GEOSException for errors that are directly raised from one of the GEOS functions.

Raising pygeos exceptions is just an intermediate state of the API then?

Yes, the fact that it is a "pygeos" exception is intermediate state. But basically everywhere you see pygeos you need to mentally replace it with shapely (as in one of the next steps we will move pygeos into shapely and replace the pygeos imports with internal shapely imports).

So the "real" question here is if we are, long term, fine with having only a generic shapely.GEOSException, or if we want to have more fine grained error classes (TopologicalError, WKBReadingError, WKTReadingError).
Note that this is only about the class of the exception, also the generic GEOSException error class will still have the custom, informative error messages.

Opened #991 to have a dedicated place to discuss this topic.

I believe that these class-level attributes are not used?

__p__ is used below, but I think this would be a good time to rename this private variable to _parent

Specifically for this GeometrySequence class, we also still need to see what to do with it (keep it or not?)

The term EmptyGeometry doesn't really cover the fact that GEOS has 'typed' empty geometries.

As `GeometryCollection([]) gives this exact same result, I think this class should best be deprecated.

This seems backwards to me.
In my opinion we should never pass these pointers around as python int objects. Do you think we can remove the geom_factory completely from shapely 2.0?

Yes, this is certainly only temporary. I don't refactor the full of Shapely in a single PR, and thus in other parts of shapely, geom_factory is still used together with ctypes. So those changes here with the DummyGeometry hack is just to ensure geom_factory keeps working. But the end goal of Shapely 2.0 for sure means that all usage of geom_factory is eliminated.