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

Mikhail V wrote: And decimal is objectively way more readable than hex standard character set, regardless of how strong your habits are. That depends on what you're trying to read from it. I can look at a hex number and instantly get a mental picture of the bit pattern it represents. I can't

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

On 13 October 2016 at 04:18, Brendan Barnwell wrote: > On 2016-10-12 18:56, Mikhail V wrote: >> >> Please don't mix the readability and personal habit, which previuos >> repliers seems to do as well. Those two things has nothing >> to do with each other. > > > You

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

> 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, and where most newcomers that wish to improve the language get hit by the

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

On Oct 12, 2016 9:25 PM, "Chris Angelico" wrote: > > On Thu, Oct 13, 2016 at 12:56 PM, Mikhail V wrote: > > But as said I find this Unicode only some temporary happening, > > it will go to history in some future and be > > used only to study extinct

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

On Oct 12, 2016 4:33 PM, "Mikhail V" wrote: > > Hello all, > > *snip* > > PROPOSAL: > 1. Remove all hex notation from printing functions, typing, > documention. > So for printing functions leave the hex as an "option", > for example for those who feel the need for hex

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

On Thu, Oct 13, 2016 at 12:56 PM, Mikhail V wrote: > But as said I find this Unicode only some temporary happening, > it will go to history in some future and be > used only to study extinct glyphs. And what will we be using instead? Morbid curiosity trumping a plonking,

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

On 2016-10-12 18:56, Mikhail V wrote: Please don't mix the readability and personal habit, which previuos repliers seems to do as well. Those two things has nothing to do with each other. You keep saying this, but it's quite incorrect. The usage of decimal notation is itself just a

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

On 13 October 2016 at 01:50, Chris Angelico wrote: > On Thu, Oct 13, 2016 at 10:09 AM, Mikhail V wrote: >> On 12 October 2016 at 23:58, Danilo J. S. Bellini >> wrote: >> >>> Decimal notation is hardly >>> readable when we're

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

On Thu, Oct 13, 2016 at 10:09 AM, Mikhail V wrote: > On 12 October 2016 at 23:58, Danilo J. S. Bellini > wrote: > >> Decimal notation is hardly >> readable when we're dealing with stuff designed in base 2 (e.g. due to the >> visual separation of

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

On Thu, Oct 13, 2016 at 2:35 AM Steven D'Aprano wrote: > On Wed, Oct 12, 2016 at 04:11:55PM +, אלעזר wrote: > > > Steve, you only need to allow multiple arguments to append(), then it > makes > > perfect sense. > > I think you're missing a step. What will multiple

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

On Wed, Oct 12, 2016 at 04:11:55PM +, אלעזר wrote: > Steve, you only need to allow multiple arguments to append(), then it makes > perfect sense. I think you're missing a step. What will multiple arguments given to append do? There are two obvious possibilities: - collect all the arguments

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

