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
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 1
On 2/17/17, Mikhail V wrote:
> Rationale
> ---
>
> Removing the brackets will help concentrate on other
> parts of code [...]
Do you think that
for i in steps * 10:
for i in steps * 1-10:
for i in steps * 1-10 ^ 2:
are better than
for i in range(10):
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 about Daisy! It's
Agreed. But there might be cases where something occurring at most one—at
some unspecified time—is desirable behavior. In general though, I think
avoiding side effects should be programming recommendations, not anything
enforced.
This model isn't really so different from what we do with asyncio an
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 agree with Chris here.
Fo
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 th
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 it allows with little syntax to indicate that the argument to
a function is not to be immediat
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 it allows with little
Hi Nathaniel,
2017-02-17 11:28 GMT+01:00 Nathaniel Smith :
>
> Note that this is definitely a different proposal from the original,
> since the original proposer's goal was to be able to use this with
> existing, unmodified functions that expect a regular value, not a
> lambda.
>
> I don't really
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: expensiveFu
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 expression
> it sees,
A few points for clarity:
Yes, I would expect each instance of delayed to result in a new delayed
expression, without caching, except for multiple calls to that same delayed
expression instance.
Also, I suggested the colon : because unlike async/await, the following
expression is NOT executed
On 2/17/17, Chris Angelico wrote:
> Do delayed-expressions have identities or only values? For example:
>
> rand = delayed: random.randrange(10)
> otherrand = rand
> assert rand is otherrand # legal?
> randid = id(rand) # legal?
> print(rand) # force to concrete value
> assert any(rand is x for x
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 true. I think
> this is
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 i
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:
> >e = L[i]
>
> Better use case:
>
> for i,
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 design goal for
> this woul
On Sat, Feb 18, 2017 at 3:30 AM, Mikhail V wrote:
> 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)
>> >
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 equal
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 s
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 mi
Actually, following from the idea that packing and unpacking variables
should be delayed by default, it might make sense to use syntax like:
>>> a = *(2+2)
>>> b = a + 1
Instead of
>>> a = lazy 2+2 # or whatever you want the keyword to be
>>> b = a + 1
That syntax sort-of resembles generator e
On 17 February 2017 at 17:37, Chris Angelico wrote:
> On Sat, Feb 18, 2017 at 3:30 AM, Mikhail V wrote:
> > 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
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 should be redirected to
>
> Further more I explained why I think iteration over index should be the
> preferred way, it help with readability a lot.
I think you'll find this statement at odds with most of the Python
community, especially Guido. I find looping over objects in a collection is
what you want to do 90% of th
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
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. Av
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 t
Hey! Excellent feedback!
In my mind, which word is selected doesn't matter much to me. I think the
technical term is 'thunk'? I think delayed is most clear.
I'm not sure if eager execution is so common in this framework it needs its own
keyword. Notably, default Python will handle that case
x
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.
> Int
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
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 in a few places (e.g.
async
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
>> wrote:
>> but I'm wondering
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:
> Couldn't the same thing be true o
>
> 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.
On 17 February 2017 at 18:40, Chris Angelico wrote:
> Further discussion probably should be redirected to python-list, but
> I'll elaborate here to explain why I do not support your proposal.
>
I don't see why you want redirect me to python-list, and how
exactly do you see it, start a related d
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
> eagerly?
>
Respectin
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
ob
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
that confusing. If you need to know what `d[k]` evaluates to right now then
the or
Abe-
You are correct. However I think it may still be salvageable.
In your code example, you could be either making a dict with a key of 1, or a
set of a delayed object. But there's no reason to build a set of a delayed
object because hashing it would immediately un-delay.
Similarly, I am not
On 17/02/17 10:22, 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)
Isn't this too general a syntax? Doesn't it lead to something like:
if a: b: c: d: e: pass
E.
_
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 expressions to other
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
> that confusing. If you
> 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 discarded.
I disagree with this claim because I do not think that you should have s
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
e
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 discarded.
>
> I disagre
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)
Python seems to be accumulating a lot of different approaches to achieving
very similar t
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]
> >>> d[k]
> 1
>
My probl
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 t
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 18, 2017 at 3:30 AM, Mikhail V 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 Mertz wrote:
> That was a problem with the colon that occurred to me. I think it can't be
I think fundamentally by special-casing a for-loop variant, you have a
construct with limited/no generality that's simply an additional burden to
learn. You're kind of doing the opposite of converting print from a
statement into a function. I far prefer the print function because it's a
function li
> On 16 Feb 2017, at 21:03, Abe Dillon wrote:
>
> I personally don't see why you can't use floats for log levels, but I'm
> interested to know how people are using logs such that they need dozens of
> levels. That, however; is tangential to the discussion about conditional
> execution of an e
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.
> >
> > The proposed format i
@ 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 s
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 say, but it is legal. In th
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 on the example Joseph
> made
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 de
On Fri, Feb 17, 2017 at 06:06:26PM -0500, Joseph Hackman 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 proper keywords in P
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 proper keywords in Pytho
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 across the language.
>
> The
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:
>
> I think fundamentally by s
On 18 February 2017 at 00:27, Mikhail V wrote:
> 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 2
On Sat, Feb 18, 2017 at 2:13 PM, Joao S. O. Bueno wrote:
> One can start coding in Python if after a couple minutes of tutorial, he
> learns
> about "for", "if", "def" and a couple data primitives - and maybe
> "print" and "input"
> for some UI. So, out of 3 needed statements to start coding, you
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 rad
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 Mertz wrote:
>
>> That wa
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
> then do an 'is'
Well, yes. I think the 'is' operator is where other attempts fall short,
and why it would require a change to Python. But yes, it would need to
force the promise.
On 17 February 2017 at 21:20, Nathaniel Smith wrote:
> On Thu, Feb 16, 2017 at 9:24 PM, Joseph Hackman
> wrote:
> > Howdy All!
> >
>
I'm not married to the colon. Does anyone else see any issue with dropping
it?
On 18 February 2017 at 00:27, David Mertz wrote:
> 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), unambiguous
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
> syntax to solve this p
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 disadvantage, and a
On Sat, Feb 18, 2017 at 03:27:00AM +0100, Mikhail V wrote:
> In what sense iteration over integer is limited?
It cannot iterate over something where the length is unknown in
advance, or infinite, or not meaningfully indexed by integers.
Here are four for-loops. How would you re-write this using
On Fri, Feb 17, 2017 at 11:37:04AM -0500, Mark E. Haase wrote:
> Python has two string formatting mini-languages.
Four. % string formatting, .format method, f-strings, string.Template
strings.
But who's counting? :-)
> Both allow formatting
> flags, for example in "%03d", the "0" (zero) is a f
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 supposed to be critics.
>>
75 matches
Mail list logo
