Mailman 3 September 2008 - Python-ideas

Re: [Python-ideas] Statements vs Expressions... why?
by Cliff Wells Sept. 12, 2008

Sept. 12, 2008

On Thu, 2008-09-11 at 16:21 -0400, Mike Meyer wrote: > On Thu, 11 Sep 2008 12:45:06 -0700 > Cliff Wells <cliff(a)develix.com> wrote: > > > The thought of running into something like the above in production > > > code is enough to make me bounce pretty much any proposal that would > > > allow it. Compared to that, > > > > > > a = (18 if x < 23 else 24) + (29 if y < 23 else 81) > > > > a = ( if x < 23: 18 else: 24 ) + ( if y < 23: 29 else: 81 ) > > And you ignored the constraint that you had to leave the newlines and > indentations in the statement. Sorry, I'm not going to satisfy "now do it with one hand behind your back" sort of challenges. This is the syntax I'm proposing, so why would I provide it any other way? > Also, you've claimed a number of times > that you didn't want to change the syntax of python, but this clearly > requires a syntax change, as current python syntax doesn't allow > multiple colon-separated statements on a line. No, I stated I didn't want to *add* any additional syntax (i.e. block delimiters, keywords or whatnot), nor do I want to break existing code. I certainly propose changing the grammar (albeit in a demonstrably backwards-compatible way). > > Granted, today this is not valid Python, but supporting it doesn't seem > > to break existing Python code either. This is precisely how Logix does > > it (from the page I linked you to earlier): > > > > x = if 2+2==4: "I thought so" else: "hmmm..." > > > > In any case, your above code seems intentionally formatted to be > > unreadable, something that could be achieved under any circumstances. > > For example, here's your code reformatted in a fashion similar to your > > first example: > > Yup, and if that was what someone was proposing, it'd be a reason to > reject it. But nobody is proposing turning expressions into > statements, which is what you just did. No, I turned statements into expressions, which is what I've been proposing since the very first post. I cannot possibly fathom where you came up with the exact opposite. You continue to be stuck in a rut of demanding that something be a statement when this is simply not a requirement. Perfectly legal (although useless) Python: 1 2 3 Note that this does not somehow magically turn numbers into statements. It affirms that expressions can be used as statements (something that is already true in Python). Ask yourself, is a function call a statement or an expression? It's an expression (a function call *always* returns a value), and yet it can be used alone: def foo(x): return x**2 foo(2) # expression used as a statement y = foo(3) # expression used as an expression > > What we do gain with the idea I've forwarded is a single, more flexible > > if-expression in place of an if-statement and an if-operator with > > inverted syntax. > > But that's not what you've been claiming you wanted. You've been > claiming you wanted statements to be expressions. Uh... yeah. Seriously: which part of "this is an example of turning a particular Python statement into an expression" am I not conveying to you? > I claim that doing > that makes for ugly code, because statements - with newlines and > whitespace as a critical part of the syntax - are ugly to embed in > expressions. I've asked for examples and not gotten them. I provide an > ugly example of statements embedded in an expressions, and you respond > by providing an alternative trinary operator to rewrite it. I did not. I'm going to let you try to understand that one line of code better after you've realized you wouldn't need an operator if the if-statement were an if-expression. > I still want to see how you propose to embed *statements* into > arbitrary expressions, complete with newlines and proper > indentation. Say... > a = ( > if x < 24: > go_make_some_side_effects() > a_nice_long_function() * another_nice_long_function() > else: > go_make_different_side_effects() > a_twisty_little_function() * a_nice_long_function() > ) \ > + ( > if y < 23: > go_make_some_different_side_effects() > a_twisty_little_function() * another_nice_long_function() > else: > go_make_different_side_effects() > a_nice_long_function() * a_twisty_little_function() > ) > > This is still simply bletcherous compared to the obvious legal > rewrite. Ignoring your superfluous backslash, the above is a perfectly valid example. Of course, like all contrived examples, it doesn't necessarily convey *why* you'd want to do this, but the syntax is correct. Also, go_make_some_side_effects() is probably ill-advised, and not something usually done in an FP style which you claim to be familiar with. Imperative programming is all about side-effects whereas functional programming is all about avoiding them. > But it's about the cleanest way I've seen to deal with the > issue. Using operator.add might be a bit cleaner, but not enough so to > justify using operator.add. > > And we haven't gotten *really* warped yet, with statements appearing > as controlling expressions inside of other statements. While making > this "simple" changes allows you to make a few use cases simpler, it > also makes some truly ugly things seem reasonable. Frankly, I'd rather > let the experts deal with those use cases individually with > well-thought out extensions than open this can of worms - unless you > can show how to do those kinds of embeddings in ways that *aren't* > ugly. I point you to the entire history of FP programming and we can leave it at that. If you've programmed in Lisp as you claim then I cannot see any reason to rehash what you, by definition, must already know, but keep pretending not to. Unless you're willing to admit you simply don't know FP or that you are being intentionally obtuse for some unfathomable reason, then I'm not interested in pursuing this discussion with you any further. If it's a matter of me not being clear, then I apologize, but frankly I've been as clear as I am able so further discussion would still certainly seem to be fruitless. Regards, Cliff