On Wed, Oct 12, 2016 at 06:32:12PM +0200, Sven R. Kunze wrote: > On 12.10.2016 17:41, Nick Coghlan wrote: > >This particular proposal fails on the first question (as too many > >people would expect it to mean the same thing as either "[*expr, for > >expr in iterable]" or "[*(expr for expr in

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

On Wed, Oct 12, 2016 at 4:26 PM Terry Reedy wrote: > I suspect that optimizing string sorting > will take some experimentation. If the initial item is str, it might be > worthwhile to record the highest 'kind' during the type scan, so that > strncmp can be used if all are

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

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? > opposite. For unicode representations, byte notation seems standard. How does this make it a good idea?

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

On 12 October 2016 at 23:58, Danilo J. S. Bellini wrote: > Decimal notation is hardly > readable when we're dealing with stuff designed in base 2 (e.g. due to the > visual separation of distinct bytes). Hmm what keeps you from separateting the logical units to be

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

Forgot to reply to all, duping my mesage... On 12 October 2016 at 23:48, M.-A. Lemburg wrote: > Hmm, in Python3, I get: > s = "абв.txt" s > 'абв.txt' I posted output with Python2 and Windows 7 BTW , In Windows 10 'print' won't work in cmd console at all by default

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

Paul Moore wrote: What I'm *not* quite clear on is why Python 3's change to reject comparisons between unrelated types makes this optimisation possible. I think the idea was that it's likely to be *useful* a higher proportion of the time, because Python 3 programmers have to be careful that

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

On Wed, Oct 12, 2016 at 3:34 PM, Alexander Belopolsky wrote: > > On Wed, Oct 12, 2016 at 6:14 PM, Elliot Gorokhovsky > wrote: >> >> so then Latin1 strings are memcmp-able, and others are not. > > > No. Strings of the same kind are

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

On 2016-10-12 23:34, Alexander Belopolsky wrote: On Wed, Oct 12, 2016 at 6:14 PM, Elliot Gorokhovsky > wrote: so then Latin1 strings are memcmp-able, and others are not. No. Strings of the same kind are "memcmp-able"

Re: [Python-ideas] PEP8 dictionary indenting addition

On 10/12/2016 1:40 PM, Stephen J. Turnbull wrote: Steven D'Aprano writes: > I learned the hard way that if I don't put the breaking space at > the beginning of the next fragment, I probably wouldn't put it at > the end of the previous fragment either. The converse applies in my case, so

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

On 10/12/2016 5:57 PM, Elliot Gorokhovsky wrote: On Wed, Oct 12, 2016 at 3:51 PM Nathaniel Smith > wrote: But this isn't relevant to Python's str, because Python's str never uses UTF-8. Really? I thought in python 3, strings are all unicode...

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

Ah. That makes a lot of sense, actually. Anyway, so then Latin1 strings are memcmp-able, and others are not. That's fine; I'll just add a check for that (I think there are already helper functions for this) and then have two special-case string functions. Thanks! On Wed, Oct 12, 2016 at 4:08 PM

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

On Thu, Oct 13, 2016 at 8:51 AM, Nathaniel Smith wrote: > The comparison methods on Python's str are codepoint-by-codepoint. Thanks, that's what I wasn't sure of. ChrisA ___ Python-ideas mailing list Python-ideas@python.org

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

On Wed, Oct 12, 2016 at 5:57 PM, Elliot Gorokhovsky < elliot.gorokhov...@gmail.com> wrote: > On Wed, Oct 12, 2016 at 3:51 PM Nathaniel Smith wrote: > >> But this isn't relevant to Python's str, because Python's str never uses >> UTF-8. >> > > Really? I thought in python 3,

Re: [Python-ideas] Add a method to get the subset of a dictionnary.

On 10/12/2016 5:52 PM, Terry Reedy wrote: On 10/12/2016 12:06 PM, Enguerrand Pelletier wrote: b = {k, v for k,v in a.items() if k in interesting_keys} Test code before posting. The above is a set comprehension creating a set of tupes. I should have followed my own advice. The above is a

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

I'm -1 on this. Just type "0431 unicode" on your favorite search engine. U+0431 is the codepoint, not whatever digits 0x431 has in decimal. That's a tradition and something external to Python. As a related concern, I think using decimal/octal on raw data is a terrible idea (e.g. On Linux, I

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

On Wed, Oct 12, 2016 at 3:51 PM Nathaniel Smith wrote: > But this isn't relevant to Python's str, because Python's str never uses > UTF-8. > Really? I thought in python 3, strings are all unicode... so what encoding do they use, then?

Re: [Python-ideas] Add a method to get the subset of a dictionnary.

On 10/12/2016 12:06 PM, Enguerrand Pelletier wrote: Hi all, It always bothered me to write something like this when i want to strip keys from a dictionnary in Python: a = {"foo": 1, "bar": 2, "baz": 3, "foobar": 42} interesting_keys = ["foo", "bar", "baz"] If the keys are hashable, this

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

On 12.10.2016 23:33, Mikhail V wrote: > Hello all, > > I want to share my thoughts about syntax improvements regarding > character representation in Python. > I am new to the list so if such a discussion or a PEP exists already, > please let me know. > > So in short: > > Currently Python uses

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

On 10/12/2016 05:33 PM, Mikhail V wrote: Hello all, Hello! New to this list so not sure if I can reply here... :) Now printing it we get: u'\u0430\u0431\u0432.txt' By "printing it", do you mean "this is the string representation"? I would presume printing it would show characters

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

> So what's Python doing? Is it a codepoint ordering? > ...ya...how is the python interpreter supposed to know what language strings are in? There is a unique ordering of unicode strings defined by the unicode standard, AFAIK. If you want to sort by natural language ordering, see here:

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

On Wed, Oct 12, 2016 at 3:39 PM Nathaniel Smith wrote: > It looks like PyUnicode_Compare already has a special case to use > memcmp when both of the strings fit into latin1: > Wow! That's great! I didn't even try reading through unicode_compare, because I felt I might miss some

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

On Thu, Oct 13, 2016 at 8:19 AM, Elliot Gorokhovsky wrote: > > My first question was how expensive python compares are vs C compares. And > since python 2 has PyString_AS_STRING, which just gives you a char* pointer > to a C string, I went in and replaced

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

On Wed, Oct 12, 2016 at 2:19 PM, Elliot Gorokhovsky wrote: [...] > So that was the motivation for all this. Actually, if I wrote this for > python 2, I might be able to get even better numbers (at least for strings), > since we can't use strcmp in python 3.

[Python-ideas] Proposal for default character representation

Hello all, I want to share my thoughts about syntax improvements regarding character representation in Python. I am new to the list so if such a discussion or a PEP exists already, please let me know. So in short: Currently Python uses hexadecimal notation for characters for input and output.

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

On Tue, Oct 11, 2016 at 9:56 PM Nick Coghlan wrote: > Once you get to the point of being able to do performance mentions on > a CPython build with a modified list.sort() implementation, you'll > want to take a look at the modern benchmark suite in >

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

On Wed, Oct 12, 2016 at 9:20 AM Tim Peters wrote: > > What I'm *not* quite clear on is why Python 3's change to reject > > comparisons between unrelated types makes this optimisation possible. > > It doesn't. It would also apply in Python 2. I simply expect the >

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

To be honest, I don't have a clear picture of what {**x for x in d.items()} should be. But I do have such picture for dict(**x for x in many_dictionaries) Elazar ‪On Wed, Oct 12, 2016 at 11:37 PM ‫אלעזר‬‎ wrote:‬ > On Wed, Oct 12, 2016 at 11:26 PM David Mertz

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

On 12.10.2016 21:38, אלעזר wrote: What is the intuition behind [1, *x, 5]? The starred expression is replaced with a comma-separated sequence of its elements. The trailing comma Nick referred to is there, with the rule that [1,, 5] is the same as [1, 5]. I have to admit that I have my

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

On 12 October 2016 at 20:22, David Mertz wrote: > I've followed this discussion some, and every example given so far > completely mystifies me and I have no intuition about what they should mean. Same here. On 12 October 2016 at 20:38, אלעזר wrote: > What is

Re: [Python-ideas] Add a method to get the subset of a dictionnary.

That discussion seemed to mostly just conclude that dicts shouldn't have all set operations, and then it kind of just dropped off. No one really argued the subset part. -- Ryan [ERROR]: Your autotools build scripts are 200 lines longer than your program. Something’s wrong.

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

On Wed, Oct 12, 2016 at 12:38 PM, אלעזר wrote: > What is the intuition behind [1, *x, 5]? The starred expression is > replaced with a comma-separated sequence of its elements. > I've never actually used the `[1, *x, 5]` form. And therefore, of course, I've never taught it

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

What is the intuition behind [1, *x, 5]? The starred expression is replaced with a comma-separated sequence of its elements. The trailing comma Nick referred to is there, with the rule that [1,, 5] is the same as [1, 5]. All the examples follow this intuition, IIUC. Elazar בתאריך יום ד׳, 12

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

Steve, you only need to allow multiple arguments to append(), then it makes perfect sense. בתאריך יום ד׳, 12 באוק' 2016, 18:43, מאת Steven D'Aprano ‏< st...@pearwood.info>: > On Tue, Oct 11, 2016 at 02:42:54PM +0200, Martti Kühne wrote: > > Hello list > > > > I love the "new" unpacking

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

[Nick Coghlan] > It's probably more relevant that cmp() went away, since that > simplified the comparison logic to just PyObject_RichCompareBool, > without the custom comparison function path. Well, the current sort is old by now, and was written for Python 2. But it did anticipate that rich

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

On 12 October 2016 at 23:58, Sven R. Kunze wrote: > Reading PEP448 it seems to me that it's already been considered: > https://www.python.org/dev/peps/pep-0448/#variations > > The reason for not-inclusion were about concerns about acceptance because of > "strong concerns about

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

[Paul Moore] > My understanding is that the code does a per-check that all the > elements of the list are the same type (float, for example). This is a > relatively quick test (O(n) pointer comparisons). If everything *is* a > float, then an optimised comparison routine that skips all the type >

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

On 12 October 2016 at 21:35, Paul Moore wrote: > What I'm *not* quite clear on is why Python 3's change to reject > comparisons between unrelated types makes this optimisation possible. > Surely you have to check either way? It's not that it's a particularly > important

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

On 12 October 2016 at 11:16, Steven D'Aprano wrote: > On Wed, Oct 12, 2016 at 12:25:16AM +, Elliot Gorokhovsky wrote: > >> Regarding generalization: the general technique for special-casing is you >> just substitute all type checks with 1 or 0 by applying the type