From: Paul Prescod <paul@prescod.net>
> Guido van Rossum wrote:
> > So the constraint under which we're
> > operating is that bool values must be ints. This constraint has only
> > two possible solutions: (a) continue to use int as the type of choice
> > for bool results, and define builtins False = 0 and True = 1; or (b)
> > make bool a subtype of int.
>
> Agree 100%. The question is whether five years or ten years or twenty
> years from now booleans will still be a subtype of integers. We have
> deprecation techniques that allow us to start a transition to a world
> where logic and integer arithmetic are completely separate.
>
> > I do not want to say that in the future only bool is acceptable in a
> > Boolean context; it would remove too many of my favorite ways of
> > expression things clearly with few words.
>
> I agree with this too. The question is whether Python 3000 will still
> allow this without error:
>
> def foo(int_size, b_metric_unit):
> if b_metric_unit:
> return int_size * 10
>
> foo(false, 10)
>
But as long as in Python 3000:
if 0: ... and if 1: ... work
then someone can still hang himself calling it so:
foo(0,10)
Maybe it is just FUD, but the question
whether people will adopt the change
and apply it to old code is central.
That means it *should* be asked, then
you can answer FUD, but just then.
Personally I would write such a function as:
def foo(size,is_metric):
if is_metric:
return size*10
else:
...
and if I fear to mess up with order I would
call it with:
foo(10,is_metric=False)
or foo(10,is_metric=0)
If you're really serious about argument order
then you need static typing and that does not save
you always either.
regards, Samuele Pedroni.
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4