Re: [Python-ideas] Show more info when `python -vV`

Nick Coghlan writes: > If we use the normal verbose flag, then both "-vV" and "-Vv" will > work, since options can be provided in any order. +0.5 for some such option, +1 for "-VV" or "-V -V" I for one would likely make that mistake (using "-VV" instead of "-vV") a lot. "python -V" is the fir

Re: [Python-ideas] Fwd: Fwd: Fwd: unpacking generalisations for list comprehension

On Mon, Oct 17, 2016, at 00:06, Nick Coghlan wrote: > Remember that what we're arguing about is that existing instances of: > > [x for subiterable in iterable for x in subiterable] > > or: > >list(itertools.chain.from_iterable(iterable)) > > would be easier to read and maintain if they we

Re: [Python-ideas] async objects

Regarding the Python C-runtime and async, I just had a good talk with Kresten Krab at Trifork. He implemented “Erjang” the Java implementation of the Erlang VM (www.erjang.org ). Doing this he had access to the Erlang (C) VM. It turn’s out that the Erlang VM and the Pyth

Re: [Python-ideas] Fwd: Fwd: Fwd: unpacking generalisations for list comprehension

On Mon, Oct 17, 2016 at 12:11:46PM -0400, Random832 wrote: > Honestly, it goes beyond just being "wrong". The repeated refusal to > even acknowledge any equivalence between [...x... for x in [a, b, c]] > and [...a..., ...b..., ...c...] truly makes it difficult for me to > accept some people's _sin

Re: [Python-ideas] Fwd: Fwd: Fwd: unpacking generalisations for list comprehension

On Mon, Oct 17, 2016, at 13:32, Steven D'Aprano wrote: > This isn't a small change: it requires not > insignificant changes to people's understanding of what list > comprehension syntax means and does. Only if their understanding is limited to a sequence of tokens that it supposedly expands to [

Re: [Python-ideas] Fwd: Fwd: Fwd: unpacking generalisations for list comprehension

On 2016-10-17 10:32, Steven D'Aprano wrote: In a list comprehension, we expect the invariant that the number of items produced will equal the number of loops performed. (Less if there are any "if" clauses.) There is one virtual append per loop. You cannot get the behaviour you want without breaki

Re: [Python-ideas] Heap data type, the revival

On 16.10.2016 19:02, Nick Timkovich wrote: Functions are great; I'm a big fan of functions. That said, the group of heapq.heap* functions are literally OOP without using that "class" word. As far as flexibility, what is the use of the those functions on non-heap structures? IIRC the statement w

Re: [Python-ideas] Fwd: Fwd: Fwd: unpacking generalisations for list comprehension

But the proposal has explicit syntax that point the reader to the fact that the invariant doesn't hold. Same as other unpacking occurences: [x, *y] The invariant does not hold. And that's explicit. Elazar בתאריך יום ב׳, 17 באוק' 2016, 21:16, מאת Brendan Barnwell ‏< brenb...@brenbarn.net>: > On

Re: [Python-ideas] Fwd: Fwd: Fwd: unpacking generalisations for list comprehension

On Sun, Oct 16, 2016 at 9:06 PM, Nick Coghlan wrote: > Remember that what we're arguing about is that existing instances of: > > [x for subiterable in iterable for x in subiterable] > > [...] would be easier to read and maintain if they were instead written as: > > [*subiter for subiter in it

[Python-ideas] please try to keep things civil (was: unpacking generalisations for list comprehension)

On Sun, 16 Oct 2016 at 09:39 Mark Lawrence via Python-ideas < python-ideas@python.org> wrote: > On 16/10/2016 16:41, Mariatta Wijaya wrote: > >>Her reaction was hilarious: > >> > >>"Whom does he teach? Children?" > > > > I sense mockery in your email, and it does not conform to the PSF code > > of

Re: [Python-ideas] Fwd: Fwd: Fwd: unpacking generalisations for list comprehension

