[Python-ideas] What about allowing '?' in method names?
steve at pearwood.info
Wed Aug 12 02:21:19 CEST 2009
On Wed, 12 Aug 2009 05:56:24 am Masklinn wrote:
> >> I'd heard the Python community
> >> was pretty big on smart conventions but I might be wrong.
And would accepting or rejecting this proposal prove that we're big on
> > But what is the advantage of "?" to "is_" then?
> I think it's easier to spot due to 1. being a fairly rare character
> in programs (in languages where the ?: ternary doesn't exist anyway)
It's certainly rare in Python, because it's illegal (except in strings
and comments). It won't be rare if this convention is allowed.
> and 2. being at the end of the call (though on Python method the ()
> operator makes that much less interesting, if you aren't using a
A thought experiment -- what if this convention had been in place in
Python? Here is literally the first piece of code I looked at from
doctest.py with a Yes/No test in it:
def _normalize_module(module, depth=2):
elif instance?(module, (str, unicode)):
return __import__(module, globals(), locals(), ["*"])
elif module is None:
raise TypeError("Expected a module, string, or None")
Notice the inconsistency -- method and function calls which return a
bool have a question mark, but operators do not. I hope you're not
going to suggest changing `is` to `is?`.
But in any case, I don't think instance?() is any more readable than
isinstance(), or module?() than ismodule(). Perhaps one advantage is
that you can run your spell checker over your code with fewer false
Deeper in doctest.py:
def _failure_header(self, test, example):
out = [self.DIVIDER]
if test.lineno is not None and example.lineno is not None:
lineno = test.lineno + example.lineno + 1
Allowing ? in identifiers won't change this method, but it illustrates
another characteristic of Python (and Pythonic) code: the distinction
between Yes/No booleans and Everything Else simply isn't that
important. There's a method with two tests, one (the inner) is a
conventional True or False test, but the other (the outer) is a
Something or Nothing style test.
For example, str.startswith(prefix) and str.endswith(suffix) could be
modified to return the prefix/suffix found, or the empty string, and
virtually all code using them should continue to work correctly. The
exceptions being code that did something like this:
if "a string".startswith("a") is True:
but in my opinion, code that bad deserves to be broken.
Elevating functions that return a Yes/No answer over other functions
with extra punctuation is an unnecessary, and dare I say, un-pythonic,
> is_ is less easy to spot as it's a pretty unremarkable sequence of
> characters and at the middle of the call/line.
The same argument could be made for len, str, dict, or any other word.
You can't expect to understand code without reading the words. Adding
another punctuation character identifiers isn't going to change that.
More information about the Python-ideas