[Python-ideas] parameter omit

Aaron Brady castironpi at comcast.net
Fri May 11 06:55:52 CEST 2007


> -----Original Message-----
> From: Josiah Carlson [mailto:jcarlson at uci.edu]
> Sent: Thursday, May 10, 2007 11:27 PM
> 
> "Aaron Brady" <castironpi at comcast.net> wrote:
> 
> Post what you want.  If people aren't offering +1 or -1, it could be for
> any number of reasons; from being busy (it is in the middle of the week),
> to just not caring enough either way, believing that their opinions and
> interests are already being expressed, etc.
> 
> But when you post something, then 24 hours and 40 minutes later you ask,
> "Also, any follow-up on this?  (I posted at top.)" at the bottom of a 95
> line quote of your own last post without cutting out the unimportant
> parts, it is pestering, and a very low signal to noise ratio 1:95. Never
> mind that you only recently seemed to learn that we don't top post in
> Python mailing lists, but you still haven't realized that we trim
> unimportant parts of quoted posts.  Had you top posted or failed to trim
> either in python-list (or the equivalent comp.lang.python), any number
> of people would have told you as much.
> 
> But hey, you are being such the good usenet poster, you couldn't have
> made a mistake, of course not.  Get over yourself.
> 
> 
> With that said, I don't particularly like the addition of syntax for
> something that can already be done other ways (TOOWTDI), or the addition
> of a new builtin to signal something that I've never heard *anyone* ask
> about before.  Really, the only *reasonable* name is 'default', which is
> used at least 146 times in the Python standard library (according to my
> regular expression of default\s*=), and I'm sure thousands of times in 3rd
> party code.  It would necessitate a huge change for a feature that no
> one (but you) as asked for so that you can use...
> 
>     foo(a, b=default, c=1234)
>     foo(a, b=253463, c=default)
> 
> rather than...
> 
>     foo(a, c=1234)
>     foo(a, b=253463)
> 
> Personally, I find the latter more consistant (only pass arguments that
> you care to change).  If you don't, that's fine.  The burdon of proof
> isn't on me, or anyone else in python-ideas to prove to you that your
> idea sucks; it's on you to prove to everyone else that your idea
> *doesn't* suck.  Good luck on that.
> 
> Local jerk,
>  - Josiah

Correct, signal to noise, content to form.  My idea came in a slightly
unconventional format.  Not posting in Hebrew or something.  Besides, that
problem cleared itself up on its own.  I noticed I wasn't blending in.

Within a full 24 hours, I expect an, "I like this, may be good.  Here's my
personal e-mail address, get back to me in a week if you haven't heard
anything."  No elaboration is necessary at this point.  It only takes one
day to write this.  But that's just where I come from.  So instead, I pursue
and follow-up on my own initiative.  Does need a reply of some sort or
another.

Lastly, most importantly, you misunderstand the issue.  The example says it
all, but I'm willing to explain, just for the asking.  Don't misquote me,
but the trade-off follows.

Three-line function definition [Carlson 19:59 American Central Time] versus
one.  More than three lines if you have more than three parameters: one line
per parameter.  Cobol is another way to do it, so be careful with acronyms.
No new syntax in this one.

The old ways:

[code to assign my_b and my_c]
if use_default_b and use_defualt_c:
	foo(a)
elif use_default_b:
	foo(a, c=my_c)
elif use_default_c:
	foo(a, my_b)

-or-

def foo(arg1, **kwargs):
	arg2 = kwargs.get('arg2', 1.2325)
	arg3 = kwargs.get('arg3', 'hello')

The new way:

my_b, my_c= paramdefault, paramdefault
[code to assign my_b and my_c]
foo(a, my_b, my_c)

And don't get me started on `d'.  ParamDefault is like True, False, and
None.  Not traditional, in truth, Pythonic.  Looking far into the future,
however, I suppose it could start to get abused, like putting None in
dictionaries, for example.  Perhaps it was None's original intent.

Fellow jerk,
- Aaron

[p.s. { 'akey': ParamDefault }, ha]




More information about the Python-ideas mailing list