Re: [Python-ideas] More classical for-loop

On 18 February 2017 at 04:13, Joao S. O. Bueno wrote: > You can still use range. Yes thats what I do, see my proposal > I don't see the point in continuing this thread. How does this add to the syntax discussion? I was replying to Nicks quite vague comments which were

Re: [Python-ideas] Delayed Execution via Keyword

On Fri, Feb 17, 2017 at 9:45 PM, David Mertz wrote: > That will make it pretty much impossible to tell whether something is a >> > delayed "thunk" or not, since *any* attempt to inspect it in any way >> will cause it to reify. Maybe that's what we want. > > > This feels like a

Re: [Python-ideas] Delayed Execution via Keyword

On Fri, Feb 17, 2017 at 5:23 PM, Steven D'Aprano wrote: > > try: > Aardvark > except NameError: > from backport import Aardvark > > No such thing is possible for new syntax. So that counts as a > disadvantage of new syntax. Are we positive that there *must* be new >

Re: [Python-ideas] Delayed Execution via Keyword

On Fri, Feb 17, 2017 at 6:20 PM, Nathaniel Smith wrote: > > value = delayed: some_dict.get("whatever") > if value is None: > ... > > I.e., the question is, how does 'is' work on delayed objects? I guess > it has to force the promise and walk the proxy chain in each input and >

Re: [Python-ideas] Delayed Execution via Keyword

On Fri, Feb 17, 2017 at 2:35 PM, Joseph Hackman wrote: > I think we should use the colon to make the delayed word (or whatever word > is selected), unambiguously used in this way (and to prevent any existing > code from breaking). > > On 17 February 2017 at 17:09, David

Re: [Python-ideas] More classical for-loop

On Fri, Feb 17, 2017 at 06:31:19PM +0100, Mikhail V wrote: > I have said I need the index, probably you've misread my last comment. > Further more I explained why I think iteration over index should be the > preferred way, it help with readability a lot. Your concept of readability is clearly

Re: [Python-ideas] More classical for-loop

A short Meta-note: I see most people are bottom-replying and still many do top-reply, namely you Nick always do. I dont know if there is a rule, but it makes quite hard to manage/read post with mixed posting style. On 17 February 2017 at 23:51, Nick Timkovich wrote: > >

Re: [Python-ideas] Delayed Execution via Keyword

On Thu, Feb 16, 2017 at 9:24 PM, Joseph Hackman wrote: > Howdy All! > > This suggestion is inspired by the question on "Efficient debug logging". > > I propose a keyword to mark an expression for delayed/lazy execution, for > the purposes of standardizing such behavior

Re: [Python-ideas] Delayed Execution via Keyword

On 17 February 2017 at 20:23, Steven D'Aprano wrote: > > > I think it would be key, like async/await, to narrowly define the scope > in > > which the word delayed functions as a keyword. > > The PEP makes it clear that's just a transition phase: they will be > turned into

Re: [Python-ideas] Delayed Execution via Keyword

On Fri, Feb 17, 2017 at 04:02:01PM -0600, Abe Dillon wrote: > I'm fairly novice, so I could be way off base here, but it seems like the > inevitable conclusion to this problem is something like JIT compilation, > right? (admittedly, I know very little about JIT compilation) No. JIT compilation

Re: [Python-ideas] Delayed Execution via Keyword

On Fri, 17 Feb 2017 at 23:14 Joshua Morton wrote: > @ Ed > > Its my understanding that d[k] is always d[k], even if d or k or both are > delayed. On the other hand, `delayed d[k]` would not be, but you would need > to explicitly state that. I think its worth expanding

Re: [Python-ideas] Delayed Execution via Keyword

On 17 February 2017 at 18:13, Joshua Morton wrote: > @ Joseph > > Function annotations can be arbitrary python expressions, it is completely > legal to have something like > > >>> def foo(bar: lambda x: x + 1): > ... pass > > Why you would want that I can't

Re: [Python-ideas] Delayed Execution via Keyword

