[Python-ideas] function defaults and an empty() builtin

[Eric Snow]

On Fri, May 20, 2011 at 1:53 PM, Bruce Leban <bruce at leapyear.org> wrote:

> On Fri, May 20, 2011 at 12:27 PM, Masklinn <masklinn at masklinn.net> wrote:
>
>>
>> Absolutely, but the mutation of the default parameters seems to be the
>> main
>> problem (historically): it's a memory leak, and it's a global data
>> corruption,
>> where modifying a provided parameter is a local data corruption (unless
>> the
>> object passed in is global of course).
>>
>>
> Agreed, but that wasn't how I interpreted Jack's question. I think there
> are two issues (with the first one the one that I think Jack was targeting):
>
> (1) I want to make sure a parameter is immutable so I don't accidentally
> change it (and none of the functions I call can do that). Akin to declaring
> a parameter const in C-like languages. For example, is_ip_blocked(ip_address,
> blocked_ip_list). (That's not just ip_address in blocked_ip_list if the
> list contains CIDR addresses.) We could add code to make the values
> immutable or use annotations:
>
>     @const
>     def func(x : const, y : const = []):
>         pass
>
> Personally, I like declaring the contract that a parameter is not being
> modified explicitly and I would like a shallow freeze() function.
>
> (2) The gotcha that the default value is the same value every time rather
> than a new value. Lot's of ways to deal with this but none of them work
> without educating people how the feature works. For example:
>
>     @copy
>     def func(x : copy, y : copy = []):
>         pass
>
>
One bad solution to both would be to have the language enforce that default
values cannot be of mutable type.  Though not a valid solution, that idea
highlights the only two reasons I can see for using mutable defaults:

- caching across function calls
- having your default be of the same type as your expected argument (a
documentation of sorts)

The idiom of using None that Jack originally described is an acceptable
alternative to using mutable defaults.  It identifies no expectations on the
type of the argument.  It explicitly indicates that None is a valid
argument.  It implies that it will be special-cased in the function/class.
 It is easy to be consistent using None regardless of the expected type of
the argument.

The advantage of Jack's original proposal is that in cases where you are not
modifying the argument your won't need to plug the correct object in for
None, so that if statement he included would not be necessary.

-eric


>
--- Bruce
> Latest blog post: http://www.vroospeak.com Your social security number is
> a very poor password
> Learn how to hack web apps: http://j.mp/gruyere-security
>
>
>
> _______________________________________________
> Python-ideas mailing list
> Python-ideas at python.org
> http://mail.python.org/mailman/listinfo/python-ideas
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-ideas/attachments/20110520/73b2cc3e/attachment.html>