bpo-29905: Fix TypeError in asyncio/proactor_events

[DimitrisJim]

A new PR for issue29905, without including the TypeError reformatting for asynchat which, if my interpretation of #issue25002 and specifically #msg250151 was correct, should probably not be included.

If my interpretation was incorrect, I'll push a change for it too :-).

[berkerpeksag]

That if branch doesn't seem to be tested in Lib/test/test_asyncio/test_proactor_events.py. Could you add a simple test that triggers TypeError? The ProactorSocketTransportTests.socket_transport() helper already provides most of the needed infrastructure so I guess it should be easy to write a test case.

Please add a note to Misc/NEWS.

Also, "is" in your PR title should be "in", right? :)

[berkerpeksag]

%r looks OK to me. Is there a reason to use '%s' with type(data).__name__?

[AraHaan]

Why not use string tuples for format like this?

            msg = ("data argument must be a bytes-like object, not '{}'"
            ).format(type(data).__name__)

And then it would eliminate any possible confusion on the %'s.

If you are wondering why I prefer string tuples. It is because of the fact that it helps simplify a lot of code or on the other hand helps make the code confine to PEP8.

For example lets say you have this code with these objects:

class Cat:
    """
    Class that makes up an instance of Cat.
    """
    def __init__(self, name, age, location):
        self.name = name
        self.age = age
        self.location = location
class Dog:
    """
    Class that makes up an instance of Dog.
    ""
    def __init__(self, name, age, location):
        self.name = name
        self.age = age
        self.location = location

Since both objects have the same attributes instead of doing an:

"My {0} is named {1} and is {2} years old and is at {3}".format(type(myobj).__name__, myobj.name, myobj.age, myobj.location)

it could become:

"My {type(0).__name__} is named {0.name} and is {0.age} years old and is at {0.location}".format(myobj)

As you can see simplifies things a lot.

[DimitrisJim]

@berkerpeksag AFAIK repring in error messages is used to play it safe in cases where the object happens to be an instance of bytes; the __name__ special attribute is always a string so %s is always certain to work. Apart from that, I followed along with other cases of formatting __name__ I encountered in other error messages.

@AraHaan The author of the module prefers using old-style formatting, so I stuck with that to keep it consistent. :-)

[DimitrisJim]

I'll address the requests soon, thanks!

(Yes, silly typo :-))

[1st1]

Thanks! Will be shipped in 3.6.2