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

[David Mertz]

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 was just an attempt to illustrate with a concrete example.
>

It's also easy to construct examples where the hypothetical * syntax can't
handle a requirement.  E.g. flatten() with levels>1 (yes, of course you can
find some way to nest more loops or more
comprehensions-within-comprehensions to make it work in some way that still
uses the * by force).

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 loops in comprehensions wrong about 25%
of the time.  Then it's a NameError, and I fix it.

This is a lot of why I like a utility function like `flatten()` that is
pretty much self-documenting.  Perhaps a couple other itertools helpers
would be nice.

-- 
Keeping medicines from the bloodstreams of the sick; food
from the bellies of the hungry; books from the hands of the
uneducated; technology from the underdeveloped; and putting
advocates of freedom in prisons.  Intellectual property is
to the 21st century what the slave trade was to the 16th.
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

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

[Tim Peters]

[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 original order of equal elements - as
the docs say, it's not that the _list_ "is reversed", is that "list
elements are sorted as if each comparison were reversed").


> 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)?

Well, the sorting "how to" already explains the basic idea.  The
`.sort()` docs also explain that stability "is helpful for sorting in
multiple passes (for example, sort by department, then by salary
grade)".

I suspect I know too much about this to be of any use in judging
what's missing ;-)

Speeding it wouldn't be easy - or usually necessary.  The obvious
"improvement" would do it all in a single `.sort()` invocation.  But
calling back into Python code to do fancy, multi-step comparisons is
so expensive that I expect it would take a large N for saving some
additional worst-case O(N*log(N)) sorting steps to repay the cost.

If you'd like to play with that, here's a different `multisort()`
implementation.  Again `specs` is a list of (key_function,
True-for-reverse) tuples, most-significant key first.  And, again, no
assumptions are made about what key functions return, and the sort
continues to guarantee that only "<" comparisons are made:

def _sorter(specs):
keyfuncs, reversers = zip(*specs)

class Wrapper(object):
def __init__(self, obj):
self.keys = tuple(f(obj) for f in keyfuncs)

def __lt__(x, y):
for a, b, r in zip(x.keys, y.keys, reversers):
if a < b:
return not r
if b < a:
return r
return False# all the keys are equal

return Wrapper

def multisort(xs, specs):
xs.sort(key=_sorter(specs))
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

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

[David Mertz]

>
> 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 something that isn't done by flatten().  I
would have had to think a while to see what you meant by the original if
you haven't provided the intermediate interpretations.

Of course, it's *really simple* to spell that in a natural way with
existing syntax that isn't confusing like yours:

[x for end in range(4) for x in range(end)]

There is no possible way to construct something that would use the proposed
syntax that can't be expressed more naturally with a nested loop... because
it's just confusing syntax sugar for exactly that.

Your example looks like some sort of interview quiz question to see if
someone knows obscure and unusual syntax.
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

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

[Michael duPont]

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 into the archives than I did to find previous
discussions. For now, I'm a fan of:

if get_foo() as foo:
bar(foo)

to replace the "if foo:" version:

foo = get_foo()
if foo:
bar(foo)
del foo

On Mon, Oct 17, 2016 at 6:18 PM Chris Angelico  wrote:

> 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 into this sort of use case.
>
> I'm pretty sure that syntax is never going to fly, for a variety of
> reasons (to see most of them, just read up a C style guide). But this
> syntax has been proposed now and then, analogously with the 'with'
> statement:
>
> if get_foo() as foo:
> bar(foo)
>
> Be careful of your definitions, though. You've said these as equivalent:
>
> if foo = get_foo():
> bar(foo)
>
> foo = get_foo()
> if foo is not None:
> bar(foo)
>
> foo = get_foo()
> if not foo:
> bar(foo)
> del foo
>
> There are three quite different conditions here. Your last two are
> roughly opposites of each other; but also, most people would expect
> "if foo = get_foo()" to be the same condition as "if get_foo()", which
> is not the same as "if get_foo() is not None". The semantics most
> likely to be accepted would be for "if get_foo() as foo:" to use the
> standard boolification rules of Python (and then make 'foo' available
> in both 'if' and 'else' blocks). Would you support that? If so, check
> out some of the previous threads on the subject - this is far from the
> first time it's been discussed, and most likely won't be the last.
>
> ChrisA
> ___
> Python-ideas mailing list
> Python-ideas@python.org
> https://mail.python.org/mailman/listinfo/python-ideas
> Code of Conduct: http://python.org/psf/codeofconduct/
>
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

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

