Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add decorator for convert #240

Open
agronholm opened this issue Sep 1, 2017 · 12 comments
Open

Add decorator for convert #240

agronholm opened this issue Sep 1, 2017 · 12 comments
Labels

Comments

@agronholm
Copy link

One can have @validator and @default but no @convert. Is this an oversight or by intention? If it's just an oversight, I'd be happy to send a PR for it.

@hynek
Copy link
Member

hynek commented Sep 24, 2017

I think it's mostly laziness on my part and a tad of indecisiveness because I'm a bit annoyed by the inconsistency of validator (noun) vs convert (verb). :-/

@devdave
Copy link

devdave commented Nov 11, 2017

Just a follow up on this, I could also provide a PR similar to how validator is defined. perhaps as convertor to keep the naming consistent?

Using a toy example, would something like this be accepted?

`
thing = attr.ib()

@thing.convertor
def sanitize_thing(self, raw_val):
return raw_val if isinstance(raw_val, int) else int(raw_val)
`

@wsanchez
Copy link

@devdave: I think so. We might have to bikeshed the name, but that's a smaller matter. I suggest you go with converter. Note spelling. :-)

@devdave
Copy link

devdave commented Nov 23, 2017

Went with dirt simple

    def converter(self, meth):
        """
        Decorator that assigns *meth* as the input converter.

        Returns *meth* unchanged.
        """
        self.convert = meth
        return meth

Adjacent, I can't find where to make a basic test for the above method. Personally, at minimum I make a stub to act as pseudo documentation and also locking the signature into a project.

Held off with submitting a PR to keep clutter down.

@hynek
Copy link
Member

hynek commented Nov 26, 2017

I’m not sure I can parse this, are you asking where to put the test for the decorator? I’d say put behind the default decorator tests in test_make.py and another one int test_dark_magic.py.

It should also be demonstrated on the examples page.

@devdave
Copy link

devdave commented Nov 27, 2017

Obviously not a pull request but initial changes are here. https://github.com/devdave/attrs/tree/pr_240 Is there an ideal PR I can use as a guiding example of what I need to aim for to make sure this would be accepted?

I don't entirely understand hypothesis but get the impression it is a BDD like extension to pytest?

@hynek
Copy link
Member

hynek commented Dec 3, 2017

Well the code is fine however you’re taking advantage of the fact that the current bad name is different from your decorator. :). IOW it has tech debt built right in and it would be nice if it could be done properly right away. If you want you can wait or tackle the convert → converter dance first.

@devdave
Copy link

devdave commented Dec 3, 2017

@hynek That's not too big of a problem. Starting on refactoring; instance property convert to _converter (similar to _validator), though for the record I am still partial to convertor :)

@devdave
Copy link

devdave commented Dec 7, 2017

All tests passing with changes to _CountingAttr, Attribute, and the init building logic
https://github.com/devdave/attrs/blob/pr_240/src/attr/_make.py#L1183

@hynek
Copy link
Member

hynek commented Dec 7, 2017

Please just open a pull request, it’s really hard to follow along like this. :)

@hynek
Copy link
Member

hynek commented Jan 17, 2018

@devdave any chance of a PR?

@coder6464
Copy link

I think some more refactoring is required to allow the converter decorator to take self, like how default and validator work

Using @devdave changes, it currently only works like this

@thing.converter
def _thing_converter(value):
    returned do_conversion(value) if ... else value

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

5 participants