[RFC] First class type support

[hynek]

This is kind of part of #214 but it stands for itself too.

Something like:

@attr.s(check_types=True)
class C:
    x = attr.ib(type=int)

ought to work.

Regardless of checking the type, the type information has to be accessible somewhere so we can have first-class deserialization support.

[yunstanford]

+1

[toumorokoshi]

This would be awesome! Is the goal to enable type checking within attrs itself? and to support types as listed in typing.py? There's a few caveats that we've discovered, diving in.

1 is there's no standardized type checking behavior for collections in typing. From my understanding, this is still an area that needs more work:

python/typing#136

Most people have been writing their own type validation libraries to compensate:

https://pypi.python.org/pypi/typeguard

All in all, I'm a huge fan of this direction. Just wondering what the choice is for type checker.

[hynek]

We don’t have concrete plans yet! Mostly because we want to make types & serialization first class concepts in attrs while doing this. :)

[hynek]

Wait, wrong ticket! :) Yeah, no still no idea yet!

[toumorokoshi]

I have a couple thoughts on this, if you're looking for ideas.

The type parameters should probably be equivalent to adding two behavior: validate and convert:

new_style = attr.ib(type=int)
old_style = attr.ib(validator=validators.instance_of(int), converter=int)

This works pretty well for primitive types. There's some nastiness with more complex types, which attrs probably shouldn't solve. For example, I'd expect to be able to do something like:

from datetime import daytime

@attr.s
class X:
    date = attr.ib(type=datetime)

# epoch
x = X(date=1092183940129)
# ISO 8601 string
x = X(date="2017-06-30T14:14:57Z")

but these would fail, because the datetime constructor takes none of these.

I would argue probably just not handling this case, and letting people override with whatever complex converters they prefer:

attr.ib(type=datetime, converter=my_complex_converter)

The other part is using or supporting typing modules. this will require some choices in behavior (e.g. validating types recursively, or just validating the top level collection for collection types). I prefer recursive validation and conversion, personally.

[hynek]

Yes, feel free to dump all your thoughts. The more input we get beforehand, the less mistakes we’re likely to make. :)

[Tinche]

OK, let's split the proposal into sub-features for easier commenting.

Create the type metadata

1. Adding a type parameter to attr.ib().

@attr.s
class C:
    x = attr.ib(type=int)

Presumably fields(C).x.type would be int then. I'm generally in favor of this. I already have a system like this in place for cattrs, except it uses metadata. I think this should be the backup though, for Pythons before 3.6. The 3.6 syntax reads much better for me.

@attr.s
class C:
    x: int = attr.ib()

So basically like #214, but with the type argument for older Pythons.

So what do we do with this data?

Static checks

My personal opinion is that static analysis is the future here. This means writing a MyPy plugin (which coincidentally I kinda promised to do, but I won't get around to until my main vacation at the end of July, probably), and maybe getting other vendors (flake8, pylint, pycharm...) in this space to cooperate too.

Static analysis has two major advantages. The first is that some types are impossible or exceedingly difficult to check for in runtime - think Iterator[int]. The other is performance. Generics in general are problematic.

@attr.s
class C:
    x: List[int] = attr.ib()

inst = C(list(range(1000)))  # Do what - iterate over the entire list?
inst.x.append('a string')  # No one will complain in the runtime here.

Even if you have simple type annotations, without generics, the isinstance calls are kinda heavy. IIRC for ints it's actually less expensive to use a convert=int than validator=instance_of(int), even though they aren't exactly the same.

This isn't me getting into static vs dynamic typing, just stating the fact that static types are a tool with advantages over doing it in runtime. We're getting them in Python and it's exciting!

We will still need validators since validators can check the values of types, and MyPy can't. So you will always need a validator to ensure your int is positive, for example.

Now, as I mentioned, this is probably the future. We can't really rely on this today since MyPy doesn't even support the easy cases of attrs classes.

Runtime checks

There is still value in runtime checking, of course. Not everyone will be able or willing to run MyPy over their code base, or maybe you want checks in the REPL, so us having a nice API for this would be good. This will require a little logic in our type validation, since not all types from typing can be used with isinstance.

The runtime type checks should be opt-in. I'm not sure if the opt-in should be on the class level (I feel like we'd need an opt-out at the attribute level) or at the attribute level, or both.

