[Python-ideas] What about allowing '?' in method names?
dreamingforward at gmail.com
Fri Aug 14 03:04:16 CEST 2009
> 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)
I know for myself, it would help me mentally organize all the
different methods within classes. To me its the sort of syntactical
convention similar to using  brackets to set off a conceptual item
as opposed to using parens and making a standard, more generic
function call. Or like the elation of when the user finally gets the
point of whitespace and case conventions in python -- they've just
improved conceptual separation (and thus readability, maintainability)
by several-fold by simply agreeing to a widely-applicable convention.
The argument "Really, blah blah how difficult is it to just use is_ ?"
To me it goes along with what's been learned with independant
component analysis (ICA)--elongate the distance between
information-independant items while minimizing the effort to keep
related information grouped together. (ICA is the same tech that
allows one to separate conversations at a cocktail party.) This
pretty much encapsulates the evolution of programming languages.
\> 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__']]
> raise TypeError("Expected a module, string, or None")
Note that any example on existing code will only be partially useful
as the names chosen were chosen before an option that provided greater
conceptual separation was available.
> 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?`.
That would be redundant.
In any case, I would take this suggestion for an additional convention
even further by suggesting that methods which have side effects or
mutate the object (list.sorted) should have an exclaimation point,
getting rid of ambiguous usages like list.sort and list.sorted which
are counter-intuitive--keep list.sort! for an in-place, mutating
method name, for example, and list.sort to return a sorted list.
More information about the Python-ideas