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

Random832 wrote: [*map(math.exp, t) for t in [(1, 2), (3, 4)]] [*(math.exp(x) for x in t) for t in [(1, 2), (3, 4)]] Or more simply, [math.exp(x) for t in [(1, 2), (3, 4)] for x in t] I think this brings out an important point. While it would be nice to allow * unpacking in

Re: [Python-ideas] Proposal for default character representation

On Fri, Oct 14, 2016 at 07:21:48AM +0200, Mikhail V wrote: > I'll explain what I mean with an example. > This is an example which I would make to > support my proposal. Compare: > > if "\u1230" <= c <= "\u123f": For an English-speaker writing that, I'd recommend: if "\N{ETHIOPIC SYLLABLE SA}"

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

I've never used nor taught a * in a list display. I don't think they seem so bad, but it's a step down a slippery slope towards forms that might as well be Perl. On Oct 13, 2016 10:33 PM, "Greg Ewing" wrote: > David Mertz wrote: > >> it would always be "Here's a

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

David Mertz wrote: it would always be "Here's a Python wart to look out for if you see it in other code... you should not ever use it yourself." Do you currently tell them the same thing about the use of * in a list display? -- Greg ___ Python-ideas

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

Steven D'Aprano wrote: py> def gen(): ... for t in [(1, 'a'), (2, 'b'), (3, 'c')]: ... yield *t File "", line 3 yield *t ^ SyntaxError: invalid syntax Even if it was allowed, what would it mean? It could only mean "unpack the sequence t, and collect the values

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

On Thu, Oct 13, 2016, at 18:15, Steven D'Aprano wrote: > Consider the analogy with f(*t), where t = (a, b, c). We *don't* have: > > f(*t) is equivalent to f(a); f(b); f(c) I don't know where this "analogy" is coming from. f(*t) == f(a, b, c) [*t] == [a, b, c] {*t} == {a, b, c} All of this

[Python-ideas] Fwd: Add sorted (ordered) containers

On Thu, Oct 13, 2016 at 1:36 PM, Марк Коренберг wrote: > > I mean mutable containers that are always sorted when iterating over them. > > See http://bugs.python.org/issue28433 > > for example: > > * SortedSet (sorted unique elements, implemented using (rb?)tree instead of >

Re: [Python-ideas] Suggestion: Deprecate metaclasses that are not instances of type

Bug: http://bugs.python.org/issue28437 On Thu, Oct 13, 2016 at 7:15 PM Neil Girdhar wrote: > That's fair. However, the documentation should at least be repaired by > replacing section 3.3.3.2 with: > > "The metaclass of a class definition is selected from the explicitly

Re: [Python-ideas] Suggestion: Deprecate metaclasses that are not instances of type

That's fair. However, the documentation should at least be repaired by replacing section 3.3.3.2 with: "The metaclass of a class definition is selected from the explicitly specified metaclass (if any) and the metaclasses (i.e. type(cls)) of all specified base classes. The most derived metaclass

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

On Thu, Oct 13, 2016 at 10:40:19PM +0200, Sjoerd Job Postmus wrote: > Likewise, > > l = [f(t) for t in iterable] > > can be seen as sugar for > > def gen(): > for t in iterable: > yield f(t) > l = list(gen()) But that is *not* how list comprehensions are

Re: [Python-ideas] Add sorted (ordered) containers

On 13.10.16 23:36, Марк Коренберг wrote: I think it should be one standardized implementation of such containers in CPython. For example, C++ has both ordered_map and unorderd_map. Instead of trees, implementation may use SkipList structure, but this is just implementation details. Such

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

On Thu, Oct 13, 2016, at 16:59, Paul Moore wrote: > I don't (for the reasons raised before). But thank you for your > explanation, it clarifies what you were proposing. And it does so > within the *current* uses of the * symbol, which is good. But: > > 1. I'm not keen on extending append's

[Python-ideas] Suggestion: Deprecate metaclasses that are not instances of type

Background: I asked a stackoverflow question here . The Python documentation

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

On Thu, Oct 13, 2016, at 16:42, Paul Moore wrote: > I remain puzzled. > > Given the well-documented and understood transformation: > > [fn(x) for x in lst if cond] > > translates to > > result = [] > for x in lst: >if cond: > result.append(fn(x)) > > please can you explain how to

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

On 13 October 2016 at 21:40, Sjoerd Job Postmus wrote: > However, consider the following spelling: > > l = [from f(t) for t in iterable] > > To me, it does not seem far-fetched that this would mean: > > def gen(): > for t in iterable: > yield

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

