Personally, as a user of pyproj, I would be -1 on this. This is subjective of course, but I often find string argument options for a keyword easier to user than enums (crs.to_wkt(version='WKT1_GDAL') vs crs.to_wkt(version=pyproj.enums.WktVersion.WKT1_GDAL))

But since I will (as a user, not as developer) be mostly using pyproj through geopandas, I won't get into touch with them typically, so you don't have to count on my opinion ;)

Quickly tried it out, and it seems that for the WKT version, the string still works, since you still convert the user input to the enum and that's how enums work (which clearly indicates I don't use them often, which might also be the reason that I prefer to not use them ;))

In that case, I would indicate that in the docs.
And for the direction of the transformer, because there an IntEnum is used, the string version actually doesn't work.

@jorisvandenbossche, thanks for your input. So, one thing to note is that the string version is still supported on the to_wkt as well as to_proj4. The only one that is not currently supporting strings is TransformDirection.

It is nice to have the option for both as it gives a programmer the ability to browse through the options in an editor with autocompletion. It also reduces the possibilities for errors due to typos in strings.

Oh hah - seems we typed at the same time 😄

Also, @jorisvandenbossche, I believe you can use the values of the enum in transform direction (-1 for inverse) in the direction function. I went with this method as it removed the mapping code to map the direction from the string.

Looks like it works:

>>> from pyproj import Transformer
>>> transformer = Transformer.from_crs(3857, 4326)
>>> transformer.transform(33, 98, direction=-1)
(10909310.09774081, 3895303.9633938945)

One "regression" in usability I noticed is that before, when passing a string with a typo, you got the options in the message:

In [4]: crs.to_wkt(version='WKT_2015')                                                                                                                        
...
ValueError: Invalid version supplied 'WKT_2015'. Only ('WKT2_2015', 'WKT2_2015_SIMPLIFIED', 'WKT2_2018', 'WKT2_2018_SIMPLIFIED', 'WKT1_GDAL', 'WKT1_ESRI') are supported.

which is now no longer the case.

Since it is now the enum __init__, there is no easy way to have that again?

For the transform direction, I think the previous string was nicer than an integer (which is not saying much), in the case one is not using the enums of course.
Could the direction enum also be based on strings? (but that means the mapping between enum and int for the cython code needs to be added back?)

Since it is now the enum init, there is no easy way to have that again?

Apparently there are some methods you can override, and one of them is the message for non-existing value: https://docs.python.org/3/library/enum.html#supported-sunder-names (_missing_ in this case)

Would you welcome a PR adding that?

Could the direction enum also be based on strings?

If you have a strong preference for it, I am not opposed.

Apparently there are some methods you can override, and one of them is the message for non-existing value: https://docs.python.org/3/library/enum.html#supported-sunder-names (missing in this case)
Would you welcome a PR adding that?

yes, that would be great