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 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
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
> 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
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
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:
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 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
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
18 matches
Mail list logo
