On Sun, Nov 17, 2019, at 21:39, Daniel Zeng wrote:
> Syntax for tuple comprehension, something like:
> (i, for i in range(10))
>
> This shouldn't result in ambiguity, since generators need to be in
> parentheses anyway:
> (i, for i in range(10)) vs (1, (i for i in range(10)))
I think it should
> > Is this meant to produce a tuple that contains inner tuples, or is it
> the same as tuple(i for i in range(10)) ?
This would be equivalent to tuple(i for i in range(10))
> Is the comma just magic that says "tuple comprehension, not genexp"?
I think that my proposal is consistent with Python's
On Sun, Nov 17, 2019, at 16:43, Greg Ewing wrote:
> Probably. I may also have mixed it up with closing(), which
> does something different.
It occurs to me that almost any usage of closing likely has the same problem,
in that the expression passed to closing may itself throw an exception. It may
On Sun, Nov 17, 2019, at 14:17, Oscar Benjamin wrote:
> Also I don't know of any other misbehaving context managers besides
> open so I'm not sure that a general utility is needed rather than just
> a well-behaved alternative for open.
It's not in dbapi2, but most database connections are context
On Mon, Nov 18, 2019 at 2:56 PM Daniel Zeng wrote:
>
> Syntax for tuple comprehension, something like:
> (i, for i in range(10))
Is this meant to produce a tuple that contains inner tuples, or is it
the same as tuple(i for i in range(10)) ?
> This shouldn't result in ambiguity, since generators
Syntax for tuple comprehension, something like:
(i, for i in range(10))
This shouldn't result in ambiguity, since generators need to be in
parentheses anyway:
(i, for i in range(10)) vs (1, (i for i in range(10)))
___
Python-ideas mailing list -- python-
> Please recall that chained comparisons such are
> >>> A < B < C
> is to produce simple code when B is not an identifier, but an expression.
For example
> >>> low < len(x) < high
> or
> >>> inner ** 2 < x**2 + y**2 + z**2 < outer**2
> which determines if (x, y, z) is in a spherical shell.
Even in
On 18/11/19 8:17 am, Oscar Benjamin wrote:
PEP 343 gives the example of
"opened" which doesn't have this problem
https://www.python.org/dev/peps/pep-0343/#examples
but apparently that didn't make it to the final release of 2.5 (I
guess that's what Greg is referring to).
Probably. I may also ha
On Sun, 17 Nov 2019 at 06:28, Random832 wrote:
> On Sat, Nov 16, 2019, at 16:13, Greg Ewing wrote:
> >
> > I seem to remember we had such a context manager for a brief
> > time after the with-statement was invented, until someone had
> > the bright idea to make open() do double duty.
> >
> > The m
Kyle Stanley wrote:
> I agree, that syntax definitely seems counter-intuitive. If it came up in
> a code review, I would request a revision to "A in B and B < C".
>
Please recall that chained comparisons such are
>>> A < B < C
is to produce simple code when B is not an identifier, but an expressi
> Some people find this legal syntax confusing:
> A in B < C
I agree, that syntax definitely seems counter-intuitive. If it came up in a
code review, I would request a revision to "A in B and B < C".
> I feel like most code reviews would not allow this kind of code to be
checked in, at least wit
Hi Neil
I'm an amateur (unpaid) research mathematician. I find the syntax
>>> A in B < C
clear. And in some cases appropriate to use. Although I don't like the
choice of identifiers. Mathematicians usually use upper-case letters for
set, and lower-case letters for their elements.
Thus I prefer
>>
On Sun, Nov 17, 2019 at 12:43:55AM -0800, Neil Girdhar wrote:
> Some people find this legal syntax confusing:
>
> A in B < C
>
> (It means A in B and B < C.)
>
> I feel like most code reviews would not allow this kind of code to be
> checked in, at least without a comment explaining what the cod
On Sun, Nov 17, 2019 at 7:45 PM Neil Girdhar wrote:
> If not, I suggest dividing the comparison operators into two groups:
>
> in, not in, is, is not
>
> and
>
> <, >, <=, >=, ==, !=
>
> and then disallowing chaining of operators from both groups.
>
> For example, still allowed:
>
> A <= B <= C
>
Neil Girdhar wrote:
> Some people find this legal syntax confusing:
> A in B < C
> (It means A in B and B < C.)
> I feel like most code reviews would not allow this kind of code to be
> checked in, at least without a comment explaining what the code does. What
> are the motivating reasons for al
Some people find this legal syntax confusing:
A in B < C
(It means A in B and B < C.)
I feel like most code reviews would not allow this kind of code to be
checked in, at least without a comment explaining what the code does. What
are the motivating reasons for allowing this syntax? Is there
16 matches
Mail list logo
