By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
425,625 Members | 1,267 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 425,625 IT Pros & Developers. It's quick & easy.

Why python doesn't use syntax like function(,,x) for default parameters?

P: n/a
I mean, it's very convenient when default parameters
can be in any position, like
def a_func(x = 2, y = 1, z):
...
(that defaults must go last is really a C++ quirk which
is needed for overload resolution, isn't it?)

and when calling, just omit parameter when you want to
use defaults:
a_func(, , 3)

There are often situations when a function has independent
parameters, all having reasonable defaults, and I want to
provide just several of them. In fact, I can do it using
keyword parameters, but it's rather long and you have to
remember/lookup names of parameters.

Is there some contradiction in python syntax which disallows
an easy implementation of this feature, or just nobody bothered
with this? If former is the case, please show me why, because
I badly need this feature in embedded python app (for
compatibility with other language that uses such syntax) and might
venture to implement it myself, so don't want to waste time
if it's gonna break something.
Or maybe it might be an idea for enhancement proposal?

Mar 10 '06 #1
Share this Question
Share on Google+
21 Replies


P: n/a
Dmitry Anikin wrote:
Is there some contradiction in python syntax which disallows
an easy implementation of this feature, or just nobody bothered
with this? If former is the case, please show me why, because
I badly need this feature in embedded python app (for
compatibility with other language that uses such syntax) and might
venture to implement it myself, so don't want to waste time
if it's gonna break something.

I think you would find it hard to implement exactly that in Python. Of
course what you can do easily enough is invent a magic 'missing' value and
map Python calls of:

a_func(missing, missing, 3)

to a call of:

a_func(,,3)

in your other language. It seems to me though that writing:

a_func(z=3)

ought to be clearer to anyone reading the code, especially when you come
back to your code in 6 months time and find:

b_func(,,,,,,,,,,,1,,,,2)
Remember Python is a dynamic language, so the compiler cannot tell which
function you are actually calling. In a statically bound language parameter
defaults are often restricted to constant values and the default values are
simply inserted in place of any missing arguments when the call is
compiled. That isn't possible in Python, so the interpreter has to insert
the missing values when you actually make the call. The code to do that is
complex enough with the current restrictions.

To allow arbitrary arguments to be defaulted, I think you would have to add
a new magic value to represent a missing parameter, make the compiler pass
that in place of any omitted positional parameters, and then make the
function call code check all parameters to see if they are missing values
and if so substitute the actual default. It would be possible, but it
doesn't really give you any additional power since you can already do that
in the cases where you need it by using keyword arguments or by passing an
explicit value to mean 'replace this parameter by some other canned value'.
Mar 10 '06 #2

P: n/a
On 10 Mar 2006 09:51:01 GMT
Duncan Booth <du**********@invalid.invalid> wrote:
Dmitry Anikin wrote:
Is there some contradiction in python syntax which
disallows an easy implementation of this feature, or
just nobody bothered with this? If former is the case,
please show me why, because I badly need this feature in
embedded python app (for compatibility with other
language that uses such syntax) and might venture to
implement it myself, so don't want to waste time if it's
gonna break something.

I think you would find it hard to implement exactly that
in Python. Of course what you can do easily enough is
invent a magic 'missing' value and map Python calls of:

a_func(missing, missing, 3)

to a call of:

a_func(,,3)


It's not uncommon, of course, to use "None" for this
purpose. I have a lot of code that does something like:

def myfunc(a, b, c):
if a is None:
a = []
...
--
Terry Hancock (ha*****@AnansiSpaceworks.com)
Anansi Spaceworks http://www.AnansiSpaceworks.com

Mar 10 '06 #3

P: n/a
"Dmitry Anikin" <an*****************@vstu.ru> wrote:
There are often situations when a function has independent
parameters, all having reasonable defaults, and I want to
provide just several of them. In fact, I can do it using
keyword parameters, but it's rather long and you have to
remember/lookup names of parameters.
Specifying the names of the keyword parameters costs you a little typing
once, but saves everybody (including yourself) a lot of grief later when
you're trying to figure out what the heck your code does 6 months later.
I badly need this feature in embedded python app (for
compatibility with other language that uses such syntax)
Can you tell us more about what it is that you're trying to do?
Or maybe it might be an idea for enhancement proposal?


You can always write up a PEP, but to be honest, this doesn't sound like
one that would meet with much enthusiasm from the community.
Mar 10 '06 #4

P: n/a
Dmitry Anikin wrote:
I mean, it's very convenient when default parameters
can be in any position, like
def a_func(x = 2, y = 1, z):
...
(that defaults must go last is really a C++ quirk which
is needed for overload resolution, isn't it?)
I've no idea why C++ required defaults last; it certainly seems wise to
avoid confusion with the positionals in Python.
and when calling, just omit parameter when you want to
use defaults:
a_func(, , 3)
Yerch! So now you've forced all arguments to be positional? This doesn't
seem like an improvement. And it's just plain fugly.
There are often situations when a function has independent
parameters, all having reasonable defaults, and I want to
provide just several of them. In fact, I can do it using
keyword parameters, but it's rather long and you have to
remember/lookup names of parameters.
Whereas you can invariably remember their positions? I don't think so.
Is there some contradiction in python syntax which disallows
an easy implementation of this feature, or just nobody bothered
with this? If former is the case, please show me why, because
I badly need this feature in embedded python app (for
compatibility with other language that uses such syntax) and might
venture to implement it myself, so don't want to waste time
if it's gonna break something.
Or maybe it might be an idea for enhancement proposal?

The thing about enhancement proposals is that they are supposed to
*improve* the language. Frankly I wouldn't see this as any kind of
enhancement.

If you have a large program to translate from another language you will
probably find that a modest application of Python suffices to translate
all the calls into whatever form turns out to be required in Python.

regards
Steve
--
Steve Holden +44 150 684 7255 +1 800 494 3119
Holden Web LLC/Ltd www.holdenweb.com
Love me, love my blog holdenweb.blogspot.com

Mar 10 '06 #5

P: n/a
Op 2006-03-10, Roy Smith schreef <ro*@panix.com>:
"Dmitry Anikin" <an*****************@vstu.ru> wrote:
There are often situations when a function has independent
parameters, all having reasonable defaults, and I want to
provide just several of them. In fact, I can do it using
keyword parameters, but it's rather long and you have to
remember/lookup names of parameters.


Specifying the names of the keyword parameters costs you a little typing
once, but saves everybody (including yourself) a lot of grief later when
you're trying to figure out what the heck your code does 6 months later.


Could you explain what is so hard in figuring out:

func(,,4)

We sure don't seem to have a problem with figuring out things like

lst[::2]
Personnaly in a situation where it is likely that the first
parameter is going to take a default and the second parameter
is going to vary a lot, I would have prefered that to be
visible in how the function is called, instead of a call
with only one argument being interpreted as being the value
for the second parameter.

More specifically I would have preferred the possibility
of range(,n) and this being equivallent to range(0,n)
instead of range(n) being equivallent to range(0,n).

--
Antoon Pardon
Mar 10 '06 #6

P: n/a
Antoon Pardon wrote:

Specifying the names of the keyword parameters costs you a little typing
once, but saves everybody (including yourself) a lot of grief later when
you're trying to figure out what the heck your code does 6 months later.


Could you explain what is so hard in figuring out:

func(,,4)

We sure don't seem to have a problem with figuring out things like

lst[::2]


That is the usual polemics. Its a HUGE difference if I'm supposed to
remember 2 default values that are 0 and <size-of-sequence>, in a
specialized syntax, than arbitrary values

f(,,,,,3)

in some arbitrary function.

Diez
Mar 10 '06 #7

P: n/a
In article <sl********************@rcpc42.vub.ac.be>,
Antoon Pardon <ap*****@forel.vub.ac.be> wrote:
Op 2006-03-10, Roy Smith schreef <ro*@panix.com>:
"Dmitry Anikin" <an*****************@vstu.ru> wrote:
There are often situations when a function has independent
parameters, all having reasonable defaults, and I want to
provide just several of them. In fact, I can do it using
keyword parameters, but it's rather long and you have to
remember/lookup names of parameters.


Specifying the names of the keyword parameters costs you a little typing
once, but saves everybody (including yourself) a lot of grief later when
you're trying to figure out what the heck your code does 6 months later.


Could you explain what is so hard in figuring out:

func(,,4)


Because while I probably remember what func does (especially if it's well
named), it's less likely that I remember all the arguments it takes, and
even less that I remember what order they come in.

Let's say I've got a function which makes a network connection. It takes
optional arguments for a port number to connect to, a timeout (in seconds)
and a buffer size (in kbytes) to use. If we used your syntax, what does
"connect (,,20)" mean? You have to go look up the definition of the
function to find out, don't you? But, if I wrote "connect (port=20)", it's
obvious to anybody reading the code what the 20 is.
Mar 10 '06 #8

P: n/a
Antoon Pardon wrote:
Op 2006-03-10, Roy Smith schreef <ro*@panix.com>:
"Dmitry Anikin" <an*****************@vstu.ru> wrote:
There are often situations when a function has independent
parameters, all having reasonable defaults, and I want to
provide just several of them. In fact, I can do it using
keyword parameters, but it's rather long and you have to
remember/lookup names of parameters.


Specifying the names of the keyword parameters costs you a little typing
once, but saves everybody (including yourself) a lot of grief later when
you're trying to figure out what the heck your code does 6 months later.

Could you explain what is so hard in figuring out:

func(,,4)


Your func has only three parameters, and only one non-default.
I think "all have reasonable defaults, I want to provide several"
means you might end up with bugs like this.

func(,,,1.2e-3,7.6e18,3.124576,3567.0,)
func(,,1.24e3,1,21.26e4,,,1220,57,35,0) # bug
TypeError: func() takes exactly 8 arguments (9 given)

Now what are the correct arguments?
1220.57, 35, and 0
1220, 57.35, and 0
1220, 57, and 35.0

With keywords parameters, this is easy to answer.

func(y=1.2e-3, z=7.6e18, i=3.124576, j=3567.0)
func(x=1.24e3, y=1, z=21.26e4, j=1220, k=57,35, w=0) # bug

SyntaxError: non-keyword arg after keyword arg.
Mar 10 '06 #9

P: n/a
Op 2006-03-10, Diez B. Roggisch schreef <de***@nospam.web.de>:
Antoon Pardon wrote:

Specifying the names of the keyword parameters costs you a little typing
once, but saves everybody (including yourself) a lot of grief later when
you're trying to figure out what the heck your code does 6 months later.
Could you explain what is so hard in figuring out:

func(,,4)

We sure don't seem to have a problem with figuring out things like

lst[::2]


That is the usual polemics. Its a HUGE difference if I'm supposed to
remember 2 default values that are 0 and <size-of-sequence>, in a
specialized syntax,


Those default values are not 0 and <size-of-sequence>, you may have
only experience with situations where they behave as such but that
is not the same.
than arbitrary values
f(,,,,,3)

in some arbitrary function.


If you need to know these values then you will need to know them
just as much when a keyword is used or when the default values
are used later. Calling

f(3) or f(arg5=3)

Will give you no more a clue about the missing default values
than calling

f(,,,,,3)

At least in the last call you are given a clue about missing
arguments.

--
Antoon Pardon
Mar 10 '06 #10

P: n/a
Op 2006-03-10, Roy Smith schreef <ro*@panix.com>:
In article <sl********************@rcpc42.vub.ac.be>,
Antoon Pardon <ap*****@forel.vub.ac.be> wrote:
Op 2006-03-10, Roy Smith schreef <ro*@panix.com>:
> "Dmitry Anikin" <an*****************@vstu.ru> wrote:
>> There are often situations when a function has independent
>> parameters, all having reasonable defaults, and I want to
>> provide just several of them. In fact, I can do it using
>> keyword parameters, but it's rather long and you have to
>> remember/lookup names of parameters.
>
> Specifying the names of the keyword parameters costs you a little typing
> once, but saves everybody (including yourself) a lot of grief later when
> you're trying to figure out what the heck your code does 6 months later.
Could you explain what is so hard in figuring out:

func(,,4)


Because while I probably remember what func does (especially if it's well
named), it's less likely that I remember all the arguments it takes, and
even less that I remember what order they come in.


Do you have trouble remembering that range(n) is actually providing the
second parameter to the function and what it does?
Let's say I've got a function which makes a network connection. It takes
optional arguments for a port number to connect to, a timeout (in seconds)
and a buffer size (in kbytes) to use. If we used your syntax, what does
"connect (,,20)" mean? You have to go look up the definition of the
function to find out, don't you? But, if I wrote "connect (port=20)", it's
obvious to anybody reading the code what the 20 is.


I don't consider this an argument. We already have the problem that we
need to figure out what connect(20) means. connect(,,20) will at least
make it clear that some parameters are missing. My syntax doesn't
make it easier to introduce inclarities than python can.

Sure connect(port=20) provides extra clarity, but nobody seems to have
a problem with range(n) where n suddenly is the second parameter and
we use the default for the first. If we want to allow things like that
I would prefer range(,n) that at least makes it clear what is going on.

--
Antoon Pardon
Mar 10 '06 #11

P: n/a
> Those default values are not 0 and <size-of-sequence>, you may have
only experience with situations where they behave as such but that
is not the same.
Well, it might be - but the conceptual behavior is (usually) the same.
If you need to know these values then you will need to know them
just as much when a keyword is used or when the default values
are used later. Calling

f(3) or f(arg5=3)

Will give you no more a clue about the missing default values
than calling

f(,,,,,3)

At least in the last call you are given a clue about missing
arguments.


I didn't argue against that - I don't like the proposal, but I'm pretty
sure that it won't be accepted in any way whatsoever so I don't bother.

I just wanted to point out that you proclaim false evidence for a similar
situation already being part of python, and that thus the f(,,1) syntax was
justified.

Diez
Mar 10 '06 #12

P: n/a
Antoon Pardon <ap*****@forel.vub.ac.be> wrote:
Do you have trouble remembering that range(n) is actually providing the
second parameter to the function and what it does?


Yes. I don't use range() everyday, and it's very rare that I use more
than one argument. I do remember that there are additional (optional)
arguments to range which alter the sequence (start point and step),
but I certainly don't remember which is which. If I needed to use it,
I would go look it up. On the other hand, if I saw "range (10,
step=2)" written, it would be immediately obvious what was going on
without need to refer to the docs.
Mar 10 '06 #13

P: n/a

"Antoon Pardon" <ap*****@forel.vub.ac.be> wrote in message
news:sl********************@rcpc42.vub.ac.be...
but nobody seems to have
a problem with range(n) where n suddenly is the second parameter and
we use the default for the first.


Actually, I consider the unique calling pattern for x/range to be something
of a wart. Learning this inconsistency was at least a minor problem. It
is a rather extreme example of typing laziness beats purity.

Given that enumerate() eliminate many uses of range(), it might be worth
considering requiring the start param. range(0,n) only takes two more
keystrokes. Better maybe to shorten range to rng to get them back ;-)

