On Sun, May 07, 2006, BJ?rn Lindqvist wrote:
>
> I do know enough about Python to know that the make_person function is
> a really bad example. The one obvious way to write make_peson is to
> use four positional arguments, name, age, phone, location and not
> complicate the function by throwing in
On 5/7/06, Steven Bethard <[EMAIL PROTECTED]> wrote:
> The most obvious one to me is the optparse module, where add_option
> takes all kinds of different keyword arguments, and there's really no
> intention of these ever being specified as positional arguments:
> http://docs.python.org/lib/modu
On 5/7/06, BJörn Lindqvist <[EMAIL PROTECTED]> wrote:
> I do know enough about Python to know that the make_person function is
> a really bad example.
Totally agreed. I've been ignoring most of that discussion because it
seemed really irrelevant.
> would be nice to instead see some real examples
BJörn Lindqvist wrote:
> But IMHO, your design is broken if you need
> to send dozens of arguments to any function or method.
My design allows property values to be specified using
keywords in the constructor. You typically only use
a few of them in any given call, but there are a large
number of
> > would have thought that the one obvious way to get rid of
> > the wanky feeling would have been to write:
> >
> > def make_person(name, age, phone, location): ...
> >
> > make_person(name, age, phone, location)
>
> This doesn't fly in something like PyGUI, where there
> are literally dozens of
On 5/5/06, Jean-Paul Calderone <[EMAIL PROTECTED]> wrote:
> @keyword
> def foo(a, b, c=10, d=20, e=30):
> return a, b, c, d, e
Cute, indeed. That decorator implementation is not as flexible as the
* which can go after positional parameters, but of course that is easy
to tweak. Howe
"Fred L. Drake, Jr." <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]
> On Friday 05 May 2006 02:38, Terry Reedy wrote:
> > My point has been that the function writer should not make such a
> > requirement (for four no-defaut, required params) and that proposing to
> > do
> > so with
"Michael Urman" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]
> On 5/5/06, Terry Reedy <[EMAIL PROTECTED]> wrote:
>> At present, Python allows this as a choice.
I made that statement in the context of comparing these syntaxes
def make_person(name, age, phone, location) # current
Jean-Paul Calderone <[EMAIL PROTECTED]> wrote:
>
> On Fri, 5 May 2006 08:20:02 -0500, Michael Urman <[EMAIL PROTECTED]> wrote:
> >On 5/5/06, Terry Reedy <[EMAIL PROTECTED]> wrote:
> >> At present, Python allows this as a choice.
> >
> >Not always - take a look from another perspective:
> >
> >def
On Friday 05 May 2006 10:16, Nick Coghlan wrote:
> And I imagine API designers that abused the feature would end up being
> abused by their users :)
If used to create poor APIs, I think that's a reasonable outcome. :-)
I don't think using such a feature to constrain APIs is necessarily abuse,
Fred L. Drake, Jr. wrote:
> On Friday 05 May 2006 02:38, Terry Reedy wrote:
> > My point has been that the function writer should not make such a
> > requirement (for four no-defaut, required params) and that proposing to do
> > so with the proposed '*' is an abuse (for public code). The caller
On Fri, 5 May 2006 08:20:02 -0500, Michael Urman <[EMAIL PROTECTED]> wrote:
>On 5/5/06, Terry Reedy <[EMAIL PROTECTED]> wrote:
>> At present, Python allows this as a choice.
>
>Not always - take a look from another perspective:
>
>def make_person(**kwds):
>name = kwds.pop('name', None)
>age
On Friday 05 May 2006 02:38, Terry Reedy wrote:
> My point has been that the function writer should not make such a
> requirement (for four no-defaut, required params) and that proposing to do
> so with the proposed '*' is an abuse (for public code). The caller should
And what exactly is the p
On 5/5/06, Terry Reedy <[EMAIL PROTECTED]> wrote:
> At present, Python allows this as a choice.
Not always - take a look from another perspective:
def make_person(**kwds):
name = kwds.pop('name', None)
age = kwds.pop('age', None)
phone = kwds.pop('phone', None)
location = kwds.pop
"Greg Ewing" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]
Terry Reedy wrote:
>> The dispute is about the sensibility and
>> politeness of requiring a small fixed number of required, no-default
>> args
>> to be passed by name only
>There seems to be some confusion between two diff
Terry Reedy wrote:
> The dispute is about the sensibility and
> politeness of requiring a small fixed number of required, no-default args
> to be passed by name only
There seems to be some confusion between two different
subthreads here. BJörn Lindqvist seemed to be saying that
instead of my sug
"Greg Ewing" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]
>BJörn Lindqvist wrote:
>> would have thought that the one obvious way to get rid of
>> the wanky feeling would have been to write:
>> def make_person(name, age, phone, location): ...
>> make_person(name, age, phone, locati
BJörn Lindqvist wrote:
> would have thought that the one obvious way to get rid of
> the wanky feeling would have been to write:
>
> def make_person(name, age, phone, location): ...
>
> make_person(name, age, phone, location)
This doesn't fly in something like PyGUI, where there
are literally do
> > >make_person(=name, =age, =phone, =location)
> >
> > And even with Terry's use case quoted I can't make out what you meant
> > that to do.
>
> I meant it to do the same thing as
>
>make_person(name=name, age=age, phone=phone, location=location)
>
> I come across use cases for this fairl
On Tuesday 02 May 2006 22:32, Guido van Rossum wrote:
> and '@deco').
Pronounced "at-deck-oh", @deco is an art-deco variant favored in "r"-deprived
regions.
-Fred
--
Fred L. Drake, Jr.
___
Python-Dev mailing list
Python-Dev@python.org
http://m
On 5/2/06, Greg Ewing <[EMAIL PROTECTED]> wrote:
> Guido van Rossum wrote:
> > On 5/2/06, Greg Ewing <[EMAIL PROTECTED]> wrote:
>
> > >make_person(=name, =age, =phone, =location)
> >
> > And even with Terry's use case quoted I can't make out what you meant
> > that to do.
>
> I meant it to do t
Guido van Rossum wrote:
> On 5/2/06, Greg Ewing <[EMAIL PROTECTED]> wrote:
> >make_person(=name, =age, =phone, =location)
>
> And even with Terry's use case quoted I can't make out what you meant
> that to do.
I meant it to do the same thing as
make_person(name=name, age=age, phone=phone
In article
<[EMAIL PROTECTED]>,
"Guido van Rossum" <[EMAIL PROTECTED]> wrote:
> On 5/2/06, Greg Ewing <[EMAIL PROTECTED]> wrote:
> > Terry Reedy wrote:
> >
> > > my way to call your example (given the data in separate variables):
> > > make_person(name, age, phone, location)
> > > your way:
>
On 5/2/06, Greg Ewing <[EMAIL PROTECTED]> wrote:
> Terry Reedy wrote:
>
> > my way to call your example (given the data in separate variables):
> > make_person(name, age, phone, location)
> > your way:
> > make_person(name=name, age=age, phone=phone, location = location)
>
> For situations like
Terry Reedy wrote:
> my way to call your example (given the data in separate variables):
> make_person(name, age, phone, location)
> your way:
> make_person(name=name, age=age, phone=phone, location = location)
For situations like that, I've sometimes thought
it would be useful to be able to
""Martin v. Löwis"" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]
> You weren't asking for a reason, you were asking for an example:
No wonder we weren't connecting very well. You somehow have it backwards.
'Why' means "for what reason". But to continue with examples:
my way to
Terry Reedy wrote:
> >> which reminds me of the following little absurdity gem from the language
> >> reference:
>
> > I am not sure of what you see as absurdity,
>
> Perhaps I do. Were you referring to what I wrote in the last paragraph of
> my response to Guido?
I don't know; I've lost track o
"Terry Reedy" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]
>
> "Fredrik Lundh" <[EMAIL PROTECTED]> wrote in message
> news:[EMAIL PROTECTED]
>> which reminds me of the following little absurdity gem from the language
>> reference:
> I am not sure of what you see as absurdity,
Pe
"Guido van Rossum" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]
> A function/method could have one argument that is obviously needed and
> a whole slew of options that few people care about. For most people,
> the signature they know is foo(arg). It would be nice if all the
> opti
Edward Loper wrote:
> >> And again, why would you *make* me, the user-programmer, type
> >>
> >> make_person(name=namex, age=agex, phone=phonex, location = locationx)
> >> #instead of
> >> make_person(namex,agex,phonex,locationx)
> >> ?
> >
> > because a good API designer needs to consider more th
Terry Reedy wrote:
> This is not a reason for subproposal two, but a special case, as you
> yourself note below, and hence does say why you want to have such.
>
>> def make_person(*, name, age, phone, location):
>>pass
You weren't asking for a reason, you were asking for an example:
this is
"Fredrik Lundh" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]
> which reminds me of the following little absurdity gem from the language
> reference:
>
>The following identifiers are used as keywords of the language, and
>cannot be used as ordinary identifiers. They must be
Fredrik Lundh wrote:
>> And again, why would you *make* me, the user-programmer, type
>>
>> make_person(name=namex, age=agex, phone=phonex, location = locationx)
>> #instead of
>> make_person(namex,agex,phonex,locationx)
>> ?
>
> because a good API designer needs to consider more than just the cur
""Martin v. Löwis"" <[EMAIL PROTECTED]> wrote in message
> I clipped it because I couldn't understand your question: "Why" what?
> (the second question only gives "Why not") I then assumed that the
> question must have applied to the text that immediately preceded the
> question - hence that's th
Terry Reedy wrote:
> And again, why would you *make* me, the user-programmer, type
>
> make_person(name=namex, age=agex, phone=phonex, location = locationx)
> #instead of
> make_person(namex,agex,phonex,locationx)
> ?
because a good API designer needs to consider more than just the current
releas
On Mon, May 01, 2006, Edward Loper wrote:
>
> But is it necessary to syntactically *enforce* that the arguments be
> used as keywords? I.e., why not just document that the arguments should
> be used as keyword arguments, and leave it at that. If users insist on
> using them positionally, then
""Martin v. Löwis"" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]
> Terry Reedy wrote:
>> There are two subproposals: first, keyword-only args after a variable
>> number of positional args, which requires allowing keyword parameter
>> specifications after the *args parameter, and se
On 5/1/06, Fredrik Lundh <[EMAIL PROTECTED]> wrote:
> btw, talking about idioms used in the language reference, can any of the
> native speakers on this list explain if "A is a nicer way of spelling B" means
> that "A is preferred over B", "B is preferred over A", "A and B are the same
> word and w
Martin v. Löwis wrote:
> > I.e., why not just document that the arguments should
> > be used as keyword arguments, and leave it at that.
>
> Because they wouldn't be keyword-only arguments, then.
which reminds me of the following little absurdity gem from the language
reference:
The followin
Edward Loper wrote:
> Martin v. Löwis wrote:
>> One reason I see is to have keyword-only functions, i.e. with no
>> positional arguments at all:
>>
>> def make_person(*, name, age, phone, location):
>> pass
>
> But is it necessary to syntactically *enforce* that the arguments be
> used as keyw
On 5/1/06, Edward Loper <[EMAIL PROTECTED]> wrote:
> > There are two subproposals: first, keyword-only args after a variable
> > number of positional args, which requires allowing keyword parameter
> > specifications after the *args parameter, and second, keyword-only args
> > after a fixed number
Fred L. Drake, Jr. wrote:
> On Sunday 30 April 2006 22:50, Edward Loper wrote:
> > I see two possible reasons:
>
> Another use case, observed in the wild:
>
>- An library function is written to take an arbitrary number of
> positional arguments using *args syntax. The library is releas
On Sunday 30 April 2006 22:50, Edward Loper wrote:
> I see two possible reasons:
Another use case, observed in the wild:
- An library function is written to take an arbitrary number of
positional arguments using *args syntax. The library is released,
presumably creating dependencie
On 4/30/06, Edward Loper <[EMAIL PROTECTED]> wrote
(referring to keyword-only arguments):
> I see two possible reasons:
>
>- A function's author believes that calls to the function will be
> easier to read if certain parameters are passed by name, rather
> than positionally; and they
Edward Loper wrote:
> > One reason I see is to have keyword-only functions, i.e. with no
> > positional arguments at all:
> >
> > def make_person(*, name, age, phone, location):
> > pass
> >
> > which also works for methods:
> >
> > def make_person(self, *, name, age, phone, location):
> >
Martin v. Löwis wrote:
> One reason I see is to have keyword-only functions, i.e. with no
> positional arguments at all:
>
> def make_person(*, name, age, phone, location):
> pass
>
> which also works for methods:
>
> def make_person(self, *, name, age, phone, location):
> pass
>
Terry Reedy wrote:
> "Nick Coghlan" <[EMAIL PROTECTED]> wrote in message
>> Because for some functions (e.g. min()/max()) you want to use *args, but
>> support some additional keyword arguments to tweak a few aspects of the
>> operation (like providing a "key=x" option).
>
> This and the rest of
Terry Reedy wrote:
> My "Why?" was and is exactly a request for that further discussion.
>
> Again: if a function has a fixed number n of params, why say that the first
> k can be passed by position, while the remaining n-k *must* be passed by
> name?
have you designed API:s for others than yours
Terry Reedy wrote:
Now, suppose you wanted to have 'key' be a keyword-only argument.
>>> Why? Why not let the user type the additional argument(s) without the
>>> parameter name?
>
> Like Martin, you clipped most of the essential context of my question:
> Talin's second proposal.
I cli
Terry Reedy wrote:
>> Are you asking why that feature (keyword-only arguments) is desirable?
>> That's the whole point of the PEP. Or are you asking why the user
>> shouldn't be allowed to pass keyword-only arguments by omitting the
>> keyword? Because they wouldn't be keyword-only arguments then,
Terry Reedy wrote:
> There are two subproposals: first, keyword-only args after a variable
> number of positional args, which requires allowing keyword parameter
> specifications after the *args parameter, and second, keyword-only args
> after a fixed number number of positional args, implemente
> ""Martin v. Löwis"" <[EMAIL PROTECTED]> wrote in message
>> Are you asking why that feature (keyword-only arguments) is desirable?
Joe Smith asked essentially the same question in a different way:
"However, I'm not sure what the use case is for keyword only arguments on
functions that do *not*
"Nick Coghlan" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]
> Terry Reedy wrote:
>> "Talin" <[EMAIL PROTECTED]> wrote in message
>> news:[EMAIL PROTECTED]
>>> Now, suppose you wanted to have 'key' be a keyword-only argument.
>>
>> Why? Why not let the user type the additional
""Martin v. Löwis"" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]
> Terry Reedy wrote:
>>> Now, suppose you wanted to have 'key' be a keyword-only argument.
>>
>> Why? Why not let the user type the additional argument(s) without the
>> parameter name?
>
> Are you asking why tha
Zachary Pincus stanford.edu> writes:
> That seems a bit odd, as my natural expectation wouldn't be to see
> kw1 ands kw2 as required, no-default keyword args, but as misplaced
> positional args.
>
> Perhaps this might be a little better?
>def foo(*args, kw1=, kw2=):
> I'm rather not sure
Thomas Wouters python.org> writes:
> Pfft, implementation is easy. I have the impression Talin wants to
implement it himself, but even if he doesn't, I'm sure I'll have a
free week somewhere in the next year and a half in which I can
implement it :) It's not that hard a problem, it just requires
"Talin" <[EMAIL PROTECTED]> wrote in message news:[EMAIL PROTECTED]
> Abstract
>
> This PEP proposes a change to the way that function arguments are
> assigned to named parameter slots. In particular, it enables the
> declaration of "keyword-only" arguments: arguments that can only
>
Zachary Pincus wrote:
> Some thoughts from a lurker, largely concerning syntax; discount as
> you wish.
>
> First:
>> Keyword-only arguments are not required to have a default value.
>> Since Python requires that all arguments be bound to a value,
>> and since the only way to bind
Some thoughts from a lurker, largely concerning syntax; discount as
you wish.
First:
> Keyword-only arguments are not required to have a default value.
> Since Python requires that all arguments be bound to a value,
> and since the only way to bind a value to a keyword-only argume
Terry Reedy wrote:
> "Talin" <[EMAIL PROTECTED]> wrote in message news:[EMAIL PROTECTED]
>> Now, suppose you wanted to have 'key' be a keyword-only argument.
>
> Why? Why not let the user type the additional argument(s) without the
> parameter name?
Because for some functions (e.g. min()/ma
On 4/30/06, Steven Bethard <[EMAIL PROTECTED]> wrote:
On 4/29/06, Talin <[EMAIL PROTECTED]> wrote:> This PEP proposes a change to the way that function arguments are> assigned to named parameter slots. In particular, it enables the
> declaration of "keyword-only" arguments: argument
Terry Reedy wrote:
>> Now, suppose you wanted to have 'key' be a keyword-only argument.
>
> Why? Why not let the user type the additional argument(s) without the
> parameter name?
Are you asking why that feature (keyword-only arguments) is desirable?
That's the whole point of the PEP. Or ar
On Sat, Apr 29, 2006, Talin wrote:
>
> Specification
>
> Syntactically, the proposed changes are fairly simple. The first
> change is to allow regular arguments to appear after a varargs
> argument:
>
> def sortwords(*wordlist, case_sensitive=False):
> ...
>
"Talin" <[EMAIL PROTECTED]> wrote in message news:[EMAIL PROTECTED]
>
> def sortwords(*wordlist, case_sensitive=False):
The rationale for this is pretty obvious. But ...
> The second syntactical change is to allow the argument name to
> be omitted for a varargs argument:
>
>
On 4/29/06, Talin <[EMAIL PROTECTED]> wrote:
> PEP: 3102
> Title: Keyword-Only Arguments
> Version: $Revision$
> Last-Modified: $Date$
> Author: Talin
> Status: Draft
> Type: Standards
> Content-Type: text/plain
> Created: 22-Apr-2006
> Python-Version: 3.0
> Post-History:
>
>
> Abstract
>
> T
PEP: 3102
Title: Keyword-Only Arguments
Version: $Revision$
Last-Modified: $Date$
Author: Talin
Status: Draft
Type: Standards
Content-Type: text/plain
Created: 22-Apr-2006
Python-Version: 3.0
Post-History:
Abstract
This PEP proposes a change to the way that function arguments are
assi
66 matches
Mail list logo