[Steven D'Aprano]

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_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 characters longer. To me, though, there's simply no 
nice way of writing this: the repetition of "language, text" reads 
poorly regardless of whether there is a star or no star.

If I were doing this more than once, I'd be strongly inclined to invest 
in a simple helper function to make this more readable:

def filter_and_flatten(language, fulltext):
for lang, text in fulltext:
if lang == language:
yield lang
yield text

filter_and_flatten('english', fulltext_tuples)


In some ways, list comprehensions are a trap: their convenience and ease 
of use for the easy cases lure us into using them when we ought to be 
using a generator. But that's just my opinion.



-- 
Steve
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

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

[Paul Moore]

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-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

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

[Paul Moore]

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 list displays today. List displays feature * without importing
> anything fancy from the stdlib.

In your other post you specifically mentioned
itertools.chain.from_iterable. I'd have to agree with you that this
specific name feels clumsy to me as well. But I'd argue for finding a
better name, not replacing the function with syntax :-)

Cheers,
Paul
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

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

[Sven R. Kunze]

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 one that drew
me to Python, and one that I value.

I am completely with you on this one, Paul.

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 list displays today. List displays feature * 
without importing anything fancy from the stdlib.


Nevermind, it seems we need to wait longer for this issue to come up 
again and maybe again to solve it eventually.


Best,
Sven
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

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

[Paul Moore]

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 essentially
>> got accused of constructing an impossible test. And yet it's an
>> entirely fair test, and one that's applied regularly to proposals -
>> and many *do* pass the test.
>
> As the one who made that accusation, my objection was specifically to
> the word "always" - which was emphasized - and which is something that I
> don't believe is actually a component of the test that is normally
> applied. His words, specifically, were "a compelling argument needs to
> be presented that the new spelling is *always* preferable to the
> existing ones"
>
> List comprehensions themselves aren't even always preferable to loops.

Sigh. And no-one else in this debate has ever used exaggerated language.

I have no idea if Nick would reject an argument that had any
exceptions at all, but I don't think it's unreasonable to ask that
people at least *try* to formulate an argument that demonstrates that
the two existing ways we have are inferior to the proposal. Stating
that you're not even willing to try is hardly productive.

Paul
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

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

[Random832]

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 impossible test. And yet it's an
> entirely fair test, and one that's applied regularly to proposals -
> and many *do* pass the test.

As the one who made that accusation, my objection was specifically to
the word "always" - which was emphasized - and which is something that I
don't believe is actually a component of the test that is normally
applied. His words, specifically, were "a compelling argument needs to
be presented that the new spelling is *always* preferable to the
existing ones"

List comprehensions themselves aren't even always preferable to loops.
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

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

[Paul Moore]

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 the same use
> cases as this proposal is for comprehensions of the *exact* form [*x for
> x in y]. For all other cases you'd need list(flatten(...generator
> expression without star...)).

Do you have a real-world example of needing this?

Paul
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

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

[Paul Moore]

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 "cumbersome"?
Is it cumbersome to have to import sys to get access to argv? To
import re to use regular expressions? To import subprocess to run an
external program?

Importing the features you use (and having an extensive standard
library of tools you might want, but which don't warrant being built
into the language) is, to me, a basic feature of Python.

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 one that drew
me to Python, and one that I value.

Paul
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

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

[Paul Moore]

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...] truly makes it difficult for me to
>> accept some people's _sincerity_.
>
> While we're talking about people being insincere, how about if you take
> a look at your own comments? This "repeated refusal" that you accuse us
> (opponents of this proposal) of is more of a rhetorical fiction than an
> actual reality. Paul, David and I have all acknowledged the point you
> are trying to make. I won't speak for Paul or David, but speaking for
> myself, it isn't that I don't understand the point you're trying to
> make, but that I do not understand why you think that point is
> meaningful or desirable.