Terry Jan Reedy

Mar 10 '06 #14

P: n/a
Some example (from real life).
def ChooseItems(StartDate, EndDate, Filter):
#function returns a set of some items in chronological order
#from required interval possibly using filter

ChooseItems() #get everything
ChooseItems('01.01.2000', ,SomeFilter) #get everything after a date using filter
ChooseItems(, '01.01.2000') #get everything before a date
ChooseItems(, , SomeFilter) #get everything using filter

Now compare this to something which (I hope) is rather pythonian

Seq[:] #get everything
Seq[2::3] #get everything after an index using filter (filter every third value)
Seq[:3] #get everythin before an index
Seq[::4] #get everything using a filter

Do you see any significant difference?

I understand that many do not need such a syntax, I don't understand
why someone would be AGAINST it. I don't propose to CHANGE anything
in python (right now this syntax is error anyway). What I propose is just
ADD another way of calling a function with keyword parameters but using
POSITIONS instead of NAMES. And sometimes position is easier to
remember than name. Anyway, who wants names let them use names.
Who wants positions let them use positions. But to have a CHOICE is
always good. As far as the choice itself doesn't damage anything,
and I don't think that my does.

I think that if we compare
ChooseItems('01.01.2000', ,SomeFilter)
and
ChooseItems(StartDate='01.01.2000', Filter=SomeFilter)
the first one is more readable, 'cos you see
what is meant right away. In second one you have to
actually READ the keyword names to understand.
It's not the common case, of course, but still, why
not have a choice to use it?