On Thu, Oct 13, 2016 at 11:42 PM Paul Moore wrote: > I remain puzzled. > > Given the well-documented and understood transformation: > > [fn(x) for x in lst if cond] > > translates to > > result = [] > for x in lst: >if cond: > result.append(fn(x)) > > please can

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

On 13 October 2016 at 20:51, Random832 wrote: > On Thu, Oct 13, 2016, at 15:46, Random832 wrote: >> so, under a similar 'transformation', "*foo for foo in bar" likewise >> becomes "def f(): for foo in bar: yield from foo" >> >> bar = [(1, 2), (3, 4)] >> (*(1, 2), *(3, 4))

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

After having followed this thread for a while, it occured to me that the reason that the idea is confusing, is because the spelling is confusing. I think the suggested spelling (`*`) is the confusing part. If it were to be spelled `from ` instead, it would be less confusing. Consider this:

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

On Thu, Oct 13, 2016, at 15:46, Random832 wrote: > so, under a similar 'transformation', "*foo for foo in bar" likewise > becomes "def f(): for foo in bar: yield from foo" > > bar = [(1, 2), (3, 4)] > (*(1, 2), *(3, 4)) == == tuple(f()) > [*(1, 2), *(3, 4)] == == list(f()) I accidentally hit

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

On Thu, Oct 13, 2016, at 14:50, David Mertz wrote: > Neither of those follows conventional Python semantics for function > calling > or sequence unpacking. So maybe that remains a type error or syntax > error. But then we exclude a very common pattern of using comprehensions > to create

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

> > [*t for t in [(1, 'a'), (2, 'b'), (3, 'c')]] > Another problem with this is that it is very hard to generalize to the case where the item included in a comprehension is a transformation on iterated values. E.g. what does this do? [math.exp(*t) for t in [(1,2),(3,4)]] Maybe that

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

