Skip to main content
deleted 762 characters in body
Source Link
Demian Brecht
  • 17.6k
  • 1
  • 48
  • 81

If you're breaking things up visually using whitespace, that would scream[snip due to me that you should be using a more obvious method:

>>> class AcceleratorTable(object):
...     @property
...     def file(self):
...             return [('a', 'b'), ('c', 'd')]
...     @property
...     def project(self):
...             return [('e', 'f'), ('g', 'h')]
... 
>>> t = AcceleratorTable()
>>> t.file + t.project
[('a', 'b'), ('c', 'd'), ('e', 'f'), ('g', 'h')]

Now you'repeople not asking questions about whitespacereading the and you've increased readability. While yes, there's slightly more overhead due to function lookups, this isn't something that needs a ridiculous level of optimization. In my mind, this would be a much more Pythonic solution than what you currently have./entire/ response]

To answer your actual question, whitespace is fine to break things up visually, but I'd recommend that the number of lines that you use should not exceed that of the number of lines between other entities in your code (such as number of lines between functions within a class, or module-level classes or functions). As Python's readability is so heavily based on whitespace, using more whitespace in a particular method to break up internal code might initially throw off a reader looking to grok it at a glance.

Edit based on comments:

>>> accel_file = [('a','b'), ('c', 'd')]
>>> accel_project = [('e', 'f'), ('g', 'h')]
>>> 
>>> from itertools import chain
>>> list(chain(accel_file, accel_project))
[('a', 'b'), ('c', 'd'), ('e', 'f'), ('g', 'h')]

Grouping as such allows your code to be self-documenting. chain is an overly complex solution in this particular case (I was writing code using at the time of the answer :P), but could be useful if doing something like:

accelerators = [accel_file, acces_project, ...]
list(chain(*accelerators))

But for the simple case, concatenation (+) would be preferred.

If you're breaking things up visually using whitespace, that would scream to me that you should be using a more obvious method:

>>> class AcceleratorTable(object):
...     @property
...     def file(self):
...             return [('a', 'b'), ('c', 'd')]
...     @property
...     def project(self):
...             return [('e', 'f'), ('g', 'h')]
... 
>>> t = AcceleratorTable()
>>> t.file + t.project
[('a', 'b'), ('c', 'd'), ('e', 'f'), ('g', 'h')]

Now you're not asking questions about whitespace and you've increased readability. While yes, there's slightly more overhead due to function lookups, this isn't something that needs a ridiculous level of optimization. In my mind, this would be a much more Pythonic solution than what you currently have.

To answer your actual question, whitespace is fine to break things up visually, but I'd recommend that the number of lines that you use should not exceed that of the number of lines between other entities in your code (such as number of lines between functions within a class, or module-level classes or functions). As Python's readability is so heavily based on whitespace, using more whitespace in a particular method to break up internal code might initially throw off a reader looking to grok it at a glance.

Edit based on comments:

>>> accel_file = [('a','b'), ('c', 'd')]
>>> accel_project = [('e', 'f'), ('g', 'h')]
>>> 
>>> from itertools import chain
>>> list(chain(accel_file, accel_project))
[('a', 'b'), ('c', 'd'), ('e', 'f'), ('g', 'h')]

[snip due to people not reading the /entire/ response]

To answer your actual question, whitespace is fine to break things up visually, but I'd recommend that the number of lines that you use should not exceed that of the number of lines between other entities in your code (such as number of lines between functions within a class, or module-level classes or functions). As Python's readability is so heavily based on whitespace, using more whitespace in a particular method to break up internal code might initially throw off a reader looking to grok it at a glance.

Edit based on comments:

>>> accel_file = [('a','b'), ('c', 'd')]
>>> accel_project = [('e', 'f'), ('g', 'h')]
>>> 
>>> from itertools import chain
>>> list(chain(accel_file, accel_project))
[('a', 'b'), ('c', 'd'), ('e', 'f'), ('g', 'h')]

Grouping as such allows your code to be self-documenting. chain is an overly complex solution in this particular case (I was writing code using at the time of the answer :P), but could be useful if doing something like:

accelerators = [accel_file, acces_project, ...]
list(chain(*accelerators))

But for the simple case, concatenation (+) would be preferred.

added 278 characters in body
Source Link
Demian Brecht
  • 17.6k
  • 1
  • 48
  • 81

If you're breaking things up visually using whitespace, that would scream to me that you should be using a more obvious method:

>>> class AcceleratorTable(object):
...     @property
...     def file(self):
...             return [('a', 'b'), ('c', 'd')]
...     @property
...     def project(self):
...             return [('e', 'f'), ('g', 'h')]
... 
>>> t = AcceleratorTable()
>>> t.file + t.project
[('a', 'b'), ('c', 'd'), ('e', 'f'), ('g', 'h')]

