On Wed, Oct 19, 2016 at 7:07 PM, Terry Reedy wrote:
> On 10/19/2016 12:38 AM, Nathaniel Smith wrote:
>
>> I'd like to propose that Python's iterator protocol be enhanced to add
>> a first-class notion of completion / cleanup.
>
>
> With respect the the standard iterator protocol, a very solid -1 f
On Wed, Oct 19, 2016 at 3:07 PM, Paul Moore wrote:
> On 19 October 2016 at 20:21, Nathaniel Smith wrote:
>> On Wed, Oct 19, 2016 at 11:38 AM, Paul Moore wrote:
>>> On 19 October 2016 at 19:13, Chris Angelico wrote:
Now it *won't* correctly call the end-of-iteration function, because
t
Alexander Heger wrote:
For me the current behaviour does not seem unreasonable as it resembles
the order in which you write out loops outside a comprehension
That's true, but the main reason for having comprehensions
syntax in the first place is so that it can be read
declaratively -- as a desc
On Wed, Oct 19, 2016 at 5:32 PM, Todd wrote:
> If there is a problem with the current options (and I'm not convinced
>> there is) it's that it in'st a literal for multidimensional array, but
>> rather a literal for a bunch of nested lists -- the list themselves are
>> created, and so are all the
On Fri, Oct 21, 2016 at 6:09 AM, Random832 wrote:
> On Tue, Oct 18, 2016, at 02:10, Nick Coghlan wrote:
>> Hi, I contributed the current list comprehension implementation (when
>> refactoring it for Python 3 to avoid leaking the iteration variable,
>> as requested in PEP 3100 [1]), and "comprehens
For me the current behaviour does not seem unreasonable as it resembles the
order in which you write out loops outside a comprehension except that the
expression for generated values is provided first.
On 21 October 2016 at 05:03, Sven R. Kunze wrote:
> On 19.10.2016 00:08, Rob Cliffe wrote:
>
>
On Tue, Oct 18, 2016, at 02:10, Nick Coghlan wrote:
> Hi, I contributed the current list comprehension implementation (when
> refactoring it for Python 3 to avoid leaking the iteration variable,
> as requested in PEP 3100 [1]), and "comprehensions are syntactic sugar
> for a series of nested for an
On 18.10.2016 08:23, Greg Ewing wrote:
If it were a namedtuple, for example, you could write
[*t for t in fulltext_tuples if t.language == 'english']
or
[x for t in fulltext_tuples if t.language == 'english' for x in t]
The latter is a bit unsatisfying, because we are having to
make up an
On 19.10.2016 00:08, Rob Cliffe wrote:
But it's far too late to change it now, sadly.
Indeed. :-( But if I were ruler of the world and could have my own
wish-list for Python 4, this (as per the first example) would be on it.
I don't see no reason why we can't make it.
Personally, I also di
On 18.10.2016 10:01, Daniel Moisset wrote:
So, for me, this feature is something that could be covered with a
(new) function with no new syntax required. All you have to learn is
that instead of [*...] you use flatten(...)
The main motivation is not "hey we need yet another way for xyz" but
"
I find the proposed syntax worse than the existing square brackets. The way
the NumPy does a repr of an array is a good model of clarity, and it's
correct current Python (except for larger arrays where visual ellipses are
used).
On Oct 20, 2016 12:01 AM, "Greg Ewing" wrote:
> Matt Gilson wrote:
Todd wrote:
||| is the delimiter for the third dimension, || is the delimiter for
the second dimension.
This seems a bit inconsistent. It appears the rule is
"n vertical bars is the delimiter for the nth dimension".
By that rule, the delimiter for the first dimension
should be a single vertical
Matt Gilson wrote:
I think that
it was mentioned that it might be possible for a user to _register_ a
callable that would then be used when this syntax was envoked -- But
having a global setting like that leads to contention.
I think for that to fly it would have to be a per-module
thing. The
13 matches
Mail list logo
