Closed ymost closed 11 months ago
Similar was suggested in https://github.com/r1chardj0n3s/parse/issues/100
I think what I'm suggesting is much simpler. It could hardly be considered new functionality, just exposing existing functionality. Basically what I have in mind is:
def format(self, *args, **kwargs) -> str:
return self._format.format(*args, **kwargs)
Does this seem reasonable?
It seems reasonable, one thing does occur to me though that the Parser supports some "extra" types which do not make sense for a formatter, e.g.
>>> p = compile("{:w}")
>>> r = p.parse("xyz")
>>> p._format.format("abc")
ValueError: Unknown format code 'w' for object of type 'str'
So the format method may be more difficult to implement in a full-featured way, rather than just exposing ._format.format()
.
Looking at the Parser
class, I also don't see any obvious reason why the ._format
attr is internal, perhaps a (read-only) property could just be added to return the format template string, instead of a format method?
class Parser(object):
...
@property
def format(self):
return self._format
Wow, I didn't know about the extra types. I guess parse()
is not exactly the opposite of format()
...
Anyway a read-only property seems good!
I think it would nice and elegant if the same object could be used both as a formatter and a parser. This can be achieved by adding a
format
method:Granted, one could simply hold on to the original string and use that, but I think it's useful if we only needed the Parser object for both of these. For example, if you pass the Parser as an argument to a function, currently you need to pass the format string as well, otherwise you have to access the internal
_format
field. At the very least, we should have aget_format
method to retrieve the internal_format
field.Another reason is that if we are using two different objects for formatting and for parsing, it increases the chance that someone creates a bug by changing one of the objects and forgetting to change the other one.