4 7

Re: [Python-ideas] Statements vs Expressions... why?
by Cliff Wells Sept. 12, 2008

Sept. 12, 2008

On Thu, 2008-09-11 at 13:48 -0400, Mike Meyer wrote: > On Thu, 11 Sep 2008 10:40:29 -0700 > Cliff Wells <cliff(a)develix.com> wrote: > > Several examples have already been posted in this thread (which has > > probably gone on long enough). > > Yes, I mentioned them. Roughly half have come from *other* people, so > they don't count. Since they were more or less exactly what I had in mind, I think they suffice. > If you really believe the thread has gone on long enough, then the > proposal is dead. If you are actually interested in seeing it happen, > then the real obstacle is that expressions built out of statements > that use indentation for control flow are *ugly*. That's only for people not used to seeing them or programming in that style. Proponents of functional and expression-oriented languages would strongly disagree. Whether or not they might be ugly *in Python* is a seemingly separate question, but I don't think it is. In fact, it seems it would be much more attractive than many traditional FP languages. > If you have a way > around it, I'd love to see it. If you don't - then again, the proposal > is dead. > > > Anyway, as was mentioned earlier, Logix very much resembles what I'm > > describing: > > > > http://www.livelogix.net/logix/tutorial/3-Introduction-For-Python-Folks.htm… > > That link doesn't have any examples, it just repeats many of the words > that have already been posted. Yes, the Logix documentation is sorely lacking (I believe the project to be long-dead), but the intent seemed clear enough to me. > If you have a link with real live > examples - in particular, showing how you can use for loops to replace > lcs and similar things, please provide it. >From an earlier example I posted: dispatch = { '1': lambda x: ( for i in range(x): if not x % 2: yield 0 else: yield 1 ), '2': lambda x: ( for i in range(x): yield i ) } for i in dispatch[val](1): print i Overall, if you are familiar with functional programming, it doesn't take a lot to imagine more examples. If you aren't, then it probably won't make much sense or seem too appealing in any case. Regards, Cliff

2 1

Re: [Python-ideas] Statements vs Expressions... why?
by Cliff Wells Sept. 11, 2008

Sept. 11, 2008

On Thu, 2008-09-11 at 14:56 -0400, Mike Meyer wrote: > Here's where we disagree. I love functional programming, having > written 10s of thousands of lines of LISP in the past. The lack of the > ability to pass around functions in Ruby is why I haven't ever written > any. You can: def a(x,y) x + y end def x(b) send(b,3,4) end puts x(:a) # 7 The semantics are a bit different, but the result is the same (caveat: I'm no Ruby expert by any stretch of the imagination). Anyway, not important =) > And I consider the results of trying to cram python statements > into expressions as almost universally ugly. I'm willing to consider > you might have a solution, but you refuse to *show* it to me. I'm not sure what else you'd like to see. I've provided an example with a for-loop as generator and if-expressions. I've no intention of writing a full PEP covering all use-cases at this point. > > Overall, if you are familiar with functional programming, it doesn't > > take a lot to imagine more examples. If you aren't, then it probably > > won't make much sense or seem too appealing in any case. > > You're right - it's easy to image in more examples. Really, really > ugly ones, like: > > a = ( > if x < 23: > 18 > else: > 24 > ) + ( > if y < 23: > 29 > else: > 81 > ) > > The thought of running into something like the above in production > code is enough to make me bounce pretty much any proposal that would > allow it. Compared to that, > > a = (18 if x < 23 else 24) + (29 if y < 23 else 81) a = ( if x < 23: 18 else: 24 ) + ( if y < 23: 29 else: 81 ) Granted, today this is not valid Python, but supporting it doesn't seem to break existing Python code either. This is precisely how Logix does it (from the page I linked you to earlier): x = if 2+2==4: "I thought so" else: "hmmm..." In any case, your above code seems intentionally formatted to be unreadable, something that could be achieved under any circumstances. For example, here's your code reformatted in a fashion similar to your first example: a = ( 18 if x < 23 else 24 ) + ( 29 if y < 23 else 81 ) Just as unreadable (although really I don't find it terrible to comprehend... certainly no worse than a complicated listcomp). At the end of the day, no programming language is going to be able to enforce sane coding style (even Python's whitespace can be circumvented to a large degree). What we do gain with the idea I've forwarded is a single, more flexible if-expression in place of an if-statement and an if-operator with inverted syntax. Regards, Cliff

1 0

