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 sequence containing the
>> it
Awesome! Thanks for the thorough explanation.
On Sat, Oct 15, 2016 at 11:01 PM, Tim Peters wrote:
> [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',
On 16 October 2016 at 08:35, Alireza Rafiei wrote:
> Awesome! Thanks for the thorough explanation.
Thank you for the interesting suggestion that prompted the
explanation. I don't know about others, but I know that I often forget
ways to use the tools already at our disposal, so threads like this
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;
>
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 intent
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 with
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" interpretation.
> >
> >
> > So far I've seen one very v
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. :-( I
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 does he teach? Chil
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 not what we mean when we talk ab
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 that other approaches le
>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
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 pytho
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 wrote:
> On 15.10.
> 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 th
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 gre
... actually, thank you Sven (but Mark also. And all the contributors to
the discussion, even those I disagree with).
On Oct 16, 2016 10:47 AM, "David Mertz" wrote:
> Actually, I agree with Marietta. I don't care whatsoever about mocking me,
> which was a certain element of it. I have thick skin
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 delays brain impairmen
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 is not only about printin
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* anything
On Sun, Oct 16, 2016 at 03:02:55PM +0200, Ivan Levkivskyi wrote:
> What I have learned from this megathread is that the syntax [*foo for foo
> in bar]
> is proposed as a replacement for a one-liner itertools.chain(*[foo for foo
> in bar]).
If people take away nothing else from this thread, it sho
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 of
On Sun, Oct 16, 2016 at 3:26 PM, Mikhail V wrote:
> One my supposition is that during the reading there is
> very intensive two-directional signalling between eye and
> brain. So generally you are correct, the eye is technically
> a camera attached to the brain and simply sends pictures
> at some
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 aspect,
On 16 October 2016 at 23:23, Greg Ewing 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.
What do you mean I can't be sure?
I am fully functional, mentally healthy man :)
>Have you *measured* anything, though? Do
On 17 October 2016 at 02:23, Steven D'Aprano wrote:
> 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 c
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 - while I can't *name* any spec
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
On 16 October 2016 at 14:44, 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" interpretation.
>
> So far I've seen one very vocal person who disgrees, and
> maybe one other who isn't sure.
"Language desi
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.
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
>> Since "-v" is already a counted option, we're also free
>> to expand it to give even more info the more verbose we ask it to be
>> (although initially I think pursuing just Inada-san's main suggestion
>> of matching the REPL header makes sense)
>
> Sure, I guess. Not sure what -Vvv would mean, b
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
>>
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 hav
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
(Added python-dev in CC list, because there are enough +1 already).
On Mon, Oct 17, 2016 at 3:06 PM, Chris Angelico wrote:
> 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
36 matches
Mail list logo