Some other examples which might benefit
SetDate(year, month, day)
SetDate(, month+1) # set next month, leaving year and day
SetDate(, , 31) # set to end of month, not changing year
#(wrong date adjusted automatically, of course)

FormatFloat(Float, Length, Precision, FormatFlags)
You might want precision, leaving length default, or just use FormatFlags

In fact, I became so used to convenience of such syntax that
it was a disappointment not to find it in python.

Please, don't try to scare me with 25-parameter functions.
This is not for them. But to remember positions of two to
five parameters is actually easier (if their order has some
logic) then what are their names: startDate ? beginDate?
firstDate? openDate? Date1?

The same approach can be used with tuples:
(, , z) = func() # returning three element tuple()
You think
z = func()[2]
is actually more clear? - By the way, I want THIRD value,
not SECOND. And tuples don't have keyword names, do they?
And what about
(a, , b) = func()
....well, maybe I got carried away a little...

Finally, if syntax
func (None, None, 10)
seems natural to you, I propose to make it even more
natural: I don't want some "None" passed as argument,
I don't want anything at all passed, so I just use empty space
func ( , , 10)
And the called func don't have to bother with checking
None for EACH argument but will happily use defaults instead.
Mar 10 '06 #15

P: n/a
Some example (from real life).
def ChooseItems(StartDate, EndDate, Filter):
#function returns a set of some items in chronological order
#from required interval possibly using filter

