setup.py fails on Python3.4 (PEP 448)

[chstem]

Running python3 setup.py gen_tl on the latest commit results in Failed to import TelegramClient due to can use starred expression only as assignment target (__init__.py, line 286)

This was with Python3.4, while Python3.5 works just fine. Telethon 0.13.6 (0f10e14) works fine as well. The actual file/line is telethon/tl/types/__init__.py:

return b''.join((b':\x1d\xe8\x98',struct.pack('<i', self.user_id),TLObject.serialize_string(self.description),b'\x15\xc4\xb5\x1c',struct.pack('<i', len(self.commands)),*[(x.to_bytes()) for x in self.commands],))

And if I researched correctly, then the issue is that PEP 448 is not supported in Python3.4.

[Lonami]

Damn it! So these were a recent addition to Python. Well, I'll just put another b''.join() there I guess (that will save me from creating a list anyway). Thanks for testing out master.

[chstem]

I wanted to use the new to_bytes() for something else, that's why I tested it.

That line is quite long and hard to read. Chunking it into smaller pieces might be a good idea anyway.

[Lonami]

Initially, I thought of splitting the line into several lines so it were more readable. But it's automatically generated code which you're not supposed to read anyway. If you were to read that, one should refer to the code generator instead.

[Lonami]

Is there any particular reason why the .to_bytes(self) function should be readable at all? It just needs to do one job, serialize an automatically generated object to bytes. Nothing else. People isn't meant to read that, as I said, they should refer to the code generator instead.

If you have any good argument, please let me know, and if it convinces me, I will change it.

[chstem]

Thanks, the fix works fine.

Since you asked for it, here are some arguments:

1. Trying to understand the code by back tracing the function calls, you will naturally arrive at the generated code, possibly before realizing that it is auto generated. You just might not know yet, that you are supposed to look into the code generator.

2. When you want to understand the code generator, it will be helpful to understand the generated code first.

3. I don't know what the general consent on this is, but I think auto generated code is still code. Hence I would apply the same code style guidelines to it. That is, unless you would have to make large trade offs in the code generator simplicity.

And one counter argument (but I think point 3. outweighs this):

4. This specific function is quite low level, and you can understand what it does very well from its name. You don't need to understand how it works, unless you are interested in the details of how the Telegram API encodes and transmits its objects/data.

[Lonami]

My counter-counter arguments:

1. If the generator has done its job right, you should never arrive to said function, as its an intermediate step and execution doesn't continue from its inside.
2. There's not much to understand from the generated code anyway. A quick look over the generator tells you endianness is 'little', strings are UTF-8 encoded, and how to serialize bytes is (as of now) on the TLObject itself (which is readable). Though I agree flags may be confusing, but if you're writing a new implementation as I advice on the wiki, start with v0.1, since is the minimal working example.
3. Code that, if you were to modify, the work would get lost anyway. Modifying autogenerated code is done on the generator itself. But yes, it looks nicer when it's pretty.
4. Agree :P

[chstem]

I don't get what you are trying to say with points 1 and 3. Can you try to be more clear on those?

[Lonami]

If the generator doesn't generate invalid code, then it will never crash there. And since the program flow is something like:

# stuff
data = request.to_bytes()
# stuff with data and further calls

Your stacktrace won't be inside the .to_bytes().

As for my third point, I mean that if you modify the code that was automatically generated, your work will get lost once it gets generated again.

[chstem]

Ok, I think you miss understood me in my points 1 and 3.

In point 1, by back tracing I mean: looking at the code and follow its functions to understand how it works. I was not talking about the traceback!

And about point 3: Of course you are not editing the generated code. But you can build the generator in such a way it produces nice code. (That is why I mentioned, you should only do this if it does not make the generator code unreasonably more complicated.)

[Lonami]

Alright, either way I may just make it readable because it does help when you need to spot bugs there ;)

Thanks for your time!