I agree 100%.
foo[True] should NOT be allowed.

The argument was that the following translations look ugly. I find the first one to be MUCH clearer.

foo[bool(x)] => foo[1 if x else 0]
foo[x==3] => foo[1 if x==3 else 0]
foo[bool(x)] => foo[int(bool(x))]

The first two are explicit, easy to read, and very clear on the meaning. None are overly verbose.
These uses are easily converted by the upgrade tool under development. Unfortunately other bool=>int coercions are not easy to detect and are neigh impossible to automatically upgrade.
Doug Napoleone | Homepage | 07/03/23 - 3:56 pm | #

Why not use the time module to do your dirty work for you? Why write a regex for what's already been done?

In [1]: import time

In [2]: time.strftime?
Type: builtin_function_or_method
Base Class:
String Form:
Namespace: Interactive
Docstring:
strftime(format[, tuple]) -> string

Convert a time tuple to a string according to a format specification.
See the library reference manual for formatting codes. When the time tuple
is not present, current time as returned by localtime() is used.


In [3]: time.strptime?
Type: builtin_function_or_method
Base Class:
String Form:
Namespace: Interactive
Docstring:
strptime(string, format) -> struct_time

Parse a string to a time tuple according to a format specification.
See the library reference manual for formatting codes (same as strftime()).


In [4]: t = "12/23/07"

In [5]: time.strptime(t, "%d/%m/%y")
-------------------------------------------------- -------------------------
exceptions.ValueError Traceback (most recent call
last)

c: snarfsnarf.rootAPPLICATIONSecondSortSortStation_IN STALL


c:Python24lib_strptime.py in strptime(data_string, format)
291 found = format_regex.match(data_string)
292 if not found:
--> 293 raise ValueError("time data did not match format: data=%s fmt=
%s" %
294 (data_string, format))
295 if len(data_string) != found.end():

ValueError: time data did not match format: data=12/23/07 fmt=%d/%m/%y

In [6]: time.strptime(t, "%m/%d/%y")
Out[6]: (2007, 12, 23, 0, 0, 0, 6, 357, -1)
Bill Mill | Homepage | 07/03/23 - 4:38 pm | #

"""We could always make the int constructor do the right thing when passed a boolean so that someList[someBool] could always be rewritten someList[int(someBool)]."""

It does do the right thing: int(True) -> 1, int(False) -> 0. There are only two boolean values. If you want to be sure a value is converted to a boolean, just be explicit: int(bool(val)).
David Goodger | Homepage | 07/03/23 - 5:16 pm | #

Do you know about dateutil? It's very useful to handle dates in various formats (event partial ones): http://labix.org/python-dateutil
Lawrence Oluyede | Homepage | 07/03/24 - 12:19 am | #

For dates we actually use the .NET DateTime class. We wanted a simple filter to recognise likely dates before delegating to DateTime, and as are such regularly formed strings, regular expressions seemed like a natural fit.
Fuzzyman | Homepage | 07/03/24 - 12:27 am | #

Oh and David - I know that int currently 'does the right thing' for bools. I was suggesting that even if we change bool to *not* inherit from int, we could maintain that behaviour.
Fuzzyman | Homepage | 07/03/24 - 12:28 am | #

Oh - for DateTimes in .Net I use DateTime.Parse and just catch an exception if it's poorly formatted. Not efficient, I know, but it works well enough.
Bill Mill | Homepage | 07/03/24 - 4:05 am | #

That problem with the space inside {m,n} seems pretty unfortunate. I would think that the regex compiler should raise an exception, like when you put in unbalanced parentheses. This would require curly brackets to be backslash escaped, which seems like a good thing.
Mike Beachy | 07/03/30 - 6:57 pm | #