Thanks to visit codestin.com
Credit goes to github.com

Skip to content

Conversation

WeatherGod
Copy link
Contributor

  • This way, a subclass could create its own list of handlers, and the
    code would work just fine. This would allow users to create subclasses
    that can handle local variations of the Metar spec without changing
    the original Metar code.

* This way, a subclass could create its own list of handlers, and the
  code would work just fine. This would allow users to create subclasses
  that can handle local variations of the Metar spec without changing
  the original Metar code.
@WeatherGod
Copy link
Contributor Author

As an example of how this could be taken advantage of:

class SuperMetar(Metar.Metar):
    def __init__(self, *args, **kwargs):
        # Initialize additional attributes *before* calling super's
        # because that's where the parsing happens.
        self.auto_type = None
        self.lightning_reported = False
        super(SuperMetar, self).__init__(*args, **kwargs)

    def _handleAutoRemark(self, d):
        super(SuperMetar, self)._handleAutoRemark(d)
        self.auto_type = ''.join(['AO', d['type']])

    def _handleLightningRemark(self, d):
        super(SuperMetar, self)._handleLightningRemark(d)
        self.lightning_reported = True

    # Rebuild remark handler list, because it was built
    # against the original set of regexes and handlers.
    remark_handlers = [
            (regex, locals().get(func.__name__, func))
            for regex, func in Metar.Metar.remark_handlers]

@akrherz akrherz merged commit 22f0dd7 into python-metar:master Jul 22, 2018
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants