Adal Chiriliuc a écrit :
On Jan 7, 10:15 pm, Bruno Desthuilliers
<bdesth.quelquech...@free.quelquepart.fr> wrote:
This being said, I can only concur with other posters here about the
very poor naming. As far as I'm concerned, I'd either keep the argument
as a boolean but rename it "ascending" (and use a default True value),
or keep the 'order' name but then accept 'asc' and 'desc' as values
('asc' being the default).
Well, I lied a bit :-p
The actual function is 20 lines long, and does other stuff to. The
"order" argument is not passed as an argument, but as a field on an
input object.
Then the input object should probably be responsible for validating this
(IMHO).
(snip)
You are all right, "order" is a bad name choice. "sort_ascending"
would be a much better name for a boolean variable.
I found Paul's idea very interesting, but I prefer to not introduce
new objects which behave like C enums (maybe that would be more
Pythonic?), so I found this variant:
def find(field, sort_ascending):
....order_by = {True: "asc", False: "desc"}
....return _find(field + "+" + order_by[sort_ascending])
for a simple True/False dispatch, my usual idiom (predating the ternary
operator) is:
order_by = ("desc", "asc")[sort_ascending]
But what if we can't solve it as ellegantly, and we need to execute
different code depending on the condition:
def find(field, fast_mode=True):
....if fast_mode:
........do_something(field, 1, DEFAULT_PAGE_SIZE)
....else:
........do_another_thing(field, False, "xml", ignore_error=False)
........and_another_one()
Should we typecheck in this case to ensure that if we pass a string
for "fast_mode" we will raise an exception?
I don't think so. Going that way, you will end up typechecking each and
any function argument. While there are a couple typechecks here and
there even in the stdlib and builtins, this doesn't mean it's how Python
is supposed to be used - Python is a dynamic language, leave with it or
choose another one !-)
But anyway, ensuring a program's correctness requires much more than
static typing. What you want IMHO is:
1/ a solid *user input* validation/conversion framework (FormEncode
comes to mind)
2/ a sensible set of unittests and integration tests.
Trying to forcefit static typing into Python will only buy you pain and
frustration (not even talking about the waste of time).
--
http://mail.python.org/mailman/listinfo/python-list