For my part:

1. I've acknowledged that equivalence. As well as the fact that the
proposal (specifically, as explained formally by Greg) is
understandable and a viable possible extension.
2. I don't find the "interpolation" equivalence a *good* way of
interpreting list comprehensions, any more than I think that loops
should be explained by demonstrating how to unroll them.
3. I've even explicitly revised my position on the proposal from -1 to
-0 (although I'm tending back towards -1, if I'm honest...).
4. Whether you choose to believe me or not, I've sincerely tried to
understand the proposal, but I pretty much had to insist on a formal
definition of syntax and semantics before I got an explanation that I
could follow.

However:

1. I'm tired of hearing that the syntax is "obvious". This whole
thread proves otherwise, and I've yet to hear anyone from the
"obvious" side of the debate acknowledge that.
2. Can someone summarise the *other* arguments for the proposal? I'm
genuinely struggling to recall what they are (assuming they exist). It
feels like I'm hearing nothing more than "it's obvious what this does,
it's obvious that it's needed and the people saying it isn't are
wrong". That may well not be the truth, but *it's the impression I'm
getting*. I've tried to take a step back and summarise my side of the
debate a couple of times now. I don't recall seeing anyone doing the
same from the other side (Greg's summarised the proposal, but I don't
recall anyone doing the same with the justification for it).
3. The fact is that the proposed behaviour was *specifically* blocked,
*precisely* because of strong concerns that it would cause readability
issues and only had "mild" support. I'm not hearing any reason to
change that decision (sure, there are a few people here offering
something stronger than "mild" support, but it's only a few voices,
and they are not addressing the readability concerns at all). There
was no suggestion in the PEP that this decision was expected to be
revisited later. Maybe there was an *intention* to do so, but the PEP
didn't state it. I'd suggest that this fact alone implies that the
people proposing this change need to write a new PEP for it, but
honestly I don't think the way the current discussion has gone
suggests that there's any chance of putting together a persuasive PEP,
much less a consensus decision.

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 impossible test. And yet it's an
entirely fair test, and one that's applied regularly to proposals -
and many *do* pass the test. It's worth noting here that we have had
no real-world use cases, so the common approach of demonstrating real
code, and showing how the proposal improves it, is not available.
Also, there's no evidence that this is a common need, and so it's not
clear to what extent any sort of special language support is
warranted. We don't (as far as I know, and no-one's provided evidence
otherwise) see people routinely writing workarounds for this
construct. We don't hear of trainers saying that pupils routinely try
to do this, and are surprised when it doesn't work (I'm specifically
talking about students *deducing* this behaviour, not being asked if
they think it's reasonable once explained). These are all arguments
that have been used in the past to justify new syntax (and so reach
Nick's "bar").

And we've had a special-case function (flatten) proposed to cover the
most common cases (taking the approach of the 80-20 rule) - but the
only response to that proposal has been "but it doesn't cover
". If it didn't cover a demonstrably common
real-world problem, that would be a different matter - but anyone can
construct cases that aren't covered by *any* given proposal. That
doesn't prove anything.

I don't see any signs of progress here. And I'm pretty much at the
point where I'm losing interest in having the same points repeated at
me 

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

[Sven R. Kunze]

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 flexibility.


I see what you are trying to do here and I appreciate it. Just one 
thought from my practical experience: I haven't had a single usage for 
levels > 1. levels==1 is basically * which I have at least one example 
for. Maybe, that relates to the fact that we asked our devs to use names 
(as in attributes or dicts) instead of deeply nested list/tuple structures.


Do you think it would make sense to start a new thread just for the sake 
of readability?



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 _sincerity_.


I am absolutely sincere in disliking and finding hard-to-teach this 
novel use of * in comprehensions.


You are consistent at least. You don't teach * in list displays, no 
matter if regular lists or comprehensions. +1


 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.


Regards,
Sven
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

Re: [Python-ideas] async objects

[Nathaniel Smith]

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 efficient message-passing mechanism.

But! It turns out that unless your new implementation supports the
CPython C API, then it's almost certainly not viable as a mainstream
CPython alternative, because there's this huge huge pile of libraries
that have been written against that C API. You're not competing
against CPython, you're competing against CPython+thousands of
libraries that you don't have and that your users expect. And
unfortunately, it turns out that the C API locks in a bunch of the
implementation assumptions (refcounting, the GIL, use of the C stack,
poor support for isolation between different interpreter states, ...)
that you were trying to get away from.

I mean, in many ways it's a good problem to have, that our current
ecosystem is just so attractive that it's hard to compete with!
(Though a pessimist could point out that this difficulty with
competing with yourself is exactly what tends to eventually undermine
incumbents -- cf. the innovator's dilemma.) And it's "just" a matter
of implementation, not Python-the-language itself. But the bottom line
is: this is *the* core problem that you have to grapple with if you
want to make any radical improvements in the Python runtime and have
people actually use them.

-n

On Mon, Oct 17, 2016 at 9:36 AM, Rene Nejsum  wrote:
> 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 Python VM has a lot of similarities
> and the differences are more in the language, than in the VM
>
> Differences between the Erlang VM and Python related to async are:
>
> 1) Most variables in Erlang are immutable
> Making it easier to have coroutines
>
> 2) coroutines are built into the Erlang using the “spawn” keyword
> Leaving the specific implementation to the VM, but never implemented with OS
> threads.
>
> 3) All coroutines have their own heap and stack (initially 200 bytes), but
> can grow as needed
>
> 4) coroutines are managed in “ready-queue”, from which the VM thread
> executes the next ready job
> Each job gets 2000 “instructions” (or until IO block) and the next coroutine
> is executed
>
> Because of this, when multicore CPU’s entered the game, it was quite easy to
> change the Erlang VM to add a thread per core to pull from the ready-queue.
> This makes an Erlang program run twice as fast (almost) every time the
> number of cores are doubled!
>
> Given this, I am still convinced that:
>
> obj = async SomeObject()
>
> should be feasible, even though there will be some “golang” like issues
> about shared data, but there could be several ways to handle this.
>
> br
> /Rene
>
>
> On 05 Oct 2016, at 18:06, Nick Coghlan  wrote:
>
> On 5 October 2016 at 16:49, Rene Nejsum  wrote:
>
> On 04 Oct 2016, at 18:40, Sven R. Kunze  wrote:
> I don't think that's actually what I wanted here. One simple keyword should
> have sufficed just like golang did. So, the developer gets a way to decide
> whether or not he needs it blocking or nonblocking **when using a
> function**. He doesn't need to decide it **when writing the function**.
>
>
> I agree, that’s why i proposed to put the async keyword in when creating the
> object, saying in this instance I want asynchronous communication with the
> object.
>
>
> OK, I think there may be a piece of foundational knowledge regarding
> runtime design that's contributing to the confusion here.
>
> Python's core runtime model is the C runtime model: threads (with a
> local stack and access to a global process heap) and processes (which
> contain a heap and one or more threads). Anything else we do (whether
> it's generators, coroutines, or some other form of paused execution
> like callback management) gets layered on top of that runtime model.
> When folks ask questions like "Why can't Python be more like Go?",
> "Why can't Python be more like Erlang?", or "Why can't Python be more
> like Rust?" and get a negative response, it's usually because there's
> an inherent conflict between the C runtime model and whatever piece of
> the Go/Erlang/Rust runtime model we want to steal.
>
> So the "async" keyword in "async def", "async for" and "async with" is
> essentially a marker saying "This is not a C-like runtime concept
> anymore!" (The closest C-ish equivalent I'm aware of would be Apple's
> Grand Central Dispatch in Objective-C and that shows many of the
> async/await characteristics also seen in Python and C#:
> 

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