Let's experiment with some ideas for attribute-level opt-in.

from attr.validators import validate_type

def positive(_, __, val):
    if val <= 0:
        raise ValueError

@attr.s
class C: 
    x: int = attr.ib(validator=validate_type)  # Magic! Requires additional support in attrs.
    y: int = attr.ib(validator=[validate_type, positive])
    z: int = attr.ib(validator=validate_type(positive))

[toumorokoshi]

I agree that at least, introducing the type attribute and doing nothing but attaching it to the field would be great. It's a fantastic building block to build off of.

It would also be great to fold in the type definition into the attr.ib object, if possible, so

x = attr.ib(type=int)

and

x: int = attr.ib()

are functionally equal (if both are declared, attr.ib(type=foo) could take precedence).

I know there's an existing PR around attrs support for MyPy, so that'll handle the static checks at some point.

Personally, I'm more interested in the dynamic checks. I'd like to integrate it as a serializer for an API validation library I've been working on (http://transmute-core.readthedocs.io/en/latest/), and attrs has a great philosophy with performance as a feature.

Regarding the way validation is declared, validate_type seems syntactically the nicest. Although the complexities of type validation is definitely a larger ordeal. A lot of choices as @Tinche points out. validate_type could do shallow or deep validation, and that's control you may want to leave to the user.

Providing simple integrations with existing runtime type checking / conversion tooling might be better. e.g. typeguard or cattrs.

[hynek]

I'm drinking Aperol Spritz by Lake Como right now but briefly:

• Yes, I want .type as a building block and a dedicated validator that doesn't take further arguments. Everything just composes nicely. We may add a specific argument to attr.s that implicitly adds the validator to all fields. We'll see. As it should be obvious by now, I'm very anti runtime costs. :)
• I think declaring two types should blow up.

More when I'm back after EP. Although I may sprint on it.

[hynek]

Turns out I didn’t and went to San Marino instead!

---

Anyhow, so far we seem to have a consensus that:

• we add a new field to the Attribute class called type
• which can be set using x = attr.ib(type=int) if your life sucks and you can’t use Python 3.6
• using x: int = attr.ib() if life is wonderful.
• Additionally we’ll add a validator called check_type which will look at the type attribute and check.

Correct?

So far that seems rather straightforward.

I’d just like to make 100% sure that it won’t paint us in a corner re: deserialization? I’d like explicit comments from the two who built deserialization on top of attrs: @glyph and @Tinche

[Tinche]

I'm 100% on board with what you wrote FWIW.

[glyph]

FYI this is a very busy weekend for me but this is definitely in my queue to look at soon.

[hynek]

Cool, but don't overthink it. This is but a first building block. :)

[hynek]

👊 @glyph

(that’s a fist bump, not an attempt of intimidation thru violence :))

[wsanchez]

That (type attribute) seems like a solid first step.

[wsanchez]

@Tinche I'm thinking about your validate_type examples and I think it has legs.

But I'm wondering if it could also have global (ew?) switch of some sort. Since type validation, as you note, can be expensive, it's nice to do it statically if possible, but…

The runtime case I'd want to check is when unit testing, I think, just in case the static analysis toolchain is missing something. At least today, there are a lot of cases where mypy let's things slip, because it was hard to annotate something correctly so someone used Any, or you are getting a value from a library with no type hints or your code is only partly hinted, etc.

So I think there's a use case for: do validation when unit testing but not otherwise.

Perhaps I'm asking for a more fine-grained version of attr.set_run_validators…

[glyph]

Personally I'd rather have validation turned on all the time by default; I care more about correctness than speed. I want to rely on this to validate types when constructing them from wire formats. On PyPy, these isinstance checks will be no-opped out on the loops where they pass anyway, won't they?

[hynek]

@wsanchez fun fact: the reason behind attr.set_run_validators is precisely your use case. :) Because I want more checks at tests and less at runtime. attrs grew since its introduction, so things are more complicated now…

@glyph I agree on correctness > speed, however adding an implicit handbrake like this makes me uneasy. The big question is: has static type checking a future in Python or not? IOW: there will be a check_types in any case, but we’ll have to decide it’s default.

I personally tend to False, especially because we’ll most likely need to introduce a dependency on something like type guard, to do it properly.

[wsanchez]

