> One of the points of using a function is to not define it in the local
scope, but in some other namespace, so it can be reused and tested.
I consider the "tested" part to be of particular importance. Especially if
it were to become multiple layers deep, this can become a real issue.
This might
22.02.20 09:43, David Mertz пише:
Comprehension are very much based on the idea of *declarative* data
collections. That's their entire reason for being. In general, one
expects comprehension to be side-effect free and just build a collection
according to declared rules. Obviously I know many
I also use PyCharm but I don't fold comprehensions; ideally I don't have to since comprehensions are meant to be simple and concise. Folding a comprehension takes away all the information, including the input to the operation.Regarding names, the example function you presented, `clean`, isn't
1. At least in my editor (PyCharm), I can collapse (fold) list comprehensions
just as easily as functions.
2. In this example the list comprehension already has a name - `clean_lines`.
Using a function actually forces me to come up with a second pointless name.
3. On the note of coming up with
You have to consider that for the reader of the code that's one line containing a function call versus six lines containing that comprehension. An advantage of functions is that you can hide the implementation but a comprehension always contains all the code. If the function name is clear
Comprehension are very much based on the idea of *declarative* data
collections. That's their entire reason for being. In general, one expects
comprehension to be side-effect free and just build a collection according
to declared rules. Obviously I know many ways to smuggle in side effects,
but
> The weird block structures inside comprehension reads terribly even in the
> trivial case shown
David, it's fine if you have that opinion, but you're replying specifically to
my post where I asked someone to elaborate on that kind of opinion, so it
bothers me that you just restated it
-100. The weird block structures inside comprehension reads terribly even
in the trivial case shown, and looks worse the more structures are inside
it. We have functions. They are great. Let's use those.
On Sat, Feb 22, 2020, 2:01 AM Alex Hall wrote:
> > You might be able to avoid calling the
Andrew, you raise a good point that I hadn't considered. I think you're right
that yield inside an expression shouldn't be allowed, to avoid confusion. If we
found a good reason to allow it we could change it later.
___
Python-ideas mailing list --
> You might be able to avoid calling the method twice using the walrus
operator.
I specifically discussed the walrus operator solution, but both you and Dominik
Vilsmeier seem to have missed that.
> I'd use the list constructor with a
> named function anyway, rather than inlining it in a
I'm not against your proposal at this point, but I think you can
already do the first example:
clean = [line.strip() for line in lines if line.strip()]
You might be able to avoid calling the method twice using the walrus
operator. For any operation more complex than that (ie, more complex
> On Feb 21, 2020, at 15:34, Greg Ewing wrote:
>
> On 22/02/20 11:45 am, Andrew Barnert via Python-ideas wrote:
>> there’s no reason you can’t write `[(yield None) for _ in range(3)]` to
>> gather the first three values sent into your generator
>
> Currently this doesn't quite do what you
On Sat, Feb 22, 2020 at 10:32 AM Greg Ewing wrote:
>
> On 22/02/20 11:45 am, Andrew Barnert via Python-ideas wrote:
> > there’s no reason you can’t write `[(yield None) for _ in range(3)]` to
> > gather the first three values sent into your generator
>
> Currently this doesn't quite do what you
> Currently this doesn't quite do what you might expect.
> It doesn't make the enclosing function into a generator,
> it make the list comprehension itself a generator:
>
> >>> def f():
> ... return [(yield x) for x in range(10)]
> ...
> >>> g = f()
> >>> g
> . at 0x6b396c>
> >>>
>
>
Am I
On 22/02/20 11:45 am, Andrew Barnert via Python-ideas wrote:
there’s no reason you can’t write `[(yield None) for _ in range(3)]` to gather
the first three values sent into your generator
Currently this doesn't quite do what you might expect.
It doesn't make the enclosing function into a
On Feb 20, 2020, at 23:56, Alex Hall wrote:
>
> This is a proposal for a new syntax where a comprehension is written as the
> appropriate brackets containing a loop which can contain arbitrary statements.
What happens if there’s a yield expression (that isn’t just ignored and used as
an
Thanks Ricky :)
Technically, if yield is always required, it would have to look like this:
[
for row in matrix:
yield [
for cell in row:
yield f(cell)
]
]
___
Python-ideas
I'll lend a supportive voice here: I like the proposal and would probably
make use of this kind of syntax quite a bit, but I think the requirement of
yield is definitely a necessity. Too much ambiguity without it.
And adding the yield, IMO, doesn't clutter things up too badly. Using one
of the
OK, I think the verdict is in and I will not try to debate it.
> Does opening a [{( and having any : statements inside
> just imply one more indentation level? Or can the statements inside
> be validly less indented than the line containing the = [...
> opening bracket?
I think this is a fun
I am disliking this proposal at all, more from a gut-feel than anything.
But then I just did `import this` and pasted bellow the
parts I think this violates.
While we all have to keep in mind that the "zen of Python" are
more guidelines than absolute standards, they still are
_good_ guidelines
This syntax basically allows to put any code from functions into comprehensions. This enables people to write fewer functions at the cost of more complex comprehensions. But functions are a good idea indeed:* They have a name and from that name it should be clear what that function does
> Yes but then it's the same as defining a generator-function.
List comprehensions are already the same as other things, but they're nice
anyway. `lambda` is the same as defining a function, but it's nice too.
Syntactic sugar is helpful sometimes. I think this:
clean = [
for line
> Would you feel better if `yield` was always required?
Yes but then it's the same as defining a generator-function.
> For almost all the examples I've provided a corresponding equivalent in the
> current syntax, so are you saying that you're still confused now or that you
> can't figure it
Antoine Rozo wrote:
> I think this syntax is very hard to read because the
> yielding-expression can be anywhere in the block and there is nothing
> to identify it.
Would you feel better if `yield` was always required?
> Even in your examples I can't figure out which expression will be
> used.
Hi,
I think this syntax is very hard to read because the
yielding-expression can be anywhere in the block and there is nothing
to identify it.
Even in your examples I can't figure out which expression will be
used. What if I call a function somewhere in the block?
Can't you just use generators +
25 matches
Mail list logo