ChooseItems() #get everything
ChooseItems('01.01.2000', ,SomeFilter) #get everything after a date using filter
ChooseItems(, '01.01.2000') #get everything before a date
ChooseItems(, , SomeFilter) #get everything using filter

Now compare this to something which (I hope) is rather pythonian

Seq[:] #get everything
Seq[2::3] #get everything after an index using filter (filter every third value)
Seq[:3] #get everythin before an index
Seq[::4] #get everything using a filter

Do you see any significant difference?

I understand that many do not need such a syntax, I don't understand
why someone would be AGAINST it. I don't propose to CHANGE anything
in python (right now this syntax is error anyway). What I propose is just
ADD another way of calling a function with keyword parameters but using
POSITIONS instead of NAMES. And sometimes position is easier to
remember than name. Anyway, who wants names let them use names.
Who wants positions let them use positions. But to have a CHOICE is
always good. As far as the choice itself doesn't damage anything,
and I don't think that my does.

I think that if we compare
ChooseItems('01.01.2000', ,SomeFilter)
and
ChooseItems(StartDate='01.01.2000', Filter=SomeFilter)
the first one is more readable, 'cos you see
what is meant right away. In second one you have to
actually READ the keyword names to understand.
It's not the common case, of course, but still, why
not have a choice to use it?