On Mon, Oct 17, 2016 at 9:11 AM, Random832 wrote: > Once again, this alleged simplicity relies on the chosen example "x for > x" rather than "f(x) for x" - this one doesn't even put the use of > flatten in the right place to be generalized to the more complex cases. > You'd need list(flatten(f(x)

Re: [Python-ideas] async objects

The problem is that if your goal is to make a practical proposal, it's not enough to look at Python-the-language. You're absolutely right, AFAICT there's nothing stopping someone from making a nice implementation of Python-the-language that has erlang-style cheap shared-nothing threads with some ef

Re: [Python-ideas] Fwd: Fwd: Fwd: unpacking generalisations for list comprehension

On Mon, Oct 17, 2016 at 10:32 AM, Steven D'Aprano wrote: > But if we *do* accept this syntax, then I believe that we should drop > the pretense that it is a natural extension of sequence unpacking in the > context of a for-loop-with-append (i.e. list comprehensions) and accept > that it will be s

Re: [Python-ideas] Fwd: Fwd: Fwd: unpacking generalisations for list comprehension

On Mon, Oct 17, 2016 at 9:49 PM David Mertz wrote: ... > Moreover, this "magical flatten" operator will crash in bad ways that a > regular flatten() will not. I.e. this is fine (if strange): > > >>> three_inf = (count(), count(), count()) > >>> comp = (x for x in flatten(three_inf)) > >>> next(c

Re: [Python-ideas] Fwd: Fwd: Fwd: unpacking generalisations for list comprehension

On 17.10.2016 20:38, David Mertz wrote: Under my proposed "more flexible recursion levels" idea, it could even be: [f(x) for x in flatten(it, levels=3)] There would simply be NO WAY to get that out of the * comprehension syntax at all. But a decent flatten() function gets all the flexibili

Re: [Python-ideas] Multiple level sorting in python where the order of some levels may or may not be reversed

On 16.10.2016 09:35, Alireza Rafiei wrote: Awesome! Thanks for the thorough explanation. Indeed. I also didn't know about that detail of reversing. :) Amazing. (Also welcome to the list, Alireza.) def multisort(xs, specs): for key, reverse in reversed(specs):

Re: [Python-ideas] Fwd: Fwd: Fwd: unpacking generalisations for list comprehension

On 17 October 2016 at 18:32, Steven D'Aprano wrote: > On Mon, Oct 17, 2016 at 12:11:46PM -0400, Random832 wrote: > >> Honestly, it goes beyond just being "wrong". The repeated refusal to >> even acknowledge any equivalence between [...x... for x in [a, b, c]] >> and [...a..., ...b..., ...c...] tru

Re: [Python-ideas] Fwd: Fwd: Fwd: unpacking generalisations for list comprehension

On 17 October 2016 at 20:35, Sven R. Kunze wrote: > P.S. It's very artificial to assume user are unable to use 'from itertools > import chain' to try to make chain() seem more cumbersome than it is. > > I am sorry but it is cumbersome. Imports are a fundamental part of Python. How are they "cumb

Re: [Python-ideas] Fwd: Fwd: Fwd: unpacking generalisations for list comprehension

On 17 October 2016 at 21:22, Random832 wrote: > For a more concrete example: > > [*range(x) for x in range(4)] > [*(),*(0,),*(0,1),*(0,1,2)] > [0, 0, 1, 0, 1, 2] > > There is simply no way to get there by using flatten(range(4)). The only > way flatten *without* a generator expression can serve th

Re: [Python-ideas] Fwd: Fwd: Fwd: unpacking generalisations for list comprehension

On Mon, Oct 17, 2016, at 14:38, David Mertz wrote: > What you're saying is EXACTLY 180 deg reversed from the truth. It's > *precisely* because it doesn't need the extra complication that > `flatten()` > is more flexible and powerful. I have no idea what your example is meant > to do, but the actu

Re: [Python-ideas] Fwd: Fwd: Fwd: unpacking generalisations for list comprehension

On Mon, Oct 17, 2016, at 16:12, Paul Moore wrote: > And finally, no-one has even *tried* to explain why we need a third > way of expressing this construction. Nick made this point, and > basically got told that his condition was too extreme. He essentially > got accused of constructing an impossibl

Re: [Python-ideas] Multiple level sorting in python where the order of some levels may or may not be reversed

On 17 October 2016 at 21:06, Sven R. Kunze wrote: > Do you think that simple solution could have a chance to be added to stdlib > somehow (with the possibility of speeding it up in the future)? You could submit a doc patch to add an explanation of this technique to the list.sort function. I doubt

Re: [Python-ideas] Fwd: Fwd: Fwd: unpacking generalisations for list comprehension

On 17.10.2016 22:12, Paul Moore wrote: 4. Whether you choose to believe me or not, I've sincerely tried to understand the proposal [...] I think you did and I would like others to follow your example. 2. Can someone summarise the *other* arguments for the proposal? I for one think it's just res

Re: [Python-ideas] unpacking generalisations for list comprehension

On Mon, Oct 17, 2016 at 11:13 PM Paul Moore wrote: ... > 2. Can someone summarise the *other* arguments for the proposal? I'm > genuinely struggling to recall what they are (assuming they exist). My own argument was uniformity: allowing starred expression in other places, and I claim that the N

Re: [Python-ideas] Fwd: Fwd: Fwd: unpacking generalisations for list comprehension

On 17 October 2016 at 21:30, Random832 wrote: > On Mon, Oct 17, 2016, at 16:12, Paul Moore wrote: >> And finally, no-one has even *tried* to explain why we need a third >> way of expressing this construction. Nick made this point, and >> basically got told that his condition was too extreme. He es

Re: [Python-ideas] Fwd: Fwd: Fwd: unpacking generalisations for list comprehension

On 17.10.2016 22:26, Paul Moore wrote: Certainly having to add an import statement is extra typing. But terseness was *never* a feature of Python. In many ways, a resistance to overly terse (I could say "Perl-like") constructs is one of the defining features of the language - and certainly, it's

Re: [Python-ideas] Multiple level sorting in python where the order of some levels may or may not be reversed

On 17.10.2016 22:31, Paul Moore wrote: On 17 October 2016 at 21:06, Sven R. Kunze wrote: Do you think that simple solution could have a chance to be added to stdlib somehow (with the possibility of speeding it up in the future)? You could submit a doc patch to add an explanation of this techni

Re: [Python-ideas] Fwd: Fwd: Fwd: unpacking generalisations for list comprehension

On 17 October 2016 at 21:33, Sven R. Kunze wrote: > On 17.10.2016 22:12, Paul Moore wrote: >> >> 4. Whether you choose to believe me or not, I've sincerely tried to >> understand the proposal [...] > > I think you did and I would like others to follow your example. >> >> 2. Can someone summarise t

Re: [Python-ideas] Fwd: Fwd: Fwd: unpacking generalisations for list comprehension

On 17 October 2016 at 21:43, Sven R. Kunze wrote: > The statement about "cumbersomeness" was specific to this whole issue. Of > course, importing feature-rich pieces from the stdlib is really cool. It was > more the missed ability to do the same with list comprehensions of what is > possible with

Re: [Python-ideas] Multiple level sorting in python where the order of some levels may or may not be reversed

On 17/10/2016 21:31, Paul Moore wrote: On 17 October 2016 at 21:06, Sven R. Kunze wrote: Do you think that simple solution could have a chance to be added to stdlib somehow (with the possibility of speeding it up in the future)? You could submit a doc patch to add an explanation of this techn

Re: [Python-ideas] Multiple level sorting in python where the order of some levels may or may not be reversed

On 17 October 2016 at 22:28, Mark Lawrence via Python-ideas wrote: > How about changing https://wiki.python.org/moin/HowTo/Sorting ? Good point. Better still, https://docs.python.org/3.6/howto/sorting.html Paul ___ Python-ideas mailing list Python-idea

[Python-ideas] Conditional Assignment in If Statement

In the spirit of borrowing from other languages, there’s a particular bit of functionality from Swift that I’ve really wanted to have in Python. To preface, Swift uses var and let (static) when variables are created. It also supports optionals which allows a variable to be either some value or n

Re: [Python-ideas] Conditional Assignment in If Statement

On Tue, Oct 18, 2016 at 9:11 AM, Michael duPont wrote: > What does everyone think about: > > if foo = get_foo(): > bar(foo) > > as a means to replace: > > foo = get_foo() > if not foo: > bar(foo) > del foo > > Might there be some better syntax or a different keyword? I constantly run > in

Re: [Python-ideas] async objects

Your are right about the importance of Python C API, it often goes under my radar. For the past 20 years I have only used it a couple of times (to integrate Python into some existing C-code) therefore it is not as much in focus as it should be and definiatly are by others. I get your innovators

[Python-ideas] Civility on this mailing list

Based on some emails I read in the " unpacking generalisations for list comprehension", I feel like I need to address this entire list about its general behaviour. If you don't follow me on Twitter you may not be aware that I am taking the entire month of October off from volunteering any personal

Re: [Python-ideas] Null coalescing operator

On Oct 15, 2016, at 04:10 PM, Nick Coghlan wrote: >Having been previously somewhere between -1 and -0, I've been doing a >lot more data mining and analysis work lately, which has been enough >to shift me to at least +0 and potentially even higher when it comes >to the utility of adding these opera

Re: [Python-ideas] Fwd: Fwd: Fwd: unpacking generalisations for list comprehension

Steven D'Aprano wrote: What I don't believe is: (1) that the majority of Python programmers (or even a large minority) regularly and consistently think of comprehensions as syntactic sugar for a completely unrolled list display; rather, I expect that they usually think of them as sugar for a

Re: [Python-ideas] Civility on this mailing list

Dear Brett/ I have been reading the python-idea archive from time to time over the past years and I joined the list about a month ago to promote my “crazy” async object idea. I did fear the response to a newcomer with an unlikely idea, but I must say the *everyone* has been extremely nice, writ

Re: [Python-ideas] Civility on this mailing list

Hi Brett, +10 for the code of conduct, first step to help people to improve their behaviour themselves. Maybe the situation might be the result that Python is more and more mainstream: like a start-up that grows too much to integrate correctly new people hired, we might face to the same issue, wi

Re: [Python-ideas] Fwd: Fwd: Fwd: unpacking generalisations for list comprehension

David Mertz wrote: >>> three_inf = (count(), count(), count()) >>> comp = (x for x in flatten(three_inf)) >>> next(comp) 0 >>> next(comp) 1 It's hard to see how that won't blow up under the new syntax (i.e. generally for all infinite sequences). It won't blow up, because * in a generator

Re: [Python-ideas] Fwd: Fwd: Fwd: unpacking generalisations for list comprehension

On Mon, Oct 17, 2016 at 11:16:03AM -0700, Brendan Barnwell wrote: > Now, personally, I don't insist on that invariant. I would > certainly like to be able to do more general things in a list > comprehension, I hear you, because I too would like to introduce a variant comprehensio

Re: [Python-ideas] Fwd: Fwd: Fwd: unpacking generalisations for list comprehension

On Mon, Oct 17, 2016 at 10:33:32PM +0200, Sven R. Kunze wrote: > Sorry? You know, I am all for real-world code and I also delivered: > https://mail.python.org/pipermail/python-ideas/2016-October/043030.html Your example shows the proposed: [*(language, text) for language, text in fulltext_t

Re: [Python-ideas] Conditional Assignment in If Statement

It was not my intention to declare those to be similar, just as a furthering train of thought. I agree that using "as" is a much more Pythonic syntax. I'm sure there was (and will be) some discussion as to whether it should operate like "if foo:" or "if foo is not None:". I'll look a bit further in

Re: [Python-ideas] Fwd: Fwd: Fwd: unpacking generalisations for list comprehension

> > For a more concrete example: > > [*range(x) for x in range(4)] > [*(),*(0,),*(0,1),*(0,1,2)] > [0, 0, 1, 0, 1, 2] > As Paul or someone pointed out, that's a fairly odd thing to do. It's the first time that use case has been mentioned in this thread. It's true you've managed to construct some

Re: [Python-ideas] Multiple level sorting in python where the order of some levels may or may not be reversed

[Sven R. Kunze ] > Indeed. I also didn't know about that detail of reversing. :) Amazing. (Also > welcome to the list, Alireza.) It follows from what the docs say, although I'd agree it may be helpful if the docs explicitly spelled out this consequence (that reverse=True also preserves the origina

Re: [Python-ideas] Fwd: Fwd: Fwd: unpacking generalisations for list comprehension

On Mon, Oct 17, 2016, at 22:17, David Mertz wrote: > > [*range(x) for x in range(4)] > > As Paul or someone pointed out, that's a fairly odd thing to do. I agree with the specific example of it being an odd thing to do with range, it was just an attempt to illustrate with a concrete example. > I

Re: [Python-ideas] Fwd: Fwd: Fwd: unpacking generalisations for list comprehension

On Mon, Oct 17, 2016 at 7:50 PM, Random832 wrote: > On Mon, Oct 17, 2016, at 22:17, David Mertz wrote: > > > [*range(x) for x in range(4)] > > > > As Paul or someone pointed out, that's a fairly odd thing to do. > > I agree with the specific example of it being an odd thing to do with > range, it

Re: [Python-ideas] Fwd: Fwd: Fwd: unpacking generalisations for list comprehension

On 18 October 2016 at 03:49, Random832 wrote: > On Mon, Oct 17, 2016, at 13:32, Steven D'Aprano wrote: >> This isn't a small change: it requires not >> insignificant changes to people's understanding of what list >> comprehension syntax means and does. > > Only if their understanding is limited to

Re: [Python-ideas] Fwd: Fwd: Fwd: unpacking generalisations for list comprehension

On 2016-10-17 16:35, Steven D'Aprano wrote: >and many times I have been irritated by the fact that the >one-item-per-loop invariant exists. I'm not sure whether I'm in favor of >this particular syntax, but I'd like to be able to do the kind of things it >allows. But doing them inherently requir

Re: [Python-ideas] Fwd: Fwd: Fwd: unpacking generalisations for list comprehension

Steven D'Aprano wrote: Your example shows the proposed: [*(language, text) for language, text in fulltext_tuples if language == 'english'] which can be written as: [x for language, text in fulltext_tuples for x in (language, text) if language == 'english'] which is only ten charact

Re: [Python-ideas] Fwd: Fwd: Fwd: unpacking generalisations for list comprehension

On 18 October 2016 at 13:32, David Mertz wrote: > On Mon, Oct 17, 2016 at 7:50 PM, Random832 wrote: >> I feel like I should be honest about something else - I'm always a >> little bit confused by the ordering for comprehensions involving >> multiple clauses. > > Me too! I get the order of nested

[Python-ideas] Order of loops in list comprehension

Random832 wrote: For me, it's the fact that: [[a for a in b] for b in ['uvw', 'xyz']] == [['u', 'v', 'w'], ['x', 'y', 'z']] which makes me want to write: [a for a in b for b in ['uvw', 'xyz']] You're not alone! Lately I've been becoming convinced that this is the way we should have done it righ