Steven D'Aprano wrote:
- list builder syntax is syntax which returns a list;
- dict builder syntax is syntax which returns a dict;
- set builder syntax is syntax which returns a set;
- generator builder syntax is syntax which returns a generator.
You only get a list/dict/set from the first t
04.07.18 04:26, Tim Peters пише:
I really don't know what Guido likes best about this, but for me it's
the large number of objectively small wins in `if` and `while`
contexts. They add up. That conclusion surprised me. That there are
occasionally bigger wins to be had is pure gravy.
Could
04.07.18 03:24, INADA Naoki пише:
I feel PEP 572 breaks border between expression and statement, and it makes
readability of dirty code worse.
Thank you, this is what I meant.
On the other hand, I understand PEP 572 allows clever code simplifies
tedious
code. It may increase readability of
04.07.18 00:51, Chris Angelico пише:
On Wed, Jul 4, 2018 at 7:37 AM, Serhiy Storchaka wrote:
I believe most Python users are not
professional programmers -- they are sysadmins, scientists, hobbyists and
kids --
[citation needed]
I don't understand what citation do you need.
In particularl
On Tue, Jul 03, 2018 at 09:54:22PM -0400, Terry Reedy wrote:
> > results = [(x, y, x/y) for x in input_data for y in [f(x)] if y > 0]
>
> Would (f(x),) be faster?
There is a deferred feature request to optimize "for x in [item]" as
equivalent to "for x in (item,)", to avoid constructing a
On 7/3/2018 5:37 PM, Serhiy Storchaka wrote:
I like programming languages in which all are expressions (including
function declarations, branching and loops) and you can use an
assignment at any point, but Python is built on other ways, and I like
Python too. PEP 572 looks violating several Pyt
I think both PEPs are relying on FASTCALL calling convention,
and can't be accepted until FASTCALL is stable & public.
There are enough time before Python 3.8 is released.
Let's go step by step.
Regards,
On Wed, Jul 4, 2018 at 12:10 AM Jeroen Demeyer wrote:
> Hello all,
>
> in order to make re
[INADA Naoki]
> ...
> On the other hand, I understand PEP 572 allows clever code
> simplifies tedious code. It may increase readability of non-dirty code.
The latter is the entire intent ,of course. We can't force people to write
readable code, but I don't understand the widespread assumption th
> > In particularly mutating and
> > non-mutating operations are separated. The assignment expression breaks
> > this.
>
> [citation needed]
>
> In terms of blending mutating and non-mutating operations, augmented
> assignment is far worse. Contrast:
>
> >>> x = 1
> >>> y = x
> >>> x += 1
>
> >>
On Wed, Jul 04, 2018 at 11:13:20AM +1200, Greg Ewing wrote:
> Terry Reedy wrote:
> >If we had followed the math precedent, instead of >language>, we would have set builders, list builders, dict builders, and
> >generator builders.
>
> I was intending to suggest something like that back when
> co
On Tue, Jul 3, 2018 at 4:25 PM Victor Stinner wrote:
> 2018-07-02 20:19 GMT+02:00 Guido van Rossum :
> > Thank you all. I will accept the PEP as is. (...)
>
> I see more and more articles ("on the Internet") saying that Guido van
> Rossum already accepted the PEP. Is the PEP already accepted or w
2018-07-02 20:19 GMT+02:00 Guido van Rossum :
> Thank you all. I will accept the PEP as is. (...)
I see more and more articles ("on the Internet") saying that Guido van
Rossum already accepted the PEP. Is the PEP already accepted or will
be accepted?
Right now, https://www.python.org/dev/peps/pep
Terry Reedy wrote:
If we had followed the math precedent, instead of language>, we would have set builders, list builders, dict builders, and
generator builders.
I was intending to suggest something like that back when
comprehensions were first being discussed, but people
raced ahead and adopte
On Tue, Jul 3, 2018 at 2:51 PM, Chris Angelico wrote:
> On Wed, Jul 4, 2018 at 7:37 AM, Serhiy Storchaka
> wrote:
> > I believe most Python users are not
> > professional programmers -- they are sysadmins, scientists, hobbyists and
> > kids --
>
> [citation needed]
fair enough, but I think we
I smell a new thread. :-)
On Tue, Jul 3, 2018 at 3:06 PM Terry Reedy wrote:
> On 7/3/2018 2:42 AM, Tim Peters wrote:
>
> > So if we had it to do over again I'd sigh and accept "generator
> > comprehensions" anyway. It's been an eternal PITA - and especially in
> > the PEP 572 threads! - to keep
On 7/3/2018 2:42 AM, Tim Peters wrote:
So if we had it to do over again I'd sigh and accept "generator
comprehensions" anyway. It's been an eternal PITA - and especially in
the PEP 572 threads! - to keep typing "comprehensions or generator
expressions". Then again, if I had the power of Guid
On Wed, Jul 4, 2018 at 7:37 AM, Serhiy Storchaka wrote:
> I believe most Python users are not
> professional programmers -- they are sysadmins, scientists, hobbyists and
> kids --
[citation needed]
> In particularly mutating and
> non-mutating operations are separated. The assignment expression
I like programming languages in which all are expressions (including
function declarations, branching and loops) and you can use an
assignment at any point, but Python is built on other ways, and I like
Python too. PEP 572 looks violating several Python design principles.
Python looks simple la
On Mon, Jul 2, 2018 at 11:42 PM, Tim Peters wrote:
> "comprehensions" was always a dubious term, carried over from set theory
> where the term focuses on the optional "if" part rather than the more
> fundamental iterator or computation parts.
>
I always wondered about that :-) -- I'd say for mo
Hello all,
in order to make reviewing PEP 576/580 easier and possibly take some
ideas from one PEP to the other, let me state the one fundamental
difference between these PEPs. There are many details in both PEPs that
can still change, so I'm focusing on what I think is the big structural
dif
On 03/07/2018 06:47, Tim Peters wrote:
[Rob Cliffe]
> It's late to raise this,
By months, yes ;-)
> but what exactly are the objections to the syntax
> expr -> name # or variations such as expr => name
> instead of
> name := expr
>
> The PEP mentions that this syntax does not
21 matches
Mail list logo
