Imports Style Guide

Wonderful PEP8, which you probably know if you are developing in Python, does not answer all the questions that arise during the coding process. As a result, each development team takes PEP8 as a basis and develops its own standards, which it tries to adhere to. How many teams - so many options. And this is the necessary artificial frame. As a grid for a typographer or layout designer - helps the code look clear, consistent and consistent. In general, code formatting is not the place where you need to show your individuality.

Before asking the main question, dear colleagues, I would like to show some examples of “liberties” that everyone takes for himself (or without a murmur makes some other people's decision).

""" Very long multiline description about function or class method """ 

I personally like more than

 """Very long multiline description about function or class method """ 

')
The distance between the import block and the first function or class is 2 blank lines.

 from unittest import TestCase class BaseURLGeneratorTestCase(TestCase): pass 

The distance between different functions or classes is also 2 blank lines. The distance between class methods is 1 blank line. The distance between the class header and the first method is 1 blank line.

 class TestSomething(TestCase): def test_some_stuff(self): pass def test_another_stuff(self): pass 

Enumeration of the elements of a list / tuple / dictionary, etc. - from each new line, if everything does not fit into one:

 records = [first_object, second_object] records = [ first_object, second_object, third_object, fourth_object, ] 

The same applies to the long logical condition:

 if ( user.is_client() and user.has_manager() and not user.is_banned() and user.has_company() ): do_something() 

If there is a need to break the chain of methods into several lines, the expression is enclosed in brackets. No backslashes (fu-fu-fu).

 templates = ( EmailTemplate.query .filter(EmailTemplate.type_id == type.id) .order_by(EmailTemplate.title) .all() ) 

A tuple of one element is written as x = (y,) or x = y, but it looks awful, so I prefer in this case to manage the list with x = [y] or the set x = {y} , there are other options.

Check for None:

 x = None if x: do_something() #  if x is not None: do_something() # -  

By the way, comments are beaten with two spaces, not just one.

Among other things, I love the string method .format (). '{0}'.format(x) is more to my liking than '%s' % x . But when the insertion points are more than two, you should use named arguments:

 '{name} {surname}, {address}'.format( name=name, surname=surname, address=address, ) 

Implicit string concatenation looks strange, but visually more pleasant concatenation by addition:

 message = _( u"    +, " u"     ?" ) 

The dictionary is written as {'key': value, 'another_key': another_value} , and not as dict(key=value, another_key=another_value) . This is visually cleaner, highlighted by all normal editors as a dictionary, and not as passing named arguments, moreover, the creation of such an object works faster than through dict ().

There are more than a dozen of such “faddies” and I am sure that there will be people ready to challenge them and offer their own vision of kosher code design. But if by the given examples everything is more or less clear to me, then by design of large (really large) blocks of imports, not everything is clear yet.

I met, somehow, in a working draft, a purse of imports in one of the modules.

 ... from lib.util import https_wrapper, logout_user from lib.util import ajax, sudo_su, sudo_exit, transactional from lib.util import has_auth, get_demo from lib.util import get_user_registration_source_id from lib.util import ajax_validate, generate_timed_hash, get_auth_user from lib.util import render_template, check_timed_hash from lib.util import create_validate_response, update_user_in_session from lib.util import prepare_watermark_text ... 

I thought to myself: “What the fuck? ..” and rewrote as I like.

 from lib.util import ( https_wrapper, logout_user, ajax, sudo_su, sudo_exit, transactional, has_auth, get_demo, ) 

Well, you understand the principle ...

For what otgreb during review. As if the previous version also has the right to life, it is convenient during the time of the year and it seems to be more convenient to read. I promised to argue my version and just give a link to this post, at the same time and find out what the habrovcians think about it.

So. The idea of ​​“every object from a new line” is important. Firstly, it is beautiful :) Secondly, during the period of the merge it gives its advantages, there is no confusion. This is a useful property, we need to save it.

In the second variant, the module (or package) from which we import is as if the title of the next paragraph of the text (the imported objects). There is no need to repeat the title each time, we have already seen once from where we import and we have a line-by-line listing of what we import. If someone needs to add a list of imports from this source, he simply goes to the end of the list, presses Enter and appends his own (+ comma, with the thought of the neighbor). It looks cleaner, the lines are shorter, read faster, you do not need to add / copy-paste each time a source, which, by the way, can be renamed. It is not necessary to ignore the part from bla_bla_bla import for each line. Eyes glide 4 spaces much easier.

In general, there are lots of options for processing a block with imports. A dozen, no less. How exactly to break lines, by what criteria, whether to sort alphabetically, to transfer or not the opening / closing bracket ... But to some common denominator you need to come, the whole team of developers must adhere to the accepted agreement. Otherwise anarchy. I know people who do not bother at all on this matter, since PyCharm has a wonderful auto import and there is a point of view that it doesn’t matter what happens in this block. But we have a large team, only I use PyCharm (most are on Sublime, the rest are Vim, Emacs, Eclipse), you need to make sure that everything is comfortable and understandable. Well, from my point of view, imports are also a code that looks good. Maintainability, after all. What do you think?

So the poll.