@ Joseph Function annotations can be arbitrary python expressions, it is completely legal to have something like >>> def foo(bar: lambda x: x + 1): ... pass Why you would want that I can't say, but it is legal. In the same way, `def foo(bar: delayed 1 + 1)` should probably be legal

Re: [Python-ideas] Delayed Execution via Keyword

On 17 February 2017 at 06:10, Steven D'Aprano wrote: > On Fri, Feb 17, 2017 at 12:24:53AM -0500, Joseph Hackman wrote: > > > I propose a keyword to mark an expression for delayed/lazy execution, for > > the purposes of standardizing such behavior across the language. > > > >

Re: [Python-ideas] Delayed Execution via Keyword

I think we should use the colon to make the delayed word (or whatever word is selected), unambiguously used in this way (and to prevent any existing code from breaking). On 17 February 2017 at 17:09, David Mertz wrote: > That was a problem with the colon that occurred to me. I

Re: [Python-ideas] More classical for-loop

Iterating over range(len(collection)) is one of the worst anti-patterns in Python. I take great pains to slap my students who do that. On Feb 17, 2017 9:32 AM, "Mikhail V" wrote: > > On 17 February 2017 at 17:37, Chris Angelico wrote: > >> On Sat, Feb

Re: [Python-ideas] Delayed Execution via Keyword

That was a problem with the colon that occurred to me. I think it can't be tokenized in function annotations. Plus I still think the no-colon looks better. But that's bikeshedding. Also other words are plausible. I like lazy even more than delayed, I think. Still, I'd love the construct whatever

Re: [Python-ideas] Delayed Execution via Keyword

On Fri, 17 Feb 2017 at 21:58 Joshua Morton wrote: > Ed, I'm not seeing this perceived problem either. > > if we have > > >>> d = delayed {'a': 1, 'b': 2} # I'm not sure how this is delayed > exactly, but sure > >>> k = delayed string.ascii_lowercase[0] >

Re: [Python-ideas] Delayed Execution via Keyword

On Fri, 17 Feb 2017 at 21:57 Joseph Jevnik wrote: > > You should be able to pass the result to *any* existing code that > expects a function and sometimes calls it, and the function should be > called when that happens, rather than evaluated to a delayed object and > then

Re: [Python-ideas] Delayed Execution via Keyword

Ed, I'm not seeing this perceived problem either. if we have >>> d = delayed {'a': 1, 'b': 2} # I'm not sure how this is delayed exactly, but sure >>> k = delayed string.ascii_lowercase[0] >>> d[k] 1 I'm not sure how the delayedness of any of the subexpressions matter, since

Re: [Python-ideas] Delayed Execution via Keyword

On Fri, 17 Feb 2017 at 21:21 Joseph Jevnik wrote: > About the "whatever is d[k]" in five minutes comment: If I created an > explict closure like: `thunk = lambda: d[k]` and then mutated `d` before > evaluating the closure you would have the same issue. I don't think it is >

Re: [Python-ideas] Delayed Execution via Keyword

On Fri, 17 Feb 2017 at 21:18 Joseph Jevnik wrote: > There is no existing code that uses delayed execution so we don't need to > worry about breaking it. > I think you're missing the point here. This thing is transparent—that's sort of the entire point—so you can pass delayed

Re: [Python-ideas] Delayed Execution via Keyword

There is no existing code that uses delayed execution so we don't need to worry about breaking it. I think it would be much easier to reason about if forcing an expression was always explicit. I am not sure what you mean with the second case; why are you delaying a function if you care about the

Re: [Python-ideas] Delayed Execution via Keyword

On Fri, 17 Feb 2017 at 19:38 Joseph Jevnik wrote: > Delayed execution and respecting mutable semantics seems like a nightmare. > For most indexers we assume hashability which implies immutability, why > can't we also do that here? Also, why do we need to evaluate callables >

Re: [Python-ideas] Delayed Execution via Keyword