[David Mertz]

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) for x in iterable))
>

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 actual correspondence is:

  [f(x) for x in flatten(it)]

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 flexibility.


> 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 _sincerity_.
>

I am absolutely sincere in disliking and finding hard-to-teach this novel
use of * in comprehensions.

Yours, David...

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.
Likewise, I would like flatten() in itertools, but I assume the usual
pattern would be importing the function itself.

-- 
Keeping medicines from the bloodstreams of the sick; food
from the bellies of the hungry; books from the hands of the
uneducated; technology from the underdeveloped; and putting
advocates of freedom in prisons.  Intellectual property is
to the 21st century what the slave trade was to the 16th.
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

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

[Brett Cannon]

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 conduct. Please read the CoC before posting in this mailing list. The
> > link is available at the bottom of every python mailing list
> > email.https://www.python.org/psf/codeofconduct/
> > 
> > I don't find teaching children is a laughing matter, neither is the idea
> > of children learning to code.
> > In Canada, we have initiatives like Girls Learning Code and Kids
> > Learning Code. I mentored in a couple of those events and the students
> > are girls aged 8-14. They surprised me with their abilities to learn. I
> > would suggest looking for such mentoring opportunities in your area to
> > gain appreciation with this regard.
> > Thanks.
> > (Sorry to derail everyone from the topic of list comprehension. Please
> > continue!)
> >
>
> The RUE was allowed to insult the community for years and got away with
> it.


