replace boolean methods on builtin types with properties [py4k?]
The number of times I've seen code written that reads well and passes less trained code reviews easily such as: if check_num and mystring and mystring.isdigit: ... has increased beyond what I can count on one hand. The code executes and even does the right thing part of the time. Proposal: any method that returns a boolean on builtins like bytes and unicode objects be turned into a property in a future python version. That way the above mistake would happen less often. mystring.isdigit would be a boolean rather than a method reference that is always True. There are many ways of detecting the above beyond code review such as making a pylink or pychecker type thing flag them, having proper unittest coverage that tests both conditions, etc. But those are not always in place. A hack could be done today to have these behave as both functions and properties by having the property return a callable bool derived class that returns itself. But that seems a bit too cool yet gross... -gps
Gregory P. Smith wrote:
You can simplify that code by writing: if check_num and mystring.isdigit(): ... since ''.isdigit() correctly returns False. Being simpler, there's less to read and it is less likely for the reader to miss any errors.
Proposal: any method that returns a boolean on builtins like bytes and unicode objects be turned into a property in a future python version.
Why limit this to booleans? Similar errors could apply to any function or method that takes no explicit arguments.
That way the above mistake would happen less often.
Making it more difficult and error prone and slower to do things like: if all(str.isdigit, list_of_strings): ... or similar. -0 on the idea. -- Steven
On Mon, Dec 13, 2010 at 1:57 PM, Steven D'Aprano <steve@pearwood.info> wrote:
Technical note: all only takes an iterable. Its signature is not like map's. The correct way to write that is if all(s.isdigit() for s in list_of_strings) (minus the calling parentheses if this proposal were accepted).
On Tue, Dec 14, 2010 at 10:08 AM, Carl M. Johnson < cmjohnson.mailinglist@gmail.com> wrote:
It's a typo. Given the point he was making, Steven presumably meant the call to be "all(map(str.isdigit, list_of_strings))". Cheers, Nick. -- Nick Coghlan | ncoghlan@gmail.com | Brisbane, Australia
Carl M. Johnson wrote:
Oops! Of course you're right. This is what happens when you test the concept with filter, then change it at the last second to something that would be more commonly used than filter :( -- Steven
1. Masklinn dixit (2010-12-14, 12:31):
There are no unbound methods in Py3k, but pure function instead. That would make the issue even easier. There could be @callableproperty decorator for such cases. I'd +0 on such an idea. 2. Maybe better idea (if we want to avoid missed-parenthesis-mistakes) would be to raise an error when trying to test such functions/methods for truth. I could be achieved with a subclass of function type with __bool__() method raising TypeError or NotImplementedError. Cheers, *j
On 13 December 2010 22:35, Gregory P. Smith <greg@krypto.org> wrote:
bool derived class... good luck with that. :-) Michael
On Mon, Dec 13, 2010 at 5:35 PM, Gregory P. Smith <greg@krypto.org> wrote:
Missing parens is only one of the issues with the above code. If you rely on the above check to make sure that mystring will be accepted by str(), you should use isdecimal instead:
Proposal: any method that returns a boolean on builtins like bytes and unicode objects be turned into a property
-1 These methods invoke fairly non-trivial calculations that are not appropriate for properties. However, the situation can be improved if methods and functions would stop supporting implicit conversion to bool. In my experience, checking the bool value of a method or function is either an outright mistake or can be appropriately replaced with an is not None check. This would have to wait for py4k, though. In py3k we have enough trouble with None becoming unorderable to introduce yet another breakage.
Gregory P. Smith wrote:
You can simplify that code by writing: if check_num and mystring.isdigit(): ... since ''.isdigit() correctly returns False. Being simpler, there's less to read and it is less likely for the reader to miss any errors.
Proposal: any method that returns a boolean on builtins like bytes and unicode objects be turned into a property in a future python version.
Why limit this to booleans? Similar errors could apply to any function or method that takes no explicit arguments.
That way the above mistake would happen less often.
Making it more difficult and error prone and slower to do things like: if all(str.isdigit, list_of_strings): ... or similar. -0 on the idea. -- Steven
On Mon, Dec 13, 2010 at 1:57 PM, Steven D'Aprano <steve@pearwood.info> wrote:
Technical note: all only takes an iterable. Its signature is not like map's. The correct way to write that is if all(s.isdigit() for s in list_of_strings) (minus the calling parentheses if this proposal were accepted).
On Tue, Dec 14, 2010 at 10:08 AM, Carl M. Johnson < cmjohnson.mailinglist@gmail.com> wrote:
It's a typo. Given the point he was making, Steven presumably meant the call to be "all(map(str.isdigit, list_of_strings))". Cheers, Nick. -- Nick Coghlan | ncoghlan@gmail.com | Brisbane, Australia
Carl M. Johnson wrote:
Oops! Of course you're right. This is what happens when you test the concept with filter, then change it at the last second to something that would be more commonly used than filter :( -- Steven
1. Masklinn dixit (2010-12-14, 12:31):
There are no unbound methods in Py3k, but pure function instead. That would make the issue even easier. There could be @callableproperty decorator for such cases. I'd +0 on such an idea. 2. Maybe better idea (if we want to avoid missed-parenthesis-mistakes) would be to raise an error when trying to test such functions/methods for truth. I could be achieved with a subclass of function type with __bool__() method raising TypeError or NotImplementedError. Cheers, *j
On 13 December 2010 22:35, Gregory P. Smith <greg@krypto.org> wrote:
bool derived class... good luck with that. :-) Michael
On Mon, Dec 13, 2010 at 5:35 PM, Gregory P. Smith <greg@krypto.org> wrote:
Missing parens is only one of the issues with the above code. If you rely on the above check to make sure that mystring will be accepted by str(), you should use isdecimal instead:
Proposal: any method that returns a boolean on builtins like bytes and unicode objects be turned into a property
-1 These methods invoke fairly non-trivial calculations that are not appropriate for properties. However, the situation can be improved if methods and functions would stop supporting implicit conversion to bool. In my experience, checking the bool value of a method or function is either an outright mistake or can be appropriately replaced with an is not None check. This would have to wait for py4k, though. In py3k we have enough trouble with None becoming unorderable to introduce yet another breakage.
participants (8)
-
Alexander Belopolsky -
Carl M. Johnson -
Gregory P. Smith -
Jan Kaliszewski -
Masklinn -
Michael Foord -
Nick Coghlan -
Steven D'Aprano