4 ms·

As I think others noted, the attr version does alot more: it adds representation and easily adds compare methods as shown in OP. Aside from that, this is not a

As I think others noted, the attr version does alot more: it adds representation and easily adds compare methods as shown in OP. Aside from that, this is not a fair comparison because attr names can, and mostly should be, longer, and there can be more of them, e.g.: class SomeClass(object): def __init__(self, myattr1, some_val, a_bool, my_other_attr): self.myattr1 = myattr1 self.some_val = some_val self.a_bool = a_bool self.my_other_attr = my_other_attr And of course they'll need to go into __str__ method as well.

carapace 10y ago
It adds magic. "Explicit is better than implicit" ~https://en.wikipedia.org/wiki/Zen_of_Python https://en.wikipedia.org/wiki/Zen_of_Python
- deleted 10y ago
  [deleted]
- RubyPinch 10y ago
  I feel like a person should be able to back their opinion up (for a specific case, not in general), instead of just mindlessly quoting a line from a bible.
  - njbooher 10y ago
    The magic in programming war is eternal and which side you're on ought to just be added to the Myers-Briggs test.
  - carapace 10y ago
    See comment in this post in reply to Glyph. (And don't be a jerk.)
- dr_zoidberg 10y ago
  Then let's get rid of the with semantics too, because they add magic. Compare: with open("file.txt") as somefile: for line in somefile: print line To the more explicit and clear: somefile = open("file.txt") line = somefile.readline() while line: print line line = somefile.readline() somefile.close() But I'm still using some magic, I should be more explicit: def explicit_readline(fd): buff = [] char = fd.read(1) while char != "\n" and char != "": buff.append(char) return "".join(buff) somefile = open("file.txt", "rb") # just to be sure now line = explicit_readline(somefile) while line != "": # to be more explicit, of course print line line = explicit_readline(somefile) somefile.close() And we could go on like this to replace open with the os module file-descriptor functions, and print with sys.stdout/stderr (because more explicit, right?). But even without getting there, it should be obvious that: * The "explicit" verison no longer behaves as the original one, because, for example, explicit_readline only handles well the NIX newline character. If I want to provide the same functionality as file.readline() I should add a lot more code. I've reinvented the wheel for no good reason, and readability has suffered. It may also leave a lingering question in the mind of a read "why did he do that? is there some edge case that wasn't well documented anywhere and he bumped into?". * I've seen more contrived code do a version of this "more explicit" programming style, to the point of having statements like: def f1(number): number = int(number) return number & 0xff00 # or plug the number parameter in an equation, etc * ... (not a verbatim example, but along those lines). And that code is redundant and it will fail anyway if another thing other than an int/long/float is passed. It would be certainly saner to have an assert, or simply specify in the docs that said function expects a number (which is implied in the args too). My point was the "Explicit is better than implicit" means "be clear of your intent". And if I see someone using the attr module (which comes with the standard library), and I'm not familiar with it, I'll read into it. And for it's use case, I think it's clear enough in what it does, and how it should be used.
  - carapace 10y ago
    Oh c'mon Zoidberg, that's a strawman argument. "with" is a Python keyword and the statement syntax is in the grammar. I would expect any working Python developer to know what it is, and even understand how to write a context manager. ...wait wat? It's in the Standard Library? No, I just checked and it's not. Too bad, if it was "blessed" by inclusion in the library I would totally withdraw my objection on that grounds. You had me going for a second there. ;-) You make my point for me though when you say that you'd have to read up on it when you first encountered it. That's exactly my point: The trade off is between one application of attr to the code base to save N time/effort for the current developer one time, versus every bit of lost time/effort of future devs taken to understand the attr package. It's cute, but it's an in-joke. Don't put in-jokes in code you want other people to use, otherwise they have to "get the joke" before they can work with it. That's what I'm on about.

carapace 10y ago

It adds magic. "Explicit is better than implicit" ~https://en.wikipedia.org/wiki/Zen_of_Python https://en.wikipedia.org/wiki/Zen_of_Python

deleted 10y ago
[deleted]
RubyPinch 10y ago
I feel like a person should be able to back their opinion up (for a specific case, not in general), instead of just mindlessly quoting a line from a bible.
- njbooher 10y ago
  The magic in programming war is eternal and which side you're on ought to just be added to the Myers-Briggs test.
- carapace 10y ago
  See comment in this post in reply to Glyph. (And don't be a jerk.)
dr_zoidberg 10y ago
Then let's get rid of the with semantics too, because they add magic. Compare: with open("file.txt") as somefile: for line in somefile: print line To the more explicit and clear: somefile = open("file.txt") line = somefile.readline() while line: print line line = somefile.readline() somefile.close() But I'm still using some magic, I should be more explicit: def explicit_readline(fd): buff = [] char = fd.read(1) while char != "\n" and char != "": buff.append(char) return "".join(buff) somefile = open("file.txt", "rb") # just to be sure now line = explicit_readline(somefile) while line != "": # to be more explicit, of course print line line = explicit_readline(somefile) somefile.close() And we could go on like this to replace open with the os module file-descriptor functions, and print with sys.stdout/stderr (because more explicit, right?). But even without getting there, it should be obvious that: * The "explicit" verison no longer behaves as the original one, because, for example, explicit_readline only handles well the NIX newline character. If I want to provide the same functionality as file.readline() I should add a lot more code. I've reinvented the wheel for no good reason, and readability has suffered. It may also leave a lingering question in the mind of a read "why did he do that? is there some edge case that wasn't well documented anywhere and he bumped into?". * I've seen more contrived code do a version of this "more explicit" programming style, to the point of having statements like: def f1(number): number = int(number) return number & 0xff00 # or plug the number parameter in an equation, etc * ... (not a verbatim example, but along those lines). And that code is redundant and it will fail anyway if another thing other than an int/long/float is passed. It would be certainly saner to have an assert, or simply specify in the docs that said function expects a number (which is implied in the args too). My point was the "Explicit is better than implicit" means "be clear of your intent". And if I see someone using the attr module (which comes with the standard library), and I'm not familiar with it, I'll read into it. And for it's use case, I think it's clear enough in what it does, and how it should be used.
- carapace 10y ago
  Oh c'mon Zoidberg, that's a strawman argument. "with" is a Python keyword and the statement syntax is in the grammar. I would expect any working Python developer to know what it is, and even understand how to write a context manager. ...wait wat? It's in the Standard Library? No, I just checked and it's not. Too bad, if it was "blessed" by inclusion in the library I would totally withdraw my objection on that grounds. You had me going for a second there. ;-) You make my point for me though when you say that you'd have to read up on it when you first encountered it. That's exactly my point: The trade off is between one application of attr to the code base to save N time/effort for the current developer one time, versus every bit of lost time/effort of future devs taken to understand the attr package. It's cute, but it's an in-joke. Don't put in-jokes in code you want other people to use, otherwise they have to "get the joke" before they can work with it. That's what I'm on about.