Exactly with Paul! As I mentioned, I teach software developers and scientists Python for a living. I get paid a lot of money to do that, and have a good sense of what learners can easily understand and not (I've also written hundred of articles and a few books about Python). The people I write

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

On Thu, Oct 13, 2016 at 6:55 PM, Steven D'Aprano wrote: > On Thu, Oct 13, 2016 at 04:34:49PM +0200, Martti Kühne wrote: > >> > If I had seen a list comprehension with an unpacked loop variable: >> > >> > [t for t in [(1, 'a'), (2, 'b'), (3, 'c')]] > > Martti, somehow you

Re: [Python-ideas] Proposal for default character representation

On 10/13/16 2:42 AM, Mikhail V wrote: > On 13 October 2016 at 08:02, Greg Ewing wrote: >> Mikhail V wrote: >>> Consider unicode table as an array with glyphs. >> >> You mean like this one? >> >> http://unicode-table.com/en/ >> >> Unless I've miscounted, that one has

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

On Thu, Oct 13, 2016 at 03:28:27PM +, אלעזר wrote: > It may also suggest that there are currently two ways to understand the > *[...] construct, This thread is about allowing sequence unpacking as the internal expression of list comprehensions: [ *(expr) for x in iterable ] It isn't

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

On 13 October 2016 at 15:32, Sven R. Kunze wrote: > Steven, please. You seemed to struggle to understand the notion of the > [*] construct and many people (not just me) here tried their best to > explain their intuition to you. And yet, the fact that it's hard to explain

Re: [Python-ideas] Proposal for default character representation

On 10/12/2016 07:13 PM, Mikhail V wrote: On 12 October 2016 at 23:50, Thomas Nyberg wrote: Since when was decimal notation "standard"? Depends on what planet do you live. I live on planet Earth. And you? If you mean that decimal notation is the standard used for

Re: [Python-ideas] Proposal for default character representation

On Fri, Oct 14, 2016 at 1:25 AM, Steven D'Aprano wrote: > On Thu, Oct 13, 2016 at 03:56:59AM +0200, Mikhail V wrote: >> and in long perspective when the world's alphabetical garbage will >> dissapear, two digits would be ok. > Talking about "alphabetical garbage" like that

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

On 13.10.2016 16:10, Steven D'Aprano wrote: On Thu, Oct 13, 2016 at 10:37:35AM +0200, Sven R. Kunze wrote: Multiplication with only a single argument? Come on. You didn't say anything about a single argument. Your exact words are shown above: "where have I seen * so far?". I'm pretty sure

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

On Thu, Oct 13, 2016 at 5:10 PM Steven D'Aprano wrote: > On Thu, Oct 13, 2016 at 10:37:35AM +0200, Sven R. Kunze wrote: > > About the list constructor: we construct a list by writing [a,b,c] or by > > writing [b for b in bs]. The end result is a list > > I construct lists

Re: [Python-ideas] Proposal for default character representation

On Thu, Oct 13, 2016 at 03:56:59AM +0200, Mikhail V wrote: > > How many decimal digits would you use to denote a single character? > > for text, three decimal digits would be enough for me personally, Well, if it's enough for you, why would anyone need more? > and in long perspective when the

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

On Thu, Oct 13, 2016 at 10:37:35AM +0200, Sven R. Kunze wrote: > On 13.10.2016 01:29, Steven D'Aprano wrote: > >On Wed, Oct 12, 2016 at 06:32:12PM +0200, Sven R. Kunze wrote: > >> > >>So, my reasoning would tell me: where have I seen * so far? *args and > >>**kwargs! > >And multiplication. > >

Re: [Python-ideas] Improve error message when missing 'self' in method definition

On Tue, Oct 11, 2016 at 02:31:25PM +1100, Chris Angelico wrote: > On Tue, Oct 11, 2016 at 2:29 PM, Stephen J. Turnbull > wrote: > > Chris Angelico writes: > > > > > Given that it's not changing semantics at all, just adding info/hints > > > to an error

Re: [Python-ideas] Proposal for default character representation

On Thu, Oct 13, 2016 at 9:05 PM, Cory Benfield wrote: > Binary notation seems like the solution, but note the above case: the only > way to work out how many bits are being masked out is to count them, and > there can be quite a lot. IIRC there’s some new syntax coming for

Re: [Python-ideas] Proposal for default character representation

Mikhail V wrote: Eee how would I find if the character lies in certain range? >>> c = "\u1235" >>> if "\u1230" <= c <= "\u123f": ... print("Boo!") ... Boo! -- Greg ___ Python-ideas mailing list Python-ideas@python.org

Re: [Python-ideas] Proposal for default character representation

Mikhail V wrote: Ok, but if I write a string filtering in Python for example then obviously I use decimal everywhere to compare index ranges, etc. so what is the use for me of that label? Just redundant conversions back and forth. I'm not sure what you mean by that. If by "index ranges"

Re: [Python-ideas] Proposal for default character representation

Mikhail V wrote: I am not against base-16 itself in the first place, but rather against the character set which is simply visually inconsistent and not readable. Now you're talking about inventing new characters, or at least new glyphs for existing ones, and persuading everyone to use them.

Re: [Python-ideas] Proposal for default character representation

Mikhail V wrote: Did you see much code written with hex literals? From /usr/include/sys/fcntl.h: /* * File status flags: these are used by open(2), fcntl(2). * They are also used (indirectly) in the kernel file structure f_flags, * which is a superset of the open/fcntl flags. Open flags

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

On 13.10.2016 01:29, Steven D'Aprano wrote: On Wed, Oct 12, 2016 at 06:32:12PM +0200, Sven R. Kunze wrote: So, my reasoning would tell me: where have I seen * so far? *args and **kwargs! And multiplication. Multiplication with only a single argument? Come on. And sequence unpacking. We

Re: [Python-ideas] Proposal for default character representation

On 13.10.2016 01:06, Mikhail V wrote: > On 12 October 2016 at 23:48, M.-A. Lemburg wrote: >> The hex notation for \u is a standard also used in many other >> programming languages, it's also easier to parse, so I don't >> think we should change this default. > > In

Re: [Python-ideas] INSANE FLOAT PERFORMANCE!!!

On Thu, Oct 13, 2016 at 5:17 PM, Stephen J. Turnbull wrote: > Chris Angelico writes: > > > I'm not sure what you mean by "strcmp-able"; do you mean that the > > lexical ordering of two Unicode strings is guaranteed to be the same > > as the byte-wise

Re: [Python-ideas] Proposal for default character representation

On 13 October 2016 at 08:02, Greg Ewing wrote: > Mikhail V wrote: >> >> Consider unicode table as an array with glyphs. > > > You mean like this one? > > http://unicode-table.com/en/ > > Unless I've miscounted, that one has the characters > arranged in rows of 16, so

Re: [Python-ideas] Proposal for default character representation

On 13 October 2016 at 04:49, Emanuel Barry wrote: >> From: Mikhail V >> Sent: Wednesday, October 12, 2016 9:57 PM >> Subject: Re: [Python-ideas] Proposal for default character representation > > Hello, and welcome to Python-ideas, where only a small portion of ideas go > further,