Re: [Python-ideas] A suggestion for a do...while loop

and "while not except" :-/ maybe we just stick with "while True' and put forward a documenting PEP advising linter packages to look for ways of getting out of the loop. On 26 June 2017 at 08:08, Terry Reedy wrote: > On 6/26/2017 12:41 AM, Nick Coghlan wrote: > >> On 26 June 2017 at 10:25, Rob

Re: [Python-ideas] A suggestion for a do...while loop

Chris Angelico wrote: And for completeness, "while not throw:". And just to completely confuse everyone, "while not pass". :-) -- Greg ___ Python-ideas mailing list [email protected] https://mail.python.org/mailman/listinfo/python-ideas Code of

Re: [Python-ideas] A suggestion for a do...while loop

On Mon, Jun 26, 2017 at 7:22 PM, Greg Ewing wrote: > And just to completely confuse everyone, "while not pass". :-) while "gandalf": ChrisA ___ Python-ideas mailing list [email protected] https://mail.python.org/mailman/listinfo/python-ideas Code

Re: [Python-ideas] + operator on generators

On 25 June 2017 at 20:55, Danilo J. S. Bellini wrote: > On Sun, Jun 25, 2017 at 3:06 PM, lucas via Python-ideas < > [email protected]> wrote: > >> I often use generators, and itertools.chain on them. >> What about providing something like the following: >> >> a = (n for n in range(2)) >

Re: [Python-ideas] A suggestion for a do...while loop

On Jun 26, 2017 2:15 AM, "Chris Angelico" wrote: On Mon, Jun 26, 2017 at 4:08 PM, Terry Reedy wrote: >> If we wanted to allow that to be expressed literally, we could >> probably special case the "while not break" keyword sequence as a do >> loop: >> >> while not break: >> # Setup

Re: [Python-ideas] + operator on generators

26.06.17 13:47, Joao S. O. Bueno пише: On 25 June 2017 at 20:55, Danilo J. S. Bellini > wrote: On Sun, Jun 25, 2017 at 3:06 PM, lucas via Python-ideas mailto:[email protected]>>wrote: I often use generators, and itertools.chain on them.

Re: [Python-ideas] + operator on generators

Personally, I find syntactic sugar for concating interators would come in handy. The purpose of iterators and generators is performance and efficiency. So, lowering the bar of using them is a good idea IMO. Also hoping back and forth a generator/iterator-based solution and a, say, list-based

Re: [Python-ideas] Improving Catching Exceptions

On 24.06.2017 01:37, MRAB wrote: I think a "shallow exception" would be one that's part of a defined API, as distinct from one that is an artifact of the implementation, a leak in the abstraction. I like the "shallow exception" idea most. It's simple and it covers most if not all issues. You

Re: [Python-ideas] [Python-Dev] Language proposal: variable assignment in functional context

Cool idea, Michał. I hope there's at least somebody willing to try it out in practice. On 23.06.2017 02:21, Michał Żukowski wrote: I've implemented a PoC of `where` expression some time ago. https://github.com/thektulu/cpython/commit/9e669d63d292a639eb6ba2ecea3ed2c0c23f2636 just compile and

Re: [Python-ideas] + operator on generators

On Sun, Jun 25, 2017 at 8:23 PM, Steven D'Aprano wrote: > On Sun, Jun 25, 2017 at 02:06:54PM +0200, lucas via Python-ideas wrote: > > I have a counter-proposal: introduce the iterator chaining operator "&": > > iterable & iterable --> itertools.chain(iterable, iterable) > In [1]: import nump

Re: [Python-ideas] Reducing collisions in small dicts/sets

Some explanations and cautions. An advantage of sticking with pure Python instead of C is that spare moments are devoted to investigating the problem instead of thrashing with micro-optimizations ;-) Why does the current scheme suffer for small tables? With hindsight it's pretty obvious: it can

Re: [Python-ideas] Reducing collisions in small dicts/sets

On 2017-06-26 19:21, Tim Peters wrote: Some explanations and cautions. An advantage of sticking with pure Python instead of C is that spare moments are devoted to investigating the problem instead of thrashing with micro-optimizations ;-) Why does the current scheme suffer for small tables? Wi

Re: [Python-ideas] Reducing collisions in small dicts/sets

[MRAB ] > If the current scheme suffers only for small tables, couldn't you use an > alternative scheme only for small tables? Sure. But whether that's desirable partly depends on timing actual C code. Try it ;-) For maintenance sanity, it's obviously better to have only one scheme to wrestle w

[Python-ideas] A suggestion for a do...while loop

>All these situations could be handled by making a "while:" with no >condition act as "while True:" >But they could also be handled by updating pep8 to make "while True:" the >recommended infinite loop syntax and make linters smarter about this (if >they aren't already). There was a big related d

Re: [Python-ideas] + operator on generators

On Mon, Jun 26, 2017 at 4:53 PM, Serhiy Storchaka wrote: > 26.06.17 13:47, Joao S. O. Bueno пише: > >> On 25 June 2017 at 20:55, Danilo J. S. Bellini > > wrote: >> >> On Sun, Jun 25, 2017 at 3:06 PM, lucas via Python-ideas >> >

Re: [Python-ideas] A suggestion for a do...while loop

On 06/26/2017 01:20 PM, Mikhail V wrote: I dont't like "while True:" simply because it does not make enough visual distinction with the "while condition:" statement. My "while True:" loops look something like: while "": -- ~Ethan~ ___ Python-ide

Re: [Python-ideas] + operator on generators

On Sunday, June 25, 2017, Wes Turner wrote: > > > On Sunday, June 25, 2017, Danilo J. S. Bellini > wrote: > >> On Sun, Jun 25, 2017 at 3:06 PM, lucas via Python-ideas < >> [email protected]> wrote: >> >>> I often use generators, and itertools.chain on them. >>> What about providing somethi

Re: [Python-ideas] A suggestion for a do...while loop

On 26Jun2017 13:30, Ethan Furman wrote: On 06/26/2017 01:20 PM, Mikhail V wrote: I dont't like "while True:" simply because it does not make enough visual distinction with the "while condition:" statement. My "while True:" loops look something like: while "": O_o Nice! Cheers, Cameron

Re: [Python-ideas] Reducing collisions in small dicts/sets

[Tim] >... I haven't yet thought of a cheap way to compute an > `inc` for double-hashing that isn't vulnerable to bad behavior for > _some_ easily constructed set of int keys. If you forget "cheap", > it's easy; e.g., > > random.seed(h) > inc = random.choice(range(1, mask + 1, 2)) Heh.