> > Couldn't the same thing be true of delayed if it is always followed by a > colon? No. Because there are other reasons you'd follow the variable `delayed` with a colon: >>> delayed = 1 >>> d = {delayed: "oops!"} My earlier proposal (using unpacking syntax) doesn't work for the same reason.

Re: [Python-ideas] Delayed Execution via Keyword

I think it could even be true without, but the colon may cause ambiguity problems with function annotations. def foo(delayed: delayed: 1 + 2) is a bit odd, especially if `delayed` is chainable. --Josh On Fri, Feb 17, 2017 at 3:32 PM Joseph Hackman wrote: >

Re: [Python-ideas] Delayed Execution via Keyword

Couldn't the same thing be true of delayed if it is always followed by a colon? I.e. delayed=1 x= delayed: slow_function() print(delayed) # prints 1 -Joseph > On Feb 17, 2017, at 2:39 PM, Mark E. Haase wrote: > >> On Fri, Feb 17, 2017 at 1:55 PM, Joshua Morton

Re: [Python-ideas] Delayed Execution via Keyword

On Fri, Feb 17, 2017 at 1:55 PM, Joshua Morton wrote: > but I'm wondering how common async and await were when that was proposed > and accepted? Actually, "async" and "await" are backwards compatible due to a clever tokenizer hack. The "async" keyword may only appear

Re: [Python-ideas] Delayed Execution via Keyword

Delayed execution and respecting mutable semantics seems like a nightmare. For most indexers we assume hashability which implies immutability, why can't we also do that here? Also, why do we need to evaluate callables eagerly? re the thunk replacing itself with the result instead of memoizing the

Re: [Python-ideas] Delayed Execution via Keyword

I think trying to eager-ify subexpressions is absurdly difficult to do right, and also a problem that occurs in other places in Python already, so solving it only for this new thing that might very well go no further is a bit odd. I don't think versions that aren't transparent are much use. >

Re: [Python-ideas] Delayed Execution via Keyword

I did some quick thinking and a bit of research about some aspects of this proposal: There are a number of keyword options (delay, defer, lazy, delayed, deferred, etc.), a quick look through github says that of these, "deferred" seems to be the least used, but it still comes up quite a lot (350K

[Python-ideas] Fwd: Detecting Attribute Updates on Objects

Whoops, I forgot to subscribe before. Seems like now I'm able to send this idea, so let's try again :) According to this idea, the interpreter calls a function on an object O everytime an attribute A of it changes, recursing through objects that contain O as attribute as well.

Re: [Python-ideas] String Format Callable Flag (Was: Efficient Debug Logging)

On 2017-02-17 16:37, Mark E. Haase wrote: In the debug logging thread, somebody suggested the "%r" format specifier and a custom __repr__. This is a neat solution because Python logging already includes a "delayed" evaluation of sorts: it formats the logging string *after* it determines that the

Re: [Python-ideas] More classical for-loop

On Sat, Feb 18, 2017 at 4:31 AM, Mikhail V wrote: > I have said I need the index, probably you've misread my last comment. > Further more I explained why I think iteration over index should be the > preferred way, it help with readability a lot. Further discussion probably

Re: [Python-ideas] Delayed Execution via Keyword

I'd like to suggest a shorter keyword: `lazy` This isn't an endorsement. I haven't had time to digest how big this change would be. If this is implemented, I'd also like to suggest that perhaps packing and unpacking should be delayed by default and not evaluated until the contents are used. It

Re: [Python-ideas] Delayed Execution via Keyword

Agreed. I think this may require some TLC to get right, but posting here for feedback on the idea overall seemed like a good start. As far as I know, the basic list and dict do not inspect what they contain. I.e. d = {} d['a']= delayed: stuff() b=d['a'] b would end up as still the thunk, and

[Python-ideas] String Format Callable Flag (Was: Efficient Debug Logging)

In the debug logging thread, somebody suggested the "%r" format specifier and a custom __repr__. This is a neat solution because Python logging already includes a "delayed" evaluation of sorts: it formats the logging string *after* it determines that the message's log level is greater than or

