...eh, nevermind. I tried to do it and you need default_found and
focus_position and errors_found, so it doesn't seem like there's much
point.
The function is very clear and linear but I was hoping to make it
shorter by making some nice internal verbs. Maybe you have another
idea? Could be for later, or never. :-)
https://codereview.appspot.com/44750044/diff/1/quickstart/cli/views.py#newcode230
quickstart/cli/views.py:230: def use(env_data):
I wonder if the env_detail function would look less forbidding at first
glance if these internal functions were defined outside (_use,
_set_default, etc.) and then hooked up as partials. I think the verbs
are clear enough that it would read well.
A counter-argument is that you are defining everything locally, so you
can read what is going on inline, and it similar to what people are
accustomed to doing with OO. If env_detail were in its own file as is,
would it look super easy, because it would look similar to a class with
methods? I don't know.
https://codereview.appspot.com/44750044/diff/1/quickstart/tests/cli/test_forms.py#newcode1
quickstart/tests/cli/test_forms.py:1: # This file is part of the Juju
Quickstart Plugin, which lets users set up a
On 2014/01/02 15:05:32, benji1 wrote:
> These tests look really nice. The running comments in each test
really increase
> understanding of what is going on.
LGTM! Thank you!
https:/ /codereview. appspot. com/44750044/ diff/1/ quickstart/ cli/forms. py cli/forms. py (right):
File quickstart/
https:/ /codereview. appspot. com/44750044/ diff/1/ quickstart/ cli/forms. py#newcode44 cli/forms. py:44: def create_ string_ widget( field, value,
quickstart/
error):
Nice behavior/approach for the widget generation. I like it.
https:/ /codereview. appspot. com/44750044/ diff/1/ quickstart/ cli/forms. py#newcode82 cli/forms. py:82: if generate_method is not None:
quickstart/
For readability, I wonder if we ought to stick most of this block in a
separate function.
if generate_method is not None: append(
create_ generate_ widget( generate_ method, edit_widget))
widgets.
...or similar?
https:/ /codereview. appspot. com/44750044/ diff/1/ quickstart/ cli/forms. py#newcode98 cli/forms. py:98: # edit widget when a choice is clicked.
quickstart/
Hah, ok, cool, that's what I mentioned in my qa. :-)
https:/ /codereview. appspot. com/44750044/ diff/1/ quickstart/ cli/forms. py#newcode172 cli/forms. py:172: urwid.Text( ('error' , 'please correct the
quickstart/
errors below')),
Nice to have: a count. ("Please correct the 2 errors below")
https:/ /codereview. appspot. com/44750044/ diff/1/ quickstart/ cli/forms. py#newcode179 cli/forms. py:179: # Boolean values as represented as
quickstart/
checkboxes.
s/as/are/
Boolean values are represented a checkboxes
https:/ /codereview. appspot. com/44750044/ diff/1/ quickstart/ cli/forms. py#newcode195 cli/forms. py:195: return dict((key, value_getter()) for key,
quickstart/
value_getter in form.items())
Nice :-)
https:/ /codereview. appspot. com/44750044/ diff/1/ quickstart/ cli/views. py cli/views. py (right):
File quickstart/
https:/ /codereview. appspot. com/44750044/ diff/1/ quickstart/ cli/views. py#newcode168 cli/views. py:168: for position, env_data in environments) :
quickstart/
enumerate(
Just as a way to make the main function smaller, what would you think of
breaking this block out into its own function?
...eh, nevermind. I tried to do it and you need default_found and
focus_position and errors_found, so it doesn't seem like there's much
point.
The function is very clear and linear but I was hoping to make it
shorter by making some nice internal verbs. Maybe you have another
idea? Could be for later, or never. :-)
https:/ /codereview. appspot. com/44750044/ diff/1/ quickstart/ cli/views. py#newcode230 cli/views. py:230: def use(env_data):
quickstart/
I wonder if the env_detail function would look less forbidding at first
glance if these internal functions were defined outside (_use,
_set_default, etc.) and then hooked up as partials. I think the verbs
are clear enough that it would read well.
A counter-argument is that you are defining everything locally, so you
can read what is going on inline, and it similar to what people are
accustomed to doing with OO. If env_detail were in its own file as is,
would it look super easy, because it would look similar to a class with
methods? I don't know.
What do you think?
https:/ /codereview. appspot. com/44750044/ diff/1/ quickstart/ tests/cli/ test_forms. py tests/cli/ test_forms. py (right):
File quickstart/
https:/ /codereview. appspot. com/44750044/ diff/1/ quickstart/ tests/cli/ test_forms. py#newcode1 tests/cli/ test_forms. py:1: # This file is part of the Juju
quickstart/
Quickstart Plugin, which lets users set up a
On 2014/01/02 15:05:32, benji1 wrote:
> These tests look really nice. The running comments in each test
really increase
> understanding of what is going on.
+1 on both
https:/ /codereview. appspot. com/44750044/ diff/1/ quickstart/ tests/cli/ test_forms. py#newcode80 tests/cli/ test_forms. py:80: return (
quickstart/
Maybe use a dict or namedtuple instead? Shrug.
https:/ /codereview. appspot. com/44750044/ diff/1/ quickstart/ tests/cli/ test_forms. py#newcode91 tests/cli/ test_forms. py:91: wrapper, edit, caption, help,
quickstart/
error, generate, choices, default = (
That works too. :-)
https:/ /codereview. appspot. com/44750044/ diff/1/ quickstart/ tests/cli/ test_views. py tests/cli/ test_views. py (right):
File quickstart/
https:/ /codereview. appspot. com/44750044/ diff/1/ quickstart/ tests/cli/ test_views. py#newcode166 tests/cli/ test_views. py:166: 'quickstart. cli.views. env_detail' )
quickstart/
@mock.patch(
This sort of thing makes me think we ought to pass the needed env_*
around as arguments everywhere. :-)
https:/ /codereview. appspot. com/44750044/ diff/1/ quickstart/ tests/cli/ test_views. py#newcode200 tests/cli/ test_views. py:200: for env_type, button in -len(env_ types): ]):
quickstart/
zip(env_types, buttons[
nice
https:/ /codereview. appspot. com/44750044/