Just a quick survey to find out what's the consensus about what (if
anything) should be done for multiples-of-four indentation.
(Full disclosure: I started to draft this mail during discussion with
Sergey, before he locked me out of the PR discussion. I'm finishing it
because I believe the results of the survey are going to be helpful for
whatever anybody is doing about indentation.)
1) Python has a PEP8 guideline that indents should be a multiple of four.
We do not currently enforce this in test_code_quality.
The consequence is that our codebase currently has two dozen spots where
you can find code that is definitely misindented, plus additional spots
with room for judgement calls.
Would it be desirable to have the guideline enforced?
(Remaining questions are irrelevant if the answer is "no".)
2) To what kinds of lines do we want the rule enforced?
If the answer to (1) was "yes", then it must be applied to executable,
non-continuation lines (the above-mentioned two dozen misindented lines).
2a) Should the rule be applied to continuation lines?
Typical case as found by me in the codebase:
a = self.fubar_the_worg(A, x) \
+ make_me_happy(x, y, z)
And this other category of continuation lines:
klaatu = self.barada_nikto(x, y, z,
a, b, c)
klaatu = self.barada_nikto(x, y, z,
a, b, c)
klaatu = self.barada_nikto(
x, y, z, a, b, c)
2b) Should the rule be applied to comment lines?
Typical situations in our code base:
blah() # Here we need to blah()
# to avoid frobnication
blub(a, x, d, w + x + y + z)
# w2 + x + y + z
3) If we want to handle continuation lines differently than normal
lines, the coding goes beyond what's easily doable in test_code_quality.
pep8.py already has this kind of code, though it is not yet 100% clear
whether it can be made to test everything exactly the way we want it tested.
If pep8.py can be made to do the tests in the way we want them done,
should we use it?
4) How do we want to handle external dependencies in general?
E.g. pep8.py is currently exhibiting a bug that makes it unsuitable for
our purposes (this is likely to get fixed in the near future). This is a
nice reminder that we need to nail any external dependencies down to a
specific version, and upgrade them only after verifying that the new
version does not exhibit any problems. We might even want to postpone
such an upgrade because we want to fix some deficit in SymPy's code first.
4a) Should we simply put a copy of the external dependency into SymPy?
This is what we've been doing for mpmath.
The downside is that we need to flag that code so that people know it's
external, and don't try to fix issues with it.
It might also conflict with other software people might want to run in
the same virtualenv as SymPy, i.e. people will be unable to upgrade or
downgrade to another version (which, of course, still risks breaking
SymPy, but having a dubious option might be better for the user than
having no option at all).
On the plus side, it's hassle-free for users and contributors.
4b) Should we require users to pip install the dependencies?
This makes the learning curve slightly steeper.
It also requires that the user be online when he finds he needs the
dependency, giving a frustrating early experience (which is bad but
fortunately won't happen to many).
4c) Installing dependencies through pip is not a hassle if SymPy itself
is installable through pip. Right now, SymPy is not prepared for that.
Should be go that route?
4d) Should the code that needs the dependency (sympy for mpmath,
test_code_quality for pep8.py) run pip install?
The downside is that being online is going to be reported as a
potentially confusing error message from the bowels of the system; also,
that it is more likely to happen for some dependencies (e.g. the missing
pep8.py could go unnoticed for quite a while until the user does his
first bin/test run).
The plus side is that for the usual case (all required web sites are up
and reachable), it is one installation step less that users need to do
before they work with (or on) SymPy.
Note that pip install can be made quite painless by providing a
dependency file. If users are supposed to install SymPy though pip
anyway, and old versions of a software package cannot ever vanish from
their download URLs, then this is easiest. (I think that the latter does
not hold in general, unfortunately.)
Sorry for presenting you with yet another wall of text, but I didn't
find a way to make this shorter.
Regards,
Jo
--
You received this message because you are subscribed to the Google Groups
"sympy" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
To post to this group, send email to [email protected].
Visit this group at http://groups.google.com/group/sympy.
To view this discussion on the web visit
https://groups.google.com/d/msgid/sympy/54A6592A.1080104%40durchholz.org.
For more options, visit https://groups.google.com/d/optout.
