It adds magic.

"Explicit is better than implicit"

~https://en.wikipedia.org/wiki/Zen_of_Python

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.

The magic in programming war is eternal and which side you're on ought to just be added to the Myers-Briggs test.

See comment in this post in reply to Glyph. (And don't be a jerk.)

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.

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.

Weird, in Windows (Python 2.7.10) I have it without having ever installed it. Even pip uninstall didn't get it (just to make sure it wasn't installed from a dependency) but I can still import it.

On my Linux machine (Python 2.7.6) I can't import it without a previous install from pip install (that's reasonable).

Can't track down much about why this happens because googling "python attr" brings results about hasattr, getattr, etc, but few about the attr module.

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.

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.

>Then let's get rid of the with semantics too, because they add magic.

With just runs the enter and exit method of a context manager. Nothing magical about it.

>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.

You don't have to read into 'with' to make an intelligent guess at what the code does. It's meaningful even if you've never heard of context managers.

Unlike this.