Re: [Python-ideas] Statements vs Expressions... why?
by Cliff Wells Sept. 11, 2008

Sept. 11, 2008

On Thu, 2008-09-11 at 11:01 -0400, Mike Meyer wrote: > On Wed, 10 Sep 2008 14:54:44 -0700 > Cliff Wells <cliff(a)develix.com> wrote: > > There were several design decisions to be made when designing Breve, the > > first and foremost being "will Breve templates be full-blown Python > > programs or will they be limited to expressions?". I chose the latter > > for a few reasons: > > That seems to be a very poor decision. If you want Breve templates to > play well with Python code (i.e. - be able to have Breve classes > inherit from Python classes and vice versa - but I guess without > statements, you don't have classes, so all of that is moot. Of course, > not having classes seems like a bad idea as well. Just to be clear because it appears to me you aren't quite following: Breve templates *are* Python code, or more exactly, they are a single Python expression. There is no preprocessor or interpreter that turns Breve into Python. It's just a bunch of class-magic. The decision to be a single large expression is largely because this is a *template* engine and an expression maps most directly to XML because XML is structured similarly: html [ head [ title [ 'A Brevé Template' ] ], body [ h1 [ 'Briefly, Brevé' ], br, div ( style = 'text-align: center;' ) [ span [ ''' As you can see, Brevé maps very directly to the final HTML output. ''' ] ] ] ] This is opposed to allowing the full of Python which would require a lot of syntax that is extraneous to the markup being generated (and most importantly would have caused a visual disjoint between the Breve source template and the final output). > Further, why do you feel that Breve templates - even if limited to > expressions - need to be limited to what Python expressions can do? Again, because Breve *is* Python. It's an internal DSL. Please see http://martinfowler.com/bliki/DomainSpecificLanguage.html for a definition of what that means. Another example of an internal DSL that's more widely used would be SQLAlchemy. Regards, Cliff

1 0

Re: [Python-ideas] Statements vs Expressions... why?
by Cliff Wells Sept. 11, 2008

Sept. 11, 2008

On Thu, 2008-09-11 at 10:44 -0400, Mike Meyer wrote: > On Wed, 10 Sep 2008 15:39:49 -0700 > Cliff Wells <cliff(a)develix.com> wrote: > > I strongly disagree. The artificial distinction between statements and > > expressions is the definition of *inconsistent*. Why do we have two > > versions of the "if" conditional? Why do we have "for" loops *and* list > > comprehensions? They express the same ideas, but the limitations in one > > required growing the language another direction. > > Because they are each more readable for the cases they handle. I > initially didn't like list comprehensions. In practice, they're not > very hard to write, and even easier to read. Doing away with for loops > because we have them would force you to construct - and then > immediately throw away - lists in the case where the for loop was > being executed for side effects. > > There have been a number of similar proposals - I've even generated > some. The general problem is that the results of embedding statements > with important indentation into expressions is ugly. While I've seen a > lot of words on this topic, I've seen very few concrete examples - and > those seem to come as often from opponents to the idea as they do from > you. > > So, how about some concrete examples? Show us translations of the > various if statements and for loops, so we have something concrete to > use to judge readability? Several examples have already been posted in this thread (which has probably gone on long enough). Anyway, as was mentioned earlier, Logix very much resembles what I'm describing: http://www.livelogix.net/logix/tutorial/3-Introduction-For-Python-Folks.htm… Regards, Cliff

1 0

Fwd: About calling syntax
by Zaur Shibzoukhov Sept. 11, 2008

Sept. 11, 2008

---------- Forwarded message ---------- From: Zaur Shibzoukhov <szport(a)gmail.com> Date: 2008/9/10 Subject: Re: [Python-ideas] About calling syntax To: Bruce Leban <bruce(a)leapyear.org> 2008/9/10 Bruce Leban <bruce(a)leapyear.org> > I'm sure there are scenarios where this is useful but I think in general it > would be less readable. As it is, I can't miss a positional argument in the > middle of a long list of keyword arguments: > > foo(a=b,c=d,e=f,g=h,i=j,k=l,m) > > But programmer could select most readable form of function call (as the case may be). Best regards, Zaur

4 4

Fwd: should there be a difference between generators and iterators?
by Zaur Shibzoukhov Sept. 10, 2008

Sept. 10, 2008

---------- Forwarded message ---------- From: Zaur Shibzoukhov <szport(a)gmail.com> Date: 2008/9/10 Subject: Re: [Python-ideas] should there be a difference between generators and iterators? To: Bruce Frederiksen <dangyogi(a)gmail.com> I think it should be as import types types.GeneratorType.__enter__ = MethodType(lambda self: self, types.GeneratorType) types.GeneratorType.__exit__ = MethodType(lambda self: self.close(), types.GeneratorType) >So that the objects returned by his generator functions (functions containing 'yield') >have context manager capability? IMHO yes. Zaur 2008/9/10 Bruce Frederiksen <dangyogi(a)gmail.com>: > Zaur Shibzoukhov wrote: >> >> Bruce Frederiksen wrote: >> >>> >>> Since there is no need to clean up after iterators in general, but only >>> for generators specifically; and since the BDFL has nixed my point #5, >>> it makes sense to only add the __enter__ and __exit__ to generators. >>> (And, by extension, itertools). >>> >> >> It makes more sense to allow extending of builtin types in order to >> support different protocols >> (not only protocol for "with" statement) >> > > Do you mean the python programmer should do: > > import types > > types.GeneratorType.__enter__ = lambda self: self > types.GeneratorType.__exit__ = lambda self: self.close() > > So that the objects returned by his generator functions (functions > containing 'yield') have context manager capability? >

1 0

About calling syntax
by Zaur Shibzoukhov Sept. 10, 2008

Sept. 10, 2008

Talin wrote: >However, to address the OP's question, do this instead: >foo = \ > Foo(x=1, y=2)( > Foo(x=4, y=5)( > Foo(x=3,y=4)(), > Foo(x=5,y=6)()) > ) > ) I use this form in my real coding. Georg Brandl wrote: > However, exchanging poisitional and keyword arguments is not in the scope of > the PEP, and isn't likely to have any future at all -- it's just too ambiguous > when the called object has named arguments instead of a catch-all *args in > its signature. More precisely I asked about the following thing. Let def foo(*args, **kw): ... So in call: foo(x=2,y=3, a,b,c) args = [a,b,c] and kw = {'x':2, 'y':3} in call: foo(a,b,c, x=2, y=3) args = [a,b,c] and kw = {'x':2, 'y':3} too. It's just simmetrical form of calling syntax. Best regards, Zaur

2 1

should there be a difference between generators and iterators?
by Zaur Shibzoukhov Sept. 10, 2008

Sept. 10, 2008

Bruce Frederiksen wrote: >Since there is no need to clean up after iterators in general, but only >for generators specifically; and since the BDFL has nixed my point #5, >it makes sense to only add the __enter__ and __exit__ to generators. >(And, by extension, itertools). It makes more sense to allow extending of builtin types in order to support different protocols (not only protocol for "with" statement)

2 1

should there be a difference between generators and iterators?
by Bruce Frederiksen Sept. 10, 2008

Sept. 10, 2008

There are several points here that might or might not be adopted individually. The specific prompt for this message is that I've run into a snag using generators with 'itertools.chain.from_iterable'. I need to be able to control when the generators called by 'chain' get closed (so that their 'finally' clauses are run). Unfortunately, chain does not propagate 'close' (or 'throw' or 'send') back to the generators that it's using. Nor, for that matter do any of the other tools in itertools, or the builtin map function (to my knowledge). I propose the following. Each of these is independent of the others, but all related to cleaning up how this works: 1. All of the itertools and map (and I've no doubt left some others out here) be extended to propagate the extra generators methods: close, throw and send. 2. That the 'for' loop be extended so that if an exception occurs within its body, it calls 'throw' on its iterable (if it has a throw method). 3. That the 'for' loop be extended to call the 'close' method on its iterable (if it has a close method) when the loop terminates (either normally, with break, or with an exception). 4. That a 'not_closing' builtin function be added that takes an iterable and shields it from a 'close' call. 5. That 'close' and 'throw' be added to all iterables. Motivation: The motivation for each proposal is (by their number): 1. This is the one that I'm specifically stuck on. I was relying on garbage collection to do this, but this doesn't work in jython and ironpython... Since the chain function is dealing with two iterables (an inner and outer iterable), I think that it makes sense for it to check whether each of these have the extra methods or not. For example, the inner iterable may have a 'close', but not the outer iterable (or vise versa). This shouldn't cause an error if 'close' is called on the chain. This one, specifically, would be helpful for me to move to Python 3K; so the sooner the better! (Please!) 2. There has been some discussion here about extending 'for' loops that has touched on non-local continue/break capability. If step 2 is provided, this capability could be provided as follows: class funky: ... def continue_(self): raise ContinueError(self) def break_(self): raise BreakError(self) def throw(self, type, value, tb): if issubclass(type, ContinueError) and value.who is self: return next(self) if issubclass(type, BreakError) and value.who is self: raise StopIteration top = funky(iterable1) for x in top: middle = funky(iterable2) for y in middle: bottom = funky(iterable3) for z in bottom: ... middle.continue_() 3. But this is a problem with: for line in filex: if test1(line): break for line in filex: ... which brings us to: 4. A solution to the above: for line in not_closing(filex): if test1(line): break for line in filex: ... 5. I thought that I may as well throw this in for discussion... This might cause some consternation to those who has written their own iterables...

5 9