Some other examples which might benefit
SetDate(year, month, day)
SetDate(, month+1) # set next month, leaving year and day
SetDate(, , 31) # set to end of month, not changing year
#(wrong date adjusted automatically, of course)

FormatFloat(Float, Length, Precision, FormatFlags)
You might want precision, leaving length default, or just use FormatFlags

In fact, I became so used to convenience of such syntax that
it was a disappointment not to find it in python.

Please, don't try to scare me with 25-parameter functions.
This is not for them. But to remember positions of two to
five parameters is actually easier (if their order has some
logic) then what are their names: startDate ? beginDate?
firstDate? openDate? Date1?

The same approach can be used with tuples:
(, , z) = func() # returning three element tuple()
You think
z = func()[2]
is actually more clear? - By the way, I want THIRD value,
not SECOND. And tuples don't have keyword names, do they?
And what about
(a, , b) = func()
....well, maybe I got carried away a little...

Finally, if syntax
func (None, None, 10)
seems natural to you, I propose to make it even more
natural: I don't want some "None" passed as argument,
I don't want anything at all passed, so I just use empty space
func ( , , 10)
And the called func don't have to bother with checking
None for EACH argument but will happily use defaults instead.
Mar 10 '06 #16

P: n/a
Dmitry Anikin napisał(a):
Some example (from real life).
def ChooseItems(StartDate, EndDate, Filter):
#function returns a set of some items in chronological order
#from required interval possibly using filter

ChooseItems() #get everything
ChooseItems('01.01.2000', ,SomeFilter) #get everything after a date
using filter
ChooseItems(, '01.01.2000') #get everything before a date
ChooseItems(, , SomeFilter) #get everything using filter

Now compare this to something which (I hope) is rather pythonian

Seq[:] #get everything
Seq[2::3] #get everything after an index using filter (filter every
third value)
Seq[:3] #get everythin before an index
Seq[::4] #get everything using a filter

Do you see any significant difference?
You're not comparing what you should. Range has only 3 parameters and is
a standard part of a language. Even if it's not obvious for someone
which parameters mean what in different combinations, it's not that hard
to look up in a manual. But user-defined functions are allowed to have
any number of arguments, with any possible meaning. That means it's
impossible to learn to recognize arguments exclusively by position
(which can be done for range), you have to look up function definition
*each time*.

