Using attrs for everything in Python • Hacker News Board

Re: Using attrs for everything in Python

#101

Post by glyph » Sat, Aug 27, 2016, 7:31 PM UTC

carapace wrote: post #95

dr_zoidberg wrote: post #90

Earlier quoted context omitted.

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…

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…

It's not an "in-joke". It follows conventions set by the Python language:

- "def" instead of "define"

- "cls" instead of "Class"

- "sys" instead of "system"

- "os" instead of "operating_system_facilities"

- "ntpath" instead of "windows_path_names"

- "abc" instead of "abstract_base_classes"

Python aggressively abbreviates almost everything in common use. If it were in the stdlib, perhaps it would be the built-in names "attrs" and "attrib" rather than having dots in them, but the names would indubitably still be very short.

Re: Using attrs for everything in Python

#102

Post by carapace » Sat, Aug 27, 2016, 10:05 PM UTC

glyph wrote: post #99

carapace wrote: post #93

Earlier quoted context omitted.

tl;dr: I don't like metaprogramming. ---- Both of those things are very good, even great, but they don't speak to the issue: It's [bad] magic. In this case, it does at module-load-time what should have been done previously at build-time. (And yes, I know Python normally doesn't have build-time the way e.g. C does.) I'm working on a large production codebase right now where several of the cowboy-coders here have added…

The same problem does not apply. I understand that spooky action-at-a-distance magic can really ruin a codebase's maintainability. But what you've developed here is not a judicious appreciation of its danger and its power, but a blanket aversion to both its risks and its benefits. An apt metaphor would be, let's say: toast. If you try to make some toast, but accidentally burn your house down, it's understandable that…

I like toast, and a toaster is better than a folded wire clothes hanger perched over the stove burner, but this robot toast-o-matic is too fancy for my kitchen at work. We gotta toast that toast and ain't nobody got time to debug some fancy toaster.

:-) Metaphors. Heh.

Let me reiterate the first part of my statement above, to wit: "this is wonderful and cute as hell".

I like it.

I could use it if it generated complete code for the classes you define. That would actually put to rest my "metaprogramming BAD" problem in this case.

Tucking __init__ source in linecache for the debugger is neat but it's also more magic. You might wind up stepping through code that doesn't exist in any file. Is this wonderful hacky weirdness mentioned in the docs? I didn't see it.

And what about __repr__? No precomputed string template?

Don't imagine that I'm crouching in the dirt tentatively reaching out to the monolith of metaprogramming. I'm into it. I read GvR's "The Killing Joke" for fun. But he called it that for a reason. :-)

I still recall a junior dev slamming into a wall trying to extend a Django HTML form widget. The reason? The cowboys over at Django made it with a metaclass.

We should look at a problem and think, "What's the simplest thing that will work?" Or, more to the point, "Does this problem require metaprogramming to solve?" ("or am I just showing off?" could be the rest of that question...)

HTML form widgets don't require metaclasses. The problem attrs solves doesn't require metaprogramming. It's a simple DSL for data models. Right? Riiiight?

If attrs took in a spec (as Python code or whatever) and emitted all your boilerplate, ready to go, I would love it so much. You would get all of the benefits without any of the downside. I know that's boring and not sexy or fun, but I just want to get this bug fixed and ship it and get on with my life. I'll play with attrs at home, on my own time, but I'm sick of magic at work.

(Damn, am I really that old? heh)

Re: Using attrs for everything in Python

#103

Post by carapace » Sat, Aug 27, 2016, 10:13 PM UTC

glyph wrote: post #101

carapace wrote: post #95

Earlier quoted context omitted.

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…

It's not an "in-joke". It follows conventions set by the Python language: - "def" instead of "define" - "cls" instead of "Class" - "sys" instead of "system" - "os" instead of "operating_system_facilities" - "ntpath" instead of "windows_path_names" - "abc" instead of "abstract_base_classes" Python aggressively abbreviates almost everything in common use. If it were in the stdlib, perhaps it would be the built-in names…

It's an "in-joke" in the sense that it doesn't make sense until you get the joke. There are people in this post discussion asking "What means .s and .ib?" It's not obvious to everyone.

Re: Using attrs for everything in Python

#104

Post by carapace » Sat, Aug 27, 2016, 10:14 PM UTC

glyph wrote: post #100

carapace wrote: post #93

Earlier quoted context omitted.

tl;dr: I don't like metaprogramming. ---- Both of those things are very good, even great, but they don't speak to the issue: It's [bad] magic. In this case, it does at module-load-time what should have been done previously at build-time. (And yes, I know Python normally doesn't have build-time the way e.g. C does.) I'm working on a large production codebase right now where several of the cowboy-coders here have added…

And, thanks for the P.S. Always nice to see people enjoy my work :)

Cheers! :)

Re: Using attrs for everything in Python

#105

Post by BerislavLopac » Sun, Aug 28, 2016, 3:12 PM UTC

asciihacker wrote: post #89

BerislavLopac wrote: post #83

attrs seems to be all over the place, but I find Schematics ( http://schematics.readthedocs.io/en/latest/ ) much better designed and more powerful.

Yes, Schematics is impressive. Thank you, I added it to my list of Python OOP extensions [1]. I wonder why you need to supply a dictionary to the object instead of keyword pairs. [1] https://github.com/metaperl/python-oop

> I wonder why you need to supply a dictionary to the object instead of keyword pairs.

My understanding is that the main reason is to make constructors more flexible, with arguments like _raw_data_, _trusted_data_ etc. But it is trivial to write a simple helper function that would accept keyword pairs and build a model instance.