[Python-ideas] parameter omit

[Aaron Brady]

> -----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.