Make Version properties change from read-only to read-write? #327
Labels
Design
Ideas, suggestions, musings about design questions
Enhancement
Not a bug, but increases or improves in value, quality, desirability, or attractiveness
Question
Unclear or open issue subject for debate
Release_3.x.y
Only for the major release 3
Projects
Situation
After having invested a lot of time in #317 with
__init__()
and validating our data, I did some research and here is another of my crazy ideas. 馃槃 Sorry if the text is a bit longer, but I think it could be worth.It might simplify
__init__()
but it would change the way our properties are handled a bit.According to the section Accessing Parts of a Version Through Names in our documentation, the
Version
class contains the propertiesmajor
,minor
etc.However, at the time of writing, these properties can be read only. They do not allow write access:
The Idea
I'm wondering if this behavior should be changed. 馃 Is that still contemporary? I can't exactly remember why we did that. 馃槈
Maybe our users have a use case which they would like to write something like this:
Why shouldn't they? Would that make sense?
Of course, the assignment should only be successful if we pass the right type. Invalid values are still rejected and would lead to an exception:
The Implementation
The idea is to start with some validating functions. We distinguish basically between two types:
They must be of type
int
orstr
. Furthermore, if it is an integer, the value must be greater than zero.Here we need to check if it is
None
(allowed) or a of typeint
orstr
(also allowed).We end up with this:
Furthermore, we need a decorator/function that creates this property automatically for us. That decorator needs to be called with a name (like
major
), a callable to check the value (see above), and another callable to convert it to the target type. One implementation could look like:To combine it in our class, we need to add it at the class level:
I see here some benefits:
typed_property
and the validating functions.__init__
is free from validating the inputs. This is all done in the validating functions. Should simplify the initializer method a bit.I see also some design issues:
Having two property names.
The
typed_property
decorator needs to have the property name twice, as an assignment on left side and as a string in the argument. It's probably not much, but it feels a bit un-pythonic.Need two callables for the
typed_property
decorator.Although this is not much either, it is also feels a bit awkward, especially with the lambda for prerelease and build.
Validating functions outside the class
Currently, the validating functions are outside of the
Version
class. I see currently no solution to integrate that into the class as that a forward reference would be needed. Theoretically, we could do that in__init__
(or even__new__
) but that would complicate the matter.Going Beyond (Descriptor Protocol)
The above issues could be solved. Python has for this kind of problems the descriptor protocol.
Properties are just an implementation of the more general descriptor protocol. That is a class which contains one of the methods
__get__
,__set__
or__delete__
, see https://docs.python.org/3/howto/descriptor.htmlTheoretically, we could add an additional class which implements the above behavior in the said methods. This would be a charming way as all the checking/validating is hidden inside the class.
However, I'm not sure to introduce another class just to implement that. It seems also a bit of an overkill to me, although it's quite pythonic. Not sure if we would introduce other problems as it raises the complexity a bit.
On the other side, it could be beneficial if we (or another user) want to derive the
Version
class with some other validating parts.Related Information
@python-semver/reviewers @tlaferriere Any comments? Thoughts?
The text was updated successfully, but these errors were encountered: