Mailing List Archive

Let me show my ignorance a bit.
def a(**x):
... print x

>>> def b(**x):
... a(x)

When 'b' calls 'a' it is passing a dictionary while 'a' wants a keyword
thing
that it resolves to a dictionary. Wouldn't be nice if the keyword thing
could
mark the dictionaries it creates. Then just pass them though when it sees
one if the only other choice was an error.

Yes this sounds like a possible programmer trap. Like one of those silent
C++ type conversions.

So as Marko said come up with interpolate(args).

Humm. Marko do you have such a function ?

Thanks
--Darrell

Marko Schulz <4mschulz@informatik.uni-hamburg.de> wrote in message
news:7ijqr6$pd7$1@rzsun02.rrz.uni-hamburg.de...
> It would be nice to have a way of interpolating sequences in parameter
> lists. In Perl it is done automatically, which causes confusion
> regularly, but it would be nice in Python sometimes too.
>
> If it were done with a new function one could also write a function,
> that computes all base_classes to a class on-the-fly:
> class Derived( interpolate(base_classes(args)) ):
> :
> :
>
> At the moment base_classes may only return one base class. Many
> apply(function,args) could be turned into function( interpolate(args) )
>
> This would be especially nice for those (self,)-Tupels, as it was used
> in the original posting above.
>
> Of cause a nicer syntax oder name than interpolate() might be found.
>
> --
> marko schulz
> "Die Welt ist gut, die Welt ist schlecht.
> Ich seh' mehr als ich begreifen kann. Ich sehe in 3-D."
> '3-D', Extrabreit

Marko Schulz wrote:
>
> It would be nice to have a way of interpolating sequences in parameter
> lists.

I'd like to be able to write

foo(a, b, c, *arglist, **kwdict)

as a function call.

--
Greg Ewing, Computer Science Dept, | The address below is not spam-
University of Canterbury, | protected, so as not to waste
Christchurch, New Zealand | the time of Guido van Rossum.
greg@cosc.canterbury.ac.nz

Darrell writes:

> Let me show my ignorance a bit.
> def a(**x):
> ... print x
>
> >>> def b(**x):
> ... a(x)
>
> When 'b' calls 'a' it is passing a dictionary while 'a' wants a
> keyword thing that it resolves to a dictionary. Wouldn't be nice if
> the keyword thing could mark the dictionaries it creates. Then just
> pass them though when it sees one if the only other choice was an
> error.

>>> def a(d=None, **kwargs):
... print `d or kwargs`

>>> def b(**kwargs):
... a(kwargs)

>>> b(foo=1, bar=3.3)
{'foo': 1, 'bar': 3.3}

- Gordon

[.It would be nice to be able to interpolate tuples into a parameter list]

Perhaps parameter-list construction syntax could be made symmetrical to
parameter declaration?

Thus:

>>> def sing(bruces, *lyrics, **madlib):
... for lyric in lyrics:
... for bruce in bruces:
... print bruce, lyric % madlib
>>> song = ('Emmanuel Kant was a real %(adj1)s', 'who was very rarely
%(adj2)')
>>> words = {'adj1': 'pissant', 'adj2': 'stable'}
>>> sing(['Bruce', 'Bruce'], *song, **words)
instead of
>>> apply(sing, (['Bruce', 'Bruce'],)+song, words)
or even
>>> nextverse = ('Rene Descartes was a %(adj3)s', 'who could %(verb1)s')
>>> morewords = {'adj3': 'drunken fart', 'verb1': 'drink you under the
table'}
>>> sing(['Eric'], *song, *nextverse, **words, **morewords)
instead of
>>> words.update(morewords)
>>> apply(sing, (['Eric'],)+song+nextverse, words)

or-is-my-philosophy-flawed?-ly y'rs
Evan Simpson

> > It would be nice to have a way of interpolating sequences in parameter
> > lists.
>
> I'd like to be able to write
>
> foo(a, b, c, *arglist, **kwdict)
>
> as a function call.
>


Sounds good.

--Darrell

Greg Ewing wrote:
>
> Marko Schulz wrote:
> >
> > It would be nice to have a way of interpolating sequences in parameter
> > lists.
>
> I'd like to be able to write
>
> foo(a, b, c, *arglist, **kwdict)
>
> as a function call.

I like this syntax too. I've been wanting to play with Python's syntax
for a while now, so I thought I'd give it a try. (Note: I'm not a
Parser-Pro. If you know what you're doing and would like to see this
done, best to do it yourself and not wait for me.. :)


I took a (very) quick stab at sticking this into the grammar file
(Grammer/Grammar), but have no idea where to go from there. The
Tokenizer/Parser sources seem large and daunting - could anyone give me
a roadmap before I drown myself? I have played with Bison./YACC and made
some working, useable toy languages, but this seems to be very
different.

oh, this is how I changed Grammar/Grammar:

(at the very end:)
arglist: argument (',' argument)* [',']
argument: [test '='] test # Really [keyword '='] test

becomes:
arglist: argument (',' argument)* ['*' NAME [('*'|'*' '*') NAME]]
[('**'|'*' '*') NAME]

is there a more sensible way to do this?


--
...
You know it's time to rethink your design when you can't debug your
#defines.
-Jim.

[Jim Meier, having fun with syntax]
> ...
> I've been wanting to play with Python's syntax for a while now, so I
> thought I'd give it a try.
> ...
> I took a (very) quick stab at sticking this into the grammar file
> (Grammer/Grammar), but have no idea where to go from there. The
> Tokenizer/Parser sources seem large and daunting - could anyone give me
> a roadmap before I drown myself? I have played with Bison./YACC and made
> some working, useable toy languages, but this seems to be very
> different.

Better preparation would have been had you played with *implementing* Bison
and YACC: in effect, Python is doing the stuff they do (well, really only
as much as it needs to), plus implementing the full Python grammar too.
It's not large or daunting given all that it's doing -- provided you've done
it all before <wink>.

I posted a link earlier to the Best Parsing Book on Earth; read the first
few chapters of that first. It's the only roadmap you're going to find.
BTW, Python's parser code is old and somewhat brittle, and may be the
hardest part of the language implementation to fiddle with. You can do it,
though! Try something, and change it when it doesn't work <0.5 wink>.

> oh, this is how I changed Grammar/Grammar:
>
> (at the very end:)
> arglist: argument (',' argument)* [',']
> argument: [test '='] test # Really [keyword '='] test
>
> becomes:
> arglist: argument (',' argument)* ['*' NAME [('*'|'*' '*') NAME]]
> [('**'|'*' '*') NAME]
>
> is there a more sensible way to do this?

Offhand, I don't know -- analysis is difficult by hand, and it's faster to
just try it anyway. Note that you're at least missing some commas, so
immediately more plausible would be:

arglist: argument (',' argument)* [',' '*' NAME] [',' '*' '*' NAME] [',']

But that still insists on having at least one "real argument" first, so
isn't what you want either. Write out concrete instances of everything you
want to accept, and make sure your grammar allows all and only those.

grammars-aren't-easy-ly y'rs - tim

"Tim Peters" <tim_one@email.msn.com> writes:

> I posted a link earlier to the Best Parsing Book on Earth; read the
> first few chapters of that first.

Which one was that? I think I missed it!

Thanks,
Michael