Re: [Python-ideas] Delayed Execution via Keyword

On Sat, Feb 18, 2017 at 3:29 AM, Joseph Hackman wrote: > ChrisA: I am not sure about collections. I think it may be fine to not > special case it: if the act of putting it in the collection reads anything, > then it is evaluated, and if it doesn't it isn't. The ideal

Re: [Python-ideas] More classical for-loop

On 17 February 2017 at 04:59, Chris Angelico wrote: > On Fri, Feb 17, 2017 at 2:13 PM, Mikhail V wrote: > > Common use case: > > > > L = [1,3,5,7] > > > > for i over len(L): > >e = L[i] > > > > or: > > > > length = len(L) > > for i over length: > >

Re: [Python-ideas] Delayed Execution via Keyword

Pavol: I think that some sort of magic string that is not a string and is actually containing Python code could function, but is less elegant. ChrisA: I am not sure about collections. I think it may be fine to not special case it: if the act of putting it in the collection reads anything, then

Re: [Python-ideas] Delayed Execution via Keyword

On Sat, Feb 18, 2017 at 2:12 AM, Joseph Hackman wrote: > As for what triggers execution? I think everything except being on the right > side of an assignment. Even identity. So if a delayed expression would > evaluate to None, then code that checks is None should return

Re: [Python-ideas] Delayed Execution via Keyword

On Fri, Feb 17, 2017 at 10:10 PM, Steven D'Aprano wrote: >> the expression is executed and the delayed >> expression is replaced with the result. (Thus, the delayed expression is >> only every evaluated once). > > That's easily done by having the "delayed" keyword cache each

Re: [Python-ideas] Delayed Execution via Keyword

On Fri, Feb 17, 2017 at 12:24:53AM -0500, Joseph Hackman wrote: > I propose a keyword to mark an expression for delayed/lazy execution, for > the purposes of standardizing such behavior across the language. > > The proposed format is: > delayed: > i.e. log.info("info is %s", delayed:

Re: [Python-ideas] Light-weight call-by-name syntax in Python

On Fri, Feb 17, 2017 at 2:22 AM, Stephan Houben wrote: > Proposal: Light-weight call-by-name syntax in Python > > The following syntax > a : b > is to be interpreted as: > a(lambda: b) > > Effectively, this gives a "light-weight macro system" to Python, > since

Re: [Python-ideas] Delayed Execution via Keyword

Hi all, If we want this it might be interesting to investigate what the Scheme community has been doing, since they have had this (under the name "promises") for many years. Basically: Scheme: (delay expr) <=> proposed Python: delayed: expr The Scheme community has experimented with what

Re: [Python-ideas] More classical for-loop

On 17.02.2017 04:59, Chris Angelico wrote: On Fri, Feb 17, 2017 at 2:13 PM, Mikhail V wrote: Common use case: L = [1,3,5,7] for i over len(L): e = L[i] or: length = len(L) for i over length: e = L[i] Better use case: for i, e in enumerate(L): I totally

Re: [Python-ideas] Delayed Execution via Keyword

Even with the new syntax I would highly discourage delaying a function with observable side effects. It would make reasoning about the behavior of the program very difficult and debugging becomes much harder. On Fri, Feb 17, 2017 at 3:31 AM, David Mertz wrote: > I had forgotten

Re: [Python-ideas] Delayed Execution via Keyword

I had forgotten about Daisy! It's an interesting project too. The behavior of 'autodask()' is closer to what I'd want in new syntax than is plain dask.delayed(). I'm not sure of all the corners. But is definitely love to have it for expressions generally, not only pure functions. On Feb 17, 2017

Re: [Python-ideas] Delayed Execution via Keyword

You can let dask "see" into the function by entering it and wrapping all of the operations in `delayed`; this is how daisy[0] builds up large compute graphs. In this case, you could "inline" the identity function and the delayed object would flow through the function and the call to identity never