@glyph I'm mostly in your camp, just trying to be sympathetic to the argument that sometimes, the validation is expensive overkill. That is, I might have a model object that, when I deserialize to it from JSON, I totally wan't validation, but when I read it from the database that I'm confident only have valid data, I might want to skip the validation, because I can test that pretty thoroughly.

I don't know what magic PyPy does to be smarter than me, and perhaps I should never optimize anything because PyPy will always do it better. Though I can't use PyPy yet, because at this point, I'm entered the "if it's not >=Py3.6, it's BULLSHIT" phase of my life. :-)

[hynek]

It's a good phase of life – enjoying not myself too.

In seriousness: unless someone comes up with a magical solution to validating types that goes beyond isinstance and doesn't introduce a new dependency, the default is settled.

[glyph]

I am using isinstance in my thing, but I'm not using the type directly. Specifically, here's a relevant function, which isn't complete:

def appropriate_type(T):
    if isunion(T):
        return tuple(appropriate_type(arg) for arg in T.__args__)
    if issubclass(T, typing.List):
        return list
    if issubclass(T, typing.Dict):
        return dict
    if issubclass(T, typing.Set):
        return set
    return T

[hynek]

FWIW, the relevant function seems to be https://github.com/agronholm/typeguard/blob/master/typeguard.py#L348

Also the pkg is by @agronholm and I have a hunch he may be open to persuasion to donate a validator to us. :)

I’m still against adding a handbrake by default – it just feels wrong. :|

[glyph]

How would you feel if we added an alternate, non-type-checked classmethod constructor? Foo.raw for example?

[toumorokoshi]

a nocheck argument is a nice piece in general. great to just instantiate things as fast as possible if you're really confident the data is valid.

I'm +1 for no default type checking. It's a big change from the existing assumption that the validation is explicit, and I really like attrs because it's a nice syntax around creating classes, and keeps the classes lean.

[glyph]

If you don't want this type of type checking, don't pass type=?

[wsanchez]

@glyph I thought the idea was that type= is superfluous:

   x: int = attribute()   # Implies type=int

[hynek]

That's certainly the plan.

Only open question to me is whether it makes any sense to artificially set __annotations__ if a user supplies .ib(type) in order to be backward compatible. Opinions @ambv?

[Tinche]

Only open question to me is whether it makes any sense to artificially set annotations if a user supplies .ib(type)

This is the first step, the second being copying from __annotations__ to Attribute.type? If so, I'd say no, if you want it in __annotations__, use a type annotation.

[agronholm]

Please don't modify __annotations__. You will want to have real annotations present for static code analysis tools like mypy or PyCharm.

[chadrik]

Please don't modify annotations. You will want to have real annotations present for static code analysis tools like mypy or PyCharm.

Modifying __annotations__ at runtime has no effect on static type analysis, which by definition never imports or runs your code. That said, my initial reaction is that I think __annotations__ should be copied to Attribute.type and not the other way around.

[agronholm]

Modifying annotations at runtime has no effect on static type analysis, which by definition never imports or runs your code. That said, my initial reaction is that I think annotations should be copied to Attribute.type and not the other way around.

The examples I've seen so far would forego the annotations and instead pass the type off to attr.ib() and have that used for run-time type checking. Therefore I agree with you.

[chadrik]

I just added a PR for the parts we all seem to agree on. Pop on by and let me know what you think.

[chadrik]

Two more thoughts:

1. I like the suggestion from @Tinche for opt-in validation:

   from attr.validators import validate_type
   
   @attr.s
   class C: 
       x: int = attr.ib(validator=validate_type)

2. We can also automatically handle defaults to some degree. e.g.:

   • int -> int()
   • str -> str()
   • typing.List[str] -> Factory(list) (the real class can be retrieved from typing.List.__extra__)
   • typing.Dict[str, int] -> Factory(dict) (same as above)

   A way of specifying this using something similar to 1 would be great:

   @attr.s
   class C: 
       x: int = attr.ib(default=default_from_type)

3. Same goes for conversion. It should also be opt-in.

For convenience, we could combine all 3 in one go by providing a dict with each of the type-aware keyword arguments:

import attr
from attr import use_type

@attr.s
class C: 
    x: int = attr.ib(**use_type)

[agronholm]

Sounds good to me.

[hynek]

