[Python-ideas] parameter omit

[Tal Einat]

On 5/11/07, Aaron Brady <castironpi at comcast.net> wrote:
>
>
> > 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.


These are simply the examples I could find with several minutes of Googling,
admittedly not great examples, as you pointed out. I was just trying to show
real world ugly code which was written as a result of an infrastructure
adopting a concept which is very similar to the one which you propose. The
point was to show that adopting your suggestion could result in even less
readable function calls.

Yes, nothing breaks. I really get it. I'm against this because it is, IMHO,
not Pythonic.

I'm not saying it won't be possible to write readable code. I'm saying it
-would- be possible to write even less readable code. Specifically, I might
be forced to write such ugly function calls when calling functions written
by others, therefore adopting this feature could lead to my being forced to
write uglier code. Not to mention reading others' uglier code...

- Tal

(P.S. in the first example, a keyword argument could not be used, because
all of the arguments were positional.)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-ideas/attachments/20070512/77a4f3c2/attachment.html>