pre-PEP: Suite-Based Keywords - syntax proposal

[Kay Schluehr]

Bengt Richter wrote:
> On 17 Apr 2005 09:27:34 -0700, "Kay Schluehr" <kay.schluehr at gmx.net>
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 dicts (which in the subtype
would
> >preserve order). E.g.,
> >>
> >>  x = property(*seq) where:
> >>              seq = (::
> >>                  def get_x():
> >>                      return self.__x
> >>                  def set_x(value):
> >>                      self.__x = value
> >>                  del_x = None
> >>                  doc   = "I'm the 'x' property." ).values())
> >>
> >> Or more directly:
> >>
> >>  x = property(*(::
> >>                  def get_x():
> >>                      return self.__x
> >>                  def set_x(value):
> >>                      self.__x = value
> >>                  del_x = None
> >>                  doc   = "I'm the 'x' property." ).values())
> >
> >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 = "I'm the 'x' property."
> >            def fget(self):
> >                return self.__x
> >
> >
> >x = property(*args) where args:
> >            def fget(self):
> >                return self.__x
> >            fset = None
> >            fdel = None
> >            doc = "I'm the 'x' property."
> >
> 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 what if you
wanted to pass
> (::x=1) as a dict object without ** expansion into a keyword dict?
>
> Maybe we need asterisks on both ends. e.g.,
>
>     foo(dct, values, *args, **kw):
>        where **dct:
>           x=1
>        where *values:
>           x=2
>        where *args:
>           x=3
>        where **kw:
>           x=4

Yes... Why not?

>
> But that still doesn't give you, e.g.,
>
>        foo(keys) where:
>            keys=sorted((::
>                from interesting.module import *
>            ).keys())

This particular statement won't work anyway inside a where-clause
because
"from *" must be called from module level. You would have to import
interesting.module before:

        import interesting.module
        foo(keys) where:
            keys = sorted(interesting.module.__dict__).keys()

But it wasn't ever intended to put arbitrary statements in a kw-suite,
right?

> I like clean sugar, but I still want to be able to
> get at the general primitives to compose them in ways
> that can't be anticipated until a use case comes up.
> And then if the primitives are inaccessible, one is
> out of luck or doomed to workaround hacking ;-)

You can always consider "where" as function of a statement. The only
restriction You have to make is to bind "where" to a function-call i.e.
regard each function as a function object with a where() method.


f(*args,**kw ).where( <specifier>,
                        (<assignment-statement>|
                         <function-definition>|
                         <class-definition>)*
                    )

But that is not a loss of generality because a free (:: x=1 ) can be
mapped onto

  dict(**kw).where(**kw, x=1)

and that is

  dict(**kw) where **kw:
       x=1

I don't see any case where this translation fails. Only if it comes to
functional composition like

  f(g(...(h(:: x=1)...))

it may be awkward to expand this into a nested where clauses. You might
probably define the argument not in a suite ;)

Regards,
Kay