Drop the @classmethod here. load() doesn't have it, and MetaData doesn't use it
either, so let's make the interface even. Also, please rename the functions to
conform to the same conventions established by MetaData: parse() and load(), the
former with a data _string_, the latter with a filename. Add parse_serialization_data
to handle the dict case. The behavior of these functions should also mimic MetaData:
load() raises FileNotFound, and so on.
These two classes are exactly alike. There's no reason for us to diverge and
then having to remind of which interface does what, which load accepts a dict,
etc.
[17]
+ def validate(self, options):
+ """Validate options using the file at `path`.
Which path?
[18]
+ This method will return a dict with options that have passed
+ validation. This means options not declared in the formula
+ metadata will trigger a ServiceConfigError exception.
+
+ This method includes defaults for options which have no values
+ supplied if such defaults are defined in the metadata.
Please reword:
This method validates all the provided options, and returns a new
dictionary with values properly typed and default values set for
missing keys. If a provided option is unknown or its value
fails validation, ServiceConfigError is raised.
[19]
+ "%s is not a valid configuration option." % (option))
(...)
+ "a normal Python regex pattern for %s" % (
+ option))
(...)
+ "See http://docs.python.org/library/re.html" % (
+ option))
(...)
+ raise ServiceConfigError("Invalid options specification: %s" % (
+ error))
This is a tuple: (option,)
This is an expression with redundant parenthesis: (option)
+class ServiceConfigError(Exception):
+ """Indicates an issue related to service options."""
+ pass
Drop pass.
[22]
+def regex_validator(str, pat):
+ return re.match(pat, str) is not None
Don't your eyes bleed and pop with the obvious inversion of parameters?
I can't emphasise enough how important consistency is for the long term
health of a software project. It's _key_ to pay attention to details
such as parameter consistency, interface consistency across similar
classes, and so on. Those are the details that will make our lives
(or someone else's) less painful when giving maintenance in years to
come.
[23]
+ "float": float,
+ "regex": regex_validator
Let's have proper validators, with an even interface on all of them,
as per [20].
Idea looks good, implementation looks good, several small issues
in terms of polishing the branch for merging.
[11]
+description and an optional default value. Additionally type may be
s/type/'type'/
[12]
+ config = ConfigOptions()
+ content = None
The second line may be dropped.
[13]
+ "options": Dict(String(),
+ OneOf(
+ # regex type requires validator
+ KeyDict({"type": Constant("regex"),
Indentation should be revised here. Feel free to define an
auxiliary variable externally.
[14]
+ "validator": String(),
We need a new RegEx type in the schema to validate the regular
expression.
[15]
+ optional= ["default" , "description",]),
s/",]/"]/
Same on the bottom one.
[16]
+ @classmethod
+ def load_file(cls, pathname, optional=False):
Drop the @classmethod here. load() doesn't have it, and MetaData doesn't use it tion_data
either, so let's make the interface even. Also, please rename the functions to
conform to the same conventions established by MetaData: parse() and load(), the
former with a data _string_, the latter with a filename. Add parse_serializa
to handle the dict case. The behavior of these functions should also mimic MetaData:
load() raises FileNotFound, and so on.
These two classes are exactly alike. There's no reason for us to diverge and
then having to remind of which interface does what, which load accepts a dict,
etc.
[17]
+ def validate(self, options):
+ """Validate options using the file at `path`.
Which path?
[18]
+ This method will return a dict with options that have passed
+ validation. This means options not declared in the formula
+ metadata will trigger a ServiceConfigError exception.
+
+ This method includes defaults for options which have no values
+ supplied if such defaults are defined in the metadata.
Please reword:
This method validates all the provided options, and returns a new
dictionary with values properly typed and default values set for
missing keys. If a provided option is unknown or its value
fails validation, ServiceConfigError is raised.
[19]
+ "%s is not a valid configuration option." % (option)) docs.python. org/library/ re.html" % ( ror("Invalid options specification: %s" % (
(...)
+ "a normal Python regex pattern for %s" % (
+ option))
(...)
+ "See http://
+ option))
(...)
+ raise ServiceConfigEr
+ error))
This is a tuple: (option,)
This is an expression with redundant parenthesis: (option)
Drop the parenthesis in all of those cases.
[20]
+ validator = validation_ kinds[kind] option] .get("validator ")
+ if kind == "regex":
+ pattern = self._data[
The interface for validators can deal with such distinctions so that
we don't have to special case them in the generic function. E.g.:
validator = validation_ kinds[kind]
value, valid = validator(value, self._data[option])
[21]
+class ServiceConfigEr ror(Exception) :
+ """Indicates an issue related to service options."""
+ pass
Drop pass.
[22]
+def regex_validator (str, pat):
+ return re.match(pat, str) is not None
Don't your eyes bleed and pop with the obvious inversion of parameters?
I can't emphasise enough how important consistency is for the long term
health of a software project. It's _key_ to pay attention to details
such as parameter consistency, interface consistency across similar
classes, and so on. Those are the details that will make our lives
(or someone else's) less painful when giving maintenance in years to
come.
[23]
+ "float": float,
+ "regex": regex_validator
Let's have proper validators, with an even interface on all of them,
as per [20].
Alright, I think with that we can merge it.