On Wed, 22 Apr 2020 12:52:01 +1000
Steven D'Aprano wrote:
> On Wed, Apr 22, 2020 at 01:07:07AM +0200, Antoine Pitrou wrote:
> > On Wed, 22 Apr 2020 08:34:56 +1000
> > Steven D'Aprano wrote:
> > > On Tue, Apr 21, 2020 at 12:09:44PM +0300, Serhiy Storchaka wrote:
> > > > 21.04.20 11:15, Antoine
22.04.20 08:11, Greg Ewing пише:
I don't this should be a guarantee, in this or any similar
situation. The only purpose for the value in a StopIteration
is to provide a return value for yield-from when the thing
being delegated to is a generator. If you're yielding from
something that's not a gen
22.04.20 11:20, Antoine Pitrou пише:
Ideally, that's what it would do. Whether it's desirable to transition
to that behaviour is an open question.
But, as far as I'm concerned, the number of times where I took
advantage of zip()'s current acceptance of heteregenously-sized inputs
is extremely s
On 22.04.20 06:43, Soni L. wrote:
On 2020-04-21 7:12 p.m., Steven D'Aprano wrote:
On Tue, Apr 21, 2020 at 05:33:24PM -0300, Soni L. wrote:
> 1. see the other thread (strict zip), especially the parts where
they > brought up the lack of peekable/unput iterators in the context
of > getting a
Alex Hall writes:
> OK, that's fair. What about `{foo::}`?
I don't like any of these, I'm just saying why, when I can. People
who are going to use the syntax should choose it.
> I would personally be quite happy if I could replace:
>
> ```
> class A:
> def __init__(self, foo, bar, sp
On Wed, Apr 22, 2020 at 10:52:44AM +0200, Dominik Vilsmeier wrote:
> You can basically use the code from this StackOverflow answer (code
> attached below) to cache the last object yielded by each iterator:
> https://stackoverflow.com/a/61126744
Caching the result of iterators is unsafe if the v
On Wed, Apr 22, 2020 at 01:43:10AM -0300, Soni L. wrote:
> are there *any* solutions for getting partial results out of zip with
> different-length iterators of unknown origin?
No. If you want to continue getting results even when one or more of
the iterators is exhausted, `zip` is the wrong to
On 22.04.20 11:19, Steven D'Aprano wrote:
On Wed, Apr 22, 2020 at 10:52:44AM +0200, Dominik Vilsmeier wrote:
You can basically use the code from this StackOverflow answer (code
attached below) to cache the last object yielded by each iterator:
https://stackoverflow.com/a/61126744
Caching the
On 2020-04-22 6:47 a.m., Steven D'Aprano wrote:
On Wed, Apr 22, 2020 at 01:43:10AM -0300, Soni L. wrote:
> are there *any* solutions for getting partial results out of zip with
> different-length iterators of unknown origin?
No. If you want to continue getting results even when one or more
On 2020-04-22 11:08 a.m., Soni L. wrote:
On 2020-04-22 6:47 a.m., Steven D'Aprano wrote:
On Wed, Apr 22, 2020 at 01:43:10AM -0300, Soni L. wrote:
> are there *any* solutions for getting partial results out of zip
with > different-length iterators of unknown origin?
No. If you want to co
Stephen J. Turnbull writes:
> _nameToLevel = { member.name : member for member in LogLevel }
Urk, premature expostulation there (not sure how it happened, I know I
fixed that line before sending...). Just
_nameToLevel = LogLevel.__members__
is fine here (LogLevel is an IntEnum, __members_
On Apr 22, 2020, at 01:52, Serhiy Storchaka wrote:
>
> 22.04.20 11:20, Antoine Pitrou пише:
>> Ideally, that's what it would do. Whether it's desirable to transition
>> to that behaviour is an open question.
>> But, as far as I'm concerned, the number of times where I took
>> advantage of zip()
On Wed, Apr 22, 2020, 4:24 AM Antoine Pitrou
> But, as far as I'm concerned, the number of times where I took
> advantage of zip()'s current acceptance of heteregenously-sized inputs
> is extremely small. In most of my uses of zip(), a size difference
> would have been a logic error that deserves
On Apr 21, 2020, at 19:35, Steven D'Aprano wrote:
>
> On Mon, Apr 20, 2020 at 07:47:51PM -0700, Andrew Barnert wrote:
>
counter = itertools.count()
yield from zip(counter, itertools.chain(headers, [''], body, [''])
lines = next(counter)
>>>
>>> That gives you one more than the n
On 21.04.2020 15:51, Chris Angelico wrote:
> On Tue, Apr 21, 2020 at 7:01 PM M.-A. Lemburg wrote:
>> Instead of keeping values in local variables, you store
>> them in the namespace object and because this knows about
>> its attributes you can do a lot more in terms of introspection
>> than what i
On Thu, Apr 23, 2020 at 6:18 AM M.-A. Lemburg wrote:
>
> On 21.04.2020 15:51, Chris Angelico wrote:
> > On Tue, Apr 21, 2020 at 7:01 PM M.-A. Lemburg wrote:
> >> Instead of keeping values in local variables, you store
> >> them in the namespace object and because this knows about
> >> its attribu
On 04/22/2020 07:08 AM, Soni L. wrote:
I have, more than once, had a desire to use zip to partially consume an
iterator from a set of iterators, and then pass the rest onto something else.
it'd fit in with that.
it's a small quality of life improvement that'd make zip even more useful than
i
> On Apr 21, 2020, at 16:02, Steven D'Aprano wrote:
>
> On Tue, Apr 21, 2020 at 12:25:06PM -0700, Andrew Barnert via Python-ideas
> wrote:
>>> On Apr 21, 2020, at 01:36, Serhiy Storchaka wrote:
>>> except ValueError: # assuming that’s the exception you want?
>> For what it’s worth, more_itert
On Wed, Apr 22, 2020 at 10:33:24AM -0700, Andrew Barnert via Python-ideas wrote:
> If that is your long-term goal, I think you could do it in three steps.
I think the first step is a PEP. This is not a small change that can be
just done on a whim.
> And of course after the first two steps you c
On 04/22/2020 02:03 PM, Steven D'Aprano wrote:
If they need to be *convinced* to use the new function, then they don't
really need it and didn't want it.
Sadly, it is not human nature to just accept that one needs something when they have been
getting along "just fine" without it.
--
~Ethan~
Forgive me if this idea has been discussed before, I searched the mailing
lists, the CPython repo, and the issue tracker and was unable to find anything.
I have found myself a few times in a position where I have a repeated argument
that uses the `append` action, along with some convenience argu
On Apr 22, 2020, at 15:04, [email protected] wrote:
>
> The natural extension to this filtering idea are convenience args that set
> two const values (eg: `--filter x --filter y` being equivalent to
> `--filter-x-y`), but there is no `extend_const` action to enable this.
>
> While this is po
On Wed, Apr 22, 2020 at 01:26:02PM -0700, Andrew Barnert wrote:
> > On Apr 21, 2020, at 16:02, Steven D'Aprano wrote:
> >
> > On Tue, Apr 21, 2020 at 12:25:06PM -0700, Andrew Barnert via Python-ideas
> > wrote:
> >>> On Apr 21, 2020, at 01:36, Serhiy Storchaka wrote:
> >>> except ValueError:
On Wed, Apr 22, 2020 at 01:43:10AM -0300, Soni L. wrote:
> I've
> recently posted my code on this list, something about a class
> LogAndCompare[1]. it's horrible. a bit of zip and it could be a bit
> nicer. but I need those partial results.
>
> [1]
> https://creationix.github.io/http-clone/?h
24 matches
Mail list logo
