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
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 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
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 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
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
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 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
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
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
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
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
> > 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
>
> >>
[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
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
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
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
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
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 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
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
21 matches
Mail list logo
