Investigate performance impact of using enums for the Sentinels instead of trivial object subclasses.

[JamesParrott]

Describe the feature request

Reader.shp = None is what the default does anyway, and I could also be persuaded that we should break backwards compatibility for users who for some reason created shape = Shape(shapeType=None, ... ) but anyway:

The enum module was previously been found to almost double the time required to write a shapefile. But that was when they were used for the Shapefile type code (0, 1, 3, 5, 7, 11, ..., 31) (instead of simple integer constants, or string constants in a trivial wrapper class) which every Shape instance needs a member of.

Perhaps other than initial import and set up, the impact is much more acceptible, if only one enum member from each new enum sub class is needed throughout the entire module and process, to mark 'private' default values?

Shape type Sentinel: https://github.com/GeospatialPython/pyshp/blob/19010dfbe0ef7a7ac0d9c2d1a62585a6a4cd2ec4/src/shapefile.py#L709C55-L709C78
Reader .shp file object Sentinel:

pyshp/src/shapefile.py

Line 2251 in 19010df

shp: Union[_NoShpSentinel, Optional[BinaryFileT]] = _NO_SHP_SENTINEL,

The advantage is, mypy handles enums much more nicely, and these casts/loop holes could be removed:

pyshp/src/shapefile.py

Line 741 in 19010df

self.shapeType = cast(int, shapeType)

pyshp/src/shapefile.py

Line 2414 in 19010df

shp = cast(Union[str, IO[bytes], None], shp)

Contributions

• I am interested in implementing the described feature request and submit as a PR.