Steven Bethard wrote:
Ron wrote:
How about using ***name in the same way as *name, and **name are used?
It extends the current argument options in a consistent manner and 'I
believe' is easy to explain and visually says something different is
happening here.
This builds on the already present a
Ron wrote:
How about using ***name in the same way as *name, and **name are used?
It extends the current argument options in a consistent manner and 'I
believe' is easy to explain and visually says something different is
happening here.
This builds on the already present arg, *arg, **arg, and
Kay Schluehr wrote:
Steven Bethard wrote:
So the object of a "where" is then always an ordered dict?
Yes.
If so, then
I guess I like this proposal best so far.
However, it does seem to have the problem that you can't have any
additional local variables so, for example, list comprehensions are
pr
On 19 Apr 2005 00:16:32 -0700, "Kay Schluehr" <[EMAIL PROTECTED]> wrote:
>
>Bengt Richter wrote:
>
>[...]
>
>> Um, I think that's too narrow for where. Consider
>>
>> foo = f1; bar=f2; x=k1; y=k2
>> foo(x)*bar(y)[3].attr
>>
>> now should
>>
>> foo(x)*bar(y)[3].attr where:
>> fo
Bengt Richter wrote:
[...]
> Um, I think that's too narrow for where. Consider
>
> foo = f1; bar=f2; x=k1; y=k2
> foo(x)*bar(y)[3].attr
>
> now should
>
> foo(x)*bar(y)[3].attr where:
> foo = f1; bar=f2; x=k1; y=k2
I think we are diverging again. You are right with Your obje
On Mon, 18 Apr 2005 14:06:08 -0700, "Robert Brewer" <[EMAIL PROTECTED]> wrote:
>Reinhold Birkenfeld wrote:
>> >y =3D (f(11, 22, x=3D1, y=3D'y for f') *
>> > g(*args_from_somewhere,
>> > x=3D'x for g', y=3D'y for g',
>> > foo=3Dlambda: return 'foo for g'))
>> >
>> >would be my curre
On Mon, 18 Apr 2005 12:50:24 +0200, Reinhold Birkenfeld <[EMAIL PROTECTED]>
wrote:
>Bengt Richter wrote:
>> On Sun, 17 Apr 2005 15:25:04 +0200, Reinhold Birkenfeld <[EMAIL PROTECTED]>
>> wrote:
>
Note that there is no problem adding other parameters, because ::
is just
a unary ex
On 17 Apr 2005 21:48:47 -0700, "Kay Schluehr" <[EMAIL PROTECTED]> wrote:
>> >
>> I like this. But how would you put "where args:" and "where kw:" if
>you needed both?
>> also, is it looking back to see the '*' or '**' to do (::x=1).values
>vs. (::x=1)
>> and how about (::x=1).keys() or (::x=1).ite
On Mon, 18 Apr 2005 14:06:08 -0700, "Robert Brewer"
<[EMAIL PROTECTED]> wrote:
>Reinhold Birkenfeld wrote:
>> >y = (f(11, 22, x=1, y='y for f') *
>> > g(*args_from_somewhere,
>> > x='x for g', y='y for g',
>> > foo=lambda: return 'foo for g'))
>> >
>> >would be my current way to ex
Reinhold Birkenfeld wrote:
> >y = (f(11, 22, x=1, y='y for f') *
> > g(*args_from_somewhere,
> > x='x for g', y='y for g',
> > foo=lambda: return 'foo for g'))
> >
> >would be my current way to express this. But still, the less lines,
> >the less confusing it is.
And Ron Adam repli
On Mon, 18 Apr 2005 12:50:24 +0200, Reinhold Birkenfeld
<[EMAIL PROTECTED]> wrote:
>y = (f(11, 22, x=1, y='y for f') *
> g(*args_from_somewhere,
> x='x for g', y='y for g',
> foo=lambda: return 'foo for g'))
>
>would be my current way to express this. But still, the less lines,
>th
Bengt Richter wrote:
> On Sun, 17 Apr 2005 15:25:04 +0200, Reinhold Birkenfeld <[EMAIL PROTECTED]>
> wrote:
>>> Note that there is no problem adding other parameters, because :: is
>>> just
>>> a unary expression returning dict subtype instance, e.g.,
>>>
>>> y = f(11,22,**::
>>>
Brian Sabbey wrote:
> Maybe using '**' would be better than '...' since it already is used to
> indicate keyword arguments. Example:
>
> class C(object):
> x = property(**):
>doc = "I'm the 'x' property."
>def fget(self):
> return self.__x
>def fset(self, val
Steven Bethard wrote:
> So the object of a "where" is then always an ordered dict?
Yes.
> If so, then
> I guess I like this proposal best so far.
>
> However, it does seem to have the problem that you can't have any
> additional local variables so, for example, list comprehensions are
> probably
Bengt Richter wrote:
> On 17 Apr 2005 09:27:34 -0700, "Kay Schluehr" <[EMAIL PROTECTED]>
wrote:
>
> >> Exactly. Except the above example is from the day-old-bread
> >items-tuple-returning version of :: ;-)
> >> And with an ordered dict subtype there is no need for the
generator
> >expression either
Kay Schluehr wrote:
Hmmm ... now You eliminate "where" completely in favor for '::'. This
may be reasonable because '::' is stronger and less context dependent.
But on the other hand it may be also reasonable to eliminate '::'
towards a stronger "where" ;)
x = property(**kw) where kw:
d
On 17 Apr 2005 09:27:34 -0700, "Kay Schluehr" <[EMAIL PROTECTED]> wrote:
>> Exactly. Except the above example is from the day-old-bread
>items-tuple-returning version of :: ;-)
>> And with an ordered dict subtype there is no need for the generator
>expression either,
>> since there is a values met
Brian Sabbey wrote:
Does anyone know if the 'where' keyword is only for readability (or does it
disambiguate the syntax in some situations)? I think I prefer leaving it
off.
To answer my own question, I see by reading the where threads that using
the 'where' keyword allows things such as:
# De
On Sun, 17 Apr 2005 15:25:04 +0200, Reinhold Birkenfeld <[EMAIL PROTECTED]>
wrote:
>Bengt Richter wrote:
>
>> Stretching for it, using my latest and greatest ;-)
>>
>> y = f(**::
>>x = 1
>>y = 'y for f'
>> )*g(**::
>>x = 'x for g'
>>y =
Oren Tirosh wrote:
Take a look at Nick Coglan's "with" proposal:
http://groups.google.co.uk/groups?selm=mailman.403.1105274631.22381.python-list%40python.org
It addresses many of the same issues (e.g. easy definition of
properties). It is more general, though: while your proposal only
applies to ke
> Exactly. Except the above example is from the day-old-bread
items-tuple-returning version of :: ;-)
> And with an ordered dict subtype there is no need for the generator
expression either,
> since there is a values method for dicts (which in the subtype would
preserve order). E.g.,
>
> x = prope
Bengt Richter wrote:
> Stretching for it, using my latest and greatest ;-)
>
> y = f(**::
>x = 1
>y = 'y for f'
> )*g(**::
>x = 'x for g'
>y = 'y for g'
>def foo(): return 'foo for g'
> )
>
> Note that there is no pr
On 16 Apr 2005 23:43:03 -0700, "Kay Schluehr" <[EMAIL PROTECTED]> wrote:
>
>Robert Brewer wrote:
>> Bengt Richter wrote:
>> > The '::' unary suite operator should return an ordered dict
>> > subtype representing the bindings
>>
>> Why ordered?
>
>Because You can't otherwise guarantee to feed optio
On 16 Apr 2005 23:06:10 -0700, [EMAIL PROTECTED] (Oren Tirosh) wrote:
>Take a look at Nick Coglan's "with" proposal:
>
>http://groups.google.co.uk/groups?selm=mailman.403.1105274631.22381.python-list%40python.org
>
>It addresses many of the same issues (e.g. easy definition of
>properties). It is
Robert Brewer wrote:
> Bengt Richter wrote:
> > The '::' unary suite operator should return an ordered dict
> > subtype representing the bindings
>
> Why ordered?
Because You can't otherwise guarantee to feed optional argument
parameters in a correct way.
Example:
x = property(*seq) where:
Take a look at Nick Coglan's "with" proposal:
http://groups.google.co.uk/groups?selm=mailman.403.1105274631.22381.python-list%40python.org
It addresses many of the same issues (e.g. easy definition of
properties). It is more general, though: while your proposal only
applies to keyword arguments i
Bengt Richter wrote:
> The '::' unary suite operator should return an ordered dict
> subtype representing the bindings
Why ordered?
Robert Brewer
MIS
Amor Ministries
[EMAIL PROTECTED]
--
http://mail.python.org/mailman/listinfo/python-list
Bengt Richter wrote:
> On Sun, 17 Apr 2005 01:10:47 GMT, [EMAIL PROTECTED] (Bengt Richter) wrote:
> [...]
> >
> >The "::" expression I'm proposing generalizes capturing suite
bindings into an ordered sequence of (key,value)
> >tuples, like an ordered vars().items() limited to the bindings
produced
On Sun, 17 Apr 2005 01:10:47 GMT, [EMAIL PROTECTED] (Bengt Richter) wrote:
[...]
>
>The "::" expression I'm proposing generalizes capturing suite bindings into an
>ordered sequence of (key,value)
>tuples, like an ordered vars().items() limited to the bindings produced in the
>suite following "::"
On Sat, 16 Apr 2005 14:01:56 -0700, Brian Sabbey <[EMAIL PROTECTED]> wrote:
>Reinhold Birkenfeld wrote:
>> Brian Sabbey wrote:
>>> Here is a pre-PEP for what I call "suite-based keyword arguments". The
>>> mechanism described here is intended to act as a complement to thunks.
>>> Please let me kno
On Sat, 16 Apr 2005 13:58:38 -0700, Brian Sabbey <[EMAIL PROTECTED]> wrote:
[...]
>
>Yes, my description of the syntax was ambiguous. To clarify, I intended
>the syntax to be backwardly compatible. That is, one would not be able to
>use a suite to define keywords if there already exists a suit
On Sat, 16 Apr 2005 14:02:32 -0700, Brian Sabbey <[EMAIL PROTECTED]> wrote:
>Bengt Richter wrote:
>> On Fri, 15 Apr 2005 19:32:02 -0700, James Stroud <[EMAIL PROTECTED]> wrote:
Examples
Using suite-based keyword arguments, the code
f(x = 1)
is equiv
On 16 Apr 2005 09:07:09 -0700, "Kay Schluehr" <[EMAIL PROTECTED]> wrote:
>The idea is interesting but not unambigously realizable. Maybe one
>should introduce some extra syntax for disambiguation and thereby
>generalize the proposal.
This is intriguing. I am reminded of trailing "where x is someth
Shane Hathaway wrote:
I like this PEP a lot, but your concern is valid. Maybe Brian could
modify the PEP slightly to disambiguate. How about using an ellipsis in
the argument list to signify suite-based keywords? Examples:
f(...):
x = 1
class C(object):
x = property(...):
doc = "I'm
Nicolas Fleury wrote:
> Shane Hathaway wrote:
> > I like this PEP a lot, but your concern is valid. Maybe Brian
could
> > modify the PEP slightly to disambiguate. How about using an
ellipsis in
> > the argument list to signify suite-based keywords? Examples:
> >
> > f(...):
> > x = 1
> >
>
Bengt Richter wrote:
On Fri, 15 Apr 2005 19:32:02 -0700, James Stroud <[EMAIL PROTECTED]> wrote:
I_vote_yes(James):
I_understand_what_it_does = True
Makes_code_formatting_way_more_managable_in_tough_cases = True
Makes_code_way_more_readable = True
To_cool = True
On Friday 15 April 2005 04:4
Reinhold Birkenfeld wrote:
Brian Sabbey wrote:
Here is a pre-PEP for what I call "suite-based keyword arguments". The
mechanism described here is intended to act as a complement to thunks.
Please let me know what you think.
Suite-Based Keyword Arguments
-
Passing complic
Shane Hathaway wrote:
Kent Johnson wrote:
Brian Sabbey wrote:
Using suite-based keyword arguments, the code
f(x = 1)
is equivalent to
f():
x = 1
ISTM the syntax is ambiguous. How do you interpret
if f():
x = 1
?
Is a suite alllowed only when a block could not be introduced in the
current synt
Shane Hathaway wrote:
I like this PEP a lot, but your concern is valid. Maybe Brian could
modify the PEP slightly to disambiguate. How about using an ellipsis in
the argument list to signify suite-based keywords? Examples:
f(...):
x = 1
class C(object):
x = property(...):
doc = "I'm
The idea is interesting but not unambigously realizable. Maybe one
should introduce some extra syntax for disambiguation and thereby
generalize the proposal.
as :
# list of definitions and assignments
Proposed specifiers are dict, tuple, *, ** and func.
- as dict:
conversion into a dict
How would you write
if f(x=1):
print "yes"
using suite-based keyword args?
Good point.
Then we should remove the extra ':' at the end of the function invocation
:
if f(x=@>):
value of x
print "yes"
if f(@**>):
x: value of x
print "yes"
--
ht
Brian Sabbey wrote:
> Here is a pre-PEP for what I call "suite-based keyword arguments". The
> mechanism described here is intended to act as a complement to thunks.
> Please let me know what you think.
>
> Suite-Based Keyword Arguments
> -
>
> Passing complicated ar
On Fri, 15 Apr 2005 16:45:55 -0700, Brian Sabbey <[EMAIL PROTECTED]> wrote:
>Here is a pre-PEP for what I call "suite-based keyword arguments". The
>mechanism described here is intended to act as a complement to thunks.
>Please let me know what you think.
>
Sorry, I replied to to you via James S
On Fri, 15 Apr 2005 19:32:02 -0700, James Stroud <[EMAIL PROTECTED]> wrote:
>I_vote_yes(James):
> I_understand_what_it_does = True
> Makes_code_formatting_way_more_managable_in_tough_cases = True
> Makes_code_way_more_readable = True
> To_cool = True
>
>On Friday 15 April 2005 04:45 pm, Br
Kent Johnson wrote:
> Brian Sabbey wrote:
>> Using suite-based keyword arguments, the code
>>
>> f(x = 1)
>>
>> is equivalent to
>>
>> f():
>>x = 1
>
>
> ISTM the syntax is ambiguous. How do you interpret
> if f():
> x = 1
> ?
>
> Is a suite alllowed only when a block could not be introduc
Brian Sabbey wrote:
Here is a pre-PEP for what I call "suite-based keyword arguments". The
mechanism described here is intended to act as a complement to thunks.
Please let me know what you think.
Suite-Based Keyword Arguments
-
Passing complicated arguments to functi
I_vote_yes(James):
I_understand_what_it_does = True
Makes_code_formatting_way_more_managable_in_tough_cases = True
Makes_code_way_more_readable = True
To_cool = True
On Friday 15 April 2005 04:45 pm, Brian Sabbey wrote:
> Here is a pre-PEP for what I call "suite-based keyword arguments
Brian Sabbey wrote:
class C(object):
x = property():
doc = "I'm the 'x' property."
def fget(self):
return self.__x
def fset(self, value):
self.__x = value
def fdel(self):
del self.__x
After seeing this example, I think I'll go on a killing spree
Here is a pre-PEP for what I call "suite-based keyword arguments". The
mechanism described here is intended to act as a complement to thunks.
Please let me know what you think.
Suite-Based Keyword Arguments
-
Passing complicated arguments to functions is currently awk
49 matches
Mail list logo
