2016-10-25 12:29 GMT-02:00 Paul Moore <p.f.moore@gmail.com>:
On the other hand, the *ideas* are really interesting and valuable. I'm certainly planning on looking at PyScanPrev when I get the chance. And the discussions can frequently make people rethink their beliefs.
So people posting ideas here should expect pushback - and should be prepared to learn how to think about the wider context in which changes to Python need to exist. That pushback won't[1] be hostile or negative, although it can feel that way to newcomers. But if a poster is inclined to take challenges to their idea personally, and even more so if they respond negatively, things can get tense. So please don't :-)
So, bringing this back on topic - Danilo, what is your justification for suggesting that this technique should be language syntax, as opposed to simply being a 3rd party module (which you've already written, which is great)? Do you know what sorts of things would be viewed as evidence in favour of promoting this to syntax, or can we help in clarifying the sort of evidence you'd need to collect? Are the relevant design guidelines (things like "there should be one obvious way to do it" that frequently get quoted around here without much explanation) clear to you, or do you have questions?
Hopefully we can change your mind about how inviting you find us :-)
Thanks for your message, Paul. When I said the list isn't inviting, I'm not talking about everyone, but about quite few people that disturbs. I'm just trying to help improving the language. I'm waiting for your opinion about PyScanPrev. =) 2016-10-25 16:01 GMT-02:00 Brendan Barnwell <brenbarn@brenbarn.net>:
Recurrence relations are much more general than just "have access to the previous value". They may have access to any of the earlier values, and/or multiple earlier values. So if what we wanted was to able to use recurrence relations, your proposal would be insufficient.
Brendan, please see the PyScanPrev examples, mainly the Fibonacci and the State-space model examples. Recursion is enough to give you that. The proposal isn't about lag and windowing, but if you've got an idea to improve that, I'd like to know. 2016-10-25 15:55 GMT-02:00 Rob Cliffe <rob.cliffe@btinternet.com>:
On 24/10/2016 06:11, Danilo J. S. Bellini wrote:
[prev * k for k in [5, 2, 4, 3] from prev = 1] [1, 5, 10, 40, 120]
That makes sense for me, and seem simpler than:
from itertools import accumulate, chain list(accumulate(chain([1], [5, 2, 4, 3]), lambda prev, k: prev * k)) [1, 5, 10, 40, 120]
Well, if you want an instant reaction from someone skimming this thread: I looked at the first example and couldn't understand it. Then I looked at the second one, and could understand it (even though I may never have used "chain" or heard of "accumulate"). Obviously your mileage varies.
Rob, would it be the same if it was the other way around? I'm also somewhat familiar with map/filter, but I think you would need more time (and documentation) to understand what the second does if you hadn't seen the first. What do you think? 2016-10-25 23:36 GMT-02:00 David Mertz <mertz@gnosis.cx>:
After reading every post in the thread, I still don't understand the proposed new syntax really.
The proposal is to create a new syntax for recursive set/list/dict comprehensions and generator expressions. And that's all. It could be a new magic keyword as you said, but there are alternatives like the "from" example I gave. 2016-10-25 23:36 GMT-02:00 David Mertz <mertz@gnosis.cx>:
If you give up a fear of using `import` and stop arbitrarily converting a possibly infinite iterator to a concrete list
Ad hominem, and that's just offensive. Who said I "fear" an import? Who is "converting a possibly infinite iterator to a concrete list"?! You know that "it was a built-in, now it's in a module" is meaningful, and when it comes to what happened to "reduce", it's an argument for my proposal, not against it. Why should I fear? -- Danilo J. S. Bellini --------------- "*It is not our business to set up prohibitions, but to arrive at conventions.*" (R. Carnap)