[Python-ideas] 'Injecting' objects as function-local constants

Nick Coghlan ncoghlan at gmail.com
Tue Jun 14 12:31:41 CEST 2011


On Tue, Jun 14, 2011 at 12:33 AM, Steven D'Aprano <steve at pearwood.info> wrote:
> Nick Coghlan wrote:
>>
>> On Mon, Jun 13, 2011 at 5:11 PM, Steven D'Aprano <steve at pearwood.info>
>> wrote:
>>>
>>> Function parameters should be kept for actual arguments, not for
>>> optimizing
>>> name look-ups.
>>
>> Still, the post-** shared state (Jan's option 2) is likely the most
>> obvious way to get early binding for *any* purpose without polluting
>> the externally visible parameter list.
>
> I wouldn't call adding even more complexity to function signatures
> "obvious", although I grant that it depends on whether you're Dutch :)
>
> Another disadvantage is that it uses a symbol instead of a word. Too many
> symbols, and your code looks like Perl (or APL). It's hard to google for **
> to find out what it means. It's harder to talk about a symbol than a word.
> (In written text you can just write ** but in speech you have to use
> circumlocutions or made-up names like double-splat.)

As with *, ** and @, you don't search for them directly, you search
for "def" (although redirects from the multiplication and power docs
to the def statement docs may not be the worst idea ever).

If we hadn't already added keyword-only arguments in Python 3, I'd
consider this significantly more obscure. Having the function
signature progress from "positional-or-keyword arguments" to
"keyword-only arguments" to "implicit arguments", on the other hand,
seems a lot cleaner than the status quo without being significantly
more complicated. After all, there's no new symbols involved - merely
a modification to allow a bare "**" to delimit the start of the
implicit arguments when arbitrary keyword arguments are not accepted.

Who knows, maybe explicitly teaching that behaviour would make people
less likely to fall into the default argument trap.

Cheers,
Nick.

-- 
Nick Coghlan   |   ncoghlan at gmail.com   |   Brisbane, Australia



More information about the Python-ideas mailing list