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
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 objection
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:
foo = f1; bar=f2; x=k1; y=k2
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
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
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 ::suite is
just
a unary expression returning dict subtype instance, e.g.,
y = f(11,22,**::
x = 1
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,
the less
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 replied:
I would
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 express this. But still,
On 17 Apr 2005 21:48:47 -0700, Kay Schluehr [EMAIL PROTECTED] wrote:
snip
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).items() ? And
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 ::suite
is just
a unary expression
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 current way to express
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
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 in
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:
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 more
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 optional argument
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
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:
#
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 method for
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:
doc
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,
since there
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 not
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, value):
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, Brian
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 Stroud's
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
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
--
The idea is interesting but not unambigously realizable. Maybe one
should introduce some extra syntax for disambiguation and thereby
generalize the proposal.
as specifier:
# list of definitions and assignments
Proposed specifiers are dict, tuple, *, ** and func.
- as dict:
conversion
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
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
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
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:45
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
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 something
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 equivalent to
f():
x = 1
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 suite for
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 know what you
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 ::
Thus
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 in the
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
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
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:
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
44 matches
Mail list logo
