@@ -62,7 +62,7 @@ the canvas John has author ?
6262the artist John has author ?
6363transforms Michael submitted John
6464documenting mpl Darren submitted John, Eric, Mike?
65- coding guide John in review Eric
65+ coding guide John complete Eric
6666and_much_more ? ? ?
6767=============================== ==================== =========== ===================
6868
@@ -136,105 +136,3 @@ minor things to close the book on this chapter:
136136
137137 - Done. It's pretty extensive, thanks to STIX... - MGD
138138
139- coding guide (reviewed by EF)
140- -----------------------------
141-
142- Mostly fine (see :ref: `coding-guide `), just a few comments.
143- Also, there are a couple of typos, but I would rather just edit those
144- directly in another pass (if you don't happen to find them) than
145- include them as formal review notes.
146-
147- #. DONE - Import recommendation for ma: given that the trunk is
148- requiring numpy 1.1, perhaps we should be consistent and
149- recommend the form::
150-
151- import numpy.ma as ma
152-
153- for use in the trunk.
154- A note about the difference between the two forms and the
155- history can stay in place, and the alternative form would
156- still be required for the maintenance branch, I presume.
157-
158- #. This is peripheral, but regarding the example::
159-
160- mpl.rcParams['xtick.major.pad'] = 6
161-
162- At least at the application level, I think we should move
163- towards using validation routinely when setting rcParams,
164- to reduce a source of hard-to-find bugs. I don't know to
165- what extent Darren's traits-based system takes care of
166- this, but if it does, that is a big point in its favor.
167- There are alternatives (e.g. building validation into the
168- rc() function and using that instead of setting the
169- dictionary entries directly), if necessary.
170-
171- Darren notes:
172-
173- Validation is actually built into RcParams. This was done
174- just prior to development of the traited config, validation is done using
175- the mechanisms developed in rcsetup. For example::
176-
177- >>> rcParams['a.b']=1
178- ---------------------------------------------------------------------------
179- KeyError Traceback (most recent call last)
180-
181- /home/darren/<ipython console> in <module>()
182-
183- /usr/lib64/python2.5/site-packages/matplotlib/__init__.pyc in __setitem__(self, key, val)
184- 555 except KeyError:
185- 556 raise KeyError('%s is not a valid rc parameter.\
186- --> 557 See rcParams.keys() for a list of valid parameters.'%key)
187- 558
188- 559
189-
190- KeyError: 'a.b is not a valid rc parameter.See rcParams.keys() for a list of valid parameters.'
191-
192- also::
193-
194- rcParams['text.usetex']=''
195- ---------------------------------------------------------------------------
196- ValueError Traceback (most recent call last)
197-
198- /home/darren/<ipython console> in <module>()
199-
200- /usr/lib64/python2.5/site-packages/matplotlib/__init__.pyc in __setitem__(self, key, val)
201- 551 instead.'% (key, alt))
202- 552 key = alt
203- --> 553 cval = self.validate[key](val)
204- 554 dict.__setitem__(self, key, cval)
205- 555 except KeyError:
206-
207- /usr/lib64/python2.5/site-packages/matplotlib/rcsetup.pyc in validate_bool(b)
208- 56 elif b in ('f', 'n', 'no', 'off', 'false', '0', 0, False): return False
209- 57 else:
210- ---> 58 raise ValueError('Could not convert "%s" to boolean' % b)
211- 59
212- 60 def validate_bool_maybe_none(b):
213-
214- ValueError: Could not convert "" to boolean
215-
216-
217-
218- #. DONE - You give the example::
219-
220- import matplotlib.cbook as cbook
221-
222- Should there also be a list of the standard variants like
223- ``mtransforms``? (And, again peripherally, I would
224- shorten that one to ``mtrans``.)
225-
226- #. DONE - The treatment of whitespace is split into two parts
227- separated by paragraphs on docstrings and line length;
228- this can be consolidated. It might be worth mentioning
229- the ``reindent.py `` and ``tabnanny.py `` utilities here.
230-
231- #. DONE - (removed first person usage) - Minor question of literary
232- style: should use of the first person be avoided in most places?
233- It is used, for example, in the discussion of the automatic kwarg
234- doc generation. I don't mind leaving the first person in, with the
235- general understanding that it means you.
236-
237- #. DONE - Licenses: you might want to add a link to your
238- explanation of your BSD choice. Peripheral question: is
239- there any problem with basemap's inclusion of
240- sub-packages with the gamut of licenses, GPL to MIT?
0 commit comments