How does this compare to schematics? It avoids inheritance, whereas in schematics and similar projects you'd have to inherit from their `Model` class (and thus acquire methods you might not want).
Using attrs for everything in Python
21–30 of 105 posts
Re: Using attrs for everything in Python
#22[deleted]
Re: Using attrs for everything in Python
#23It feels a bit hampered by "bad" design decisions to me
I think its safe to say that the current view of what decorators do is, a) filter things going to functions (so they error, or hit a cache), or b) register a function with another library (e.g. flask path decorator)
This library does a lot more than that, so it seems that maybe a metaclass (which exists to mutate the class's creation) would be more appropriate?
This seems to act as a __init__ replacement, but it would be cool to act as a __init__ assistant (in other words, run the attr.s __init__, then run the user defined __init__)
The ordering of attrs matters a bit more than one would expect, not only does it define the attribute order for creating a new instance, it also defines the order of attributes when sorting against other classes. You would not want a id=attr.ib() at the top of the class definition, where it most makes sense!
The ordering of attrs is done through the .ib() call itself (which gives itself a number, and increments a global counter). This is a way of doing it, and practically might be the best way (it won't lead to any inconsistencies within a class), but it still feels weird
I personally won't use it, but I might make a competitor to it for personal use
Re: Using attrs for everything in Python
#24This seems nice, but other than easy destructuring of functions that return long tuples (which really should return dicts), I cannot figure out a good use case for it over using a dictionary. I am keen to hear others' opinions.
You'd have to expand more on your proposal for using a dictionary for people to be able to reply. The article was full of use cases, so why not address those rather than simply state that you can't think of any? When you say use a dictionary, do you mean subclass `dict`? One of the aims of the project is to constrain the available instance attributes, as in a normal class. How would your dict proposal do that?
In that case, I'd just deal with the overhead of a normal class. More boilerplate, of course, but I'd have more control over the class.
As to the use cases, I was not really buying into them other than the nice destructuring example, which is actually very nice one.
Re: Using attrs for everything in Python
#25The short names confuse me a bit on this.
http://attrs.readthedocs.io/en/latest/overview.html#on-the-a...
Hello, Hynek!
Thanks for attrs, wonderful library!
I'd suggest to market the "serious business aliases" more prominently. It's not about aesthetics, but expectations: people like me are immediately puzzled by "attr.ib()", thinking "why ib?".
The reason is because after reading a lot of Python code, our brain is already trained to recognize attributes and method names after the dot.
Also, it's a reasonable expectation to be able to import a function or submodule and the code still make sense, but this won't make sense:
from attr import s, ib
@s
class Thing(object):
x = ib()
I have the feeling that by making the "no non-sense" alternative more prominent in the examples and documentation, it would reduce cognition steps for newbie users and maybe make your own life easier by not having to explain and paste this link every time someone finds it odd (which will probably continue to happen).
Cheers!
Re: Using attrs for everything in Python
#26How does this compare to schematics? It avoids inheritance, whereas in schematics and similar projects you'd have to inherit from their `Model` class (and thus acquire methods you might not want).
Until your comment, I had never seen schematics. I poked around a bit and my initial impression is that it seems like marshmallow-- it's heavily focused on validation rather than reducing boilerplate.
Re: Using attrs for everything in Python
#27While the conciseness of attrs is nice, it's not very readable. This: class Point3D(object): def __init__(self, x, y, z): self.x = x self.y = y self.z = z ...is much easier to read than this: import attr @attr.s class Point3D(object): x = attr.ib() y = attr.ib() z = attr.ib() Readability is what I love about Python. I don't think the conciseness of attrs is worth the loss in readability.
I find the @attr example more readable.
I've been using Python for a while, but it's not my main development language. I mainly use it for scripting experiments, processing data and generating graphs. I generally avoid defining classes as much as possible, and use namedtuple whenever appropriate.
Re: Using attrs for everything in Python
#28Would there be any value to allowing a convention for the __init__() method that allows direct assignment of arguments to attributes? For example, replacing the following: class Point3D(object): def __init__(self, x, y, z): self.x = x self.y = y self.z = z with: class Point3D(object): def __init__(self, self.x, self.y, self.z): # Other initialization work It seems __init__ could be made to parse the list of parameter…
you can just do class B: def __init__(self, a, b, c): self.__dict__.update(locals())
That makes B.self a field too, which you probably don't want.
Re: Using attrs for everything in Python
#29The problem with constructs like this one is that it looks nice at first glance, but adds a cognitive load to an ecosystem that already has about "20 ways to do it" for every single problem.
Python is beginning to rival C++ in that respect.
Re: Using attrs for everything in Python
#30"Another place you probably should be defining an object is when you have a bag of related data that needs its relationships, invariants, and behavior explained. Python makes it soooo easy to just define a tuple or a list."
Yes, and defining a tuple or a list is often better than a small object because of Python's problems with serializing (pickling) objects. If you're doing anything with data, anything functional, anything with multiprocessing, anything with distributed programming -- you want to avoid using objects as small bags of data. (Namedtuples should have been a way to improve this, but they are implemented as a class, so they have serialization issues too.)
Lists of data can be serialized easily. Lists of objects cannot. dill tried really really hard to fix this, but the problems that remain are problems created by the Python language spec.