René's URL Explorer Experiment

{"@context":"https://schema.org","@type":"DiscussionForumPosting","headline":"Decide to deprecate module level functions?","articleBody":"## Situation\r\n\r\nCurrently, we have mostly functions which are either on the module level (`semver.next_version`, `semver.bump_*`) and almost the same on the `VersionInfo` level (`semver.VersionInfo.next_version`, `semver.VersionInfo.bump_*`).\r\n\r\nI know, they both serve distinctive purposes: the first expects and returns a string whereas the second needs a `VersionInfo` object.\r\n\r\nHowever, from an implementation perspective, I'm wondering if this is double work. It looks inefficient to me when the `VersionInfo` methods need to convert the object first into a string, call the modul level function, and convert it back to a `VersionInfo` object.\r\n\r\nIMHO, we should improve this situation.\r\n\r\n\r\n## Suggested Solution\r\n\r\nThe question boils down to this: should we treat `VersionInfo` as **first class object**?\r\n\r\nI have the impression this isn't currently the case. The developer can decide between two implementation which does mostly the same. The only difference is, one implementation use strings, the other use a \"detour\" with an `VersionInfo` object.\r\n\r\nIf we would treat `VersionInfo` as our one and only solution, that would mean we have to move the implementation into the methods. The module level functions would serve as \"helper functions\".\r\n\r\nOr... maybe we could think about a more radical approach? Are the module level functions really necessary? Should we deprecate them? As we can convert a `VersionInfo` object into a string through `str(versionobject)`, it seems to me, they are obsolete...\r\n\r\nI see the following benefits of this approach:\r\n\r\n* Focus on the `VersionInfo` class, all the magic would happen there. :wink: \r\n* Avoids writing two functions which mostly implements the same functionality, but with different types.\r\n* Simplifies testing.\r\n* Focus more on objects than strings (which can't be controlled).\r\n* Improves the project to be more slim and well-arranged.\r\n* Makes conversion between objects obsolete. Without conversion, it would have a improved effect on performance (maybe only slightly, but...).\r\n\r\nIf we want to follow this path, we would need:\r\n\r\n* Use the `warning` module to issue a deprecation warning in affected module functions.\r\n* Document the change for our upcoming major release. :wink:\r\n* Release 2.9.2 of semver to implement the warnings\r\n* Make the whole removal in release 3 only.\r\n\r\n@gsakkis, @scls19fr  Does that make sense to you? Do I miss an important point? I would really like to hear your view on this. :heart: \r\n","author":{"url":"https://github.com/tomschr","@type":"Person","name":"tomschr"},"datePublished":"2020-02-29T17:48:27.000Z","interactionStatistic":{"@type":"InteractionCounter","interactionType":"https://schema.org/CommentAction","userInteractionCount":10},"url":"https://github.com/225/python-semver/issues/225"}