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 programming literature it i

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

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 an

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

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" you're

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 [email protected] https://mail.python.org/mailman

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

Mikhail V wrote: But: you claim to see bit patterns in hex numbers? Then I bet you will see them much better if you take binary notation (2 symbols) or quaternary notation (4 symbols), I guarantee. Nope. The meaning of 0xC001 is much clearer to me than 1101, because I'd have to coun

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

> On 13 Oct 2016, at 09:43, Greg Ewing wrote: > > Mikhail V wrote: >> Did you see much code written with hex literals? > > From /usr/include/sys/fcntl.h: > Backing Greg up for a moment, hex literals are extremely common in any code that needs to work with binary data, such as network program

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 binary > literals tha

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 message, it could well be added in a point

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

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 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 using all sorts of ways:

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 you'v

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 makes you seem to be an

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 _counting_ by people, then y

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

On Wed, Oct 12, 2016 at 5:41 PM, Nick Coghlan wrote: > However, set builder notation doesn't inherently include the notion of > flattening lists-of-lists. Instead, that's a *consumption* operation > that happens externally after the initial list-of-lists has been > built, and that's exactly how it

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 your intuition to oth

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

On Thu, Oct 13, 2016 at 6:19 PM Paul Moore wrote: > 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. > > An

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 a

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

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')]] Marttii, somehow you have lost the leading * when quoting me. What I actually wrote was: [*t for t in

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 the characters >> arranged in r

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 have lost the leading

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 f

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 some

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 collectio

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 ct

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: g

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)) == == tuple(f()) >> [*(1

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 you explain how to modif

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

Related: Nick posted an excellent answer to this question here: http://stackoverflow.com/questions/5953205/why-are-there-no-sorted-containers-in-pythons-standard-libraries On Thursday, October 13, 2016 at 4:36:39 PM UTC-4, Марк Коренберг wrote: > > I mean mutable containers that are always sor

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 from f(t) > l = list(ge

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

On 13 October 2016 at 21:47, אלעזר wrote: > if you allow result.append(1, 2, 3) to mean result.extend([1,2,3]) # which > was discussed before 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* use

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 modi

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

First of all: +1 to Sven's very well-expressed support of the proposal, and +1 to Nick's very well-explained reasons for rejecting it. As one of the main implementers of PEP 448, I have always liked this, but I suggested that we leave this out when there was opposition since there's no rush for

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

On Thu, Oct 13, 2016 at 11:59 PM Paul Moore wrote: > On 13 October 2016 at 21:47, אלעזר wrote: > > if you allow result.append(1, 2, 3) to mean result.extend([1,2,3]) # > which > > was discussed before > > I don't (for the reasons raised before). But thank you for your > explanation, it clarifie

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

On Fri, Oct 14, 2016 at 12:06 AM Neil Girdhar wrote: > Regarding Steven's example, like Sven, I also see it this way: > > [*t for t in [(1, 'a'), (2, 'b'), (3, 'c')]] > > should mean: > >[*(1, 'a'), *(2, 'b'), *(3, 'c')]] > > Which coincides with what the OP is asking for. > > >From a C

[Python-ideas] Add sorted (ordered) containers

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 hash) * SortedList (sorted elements, the same as SortedSet, but without uniquiness constrain

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

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

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 meaning

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

On Thu, Oct 13, 2016 at 01:46:34PM -0700, Neil Girdhar wrote: > If provided, the explicit metaclass must be an instance of > type()." -1 for pointless breakage. The metaclass has always been permitted to be any callable. You haven't given any good reason for gratuitously changing this. --

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 struct

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

Trying to restate the proposal, somewhat more formal following Random832 and Paul's suggestion. I only speak about the single star. --- *The suggested change of syntax:* comprehension ::= starred_expression comp_for *Semantics:* (In the following, f(x) must always evaluate to an iterable)

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 treated

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

Those are great articles. One thing that Andrew does recommend would be to standardize the interface to the sorted containers, and add them to collections.abc as SortedDict, and SortedSet. I recently switched from blist to sortedcontainers and it would be nice to have these standardized going

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 i

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 > specified metaclass (i

[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 > hash) > * SortedList (

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

On Thu, Oct 13, 2016 at 08:15:36PM +0200, Martti Kühne wrote: > Can I fix my name, though? I don't understand what you mean. Your email address says your name is Martti Kühne. Is that incorrect? [...] > I meant that statement in context of the examples which were brought up: > the occurrence

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

On 2016-10-14 02:04, Steven D'Aprano wrote: On Thu, Oct 13, 2016 at 08:15:36PM +0200, Martti Kühne wrote: Can I fix my name, though? I don't understand what you mean. Your email address says your name is Martti Kühne. Is that incorrect? [snip] You wrote "Marttii" and he corrected it when h

Re: [Python-ideas] Null coalescing operator

(Replying to multiple posts in this thread) Guido van Rossum: > Another problem is PEP 505 -- it > is full of discussion but its specification is unreadable due to the > author's idea to defer the actual choice of operators and use a > strange sequence of unicode characters instead. Hi, I wrote

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 i

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

Greg Ewing wrote: > #define O_RDONLY0x /* open for reading only */ > #define O_WRONLY0x0001 /* open for writing only */ > #define O_RDWR 0x0002 /* open for reading and writing */ > #define O_ACCMODE 0x0003 /* mask for above mod

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 i

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: 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 Python wart to look out for if yo

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: 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 comprehensions

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

Neil Girdhar wrote: At the end of this discussion it might be good to get a tally of how many people think the proposal is reasonable and logical. I think it's reasonable and logical. -- Greg ___ Python-ideas mailing list [email protected] http

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

On 13 October 2016 at 10:18, M.-A. Lemburg wrote: > I suppose you did not intend everyone to have to write > \u010 just to get a newline code point to avoid the > ambiguity. Ok there are different usage cases. So in short without going into detail, for example if I need to type in a unicode

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

Sjoerd Job Postmus wrote: I think the suggested spelling (`*`) is the confusing part. If it were to be spelled `from ` instead, it would be less confusing. Are you suggesting this spelling just for generator comprehensions, or for list comprehensions as well? What about dict comprehensions? --

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

Paul Moore wrote: please can you explain how to modify that translation rule to incorporate the suggested syntax? It's quite simple: when there's a '*', replace 'append' with 'extend': [*fn(x) for x in lst if cond] expands to result = [] for x in lst: if cond: result.extend(fn(x))

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

On Fri, Oct 14, 2016 at 1:54 AM, Steven D'Aprano wrote: >> and: >> >> o = ord (c) >> if 100 <= o <= 150: > > Which is clearly not the same thing, and better written as: > > if "d" <= c <= "\x96": > ... Or, if you really want to use ord(), you can use hex literals: o = ord(c) if 0x64 <= o <=

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

Paul Moore wrote: Where in [fn(x) for x in lst if cond] is the * allowed? fn(*x)? *fn(x)? Obviously you're *allowed* to put fn(*x), because that's already a valid function call, but the only *new* place we're talking about, and proposing new semantics for, is in front of the expression represen