[Python-ideas] What about allowing '?' in method names?

[Steven D'Aprano]

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 
smart conventions?


> > 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
> property).

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):
    if inspect.module?(module):
        return module
    elif instance?(module, (str, unicode)):
        return __import__(module, globals(), locals(), ["*"])
    elif module is None:
        return sys.modules[sys._getframe(depth).f_globals['__name__']]
    else:
        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 
negatives.


Deeper in doctest.py:

    def _failure_header(self, test, example):
        out = [self.DIVIDER]
        if test.filename:
            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, 
distinction.


> 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.



-- 
Steven D'Aprano