Mailman 3 July 2009 - Python-ideas

Re: [Python-ideas] Where-statement (Proposal for function expressions)
by Carl Johnson 18 Jul '09

18 Jul '09

Daniel Stutzbach wrote: > Unlikely, but this is: > > total =3D sum(f(item) for item in lst) where: > def f(item): > return item.size if item.size > 0 else 1 Yes, that seems much more sensible than trying to repeat the where's inside of list comp or gen exp. Daniel Stutzbach wrote: > How about the following as additional syntactic sugar for the common one-= function case? > > x =3D blah(f) where def f(item): > body_of_f I like it. Gerald Britton wrote: > Why not just use the Haskell approach? > > foo(x,y) =3D myfunc(bar) where: > =A0 =A0 =A0 =A0 =A0 myfunc, bar =3D f(x), g(y) where: > =A0 =A0 =A0 =A0 =A0 =A0 =A0f,g =3D func1, func2 Because I've been looking at that for a couple minutes and still have no idea what it is supposed to mean. :-( List comprehensions and pattern matching are the only Haskell features that make any sense to me. Jan Kaliszewski wrote: > I don't like the direction of limiting content of the block to set of sin= gular simple statements. I suppose where-block should simply create a separ= ate nested scope. Yes. It strikes me that one of the problems with Ruby is that there are different scoping rules for blocks, lambda, methods, procs, and whatever else=85 It would be much easier for users if "where" blocks had the exact same scoping rules as functions. Daniel Stutzbach's suggested equivalence strikes me as exactly correct: [return|yield|x=3D] expression_list where: suite is roughly equivalent to: def where_expression(): suite return expression_list [return|yield|x=3D] where_expression() -- Carl Johnson

20 56

Immemorial desire for "do-while"-like construction
by Jan Kaliszewski 16 Jul '09

16 Jul '09

Hello, The issue has been coming back repeatedly: How we could elegantly and pythonic'ly avoid repeating ourselves if we need the control flow structure that e.g. in PASCAL has the form: repeat ... until CONDITION In Python we must use while-loop in not very DRY (Don't Repeat Yourself) manner: SOME ACTIONS HERE ... while CONDITION: THE SAME ACTIONS AGAIN ... (See also: http://www.python.org/dev/peps/pep-0315/ http://mail.python.org/pipermail/python-dev/2006-February/060718.html http://preview.tinyurl.com/nodgwt ) Maybe here the simplest approach can lead us to the solution? I.e.: repeat while CONDITION: SOME ACTIONS HERE ... In human language it'd mean: do ACTIONS once unconditionally, then *repeat* them while the CONDITION is true. Additional advantage is that probably for many people associate 'repeat' with such construction (from experience with other languages). What do you think about the idea? -- Jan Kaliszewski <zuo(a)chopin.edu.pl>

8 10

Where-statement (Proposal for function expressions)
by Weeble 15 Jul '09

15 Jul '09

> Date: Wed, 15 Jul 2009 19:55:15 +1200 > From: Greg Ewing <greg.ewing(a)canterbury.ac.nz> > To: python-ideas(a)python.org > Subject: [Python-ideas] Where-statement (Proposal for function > expressions) > Message-ID: <4A5D8B63.4040509(a)canterbury.ac.nz> > Content-Type: text/plain; charset=UTF-8; format=flowed > > Carl Johnson wrote: > >> My suggestion for future would be language extenders is that they try >> to solve a broader problem than just the "how do I make callbacks more >> convenient" problem. > > One such extension might be a "where" block. Applied > to the current problem: > > foo(f) where: > def f(x): > ... I was just thinking of something similar: in: foo(f,a) let: def f(x): ... a = ... (Keywords open to debate.) It's a little verbose, but I dislike it much less than all the proposals that introduce special sigils or do weird things to the syntax of the code. Things I like about it: there's a clear warning (the "in:") right at the start that the statement (or block?) is special and relies on code that comes after; the syntax isn't complex; both lets you provide a name and prevents it leaking into places you don't want it; and the contents of both the "in:" block and the "let:" block are normal Python. I'd expect the behaviour to be something like this: execute the "let:" block in its own nested scope, then execute the "in:" block in the regular local scope but with the symbols defined by the "let:" block available. Does that make some sort of sense? Most of the things I like are achieved by Greg's "where:" block, the only thing I don't like about it is tacking a keyword onto the end of a statement, which feels a bit awkward to me. That may just be aesthetics. I certainly like the "where:" idea a lot better than the other proposals. It seems to achieve the most utility with the least confusing syntax.

1 0

Decorations
by Andrey Fedorov 13 Jul '09

13 Jul '09

Hi there, It's always bothered me that decorators require a lot of "cruft" to work. Consider an example, from PEP-318 <http://www.python.org/dev/peps/pep-0318/>(Decorators for Functions and Methods): def returns(rtype): def check_returns(f): def new_f(*args, **kwds): result = f(*args, **kwds) assert isinstance(result, rtype), \ "return value %r does not match %s" % (result,rtype) return result new_f.func_name = f.func_name return new_f return check_returns It seems to me everything but line 5 "assert..." is cruft. In my mind, it makes sense to call that line the "decoration" (part of the decorator). Since it's a decoration that's executed after the decorated function, it makes sense to call it a post-decoration, one that may be more nicely defined as: @postdecoration def returns(result, rtype): assert isinstance(result, rtype), "return value %r does not match %s" % (result, rtype) Then, `returns' can be used as in PEP-318 (but without the cruft). I've defined similar `decoration', and `predecoration' decorators. I use the latter for my Django views to accept POST parameters as arguments: def filter_dict(d, fltr): return dict( (str(x.lower()), d[x]) for x in d if x.lower() in fltr ) @predecoration def takesPOST(f, args): if len(args) == 1: fargs = getargspec(f).args get = args[0].POST return filter_dict(get, fargs[1:]) This way, I can define a view login(reqest, user, password) which can be called simply from another view, without having to construct a special `request' object. An initial shot at the definitions is here: http://gist.github.com/146235 The design decisions I'm least confident about is the argument specs. In the `predecoration' example, the argument `args' is a special name that specifies the arguments passed into the decoratee, `kwargs' would be the keyword arcgs passed into the decorateee, dec_args and dec_params being the arguments passed into the *decorator*. This doesn't seem like an optimal solution. The problem I'm trying to solve is "moving from a decoration which takes no parameters to a decoration which takes parameters". For example, it was trivial to refactor takesPOST to group POST parameters by regex passed into the decorator. Still, I'm open to questions, ideas, opinions, etc. What do you guys this? Cheers, Andrey

3 4

Signed eggs?
by Tim Lesher 10 Jul '09

10 Jul '09

In all the current discussion on python-dev about improving eggs and setuptools in general, I don't think I've seen anything regarding digitally signed eggs or verifiable egg distribution. Google doesn't seem to turn anything up, either. Has anyone put any thought into this? -- Tim Lesher <tlesher(a)gmail.com>

3 4