And please remember that when writing a function, you define defaults as
values that user will mostly consider as appropriate. So if he doesn't
define them, that means he doesn't care. And Python syntax shows exactly
this intention. Your proposed syntax doesn't, as it suggest something
that user should know about is going on.

Now look at your example rewritten with standard Python keyword syntax.
If you know nothing about ChooseItems function, which version in your
opinion is more informative?

# get everything
ChooseItems()
# get everything after a date using filter
ChooseItems(after='01.01.2000', filter_with=SomeFilter)
# get everything before a date
ChooseItems(before='01.01.2000')
# get everything using filter
ChooseItems(filter_with=SomeFilter)
I understand that many do not need such a syntax, I don't understand
why someone would be AGAINST it. I don't propose to CHANGE anything
in python (right now this syntax is error anyway). What I propose is just
ADD another way of calling a function with keyword parameters but using
POSITIONS instead of NAMES. And sometimes position is easier to
remember than name. Anyway, who wants names let them use names.
Who wants positions let them use positions. But to have a CHOICE is
always good. As far as the choice itself doesn't damage anything,
and I don't think that my does.
With this attitude Python will end up being Perl. Current semantics of
calling functions are already good enough to write clean and
understandable code.
I think that if we compare
ChooseItems('01.01.2000', ,SomeFilter)
and
ChooseItems(StartDate='01.01.2000', Filter=SomeFilter)
the first one is more readable, 'cos you see
what is meant right away. In second one you have to
actually READ the keyword names to understand.
It's not the common case, of course, but still, why
not have a choice to use it?
I still think reading is better than guessing. :) Choosing good names
for arguments is another important factor (as shown in last example) in
readability.
Some other examples which might benefit
SetDate(year, month, day)
SetDate(, month+1) # set next month, leaving year and day
SetDate(, , 31) # set to end of month, not changing year
#(wrong date adjusted automatically, of course)
In Poland we usually write dates in day-month-year notation. Having
function calls like this:

SetDate(year=y, month=m, day=d)
SetDate(month=m+1)
SetDate(day=31)

will be understandable by anyone.
Please, don't try to scare me with 25-parameter functions.
This is not for them. But to remember positions of two to
five parameters is actually easier (if their order has some
logic) then what are their names: startDate ? beginDate?
firstDate? openDate? Date1?
I must disagree. If you choose argument names wisely you won't have any
trouble remembering which is which.
The same approach can be used with tuples:
(, , z) = func() # returning three element tuple()
You think
z = func()[2]
is actually more clear? - By the way, I want THIRD value,
not SECOND. And tuples don't have keyword names, do they?
It's not cleaner. It's error-prone, as you may lost one comma somewhere.
You also have to literally count what is the index of returned tuple
value that will be binded to "z".
Finally, if syntax
func (None, None, 10)
seems natural to you, I propose to make it even more
natural: I don't want some "None" passed as argument,
I don't want anything at all passed, so I just use empty space
func ( , , 10)
And the called func don't have to bother with checking
None for EACH argument but will happily use defaults instead.


If you would write it as func(third=10) it would be clearer that
func(, , 10) and called function will still behave as you expect
(without checking for None, but using defaults).

mk
--
. o . >> http://joker.linuxstuff.pl <<
. . o It's easier to get forgiveness for being wrong
o o o than forgiveness for being right.
Mar 10 '06 #17

