[Python-Dev] anonymous blocks
(I apologize that this is my first post. Please don't flame me into
oblivion or think I'm a quack!)
Have you guys considered the following syntax for anonymous blocks? I
think it's possible to parse given Python's existing syntax:
items.doFoo(
def (a, b) {
return a + b
},
def (c, d) {
return c + d
}
)
Notice the trick is that there is no name between the def and the "(",
and the ")" is followed by a "{".
I understand that there is hesitance to use "{}". However, you can
think of this as a Python special case on the same level as using ";"
between statements on a single line. From that perspective, it's not
inconsistent at all.
Best Regards,
-jj
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] anonymous blocks
I apologize for sparking such debate on this list instead of on
c.l.py. By the way, the only reason I brought this up was as a
replacement for lambdas in Py3K.
Guido, in response to your much earlier comment about supporting "{}"
for normal defs as a matter of consistency within my proposal, yes, I
agree. Just like ";", you should rarely use them.
Best Regards,
-jj
On 4/19/05, Phillip J. Eby <[EMAIL PROTECTED]> wrote:
> At 01:00 PM 04/19/2005 -0700, Guido van Rossum wrote:
> > > Interestingly, this syntax also works to do decoration, though it's not a
> > > syntax that was ever proposed for that. e.g.:
> > >
> > > foo = classmethod(foo) where:
> > > def foo(cls,x,y,z):
> > > # etc.
> >
> >This requires you to write foo three times, which defeats at least
> >half of the purpose of decorators.
>
> Well, you could do 'foo = classmethod(x) where: def x(...)', but that *is*
> kind of kludgy. I'm just suggesting that if 'where:' had existed before
> decorators, people might have griped about the three-time typing or kludged
> around it, but there wouldn't likely have been strong support for creating
> a syntax "just" for decorators.
>
> Indeed, if somebody had proposed this syntax during the decorator debates I
> would have supported it, but of course Bob Ippolito (whose PyObjC use cases
> involve really long function names) might have disagreed.
>
>
> > > foo = property(get_foo,set_foo) where:
> > > def get_foo(self):
> > > # ...
> > > def set_foo(self):
> > > # ...
> > >
> > > I don't mind @decorators, of course, but maybe they wouldn't be needed
> > here.
> >
> >As I said before, I'm not sure why keeping get_foo etc. out of the
> >class namespace is such a big deal.
>
> That's a relatively minor thing, compared to being able to logically group
> them with the property, which I think enhances readability, even more than
> the sometimes-proposed '@property.getter' and '@property.setter' decorators.
>
> Anyway, just to be clear, I don't personally think 'where:' is needed in
> Python 2.x; lambda and decorators suffice for all but the most Twisted use
> cases. ;) I was just viewing it as a potential alternative to lambda in
> Py3K.
>
> ___
> Python-Dev mailing list
> Python-Dev@python.org
> http://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe:
> http://mail.python.org/mailman/options/python-dev/jjinux%40gmail.com
>
--
I have decided to switch to Gmail, but messages to my Yahoo account will
still get through.
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Re: anonymous blocks (off topic: match)
> PS. a side effect of the for-in pattern is that I'm beginning to feel that > Python > might need a nice "switch" statement based on dictionary lookups, so I can > replace multiple callbacks with a single loop body, without writing too many > if/elif clauses. That's funny. I keep wondering if "match" from the ML world would make sense in Python. I keep thinking it'd be a really nice thing to have. -jj -- I have decided to switch to Gmail, but messages to my Yahoo account will still get through. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Re: switch statement
On 4/20/05, M.-A. Lemburg <[EMAIL PROTECTED]> wrote: > Fredrik Lundh wrote: > > PS. a side effect of the for-in pattern is that I'm beginning to feel > > that Python > > might need a nice "switch" statement based on dictionary lookups, so I can > > replace multiple callbacks with a single loop body, without writing too > > many > > if/elif clauses. > > PEP 275 anyone ? (http://www.python.org/peps/pep-0275.html) > > My use case for switch is that of a parser switching on tokens. > > mxTextTools applications would greatly benefit from being able > to branch on tokens quickly. Currently, there's only callbacks, > dict-to-method branching or long if-elif-elif-...-elif-else. I think "match" from Ocaml would be a much nicer addition to Python than "switch" from C. -jj -- I have decided to switch to Gmail, but messages to my Yahoo account will still get through. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Re: switch statement
On 4/21/05, Michael Hudson <[EMAIL PROTECTED]> wrote:
> Shannon -jj Behrens <[EMAIL PROTECTED]> writes:
>
> > On 4/20/05, M.-A. Lemburg <[EMAIL PROTECTED]> wrote:
> >
> >> My use case for switch is that of a parser switching on tokens.
> >>
> >> mxTextTools applications would greatly benefit from being able
> >> to branch on tokens quickly. Currently, there's only callbacks,
> >> dict-to-method branching or long if-elif-elif-...-elif-else.
> >
> > I think "match" from Ocaml would be a much nicer addition to Python
> > than "switch" from C.
>
> Can you post a quick summary of how you think this would work?
Sure.
Now that I'm actually trying to come up with an example, I'm noticing
that Ocaml is very different than Python because Python distinguishes
statements and expressions, unlike say, Scheme. Furthermore, it's
important to minimize the number of new keywords and avoid excessive
punctuation (which Ocaml is full of). Hence, I propose something
like:
def handle_token(token):
match token:
NUMBER:
return number / a
WHITESPACE if token.value == "\n":
return NEWLINE
(a, b):
return a / b
else:
return token
Hence, the syntax is something like (in pseudo EBNF):
'match' expr ':'
{match_expression ':'
block}*
'else' ':'
block
match_expr ::= lvalue | constant_expression
Sematically, the above example translates into:
def handle_token(token):
if token == NUMBER:
return number / a
elif token == WHITESPACE and token.value == "\n":
return NEWLINE
elif "setting (a, b) = token succeeds":
return a / b
else:
return token
However, unlike the code above, you can more easily and more
aggressively optimize.
Best Regards,
-jj
--
I have decided to switch to Gmail, but messages to my Yahoo account will
still get through.
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Re: switch statement
On 4/25/05, M.-A. Lemburg <[EMAIL PROTECTED]> wrote: > Shannon -jj Behrens wrote: > > On 4/20/05, M.-A. Lemburg <[EMAIL PROTECTED]> wrote: > > > >>Fredrik Lundh wrote: > >> > >>>PS. a side effect of the for-in pattern is that I'm beginning to feel > >>>that Python > >>>might need a nice "switch" statement based on dictionary lookups, so I can > >>>replace multiple callbacks with a single loop body, without writing too > >>>many > >>>if/elif clauses. > >> > >>PEP 275 anyone ? (http://www.python.org/peps/pep-0275.html) > >> > >>My use case for switch is that of a parser switching on tokens. > >> > >>mxTextTools applications would greatly benefit from being able > >>to branch on tokens quickly. Currently, there's only callbacks, > >>dict-to-method branching or long if-elif-elif-...-elif-else. > > > > I think "match" from Ocaml would be a much nicer addition to Python > > than "switch" from C. > > PEP 275 is about branching based on dictionary lookups which > is somewhat different than pattern matching - for which we > already have lots and lots of different tools. > > The motivation behind the switch statement idea is that of > interpreting the multi-state outcome of some analysis that > you perform on data. The main benefit is avoiding Python > function calls which are very slow compared to branching to > inlined Python code. > > Having a simple switch statement > would enable writing very fast parsers in Python - > you'd let one of the existing tokenizers such as mxTextTools, > re or one of the xml libs create the token input data > and then work on the result using a switch statement. > > Instead of having one function call per token, you'd > only have a single dict lookup. > > BTW, has anyone in this thread actually read the PEP 275 ? I'll admit that I haven't because dict-based lookups aren't as interesting to me as an Ocaml-style match statement. Furthermore, the argument "Instead of having one function call per token, you'd only have a single dict lookup" isn't very compelling to me personally, because I don't have such a performance problem in my applications, which isn't to say that it isn't important or that you don't have a valid point. Best Regards, -jj -- I have decided to switch to Gmail, but messages to my Yahoo account will still get through. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
