Re: [Python-ideas] Delayed Execution via Keyword

On Thu, Feb 16, 2017 at 11:15 PM, David Mertz wrote: > > This also means that a 'delayed' object needs to be idempotent. So > > x = delayed 2+2 > > y = delayed x > > z = delayed delayed delayed y > > > Wrapping more delays around an existing delayed object should probably > just

Re: [Python-ideas] Delayed Execution via Keyword

I think maybe the idiomatic pattern should be assignment rather than just bare name. E.g. f = delayed 1 + 2 # We want to evaluate f before next op for some reason *f = f* # f is already a concrete value now, before calculating g g = f * 7 I think if we follow my rule that "everything lazy

Re: [Python-ideas] Delayed Execution via Keyword

On Thu, Feb 16, 2017 at 10:33 PM, Joshua Morton wrote: > David, can you elaborate on your example? > > if we replaced line four with > > >>> x = my_lazy_func(b, delayed c) > > what would the value of `x` be, and how would this differ from either > The value of the

Re: [Python-ideas] Delayed Execution via Keyword

David, can you elaborate on your example? if we replaced line four with >>> x = my_lazy_func(b, delayed c) what would the value of `x` be, and how would this differ from either >>> x = delayed my_lazy_func(b, delayed c) or >>> x = delayed my_lazy_func(b, c) To put it another

Re: [Python-ideas] Delayed Execution via Keyword

Dask also has a function delayed() that may be used as an decorator and in other ways like: >>> from dask import delayed >>> from operator import add, mul >>> a = delayed(add)(1, 2) >>> b = delayed(mul)(a, 3) >>> b Delayed('mul-1907f29b-60a4-48af-ba2a-938556555f9b') >>> c = b.compute() >>> c

Re: [Python-ideas] Delayed Execution via Keyword

I rather like this at first brush! On Feb 16, 2017 9:25 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

[Python-ideas] Delayed Execution via Keyword

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 across the language. The proposed format is: delayed: i.e. log.info("info is %s", delayed:

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

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): ChrisA

[Python-ideas] More classical for-loop

Here is a summary of my idea about for-loop. It focuses on readability and does not take in account possible technical nuances. This is my first attempt to write a full proposal and I suppose it is ok to post it here. Many things (readability) can raise opinion based dispute, so it is sort of my

Re: [Python-ideas] Efficient debug logging

> > You are right that Python logging infrastructure can deal with logs at a > finer grain, but the code required to do it is more verbose than logical > switches The default behavior of filters seems pretty useful to me (filtering by hierarchy), but, then again, so do the default log levels. I

Re: [Python-ideas] Efficient debug logging

On Feb 16, 2017, at 03:20 PM, M.-A. Lemburg wrote: >I know some people will disagree, but IMO using "assert" is the wrong >approach in such situations - it's meant for development and testing >only, not as short-cut to avoid having to write a proper error >handler :-) I use assertions for

Re: [Python-ideas] Efficient debug logging

Yeah, I had a similar issue in a previous company. A colleague wrote a script using a regex to remove these debug logs in the .py code. IHMO the clean design for that would be to support officially preprocessors in Python. My PEP opens the gate for that: https://www.python.org/dev/peps/pep-0511/

Re: [Python-ideas] Efficient debug logging

> On 15 Feb 2017, at 21:06, Abe Dillon wrote: > > On 15.02.2017, 20:39 Kyle Lahnakoski wrote: > Log "levels" never made sense to me; how can a single dimension be useful > substitute for a number of binary switches? With log "levels", you either > don't have enough

Re: [Python-ideas] Efficient debug logging

So if python converted: debugLog( <# ‘format string %r’ % (expensive(),) #> ) Into: def __tmp__(): yield ‘format string %r’ % (expensive(),) debugLog( __tmp__ ) Then debugLog can detect the generator and call __next__ only if logging is enabled. I