P: n/a
On Fri, 10 Mar 2006 12:06:57 +0300, Dmitry Anikin wrote:
I mean, it's very convenient when default parameters
can be in any position, like
def a_func(x = 2, y = 1, z):
...
(that defaults must go last is really a C++ quirk which
is needed for overload resolution, isn't it?)
I'm confused... it looks to me like the defaults are *first*, not last, in
the above definition. We write from left to write in English, so normal
convention in English is that first -> last, not last <- first.

and when calling, just omit parameter when you want to
use defaults:
a_func(, , 3)
Can you do this? another_func(,,,4,,,,)

That looks like bug-city to me. (Did I mean 4 to go in the fourth position
or fifth?)

In any case, given the way Python defaults work, the commas are
superfluous. There is no ambiguity:

def f(w, x, y=1, z=1):
pass

Positional arguments without defaults *must* go first, and must be
supplied:

f(5, 6) => w=5, x=6, y=1, z=1

Commas would be pointless: f(5, 6, , ) isn't needed, because the first
and second arguments are already assigned to the w and x arguments before
the first empty comma is spotted.

You can't do this: f(, , 5, 6) => w,x = default, y=5, z=6

because w and x don't have defaults.

There are often situations when a function has independent
parameters, all having reasonable defaults, and I want to
provide just several of them. In fact, I can do it using
keyword parameters, but it's rather long and you have to
remember/lookup names of parameters.


And you think it is easier to remember the position of parameters rather
than their names?
--
Steven.

Mar 11 '06 #18

P: n/a
On Fri, 10 Mar 2006 11:33:56 -0500, Terry Reedy wrote:
Actually, I consider the unique calling pattern for x/range to be something
of a wart. Learning this inconsistency was at least a minor problem. It
is a rather extreme example of typing laziness beats purity.


Amazing. I consider it to be a rather extreme example of practicality
beating purity, an excellent example of interface design.

But I guess that's why Guido is BDFL. Well, that and the fact that he
invented Python *wink*
--
Steven.

Mar 11 '06 #19

P: n/a
Op 2006-03-10, Terry Reedy schreef <tj*****@udel.edu>:

"Antoon Pardon" <ap*****@forel.vub.ac.be> wrote in message
news:sl********************@rcpc42.vub.ac.be...
but nobody seems to have
a problem with range(n) where n suddenly is the second parameter and
we use the default for the first.
Actually, I consider the unique calling pattern for x/range to be something
of a wart. Learning this inconsistency was at least a minor problem. It
is a rather extreme example of typing laziness beats purity.


Well then we can at least agree on that.
Given that enumerate() eliminate many uses of range(), it might be worth
considering requiring the start param. range(0,n) only takes two more
keystrokes. Better maybe to shorten range to rng to get them back ;-)


I can't use enumerate that much. I usually work with a Table which is
like a list, but the index can start at any integer value. Enumerate
doesn't work well with a table.

--
Antoon Pardon
Mar 14 '06 #20

P: n/a
Op 2006-03-10, Terry Reedy schreef <tj*****@udel.edu>:

"Antoon Pardon" <ap*****@forel.vub.ac.be> wrote in message
news:sl********************@rcpc42.vub.ac.be...
but nobody seems to have
a problem with range(n) where n suddenly is the second parameter and
we use the default for the first.


Actually, I consider the unique calling pattern for x/range to be something
of a wart. Learning this inconsistency was at least a minor problem. It
is a rather extreme example of typing laziness beats purity.

Given that enumerate() eliminate many uses of range(), it might be worth
considering requiring the start param. range(0,n) only takes two more
keystrokes. Better maybe to shorten range to rng to get them back ;-)


Take the split method of strings. Personnaly I would prefer to be able
to write:

s.split(,3)

Instead of having to write

s.split(None,3)
The reason is that None is IMO an implemenation detail here. Also
the alternative

s,split(maxsplit=3)

doesn't work in this case.
What may be an option for the future is a Default Object. So that
if you have.

def f(x=0,y=0):
...

then

f(Default, 5)
would be equivallent to

f(0,5)

--
Antoon Pardon
Mar 14 '06 #21

P: n/a
Op 2006-03-10, Diez B. Roggisch schreef <de***@nospam.web.de>:
Those default values are not 0 and <size-of-sequence>, you may have
only experience with situations where they behave as such but that
is not the same.
Well, it might be - but the conceptual behavior is (usually) the same.
If you need to know these values then you will need to know them
just as much when a keyword is used or when the default values
are used later. Calling

f(3) or f(arg5=3)

Will give you no more a clue about the missing default values
than calling

f(,,,,,3)

At least in the last call you are given a clue about missing
arguments.


I didn't argue against that - I don't like the proposal, but I'm pretty
sure that it won't be accepted in any way whatsoever so I don't bother.


You argued that f(,,3) would somehow be hard to figure out.
I just wanted to point out that you proclaim false evidence for a similar
situation already being part of python, and that thus the f(,,1) syntax was
justified.


I didn't claim that the f(,,1) syntax was justified. I asked for an
explanation about why something like f(,,3) would be hard to figure
out.

--
Antoon Pardon
Mar 14 '06 #22

This discussion thread is closed

Replies have been disabled for this discussion.