Re: [Python-Dev] Fwd: Problem withthe API for str.rpartition()
On 9/5/06, Barry Warsaw <[EMAIL PROTECTED]> wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > On Sep 5, 2006, at 2:06 PM, Raymond Hettinger wrote: > > >> Then shouldn't rpartition be S.rpartition(sep) -> (rest, sep, tail) > > > > Gads, the cure is worse than the disease. > > > > car and cdr are starting to look pretty good ;-) > > LOL, the lisper in me likes that too, but I don't think it'll work. :) > but when it comes to cadr, cddr, cdar... ;^) I personally prefer (left, sep, right ) since it's most clear and there are many Python programmers whose first language is not English. > Fred's disagreement notwithstanding, I still like (left, sep, right), > but another alternative comes to mind after actually reading the > docstring for rpartition : (before, sep, after). Now, that's > not ambiguous is it? Seems to work for both partition and rpartition. > > - -Barry > > -BEGIN PGP SIGNATURE- > Version: GnuPG v1.4.5 (Darwin) > > iQCVAwUBRP2+AHEjvBPtnXfVAQLiPAP+N80jHkoT5VNTtX1h2cqD4pONz+j2maCI > QXDBoODucxLDPrig8FJ3c6IcT+Uapifu8Rrvd7Vm8gSPMUsMqAgAqhqNDbXTkHVH > xLk31en2k2fdiCQKQyKJSjE1R1CaFCezByV29FK3fWvqrrxObISRnsxf/wXB6Czu > pOUNSA9LLKo= > =g+iz > -END PGP SIGNATURE- > ___ > 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/seojiwon%40gmail.com > ___ 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] Please help complete the AST branch
I'd like to help here on the AST branch, if it's not too late. (Especially I'm interested with the generator expression part.) If I want to volunteer, do I just begin to work with it? Or do I need to read something or discuss with someone? Thanks. Jiwon. On Mon, 3 Jan 2005 23:03:33 -0500, Jeremy Hylton <[EMAIL PROTECTED]> wrote: > On Mon, 03 Jan 2005 18:02:52 -0800, Brett C. <[EMAIL PROTECTED]> wrote: > > Plus there is the running tradition of sprinting on the AST branch at > > PyCon. I > > was planning on shedding my bug fixing drive at PyCon this year and > > sprinting > > with (hopefully) Jeremy, Neal, Tim, and Neil on the AST branch as a prep for > > working on it afterwards for my class credit. > > I'd like to sprint on it before PyCon; we'll have to see what my > schedule allows. > > > If anyone would like to see the current code, check out ast-branch from CVS > > (read the dev FAQ on how to check out a branch from CVS). Read > > Python/compile.txt for an overview of how the thing works and such. > > > > It will get done, just don't push for a 2.5 release within a month. =) > > I think the branch is in an awkward state, because of the new features > added to Python 2.4 after the AST branch work ceased. The ast branch > doesn't handle generator expressions or decorators; extending the ast > to support them would be a good first step. > > There are also the simple logistical questions of integrating changes. > Since most of the AST branch changes are confined to a few files, I > suspect the best thing to do is to merge all the changes from the head > except for compile.c. I haven't done a major CVS branch integrate in > at least nine months; if someone feels more comfortable with that, it > would also be a good step. > > Perhaps interested parties should take up the discussion on the > compiler-sig. I think we can recover the state of last May's effort > pretty quickly, and I can help outline the remaining work even if I > can't help much. (Although I hope I can help, too.) > > Jeremy > ___ > 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/seojiwon%40gmail.com > ___ 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] problem with genexp
Regarding this Grammar change; (last October)
from argument: [test '=' ] test [gen_for]
to argument: test [gen_for] | test '=' test ['(' gen_for ')']
- to raise error for "bar(a = i for i in range(10)) )"
I think we should change it to
argument: test [gen_for] | test '=' test
instead of
argument: test [gen_for] | test '=' test ['(' gen_for ')']
that is, without ['(' gen_for ')'] . We don't need that extra term,
because "test" itself includes generator expressions - with all those
parensises.
Actually with that extra ['(' gen_for ')'] , foo(a= 10 (for y in
'a')) is grammartically correct ; although that error seems to be
checked elsewhere.
I tested without ['(' gen_for ')'] , and worked fine passing
Lib/test/test_genexps.py
-Jiwon
On 10/20/05, Neal Norwitz <[EMAIL PROTECTED]> wrote:
> On 10/16/05, Neal Norwitz <[EMAIL PROTECTED]> wrote:
> > On 10/10/05, Neal Norwitz <[EMAIL PROTECTED]> wrote:
> > > There's a problem with genexp's that I think really needs to get
> > > fixed. See http://python.org/sf/1167751 the details are below. This
> > > code:
> > >
> > > >>> foo(a = i for i in range(10))
> > >
> > > I agree with the bug report that the code should either raise a
> > > SyntaxError or do the right thing.
> >
> > The change to Grammar/Grammar below seems to fix the problem and all
> > the tests pass. Can anyone comment on whether this fix is
> > correct/appropriate? Is there a better way to fix the problem?
>
> Since no one responded other than Jiwon, I checked in this change. I
> did *not* backport it since what was syntactically correct in 2.4.2
> would raise an error in 2.4.3. I'm not sure which is worse. I'll
> leave it up to Anthony whether this should be backported.
>
> BTW, the change was the same regardless of old code vs. new AST code.
>
> n
> ___
> 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/seojiwon%40gmail.com
>
___
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] conditional expressions - add parens?
With parentheses, we can use "if cond then val1 else val2" form without the burden of hacking the parser, although the cost of the keyword "then" is still there. so, some possible forms that prompts in my mind are level = (if "absolute_import" in self.future then 0 else -1) level = (if "absolute_import" in self.future: 0 else: -1) level = (0 if "absolute_import" in self.future else -1) -Jiwon On 3/7/06, Jeremy Hylton <[EMAIL PROTECTED]> wrote: > On 3/6/06, Alex Martelli <[EMAIL PROTECTED]> wrote: > > > > On Mar 6, 2006, at 9:17 AM, Jim Jewett wrote: > > ... > > > I think that adding parentheses would help, by at least signalling > > > that the logic is longer than just the next (single) expression. > > > > > > level = (0 if "absolute_import" in self.futures else -1) > > > > +1 (just because I can't give it +3.1415926...!!!). *Mandatory* > > parentheses make this form MUCH more readable. > > Recent language features seem to be suffereing from excessive > parenthesisitis. I worry that people will stop remembering which > expressions requirement parens in which context. Perhaps the solution > is to require parens around all expressions, a simple consistent rule. > If so, then adding parens around all statements is a fairly natural > extension, which solves a number of problems like how to make a richer > lambda. > > Jeremy > ___ > 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/seojiwon%40gmail.com > ___ 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] problem with genexp
On 10/16/05, Neal Norwitz <[EMAIL PROTECTED]> wrote:
> On 10/10/05, Neal Norwitz <[EMAIL PROTECTED]> wrote:
> > There's a problem with genexp's that I think really needs to get
> > fixed. See http://python.org/sf/1167751 the details are below. This
> > code:
> >
> > >>> foo(a = i for i in range(10))
> >
> > I agree with the bug report that the code should either raise a
> > SyntaxError or do the right thing.
>
> The change to Grammar/Grammar below seems to fix the problem and all
> the tests pass. Can anyone comment on whether this fix is
> correct/appropriate? Is there a better way to fix the problem?
>
> -argument: [test '='] test [gen_for] # Really [keyword '='] test
> +argument: test [gen_for] | test '=' test ['(' gen_for ')'] # Really
> [keyword '='] test
The other option would be changes in the Python/compile.c (somewhat)
like following
diff -r2.352 compile.c
6356c6356,6362
- if (TYPE(n) == argument && NCH(n) == 3) {
---
+ if (TYPE(n) == argument && NCH(n) == 4) {
+ PyErr_SetString(PyExc_SyntaxError,
+ "invalid syntax");
+ symtable_error(st, n->n_lineno);
+ return;
+ }
+ else if (TYPE(n) == argument && NCH(n) == 3) {
but IMO, changing the Grammar looks more obvious.
>
> n
> ___
> 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/seojiwon%40gmail.com
>
>
___
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] Let's just *keep* lambda
On 2/6/06, Christopher Armstrong <[EMAIL PROTECTED]> wrote: > On 2/7/06, "Martin v. Löwis" <[EMAIL PROTECTED]> wrote: > > Brett Cannon wrote: > > > But I know that everyone and their email client is against me on this > > > one, so I am not going to really try to tear into this. But I do > > > think that lambda needs a renaming. Speaking as someone who still > > > forgets that Python's lambda is not the same as those found in > > > functional languages > > > > Can you elaborate on that point? I feel that Python's lambda is exactly > > the same as the one in Lisp. Sure, the Lisp lambda supports multiple > > sequential expressions (the "progn" feature), but I understand that > > this is just "an extension" (although one that has been around several > > decades). > > > > Of course, Python's expressions are much more limited as Lisp's (where > > you really can have macros and special forms in as the "expression" > > in a lambda), but the lambda construct itself seems to be the very > > same one. > > If we phrase it somewhat differently, we can see that lambdas are > different in Python and Lisp, in a very practical way. First: > Everything in Lisp is an expression. There's no statement, in Lisp, > that isn't also an expression. Lambdas in Lisp can contain arbitrary > expressions; therefore you can put any language construct inside a > lambda. In Python, you cannot put any language construct inside a > lambda. Python's and Lisp's lambdas are effectively totally different. > > +1 on keeping Lambda, +1 on making it more useful. After lambda being made more useful, can I hope that I will be able to use lambda with multiple statements? :) Lambdas in Lisp and Python are different, but in the usability perspective they don't need to differ too much. -Jiwon ___ 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] Let's just *keep* lambda
On 2/8/06, Guido van Rossum <[EMAIL PROTECTED]> wrote: > On 2/8/06, Patrick Collison <[EMAIL PROTECTED]> wrote: > > And to think that people thought that keeping "lambda", but changing > > the name, would avoid all the heated discussion... :-) > > Note that I'm not participating in any attempts to "improve" lambda. Then, is there any chance anonymous function - or closure - is supported in python 3.0 ? Or at least have a discussion about it? (IMHO, closure is very handy for function like map, sort etc. And having to write a function for multiple statement is kind of good in that function name explains what it does. However, I sometimes feel that having no name at all is clearer. Also, having to define a function when it'll be used only once seemed inappropriate sometimes.) or is there already discussion about it (and closed)? -Jiwon -Jiwon > > Just about the only improvement I'd like to see is to add parentheses > around the arguments, so you'd write lambda(x, y): x**y instead of > lambda x, y: x**y. > > -- > --Guido van Rossum (home page: http://www.python.org/~guido/) > ___ > 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/seojiwon%40gmail.com > ___ 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] Let's just *keep* lambda
On 2/8/06, Josiah Carlson <[EMAIL PROTECTED]> wrote: > > Jiwon Seo <[EMAIL PROTECTED]> wrote: > > > > On 2/8/06, Guido van Rossum <[EMAIL PROTECTED]> wrote: > > > On 2/8/06, Patrick Collison <[EMAIL PROTECTED]> wrote: > > > > And to think that people thought that keeping "lambda", but changing > > > > the name, would avoid all the heated discussion... :-) > > > > > > Note that I'm not participating in any attempts to "improve" lambda. > > > > Then, is there any chance anonymous function - or closure - is > > supported in python 3.0 ? Or at least have a discussion about it? > > > > or is there already discussion about it (and closed)? > > Closures already exist in Python. > > >>> def foo(bar): > ... return lambda: bar + 1 > ... > >>> a = foo(5) > >>> a() > 6 Not in that we don't have anonymous function (or closure) with multiple statements. Also, current limited closure does not capture programming context - or variables. -Jiwon ___ 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] Let's just *keep* lambda
On 2/8/06, "Martin v. Löwis" <[EMAIL PROTECTED]> wrote:
> Jiwon Seo wrote:
> > Then, is there any chance anonymous function - or closure - is
> > supported in python 3.0 ? Or at least have a discussion about it?
>
> That discussion appears to be closed (or, not really: everybody
> can discuss, but it likely won't change anything).
>
> > (IMHO, closure is very handy for function like map, sort etc. And
> > having to write a function for multiple statement is kind of good in
> > that function name explains what it does. However, I sometimes feel
> > that having no name at all is clearer. Also, having to define a
> > function when it'll be used only once seemed inappropriate sometimes.)
>
> Hmm. Can you give real-world examples (of existing code) where you
> needed this?
Apparently, simplest example is,
collection.visit(lambda x: print x)
which currently is not possible. Another example is,
map(lambda x: if odd(x): return 1
else: return 0,
listOfNumbers)
(however, with new if/else expression, that's not so much a problem any more.)
Also, anything with exception handling code can't be without explicit
function definition.
collection.visit(lambda x: try: foo(x); except SomeError: error("error
message"))
Anyway, I was just curious that if anyone is interested in having more
closure-like closure in python 3.0 - in any form, not necessary an
extension on lambda.
-Jiwon
>
> Regards,
> Martin
>
___
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
