> With the increased emphasis on iterators and generators in Python 3.x,
> the lack of a simple expression level equivalent to "for item in
> iterable: pass" is occasionally irritating, especially when
> demonstrating behaviour at the interactive prompt.
I've sometimes thought that exhaust(iterato
> On Apr 8, 2018, at 6:43 PM, Tim Peters wrote:
>
>> My other common case for accumulate() is building cumulative
>> probability distributions from probability mass functions (see the
>> code for random.choice() for example, or typical code for a K-S test).
>
> So, a question: why wasn't iter
Raymond Hettinger wrote:
For neither of those use case categories did I ever want an initial value and
it would have been distracting to even had the option. For example, when
doing a discounted cash flow analysis, I was taught to model the various
flows as a single sequence of up and down arrows
> >>> list(accumulate([1, 2, 3]))
> [11, 13, 16]
Wow! I would have sworn that said
[1, 3, 6]
when I sent it. Damn Gmail ;-)
> >>> list(accumulate([1, 2, 3], initial=10))
> [10, 11, 13, 16]
___
Python-ideas mailing list
Python-ideas@python.org
https
[Raymond]
> The Bayesian world view isn't much different except they would
> prefer "prior" instead of "initial" or "start" ;-)
>
> my_changing_beliefs = accumulate(stream_of_new_evidence, bayes_rule,
> prior=what_i_used_to_think)
>
> Though the two analogies are cute, I'm not sure they tell u
Kyle Lahnakoski wrote:
Consider Serhiy Storchaka's elegant solution, which I reformatted for
readability
smooth_signal = [
average
for average in [0]
for x in signal
for average in [(1-decay)*average + decay*x]
]
"Elegant" isn't the word I would use, more like "clever".
Rather
# Dict display
data = {
key_a: local_a := 1,
key_b: local_b := 2,
key_c: local_c := 3,
}
Isn’t this a set display with local assignments and type annotations? :o)
(I’m -1 on all of these ideas, btw. None help readability for me, and I read
much more code than I wr
> On Apr 8, 2018, at 12:22 PM, Tim Peters wrote:
>
> [Guido]
>> Well if you can get Raymond to agree on that too I suppose you can go ahead.
>> Personally I'm -0 but I don't really write this kind of algorithmic code
>> enough to know what's useful.
>
> Actually, you do - but you don't _think_
Hi!
I thought that maybe dict could accept several mappings as positional
arguments, like this:
class Dict4(dict):
> def __init__(self, *args, **kwargs):
> if len(args) > 1:
> if not all([isinstance(arg, dict) for arg in args]):
> raise TypeError('Dict4 ex
[Guido]
> Well if you can get Raymond to agree on that too I suppose you can go ahead.
> Personally I'm -0 but I don't really write this kind of algorithmic code
> enough to know what's useful.
Actually, you do - but you don't _think_ of problems in these terms.
Neither do I. For those who do: c
2018-04-08 8:19 GMT+03:00 Nick Coghlan :
> A name like "first_result" would also make it clearer to readers that
> passing that parameter has an impact on the length of the output
> series (since you're injecting an extra result), and also that the
> production of the first result skips calling fu
On 2018-04-05 21:18, Steven D'Aprano wrote:
> (I don't understand why so many people have such an aversion to writing
> functions and seek to eliminate them from their code.)
>
I think I am one of those people that have an aversion to writing functions!
I hope you do not mind that I attempt to
Another bit of prior art: the Python itertoolz package also supplies
`accumulate()`, with an optional `initial` argument. I stumbled into
that when reading a Stackoverflow "how can I do Haskell's scanl in
Python?" question.
https://toolz.readthedocs.io/en/latest/api.html#toolz.itertoolz.accumula
On Sun, Apr 8, 2018 at 8:01 AM, Steven D'Aprano wrote:
> If we really wanted to keep the sublocal scoping, we could make
> list/set/dict displays their own scope too.
>
> Personally, that's the only argument for sublocal scoping that I like
> yet: what happens inside a display should remain insid
Well if you can get Raymond to agree on that too I suppose you can go
ahead. Personally I'm -0 but I don't really write this kind of algorithmic
code enough to know what's useful. I do think that the new parameter name
is ugly. But maybe that's the point.
On Sat, Apr 7, 2018 at 10:26 PM, Tim Peter
On Sun, Apr 08, 2018 at 09:25:33PM +1000, Nick Coghlan wrote:
> I was writing a new stdlib test case today, and thinking about how I
> might structure it differently in a PEP 572 world, and realised that a
> situation the next version of the PEP should discuss is this one:
>
> # Dict display
On 23 March 2018 at 20:01, Chris Angelico wrote:
> Apologies for letting this languish; life has an annoying habit of
> getting in the way now and then.
>
> Feedback from the previous rounds has been incorporated. From here,
> the most important concern and question is: Is there any other syntax
>
FYI:
[Raymond]
> ...
> Q. Do other languages do it?
> A. Numpy, no. R, no. APL, no. Mathematica, no. Haskell, yes.
>
>...
> * https://www.haskell.org/hoogle/?hoogle=mapAccumL
Haskell has millions of functions ;-) `mapAccumL` is a God-awful
mixture of Python's map(), reduce(), and accumul
18 matches
Mail list logo