On Tue, 21 Jun 2022 at 15:48, Brendan Barnwell wrote:
>
> On 2022-06-20 22:26, Chris Angelico wrote:
> > Okay, here's a compromise.
> >
> > Go and write a full and detailed specification of the Python-visible
> > semantics of deferred evaluation objects, including how they would be
> > used to imp
On 2022-06-20 22:26, Chris Angelico wrote:
Okay, here's a compromise.
Go and write a full and detailed specification of the Python-visible
semantics of deferred evaluation objects, including how they would be
used to implement late-bound argument defaults.
Go and actually do some real work on y
wt., 21 cze 2022 o 05:20 Steven D'Aprano napisał(a):
> The point is, Rob thought (and possibly still does, for all I know) that
> lazy evaluation is completely orthogonal to late-bound defaults. The PEP
> makes that claim too, even though it is not correct. With a couple of
> tweaks that we have
On Tue, 21 Jun 2022 at 13:17, Steven D'Aprano wrote:
>
> On Tue, Jun 21, 2022 at 12:13:08AM +1000, Chris Angelico wrote:
>
> > Nice analogy. It doesn't hold up.
> >
> > Consider this function:
> >
> > def f(stuff, max=>len(stuff)):
> > stuff.append(1)
> > print(max)
> >
> > f([1,2,3])
> >
On Tue, 21 Jun 2022 at 13:07, Steven D'Aprano wrote:
>
> On Tue, Jun 21, 2022 at 03:15:32AM +0100, Rob Cliffe wrote:
>
> > Why do people keep obscuring the discussion of a PEP which addresses
> > Problem A by throwing in discussion of the (unrelated) Problem B?
> > (Chris, and I, have stated, ad n
It seems like this is all an occasion to use itertools.tee() ... But with a
consciousness that implicit caching uses memory.
On Mon, Jun 20, 2022, 11:36 PM Steven D'Aprano wrote:
> On Sun, Jun 19, 2022 at 01:34:35AM +0100, Rob Cliffe via Python-ideas
> wrote:
>
> > To me, the natural implementat
On Sun, Jun 19, 2022 at 01:34:35AM +0100, Rob Cliffe via Python-ideas wrote:
> To me, the natural implementation of slicing on a non-reusable iterator
> (such as a generator) would be that you are not allowed to go backwards
> or even stand still:
> mygen[42]
> mygen[42]
> ValueError: El
On Tue, Jun 21, 2022 at 12:13:08AM +1000, Chris Angelico wrote:
> Nice analogy. It doesn't hold up.
>
> Consider this function:
>
> def f(stuff, max=>len(stuff)):
> stuff.append(1)
> print(max)
>
> f([1,2,3])
>
> How would you use lazy evaluation to *guarantee* the behaviour here?
By
On Tue, Jun 21, 2022 at 03:15:32AM +0100, Rob Cliffe wrote:
> Why do people keep obscuring the discussion of a PEP which addresses
> Problem A by throwing in discussion of the (unrelated) Problem B?
> (Chris, and I, have stated, ad nauseam, that these *are* unrelated
> problems.
Chris says:
"E
On 18/06/2022 15:51, Stephen J. Turnbull wrote:
> This raises another choice: should lazy defaults be evaluated before
> entering the body of the function, or at the point where the parameter
> is used? Which would be more useful?
Both are potentially useful.
Yes, both *ARE* potentially
On Tue, 21 Jun 2022 at 11:07, Rob Cliffe via Python-ideas
wrote:
>
>
>
> On 20/06/2022 17:39, Jeremiah Paige wrote:
>
> On Sat, Jun 18, 2022 at 5:42 PM Rob Cliffe via Python-ideas
> wrote:
>>
>> To me, the natural implementation of slicing on a non-reusable iterator
>> (such as a generator) woul
On 20/06/2022 17:39, Jeremiah Paige wrote:
On Sat, Jun 18, 2022 at 5:42 PM Rob Cliffe via Python-ideas
wrote:
To me, the natural implementation of slicing on a non-reusable
iterator
(such as a generator) would be that you are not allowed to go
backwards
or even stand stil
On Tue, 21 Jun 2022 at 10:13, Rob Cliffe via Python-ideas
wrote:
>
> On 19/06/2022 04:42, David Mertz, Ph.D. wrote:
>
> On Sat, Jun 18, 2022, 9:21 PM Rob Cliffe
>>
>> Sorry again, but IMO discussing any model except one where late-bound
>> defaults are evaluated at function call time is just addi
On 19/06/2022 04:42, David Mertz, Ph.D. wrote:
On Sat, Jun 18, 2022, 9:21 PM Rob Cliffe
Sorry again, but IMO discussing any model except one where
late-bound defaults are evaluated at function call time is just
adding FUD.
It's definitely rude to repeatedly state that anyone who's
On 19/06/2022 04:42, David Mertz, Ph.D. wrote:
On Sat, Jun 18, 2022, 9:21 PM Rob Cliffe
Sorry again, but IMO discussing any model except one where
late-bound defaults are evaluated at function call time is just
adding FUD.
It's definitely rude to repeatedly state that anyone who's
On 2022-06-20 03:34, Paul Moore wrote:
For the record, I think the islice solution is sufficient for this
case. But I have needed this sort of thing occasionally, and islice
The post above sums it up for me. We have next() for one to a few, islice for
several to zillions, and a for-enumera
On Mon, 20 Jun 2022 at 18:42, Steve Jorgensen wrote:
>
> Steven D'Aprano wrote:
> > Okay, I'm convinced.
> > If we need this feature (and I'm not convinced about that part), then it
> > makes sense to keep the star and write it as `spam, eggs, *... = items`.
>
> I thought about that, but to me, th
Steve Jorgensen wrote:
> Jonathan Slenders wrote:
> > Hi everyone,
> > Today was the 3rd time I came across a situation where it was needed to
> > retrieve all the positions of the line endings (or beginnings) in a very
> > long python string as efficiently as possible. First time, it was needed in
Jonathan Slenders wrote:
> Hi everyone,
> Today was the 3rd time I came across a situation where it was needed to
> retrieve all the positions of the line endings (or beginnings) in a very
> long python string as efficiently as possible. First time, it was needed in
> prompt_toolkit, where I spent
Steven D'Aprano wrote:
> Okay, I'm convinced.
> If we need this feature (and I'm not convinced about that part), then it
> makes sense to keep the star and write it as `spam, eggs, *... = items`.
I thought about that, but to me, there are several reasons to not do that and
to have the ellipsis m
On Tue, 21 Jun 2022 at 01:44, MRAB wrote:
>
> On 2022-06-20 15:05, Chris Angelico wrote:
> > On Mon, 20 Jun 2022 at 21:11, Jonathan Fine wrote:
> >>
> >> Hi
> >>
> >> Some have liked adding a new syntax
> >> a, b, ... = iterable
> >> to mean consume two items from the iterable. However,
> >>
On Sat, Jun 18, 2022 at 5:42 PM Rob Cliffe via Python-ideas <
python-ideas@python.org> wrote:
> To me, the natural implementation of slicing on a non-reusable iterator
> (such as a generator) would be that you are not allowed to go backwards
> or even stand still:
> mygen[42]
> mygen[42]
Chris Angelico wrote:
> On Mon, 20 Jun 2022 at 21:11, Mathew Elman mathew.el...@ocado.com wrote:
> > This I like - it seems very intuitive, almost like an irreversible io
> > stream.
> > I don't know if there would be cases where this would lead to unexpected
> > bugs, but without looking into it
On 2022-06-20 16:12, Christopher Barker wrote:
Hmm - I’m a bit confused about how you handle mixed / multiple line
endings. If you use splitlines(), then it will remove the line endings,
so if there are two-char line endings, then you’ll get off by one
errors, yes?
I would think you could loo
On 2022-06-20 15:05, Chris Angelico wrote:
On Mon, 20 Jun 2022 at 21:11, Jonathan Fine wrote:
Hi
Some have liked adding a new syntax
a, b, ... = iterable
to mean consume two items from the iterable. However,
a, b, Ellipsis = iterable
has a different meaning (at least in Python 3.8). It
Hmm - I’m a bit confused about how you handle mixed / multiple line
endings. If you use splitlines(), then it will remove the line endings, so
if there are two-char line endings, then you’ll get off by one errors, yes?
I would think you could look for “\n”, and get the correct answer ( with
extran
If you are working with bytes, then numpy could be perfect— not a small
dependency of course, but it should work, and work fast.
And a cython method would be quite easy to write, but of course
substantially harder to distribute :-(
-CHB
On Sun, Jun 19, 2022 at 5:30 PM Jonathan Slenders
wrote:
Hi
Some of us might believe that a currently legal syntax should only
exceptionally be given a new meaning, even if there is no evidence
whatsoever that this legal syntax is actually in use. My own belief is more
pragmatic. If there's very strong evidence that the syntax is not in use,
I'm happy t
On Mon, 20 Jun 2022 at 21:19, Steven D'Aprano wrote:
> > (4) The guarantee that a late-bound default WILL be executed at
> > function call time, can be useful, even essential (it could be
> > time-dependent or it could depend on the values - default or otherwise -
> > of other parameters whose
On Mon, 20 Jun 2022 at 21:11, Jonathan Fine wrote:
>
> Hi
>
> Some have liked adding a new syntax
> a, b, ... = iterable
> to mean consume two items from the iterable. However,
>a, b, Ellipsis = iterable
> has a different meaning (at least in Python 3.8). It redefines Ellipsis. (As
> an e
On Mon, 20 Jun 2022 at 21:11, Mathew Elman wrote:
>
> This I like - it seems very intuitive, almost like an irreversible io stream.
>
> I don't know if there would be cases where this would lead to unexpected
> bugs, but without looking into it it seems nice.
>
> Question: What would be the natur
On Sun, Jun 19, 2022 at 02:21:16AM +0100, Rob Cliffe via Python-ideas wrote:
> Sorry, but I think all this talk about lazy evaluation is a big red herring:
> (1) Python is not Haskell or Dask.
Python is not Haskell, but we stole list comprehensions and pattern
matching from it. Python steals
Hi
Some have liked adding a new syntax
a, b, ... = iterable
to mean consume two items from the iterable. However,
a, b, Ellipsis = iterable
has a different meaning (at least in Python 3.8). It redefines Ellipsis.
(As an explicit constant, '...' can be redefined.)
The syntax
a, b, ... = i
This I like - it seems very intuitive, almost like an irreversible io stream.
I don't know if there would be cases where this would lead to unexpected bugs,
but without looking into it it seems nice.
Question: What would be the natural behaviour for negative indices? Raising an
error?
On Mon, 20 Jun 2022 at 11:08, Steven D'Aprano wrote:
> But that's basically islice. So:
>
> # Its okay to put reusable helper functions in a module.
> # Not everything has to be syntax.
> first, second, third = itertools.islice(items, 3)
>
> I think that we have a working solution for
On Sun, Jun 19, 2022 at 11:03:45PM -0700, Jeremiah Paige wrote:
> What if next grew a new argument? Changing the signature of a builtin is a
> big change, but surely not bigger than new syntax? If we could ask for the
> number of items returned the original example might look like
>
> >>> first,
Some background. PEP 3132 (https://peps.python.org/pep-3132/) lists the
following:
>
> Possible changes discussed were:
>
>
>- Only allow a starred expression as the last item in the exprlist.
>This would simplify the unpacking code a bit and allow for the starred
>expression to be assi
@Chris
My bottom line, as I wrote before, is that even if this were
introduced, I probably will continue to default to
def foo(arg=None):
if arg is None:
arg = default
in my own code until I start seeing "def foo(arg=>default)" in a lot
of code I read. Since Mailman gene
38 matches
Mail list logo
