[Python-ideas] parameter omit
Aaron Brady
castironpi at comcast.net
Fri May 11 22:40:46 CEST 2007
> -----Original Message-----
> From: Tal Einat [mailto:taleinat at gmail.com]
> Sent: Friday, May 11, 2007 3:02 PM
>
> On 5/11/07, Aaron Brady <castironpi at comcast.net> wrote:
>
> Note DefaultArg needs never get referenced literally in
> declarations, only
> in calls.
>
> def ghi( j=None, k=None, l=None ):
> if j is None: j= Something
> if k is None: k= Something2
> if l is None: l= Something3
>
> No. Here, I do it all at once.
> def ghi( j=Something, k=Something2, l=Something3 ):
>
>
> Maybe I'm missing something here... But why would someone not use the
> latter syntax unless the value must be calculated when the function is
> called, as opposed to when the function is defined? In such cases, None
> fits the bill. (Default arguments are evaluated at function definition.)
>
>
>
> Calls like ghi( MyThing ) still work, as does:
> ghi( MyThing, l=MyThing3 ).
>
> Everybody's on board so far and nothing's changed. Omissions,
> positional,
> and keyword arguments still work as we've grown to know and love.
>
> What we can do, is always know the parameter. The change is to know
> the
> default value in every situation. It's always DefaultArg.
>
> ghi( MyThing, DefaultArg, Mything3 )
> as well as
> ghi( DefaultArg, MyThing2 )
>
>
> IMHO this is far less readable than using keyword arguments and omitting
> those arguments for which you'd like to use the default value. I
> personally like the "keyword-only arguments" PEP (3102) because it could
> help make function calls more readable.
>
>
> Perhaps we could learn from experience?
>
> I've recently had to automate Excel with Python and used the COM
> interface. In COM, there is a value called "Missing" which is passed to
> functions when no value should be passed for an argument - similar to your
> DefaultArg. This leads to code like this (C# code examples):
>
> http://msdn2.microsoft.com/en-us/library/aa168343(office.11).aspx
> (straight from the online MSDN)
>
> MenuBarItem = MainMenuBar.Controls.Add(
> Office.MsoControlType.msoControlPopup,
> Type.Missing, Type.Missing, Type.Missing, true);
>
> And that was not a far-fetched example - here is an extreme example:
>
> http://blogs.ittoolbox.com/visualbasic/evolution/archives/importing-
> unformatted-excel-sheets-into-sql-server-2000-using-net-part-i-7501
> <http://blogs.ittoolbox.com/visualbasic/evolution/archives/importing-
> unformatted-excel-sheets-into-sql-server-2000-using-net-part-i-7501>
>
> Excel.Application excelApp = new Excel.ApplicationClass();
> Excel.Workbook thisWorkbook =
> excelApp.Workbooks.Open(strFileName,Type.Missing, Type.Missing,
> Type.Missing, Type.Missing,Type.Missing, Type.Missing, Type.Missing,
> Type.Missing,Type.Missing, Type.Missing, Type.Missing,
> Type.Missing,Type.Missing, Type.Missing);
>
>
> IMO this is horrendous. Horrible. Eye-gouging.
>
> I'd rather write machine code in hex.
>
>
> - Tal
Ok, this isn't working to get my idea over. There's something wrong with
somebody, and it's simplest to assume its me. Probably inexperience in
posting. Not to mention, I have no idea who I'm talking to, or what the
local dialect is. (Sorry about the blank message too... wrong keystroke.)
Tal's examples don't contradict me. In his, I call:
> MenuBarItem = MainMenuBar.Controls.Add(
> Office.MsoControlType.msoControlPopup, thenamedarg= true);
and
> Excel.Workbook thisWorkbook = excelApp.Workbooks.Open(strFileName)
Traditional function call. Calls still will work the way they do today.
You have -extra- flexibility, not less, sir. I add zero requirements.
Please let me repeat. Nothing breaks.
More information about the Python-ideas
mailing list