What is the "RUE"?


>   I'm autistic, stepped across the line, and got hammered.  Hypocrisy
> at its best.


While some of us know your background, Mark, not everyone on this list does
as people join at different times, so please try to give the benefit of the
doubt to people. Marietta obviously takes how children are reflected
personally and was trying to point out that fact. I don't think she meant
for the CoC reference to come off as threatening, just to back up why she
was taking the time out to speak up that she was upset by what was said.
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

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

[Chris Angelico]

On Mon, Oct 17, 2016 at 5:02 PM, INADA Naoki  wrote:
> $ ./python.exe -V
> Python 3.6.0b2+
>
> $ ./python.exe -VV
> Python 3.6.0b2+ (3.6:0b29adb5c804+, Oct 17 2016, 15:00:12)
> [GCC 4.2.1 Compatible Apple LLVM 8.0.0 (clang-800.0.38)]

LGTM.

What's the view on backporting this to 2.7.x? We're still a good few
years away from its death, and it'd be helpful if recent 2.7s could
give this info too.

ChrisA
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

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

[Chris Angelico]

On Mon, Oct 17, 2016 at 5:02 PM, Nick Coghlan  wrote:
> I'm fine with making "-V" itself a counted option, and hence
> supporting -VV *instead of* -vV.
>
> The only approach I'm not OK with is allowing both -VV *and* the
> mixed-case form to request more detailed version information.

Okay. I'd have no problem with that. It's easy enough to ask people to
capitalize them both.

Definite +1 from me.

ChrisA
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

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

[Nick Coghlan]

On 17 October 2016 at 15:51, Chris Angelico  wrote:
> On Mon, Oct 17, 2016 at 3:21 PM, Nick Coghlan  wrote:
>> On 17 October 2016 at 13:40, Chris Angelico  wrote:
>>> On Mon, Oct 17, 2016 at 2:33 PM, Nick Coghlan  wrote:
 While it *is* a little unusual to implement it that way, I don't think
 that's sufficient reason to break with the established output format
 for the plain "-V".
>>>
>>> Seems reasonable. Minor point: I'd be forever having to check whether
>>> it's -vV, -Vv, or -VV
>>
>> If we use the normal verbose flag, then both "-vV" and "-Vv" will
>> work, since options can be provided in any order.
>
> That's a good start, at least.
>
>> I don't think it makes sense to also allow "-VV" - we're not
>> requesting the version twice, we're asking for more verbose version
>> information.
>
> It's not as far-fetched as you might think - if "vv" means "more
> verbose", and "qq" means "more quiet", then "VV" means "more version
> info".

I'm fine with making "-V" itself a counted option, and hence
supporting -VV *instead of* -vV.

The only approach I'm not OK with is allowing both -VV *and* the
mixed-case form to request more detailed version information.

Cheers,
Nick.

-- 
Nick Coghlan   |   ncogh...@gmail.com   |   Brisbane, Australia
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/