FTR, the reason why I’m thinking about modifying __annotations__ is that IIUC, on Python 2, people are gonna have to write:

@attr.s
class C(object):
    x = attr.ib(type=int)  # type: int

Although I concur, that it should be probably solved in mypy.

The use_type magic goes a bit too far for attrs proper but we can revisit that topic once the groundwork is done.

[chadrik]

FTR, the reason why I’m thinking about modifying __annotations__ is that IIUC, on Python 2, people are gonna have to write:

@attr.s
class C(object):
    x = attr.ib(type=int)  # type: int

Static analysis and type annotations are pretty new, so before proceeding I should make a few non-obvious things clear so that we're all on the same page:

• the __annotations__ attribute is provided for runtime access to annotations:
  • it is available on function objects (for inspecting argument types) as of python 3.4 (PEP 3107)
  • it is available on any object with attributes (for inspecting attribute types) as of python 3.6 (PEP 526)
• type comments do not affect __annotations__ (the attribute is not present prior to python 3.4). __annotations__ are a direct corollary to (or bi-product of?) syntax support.
• the __annotations__ attribute does not affect static type checking. thus modifying it at runtime would have no affect on mypy.

Getting back to the original point: we can avoid the need for type comments in python 2.7 by providing pyi stubs with an overload specific to signatures that include the type argument. Here's a sketch:

from typing import Any, Mapping, Type, TypeVar, overload
T = TypeVar('T')

@overload
def attr(default: Any = ..., metadata: Mapping = ...) -> Any: ...
@overload
def attr(default: Any = ..., metadata: Mapping = ..., type: Type[T] = ...) -> T: ...

This says that if attr receives a type argument the function will return an instance of type. Otherwise, it returns Any (i.e. unknown).

That makes clear to static type-checkers that in your example x is an int without the need for type comments. So this is fine again:

@attr.s
class C(object):
     x = attr.ib(type=int)

[agronholm]

Hm, that actually looks quite clever!

[aldanor]

I'll throw my 2c in here -- I've written a little PoC library a while ago that codegens runtime type checkers in an efficient fashion given the type annotations: http://github.com/aldanor/typo. It can handle most basic type classes, but also things like Tuple[T, Dict[U, T]] with type vars and bounds.

Compared to other similar libraries, specifying x: int literally results in if isinstance(x, int) at runtime and doesn't involve a gazillion closures and lookups and decorators around it, which for simple type checks like the latter is an important thing to have. TLDR: it's very fast.

It gets pretty complicated with generic type vars though (specifically, with union-type ones) since you have to generate some pretty complicated code to deal with generics inside sum-types (not going into further details but it's fairly hairy). If you ban generics inside sum-types then it becomes very simple and straightforward -- e.g. constraints like Tuple[T, Dict[U, T]] are handled quite easily.

Maybe some pieces could be reused or partially reused in here, saving everyone a bit of time :)

[hynek]

We have recently merged generic type support, maybe you'd like to play with it a bit and give feedback?

I'm don't think we'll rush adding the actual checking anytime soon. Maybe we'll even point at external solution, so feel free to experiment.

[hynek]

First class support is in thanks to #239, we can open new issues on what to do with those type now.

[glyph]

I was trying to find https://github.com/aldanor/typo today but instead I ran across https://github.com/RussBaz/enforce which looks like it may be a fairly full-featured version of the same thing.

[chadrik]

There is also https://github.com/Stewori/pytypes May the best project win.

…

On Tue, Nov 14, 2017 at 4:37 PM Glyph ***@***.***> wrote: I was trying to find https://github.com/aldanor/typo today but instead I ran across https://github.com/RussBaz/enforce which looks like it may be a fairly full-featured version of the same thing. — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#215 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAD3ExNEMEFKt-RbcCG4I_VwqdxFp-oEks5s2jI6gaJpZM4OFBOJ> .

[anthrotype]

First class support is in thanks to #239, we can open new issues on what to do with those type now.

Where is the discussion about runtime automatic type checking happening?

[hynek]

There is none so far. I believe a good first step would be to add generic class-wide validators (@attr.s(validator=whatever)) and then make type checking a special case of it, possibly with some syntactic sugar.

[anthrotype]

Thanks. Shall we open a separate issue or re-open this one?

[hynek]

I think a new one would be best.