I still think that 'operator.subscript' would be valuable to me for
all of the same reasons discussed in the previous threads and issues.
I don't understand why it was reverted without any serious discussion
given that it was already accepted and many people find this useful.
On Mon, Jul 23, 2018
The GIL must be held to allocate memory for Python objects and to
invoke the Python code to deserialize user defined picklable objects.
I don't think there is a long span of time where the code could leave
the GIL released. The Python implementation is just pausing to let
other Python threads run,
I have also wanted sentinel objects many times. These are often useful
for creating a "Not Specified" default value when explicitly passing
`None` has semantic meaning.
There are a few issues with the `sentinel = object()` code. One is
that they don't repr well so they make debugging harder. Anoth
This was already posted in the thread, but
https://github.com/ll/cloudpickle-generators is just an
extension to the standard pickle machinery and is able to support
closures, nonlocals, and globals:
https://github.com/ll/cloudpickle-generators/blob/master/cloudpickle_generators/test
This can be accomplished as a decorator. Jim Crist wrote a version of this using
the codetransformer library. The usage is pretty simple:
@trace()
def sum_word_lengths(words):
total = 0
for w in words:
word_length = len(w)
total += word_length
return total
>>> sum_wo
This would break code that uses str.format everywhere for very little benefit.
On Tue, Dec 5, 2017 at 4:19 PM, Neil Schemenauer
wrote:
> I think most people who have tried f-strings have found them handy.
> Could we transition to making default string literal into an
> f-string? I think there is
How is that different from "pi = 3.14"?
On Tue, Nov 21, 2017 at 1:33 AM, Saeed Baig wrote:
> Hey guys I am thinking of perhaps writing a PEP to introduce user-defined
> constants to Python. Something along the lines of Swift’s “let” syntax (e.g.
> “let pi = 3.14”).
>
> Do you guys think it would
If we are worried about speed but want to keep the same API I have a
near drop in replacement for collections.namedtuple that dramatically
improves class and instance creation speed [1]. The only things
missing from this implementation are `_source` and `verbose` which
could be dynamically computed
he state variables in a list iterator are
> actually visible to the Interpreter or if it's implemented in C that is
> inscrutable to the interpreter.
>
>
> On Mar 2, 2017 5:54 PM, "Joseph Jevnik" wrote:
>
> Other things that scrutinize an expression are iteration
Other things that scrutinize an expression are iteration or branching (with
the current evaluation model). If `xs` is a thunk, then `for x in xs` must
scrutinize `xs`. At first this doesn't seem required; however, in general
`next` imposes a data dependency on the next call to `next`. For example:
ave side
effects and delayed execution anywhere near each other. You only open
youself up to a long list of special cases for when and where things get
evaluated.
On Fri, Feb 17, 2017 at 4:49 PM, Ed Kellett wrote:
> On Fri, 17 Feb 2017 at 21:18 Joseph Jevnik wrote:
>
>> There is n
ht now then
the order of evaluation is part of the correctness of your program and you
need to sequence execution such that `d` is evaluated before creating that
closure.
On Fri, Feb 17, 2017 at 4:17 PM, Joseph Jevnik wrote:
> There is no existing code that uses delayed execution so we don'
t the
observable side-effect?
On Fri, Feb 17, 2017 at 4:14 PM, Ed Kellett wrote:
> 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
>&g
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
isy! 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.
>
&g
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
You might be interested in https://github.com/ll/lazy_python, which
implements the features you describe but instead of a keyword it uses a
decorator.
On Fri, Feb 17, 2017 at 12:24 AM, Joseph Hackman
wrote:
> Howdy All!
>
> This suggestion is inspired by the question on "Efficient debug
You could add or prototype this with quasiquotes (
http://quasiquotes.readthedocs.io/en/latest/). You just need to be able to
parse the body of your expression as a string into an array. Here is a
quick example with a parser that only accepts 2d arrays:
```
# coding: quasiquotes
import numpy as n
Hello everyone, this idea looks like something I have tried building
already: https://github.com/ll/lazy_python. This project implements
a `thunk` class which builds up a deferred computation which is evaluated
only when needed. One use case I have had for this project is building up a
larg
19 matches
Mail list logo
