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

On 16 October 2016 at 04:36, INADA Naoki wrote: [Serhiy wrote] >> >> Are there precedences of combining verbose and version options in other >> programs? >> > > No, I was just afraid about other programs rely on format of python -V. That would be my concern as well -

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

On Sun, Oct 16, 2016 at 05:02:49PM +0200, Mikhail V wrote: > In this discussion yes, but layout aspects can be also > improved and I suppose special purpose of > language does not always dictate the layout of > code, it is up to you who can define that also. > And glyphs is not very narrow

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

On Sun, Oct 16, 2016 at 02:34:58PM +0200, Sven R. Kunze wrote: > As this discussion won't come to an end, I decided to consult my girlfriend. [...] > >>> [(i,i,i) for i in range(4)] > [(0, 0, 0), (1, 1, 1), (2, 2, 2), (3, 3, 3)] Did you remember to tell your girlfriend that a critical property

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

Mikhail V wrote: Those things cannot be easiliy measured, if at all, If you can't measure something, you can't be sure it exists at all. > In my case I am looking at what I've achieved during years of my work on it and indeed there some interesting things there. Have you *measured*

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

On 16 October 2016 at 04:10, Steve Dower wrote: >> I posted output with Python2 and Windows 7 >> BTW , In Windows 10 'print' won't work in cmd console at all by default >> with unicode but thats another story, let us not go into that. >> I think you get my idea right, it

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

On 16 October 2016 at 17:16, Todd wrote: >Even if you were right that your approach is somehow inherently easier, >it is flat-out wrong that other approaches lead to "brain impairment". >On the contrary, it is well-established that challenging >the brain prevents or at least

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

Actually, I agree with Marietta. I don't care whatsoever about mocking me, which was a certain element of it. I have thick skin and am confident in these conversations. The part that was probably over the line was mocking children who learn to program or those who teach them. That's a huge and

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

> As I said, it has been discussed and the consensus so far was: "not > everything needs to be a class if it does not provide substantial benefit" + > "functions are more flexible" + "if it's slower that the original it won't > happen". (These) functions are less flexible here. heapq forbids

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

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? On Sat, Oct 15, 2016 at 4:21 PM, Sven R. Kunze

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

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

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

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

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

On Thu, Oct 13, 2016 at 1:46 AM, Mikhail V wrote: > Practically all this notation does, it reduces the time > before you as a programmer > become visual and brain impairments. > > Even if you were right that your approach is somehow inherently easier, it is flat-out wrong

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

On 16 October 2016 at 02:58, Greg Ewing wrote: >> even if it is assembler or whatever, >> it can be made readable without much effort. > > > You seem to be focused on a very narrow aspect of > readability, i.e. fine details of individual character > glyphs. That's

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

On Sun, Oct 16, 2016 at 5:34 AM, Sven R. Kunze wrote: > On 16.10.2016 07:08, David Mertz wrote: > >> In case it wasn't entirely clear, I strongly and vehemently opposed this >> unnecessary new syntax. It is confusing, bug prone, and would be difficult >> to teach. > > > "Whom

Re: [Python-ideas] PEP8 dictionary indenting addition

Terry Reedy writes: > On 10/12/2016 1:40 PM, Stephen J. Turnbull wrote: > > Ie, space-at-beginning makes for more effective review for me. YMMV. > > I think that PEP 8 should not recommend either way. Oops, sorry, I forgot that was what we were talking about (subject notwithstanding. :-(

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

On 16 October 2016 at 06:47, Chris Angelico wrote: > On Sun, Oct 16, 2016 at 3:44 PM, Greg Ewing > wrote: > > Steven D'Aprano wrote: > > > >> This thread is a huge, multi-day proof that people do not agree that > this > >> is a "reasonable"

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

On 16.10.2016 07:08, David Mertz wrote: In case it wasn't entirely clear, I strongly and vehemently opposed this unnecessary new syntax. It is confusing, bug prone, and would be difficult to teach. As this discussion won't come to an end, I decided to consult my girlfriend. I started

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

On Sun, Oct 16, 2016 at 05:14:54AM +, Neil Girdhar wrote: [Steven (me), refering to Greg] > > Because as your own email inadvertently reinforces, if sequence > > unpacking made sense in the context of a list comprehension, it would > > already be allowed rather than a SyntaxError: it is

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

On Sat, Oct 15, 2016 at 05:38:15PM +, Neil Girdhar wrote: > In ast.c, you can find: > > if (is_dict) { > ast_error(c, n, "dict unpacking cannot be used in " > "dict comprehension"); > return NULL; >

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

On 16 October 2016 at 03:17, Random832 wrote: > On Sat, Oct 15, 2016, at 06:38, Steven D'Aprano wrote: >> > Replacing it _with the items_ is not the same thing as replacing it >> > _with a sequence containing the items_, >> >> I don't think I ever used the phrasing "a

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

[Alireza Rafiei ] > I have a list called count_list which contains tuples like below: > > > [('bridge', 2), ('fair', 1), ('lady', 1), ('is', 2), ('down', 4), > > ('london', 2), ('falling', 4), ('my', 1)] > > > I want to sort it based on the second parameter in