Re: [Python-ideas] A directive for indentation type, stricter indentation parsing.

2019-03-25 Thread fhsxfhsx
Just as to your example, you can try `textwrap.dedent` At 2019-03-26 00:32:26, "Mikhail V" wrote: >Not a proposal yet, but some thoughts: >I think it would help in a longer perspective if a user could >include a directive in the header of the source code file that >defines indentation

Re: [Python-ideas] Dict joining using + and +=

2019-02-28 Thread fhsxfhsx
Considering potential ambiguity, I suggest `d1.append(d2)` so we can have an additional argument saying `d1.append(d2, mode="some mode that tells how this function behaviours")`. If we are really to have the new syntax `d1 + d2`, I suggest leaving it for `d1.append(d2, mode="strict")` which

Re: [Python-ideas] Left arrow and right arrow operators

2019-03-03 Thread fhsxfhsx
I wonder if it is necessary to add two new operators, and for me, "arrow operator" is not clearer than `+`. Could you explain why do you prefer this operator than `+`? Also -> is a symbol of propositional logic, like ∧ and ∨ , do we also need these operators as well? At 2019-03-03

Re: [Python-ideas] dict.merge(d1, d2, ...) (Counter proposal for PEP 584)

2019-03-05 Thread fhsxfhsx
I agree so much on your opinion that I was just to create a topic about this if you didn't. I also propose here a small modification to make it more general which adds an argument `how` (name to be discussed), telling how to merge the dicts, as many have pointed out that there could be

[Python-ideas] Temporary variables in comprehensions

2018-02-14 Thread fhsxfhsx
As far as I can see, a comprehension like alist = [f(x) for x in range(10)] is better than a for-loop for x in range(10): alist.append(f(x)) because the previous one shows every element of the list explicitly so that we don't need to handle `append` mentally. But when it comes to something

Re: [Python-ideas] Temporary variables in comprehensions

2018-02-17 Thread fhsxfhsx
pr_using_i > for j in is > y = expr_using_j_and_x] > > This demonstrates the scope of each assignment; available in main result and > then every clause that follows it. > > Sorry to op who will receive twice, forgot reply to all > > On 15 Feb 2018 7:03 am, "fhsxfhsx

Re: [Python-ideas] Temporary variables in comprehensions

2018-02-17 Thread fhsxfhsx
> y = expr_using_j_and_x] > > This demonstrates the scope of each assignment; available in main result and > then every clause that follows it. > > Sorry to op who will receive twice, forgot reply to all > > On 15 Feb 2018 7:03 am, "fhsxfhsx" <fhsxf...@126.com>

Re: [Python-ideas] Temporary variables in comprehensions

2018-02-17 Thread fhsxfhsx
riting: first you give the thing you >care about a name, then you refer to it by name. However, that's a problem every comprehension faces, not a problem drawn by the new syntax. At 2018-02-15 18:08:46, "Paul Moore" <p.f.mo...@gmail.com> wrote: >On 15 February 2018 at 0

Re: [Python-ideas] Temporary variables in comprehensions

2018-02-17 Thread fhsxfhsx
Hi Steve, Thank you for so detailed comments. My comments also below interleaved with yours. At 2018-02-16 08:57:40, "Steven D'Aprano" <st...@pearwood.info> wrote: >Hi fhsxfhsx, and welcome. > >My comments below, interleaved with yours. > > >On Thu, Feb 15,

Re: [Python-ideas] Temporary variables in comprehensions

2018-02-18 Thread fhsxfhsx
Thanks so much for the comments and the collect on this syntax! Comments on *previous talk* The list also mentioned some other previous proposals, so I myself search it and find that there're even more in the mailing list since 2008.