On Wed, Apr 2, 2008 at 4:19 PM, Thomas Wouters <[EMAIL PROTECTED]> wrote:
> On Wed, Apr 2, 2008 at 2:14 AM, Guido van Rossum <[EMAIL PROTECTED]> wrote:
> > Thomas Wouters's changes for variable tuple packing might fix this, if
> > we can agree to add that feature.
> In all fairness, liberating the
On Wed, Apr 2, 2008 at 2:14 AM, Guido van Rossum <[EMAIL PROTECTED]> wrote:
> Thomas Wouters's changes for variable tuple packing might fix this, if
> we can agree to add that feature.
>
In all fairness, liberating the argument-unpacking doesn't *require* the
variable sequence unpacking patch, al
On Wed, Apr 2, 2008 at 10:30 PM, Alexander Belopolsky <
[EMAIL PROTECTED]> wrote:
> On Wed, Apr 2, 2008 at 3:47 PM, Guido van Rossum <[EMAIL PROTECTED]> wrote:
>
> > > > Thomas Wouters's changes for variable tuple packing might fix
> this, if
> > > > we can agree to add that feature.
> ..
>
On Wed, Apr 2, 2008 at 3:47 PM, Guido van Rossum <[EMAIL PROTECTED]> wrote:
> > > Thomas Wouters's changes for variable tuple packing might fix this, if
> > > we can agree to add that feature.
..
>
> Thomas isn't finished yet.
The reason I am asking is that I've been looking into ways of f
On Wed, Apr 2, 2008 at 12:39 PM, Alexander Belopolsky
<[EMAIL PROTECTED]> wrote:
> On Tue, Apr 1, 2008 at 8:14 PM, Guido van Rossum <[EMAIL PROTECTED]> wrote:
> ..
> > Thomas Wouters's changes for variable tuple packing might fix this, if
> > we can agree to add that feature.
> >
>
> Do you
On Tue, Apr 1, 2008 at 8:14 PM, Guido van Rossum <[EMAIL PROTECTED]> wrote:
..
> Thomas Wouters's changes for variable tuple packing might fix this, if
> we can agree to add that feature.
>
Do you mean http://bugs.python.org/issue2292 ? From description it
does not seem to address function call
On Mon, Mar 31, 2008 at 12:12 PM, Alexander Belopolsky
<[EMAIL PROTECTED]> wrote:
> Do I understand correctly that with PEP 3102 implemented, keyword
> arguments can follow vararg in function definitions, but doing the
> same when calling the function is still a syntax error?
>
> With the latest
Do I understand correctly that with PEP 3102 implemented, keyword
arguments can follow vararg in function definitions, but doing the
same when calling the function is still a syntax error?
With the latest py3k,
>>> def f(a, *args, v=None):
...pass
...
>>> f(a, *args, v=None)
File "", line 1
> I guess it might be too late, but has anyone considered:
>
> def func(normal_arg, *, positional_arg, **, keyword_arg):
> pass
Or even that, since it's meaningless to have a positional argument in the
middle:
def func(positional_arg, *, normal_arg, **, keyword_arg):
pass
--
Gustavo N
> Agreed. Now can you come up with a syntax for positional-only
> arguments? So far everybody has failed at that, and there are some use
> cases where it's useful too.
I guess it might be too late, but has anyone considered:
def func(normal_arg, *, positional_arg, **, keyword_arg):
pass
--
On 2/18/08, Adam Olsen <[EMAIL PROTECTED]> wrote:
> On Feb 18, 2008 1:17 PM, Arnaud Delobelle <[EMAIL PROTECTED]> wrote:
> > A typical use of positional-only arguments is with a function
> > def f(x, y=1, **kwargs):
> > ...
> >
> > where keyword arguments are potentially anything at all, i
On 19 Feb 2008, at 10:49, Nick Coghlan wrote:
[...]
>> Such obscure features warrant an obscure yet well-named decorator,
>> not
>> an obscure syntax that's difficult to get help on.
>
> It's difficult to handle this in a decorator, as the problem that
> occurs is the underlying function repor
Adam Olsen wrote:
> Whereas keyword-only arguments force explicitness (at the cost of
> brevity), positional-only arguments do the opposite. The default
> already allows us to choose brevity when appropriate, and the only
> reason I see to force it is when there's a conflict with **kwargs.
Which
On Feb 18, 2008 1:17 PM, Arnaud Delobelle <[EMAIL PROTECTED]> wrote:
> A typical use of positional-only arguments is with a function
>
> def f(x, y=1, **kwargs):
> ...
>
> where keyword arguments are potentially anything at all, including x
> and y. For example: dict.update(). In fact it
On 18 Feb 2008, at 19:39, Talin wrote:
> Arnaud Delobelle wrote:
>>
[...]
>> Unconvincingly yours,
>
> Well, that is certainly a logical continuation of the train of
> thought behind the 'single *' syntax.
> I'd be curious to know which parts of 3102 people are finding most
> useful. You see
Arnaud Delobelle wrote:
>
> On Feb 14, 11:13 pm, "Guido van Rossum" <[EMAIL PROTECTED]> wrote:
>> On Thu, Feb 14, 2008 at 2:48 PM, Raymond Hettinger <[EMAIL PROTECTED]> wrote:
>>> I've been exercising the new keyword-only arguments syntax. It is
>>> absolutely wonderful. I'm amazed at how many
On Feb 14, 11:13 pm, "Guido van Rossum" <[EMAIL PROTECTED]> wrote:
> On Thu, Feb 14, 2008 at 2:48 PM, Raymond Hettinger <[EMAIL PROTECTED]> wrote:
> > I've been exercising the new keyword-only arguments syntax. It is
> > absolutely wonderful. I'm amazed at how many long standing problems it
>
Raymond Hettinger wrote:
> I've been exercising the new keyword-only arguments syntax. It is absolutely
> wonderful. I'm amazed at how many long standing problems it solves elegantly.
>
> Thanks Talin!
Well, that made my day :)
-- Talin
___
Python-3
Dj Gilcrease wrote:
> Positional only args would be arguments that you cannot specify by
> keyword, so having a positional only arg that has a default value,
> thus making it optional just seems broken to me.
There's no logical problem with optional positional-only
args -- it just means you have t
Dj Gilcrease schrieb:
> On Fri, Feb 15, 2008 at 8:46 AM, Joel Bender <[EMAIL PROTECTED]> wrote:
>> How about a BNFish notation? Use brackets around optional parameters.
>>
>> def test([arg1, [arg2,]] arg3):
>> ...
>
> If I understand right, positional only arguments would not be op
Dj Gilcrease wrote:
> If I understand right, positional only arguments would not be optional
> in any way shape or form, thats what default arguments are for.
I have been expecting that by providing a default value to an argument
in the definition that you are making it optional, be it keyword o
Dj Gilcrease wrote:
> On Thu, Feb 14, 2008 at 6:04 PM, Greg Ewing <[EMAIL PROTECTED]> wrote:
>> Guido van Rossum wrote:
>> > Now can you come up with a syntax for positional-only
>> > arguments? So far everybody has failed at that, and there are some use
>> > cases where it's useful too.
>
>
>
On Fri, Feb 15, 2008 at 8:46 AM, Joel Bender <[EMAIL PROTECTED]> wrote:
> How about a BNFish notation? Use brackets around optional parameters.
>
> def test([arg1, [arg2,]] arg3):
> ...
If I understand right, positional only arguments would not be optional
in any way shape or form,
On Fri, Feb 15, 2008 at 9:37 AM, Dj Gilcrease <[EMAIL PROTECTED]> wrote:
> The intent is to make it so (Assuming arg1 and arg2 are positional
> only) you cannot do test(arg3=9, arg1=7, arg2=8), thus you would be
> required to do test(7, 8, 9) {since doing test(7, 8, arg3=9) would
> raise an err
On Thu, Feb 14, 2008 at 6:04 PM, Greg Ewing <[EMAIL PROTECTED]> wrote:
> Guido van Rossum wrote:
> > Now can you come up with a syntax for positional-only
> > arguments? So far everybody has failed at that, and there are some use
> > cases where it's useful too.
>
> def foo(*(a, b,c)):
>...
Guido van Rossum wrote:
> Now can you come up with a syntax for positional-only
> arguments? So far everybody has failed at that, and there are some use
> cases where it's useful too.
def foo(*(a, b,c)):
...
i.e. catch them in a * arg which is unpacked in-place.
--
Greg Ewing, Computer Scien
On Thu, Feb 14, 2008 at 2:48 PM, Raymond Hettinger <[EMAIL PROTECTED]> wrote:
> I've been exercising the new keyword-only arguments syntax. It is absolutely
> wonderful. I'm amazed at how many long standing problems it solves elegantly.
Agreed. Now can you come up with a syntax for positional-o
I've been exercising the new keyword-only arguments syntax. It is absolutely
wonderful. I'm amazed at how many long standing problems it solves elegantly.
Thanks Talin!
Raymond
___
Python-3000 mailing list
Python-3000@python.org
http://mail.python.o
Nick Coghlan wrote:
> def f(a, b, *(pos1, pos2), c, d):
> # Exactly 2 extra positional arguments required
Then someone is going to want
def f(a, b, *(pos1, pos2, *args), c, d):
# 2 or more positional-only arguments required
--
Greg
___
At 11:42 AM 5/25/2006 +0200, Baptiste Carvello <[EMAIL PROTECTED]> wrote:
>maybe those use cases can work without syntactic sugar. With only part 1, you
>can already add a manual check if you need:
>
> >>> def myfunction(a1, a2, *forbidden, kw1, kw2):
>...assert forbidden is (), "myfunction()
On 5/25/06, Nick Coghlan <[EMAIL PROTECTED]> wrote:
> def f(a, b, *(pos1, pos2), c, d):
> # Exactly 2 extra positional arguments required
-1.
This is (nearly?) just an obscure way to say "def f(a, b, pos1, pos2)".
Suggestion to everyone: please stop proposing alternatives. Let's
instead wor
Greg Ewing wrote:
> tomer filiba wrote:
>> talin asked for comments, so
>>
>> def f(a, b, *, c, d)
>>
>> seems wrong to me. '*' can't be a token on its own, at least
>> that's the way i see it. opeators shouldn't stand for themselves.
>
> But * is not an operator here. It's just a token
> with a s
> > Here's a related but more complicated wish: define a function in such
> > a way that certain parameters *must* be passed as keywords, *without*
> > using *args or **kwds. This may require a new syntactic crutch.
>
> While a number of people have submitted possible use cases for this
> feat
tomer filiba wrote:
> talin asked for comments, so
>
> def f(a, b, *, c, d)
>
> seems wrong to me. '*' can't be a token on its own, at least
> that's the way i see it. opeators shouldn't stand for themselves.
> just like the {/} (empty set) was rejected.
>
Um, before we get all tangled up in sy
Antoine Pitrou wrote:
> Why not:
> def f(a, b, !c, !d):
That looks like "you're not allowed to pass these arguments". :-)
--
Greg
___
Python-3000 mailing list
Python-3000@python.org
http://mail.python.org/mailman/listinfo/python-3000
Unsubscribe:
ht
tomer filiba wrote:
> talin asked for comments, so
>
> def f(a, b, *, c, d)
>
> seems wrong to me. '*' can't be a token on its own, at least
> that's the way i see it. opeators shouldn't stand for themselves.
But * is not an operator here. It's just a token
with a special meaning in this context
Antoine Pitrou wrote:
> Le mercredi 24 mai 2006 à 17:15 -0400, Benji York a écrit :
>
>>In that case, just use the current default value syntax, sans value (d,
>>below):
>>
>>def f(a, b, c=None, d=):
>
> Then we can't decide whether "c" can be positional or is keyword-only.
True. As I suspect
Le mercredi 24 mai 2006 à 17:15 -0400, Benji York a écrit :
> In that case, just use the current default value syntax, sans value (d,
> below):
>
> def f(a, b, c=None, d=):
Then we can't decide whether "c" can be positional or is keyword-only.
___
Py
Antoine Pitrou wrote:
> Why not:
> def f(a, b, !c, !d):
>
> The exclamation mark can be thought to say "you must explicitly mention
> this one by its name".
> I think having a sigil in front of a variable name is less ugly than
> having a separate sigil between commas as a fake parameter.
In th
Le mercredi 24 mai 2006 à 15:43 -0400, Benji York a écrit :
> Hmm, the next best thing I can come up with is:
>
> def f(a, b, =, c, d):
Why not:
def f(a, b, !c, !d):
The exclamation mark can be thought to say "you must explicitly mention
this one by its name".
I think having a sigil in front o
tomer filiba wrote:
> i'd vote for placing it at the end of the last
> argument's name, for example:
>
> def f(a, b*, c, d)
Another idea:
def f(a, b; c, d):
It fails the "syntax variants shouldn't look like grime on your monitor"
test though.
Hmm, the next best thing I can come up with is:
d
talin asked for comments, so
def f(a, b, *, c, d)
seems wrong to me. '*' can't be a token on its own, at least
that's the way i see it. opeators shouldn't stand for themselves.
just like the {/} (empty set) was rejected.
anyway, this pep is certainly very useful (i would have used it
countless t
Talin writes:
> So in other words, nothing has really changed - most people seem to
> like the idea of keyword-only arguments, but find the 'required
> keyword arguments' syntax confusing. (I haven't found many people
> who were in favor of it, however Guido says that's the form that he
> pref
On 5/23/06, Talin <[EMAIL PROTECTED]> wrote:
> Well, c.l.p was strangely quiet in response to my posting PEP 3102 a few
> days ago. Only two comments, one of a general "ick" variety that seems
> mainly based on personal bias, and another which likes the idea but
> votes a -1 on the 'naked star' syn
Talin writes:
> So in other words, nothing has really changed - most people seem to
> like the idea of keyword-only arguments, but find the 'required
> keyword arguments' syntax confusing. (I haven't found many people
> who were in favor of it, however Guido says that's the form that he
> p
On 5/23/06, Talin <[EMAIL PROTECTED]> wrote:
> Well, c.l.p was strangely quiet in response to my posting PEP 3102 a few
> days ago. Only two comments, one of a general "ick" variety that seems
> mainly based on personal bias, and another which likes the idea but
> votes a -1 on the 'naked star' syn
Well, c.l.p was strangely quiet in response to my posting PEP 3102 a few
days ago. Only two comments, one of a general "ick" variety that seems
mainly based on personal bias, and another which likes the idea but
votes a -1 on the 'naked star' syntax.
So in other words, nothing has really change
Talin wrote:
> I have to admit that while the reasoning behind the use of the
> '*' character is logical, the logic seems a little convoluted. Part of this
> is due to the use of negative logic - the absence of something
> that would normally be there (i.e. a keyword after the '*') indicates
> a r
On 5/3/06, Talin <[EMAIL PROTECTED]> wrote:
> 1) Drop this portion of the proposal
> 2) Go with the 'naked star' syntax anyway over the objections, and
> explain the rationale in the docs;
> 3) Come up with a separator character we can agree on
> 4) Come up with a brilliantly-devised alternative
T
Given that this PEP is shorter, there is less to discuss. :)
It seems that most people are in favor of the first part of the
proposal, which is relaxing the restriction that *args must come
after any keyword arguments. There is less agreement on the
proposal to have non-defaulted arguments after t
50 matches
Mail list logo