Now you're not asking questions about whitespace and you've increased readability. While yes, there's slightly more overhead due to function lookups, this isn't something that needs a ridiculous level of optimization. In my mind, this would be a much more Pythonic solution than what you currently have.

To answer your actual question, whitespace is fine to break things up visually, but I'd recommend that the number of lines that you use should not exceed that of the number of lines between other entities in your code (such as number of lines between functions within a class, or module-level classes or functions). As Python's readability is so heavily based on whitespace, using more whitespace in a particular method to break up internal code might initially throw off a reader looking to grok it at a glance.

Edit based on comments:

>>> accel_file = [('a','b'), ('c', 'd')]
>>> accel_project = [('e', 'f'), ('g', 'h')]
>>> 
>>> from itertools import chain
>>> list(chain(accel_file, accel_project))
[('a', 'b'), ('c', 'd'), ('e', 'f'), ('g', 'h')]

If you're breaking things up visually using whitespace, that would scream to me that you should be using a more obvious method:

>>> class AcceleratorTable(object):
...     @property
...     def file(self):
...             return [('a', 'b'), ('c', 'd')]
...     @property
...     def project(self):
...             return [('e', 'f'), ('g', 'h')]
... 
>>> t = AcceleratorTable()
>>> t.file + t.project
[('a', 'b'), ('c', 'd'), ('e', 'f'), ('g', 'h')]

Now you're not asking questions about whitespace and you've increased readability. While yes, there's slightly more overhead due to function lookups, this isn't something that needs a ridiculous level of optimization. In my mind, this would be a much more Pythonic solution than what you currently have.

To answer your actual question, whitespace is fine to break things up visually, but I'd recommend that the number of lines that you use should not exceed that of the number of lines between other entities in your code (such as number of lines between functions within a class, or module-level classes or functions). As Python's readability is so heavily based on whitespace, using more whitespace in a particular method to break up internal code might initially throw off a reader looking to grok it at a glance.

If you're breaking things up visually using whitespace, that would scream to me that you should be using a more obvious method:

>>> class AcceleratorTable(object):
...     @property
...     def file(self):
...             return [('a', 'b'), ('c', 'd')]
...     @property
...     def project(self):
...             return [('e', 'f'), ('g', 'h')]
... 
>>> t = AcceleratorTable()
>>> t.file + t.project
[('a', 'b'), ('c', 'd'), ('e', 'f'), ('g', 'h')]

Now you're not asking questions about whitespace and you've increased readability. While yes, there's slightly more overhead due to function lookups, this isn't something that needs a ridiculous level of optimization. In my mind, this would be a much more Pythonic solution than what you currently have.

To answer your actual question, whitespace is fine to break things up visually, but I'd recommend that the number of lines that you use should not exceed that of the number of lines between other entities in your code (such as number of lines between functions within a class, or module-level classes or functions). As Python's readability is so heavily based on whitespace, using more whitespace in a particular method to break up internal code might initially throw off a reader looking to grok it at a glance.

Edit based on comments:

>>> accel_file = [('a','b'), ('c', 'd')]
>>> accel_project = [('e', 'f'), ('g', 'h')]
>>> 
>>> from itertools import chain
>>> list(chain(accel_file, accel_project))
[('a', 'b'), ('c', 'd'), ('e', 'f'), ('g', 'h')]
Source Link
Demian Brecht
  • 17.6k
  • 1
  • 48
  • 81

If you're breaking things up visually using whitespace, that would scream to me that you should be using a more obvious method:

>>> class AcceleratorTable(object):
...     @property
...     def file(self):
...             return [('a', 'b'), ('c', 'd')]
...     @property
...     def project(self):
...             return [('e', 'f'), ('g', 'h')]
... 
>>> t = AcceleratorTable()
>>> t.file + t.project
[('a', 'b'), ('c', 'd'), ('e', 'f'), ('g', 'h')]

Now you're not asking questions about whitespace and you've increased readability. While yes, there's slightly more overhead due to function lookups, this isn't something that needs a ridiculous level of optimization. In my mind, this would be a much more Pythonic solution than what you currently have.

To answer your actual question, whitespace is fine to break things up visually, but I'd recommend that the number of lines that you use should not exceed that of the number of lines between other entities in your code (such as number of lines between functions within a class, or module-level classes or functions). As Python's readability is so heavily based on whitespace, using more whitespace in a particular method to break up internal code might initially throw off a reader looking to grok it at a glance.